In September, a software engineer at Binance (Binance's report calls him Engineer B) was contacted on a legitimate job site by someone claiming to be a project director at another company. His profile on that site mentioned that he worked at Binance.

There were two interviews. The first was a live video call with someone posing as HR, who shared a social media account full of personal photos and videos to make it all feel real. The second was over a popular chat app with someone posing as the company's CEO. At the end, he was asked to download a coding assignment onto his work laptop.

The assignment had malicious code that ran as soon as he set it up. It replaced a normal developer tool on his Mac with a copy that took commands from a server the attackers controlled. Binance says its endpoint security didn't catch it.

On October 29, about $6.34 billion in crypto was taken from Binance's hot wallets, the online wallets the exchange uses to process withdrawals. It's the largest crypto theft on record. The FBI says North Korea did it, and North Korea denies it. Binance says it is covering the full loss and customers won't lose anything.

Most coverage stops at the fake interview. I think that's the least interesting part. People will always click on things. What I want to understand is how one infected laptop turned into billions of dollars leaving the company.

Binance published its own incident report on November 3, and it's worth reading in full. Here's the path in order. Three different engineers were involved, and I'll call them A, B and C, the same way Binance does. The one from the fake interview is Engineer B. Engineer A was hit separately, months earlier.

Here's what happened next, according to Binance:

The short version: fake interview, then Engineer B's laptop, then the internal AI tool, then Engineer A's and C's laptops, then the deployment token, then a container inside the wallet environment, then the signing service, then hot wallets on ten blockchains.

This is the part I think matters most. In its early findings, Binance said it found no evidence that any wallet private key was leaked.

So the attackers didn't steal an admin password, and they didn't steal the keys to the wallets. They didn't have to. Binance's systems already trusted the things they took over, and once they were inside, Binance's own signing service did what it was asked.

That's why I don't think the lesson here is "train your people better." Training matters, but someone will always click. The real question for any company is what one compromised laptop can reach. At Binance, the answer was the money. When I went through the report, I counted four places where access was left open.

An internal AI tool that could control other people's computers. The attackers used it to get from one engineer's laptop to two others. A tool that can do that has a lot of access, and it should be managed like any other account with that much access. Binance says it has rebuilt the tool and tightened its access controls.

A deployment token that kept coming back. After the June incident, Binance replaced Engineer A's laptop and rotated his credentials. Four months later, his laptop again had a token that could deploy into the wallet environment. Rotating credentials gets rid of the old ones, but the access itself was still always there. That token also worked from Engineer C's computer, which tells me it wasn't tied to a specific person or device. Anyone who had it could use it.

A container that was trusted because of where it was running. Once the attackers' container was running inside the wallet environment, it could talk to the signing service.

A signing service that signed what it was asked to sign. This is where the money actually left. The service signed large transfers to the attackers' addresses on ten blockchains, outside the normal withdrawal process. It also signed the Ethereum delegation that gave the attackers' contract control of a wallet. According to Phoenix Security's write-up of a video update from co-CEO Richard Teng, that delegation did not go through Binance's normal approval controls. Binance now says it is reviewing the scope of its signing policy and its hot wallet controls.

Experts quoted by Cointelegraph point out that the controls that limit damage in a case like this sit before anything gets signed: limits on transaction size, a list of approved withdrawal addresses, and extra approval for anything unusual. There's one more gap worth naming. The alert worked, but it didn't stop anything. Bitcoin kept leaving after it went off.

Teng told CNBC the attackers "spent months building their way in," and he pushed back on the idea that one laptop caused all of this. I agree with him, it wasn't one laptop. But that supports my point. Patient attackers will eventually get a foothold somewhere. How much they walk away with depends on how much access is sitting around once they're in.

More companies are putting AI tools inside their environments and connecting them to employee laptops and code. At Binance, one of those tools is how the attackers moved between computers.

The fake recruiter approach isn't new either. Binance says it detected and stopped 57 suspected North Korea-linked attempts since the start of 2026, including fake interviews, malware disguised as developer tools and fake video-call apps. Chainalysis has tied more than $14.3 million in smaller thefts over the past 18 months to the same playbook.

Before this, the biggest crypto theft was the $1.5 billion Bybit hack in February 2025, which the FBI also blamed on North Korea's TraderTraitor group. This one is more than four times bigger. Bloomberg Law reported that Binance hasn't been able to get cyber insurance, and on November 5 Reuters reported that US bank regulators had started checking banks for similar weaknesses.

I'd start with three things.

Most deployment tokens I see in the field work like a house key. Whoever has it can use it, from any machine, for months. That's exactly what makes them so valuable to an attacker.

Here's how I'd set it up instead. When an engineer needs to deploy, they sign in with their own identity and MFA. The system then issues a token that lasts minutes, not months, and only covers the one environment they're working in. Deployments to production go through the pipeline, which has its own workload identity, instead of a token sitting on someone's laptop. For the most sensitive systems, a second person approves the request before the token is issued. Where you can, bind the token to the device that asked for it (standards like DPoP and mutual TLS do this), so a copied token doesn't work anywhere else.

So what happens when someone gets hold of one? A token that expired ten minutes ago is worthless. A token bound to one engineer's laptop doesn't work from a coworker's. A token scoped to a test environment can't touch production. And because every token was issued to a named person for a specific request, one being used from the wrong place shows up in the logs right away. Rotating credentials after an incident is good hygiene, but it only replaces the key. With this setup, there's no standing key to steal in the first place.

A lot of internal AI tools run on a shared service account, or they borrow the access of whoever is using them. Either way, you can't tell what the tool did versus what a person did, and you can't control the tool on its own.

Giving the tool its own identity, the same way you would a new employee, fixes that in a few ways:

At Binance, an internal AI tool was the bridge from one engineer's laptop to two others. A tool whose identity only allowed it to do its actual job would have been a much harder bridge to cross.

A lot of internal systems still trust a request because of where it comes from. If it comes from inside the network or from an approved server, it gets through. That's how one compromised piece of the environment ends up reaching everything else.

Instead, every request to a sensitive system should carry an identity, whether that's a person, a service or an AI tool, and the system should check right then whether that identity is allowed to do that specific thing. Not just "can this service talk to the customer database," but "can it export ten million records at 3 a.m." Keep those rules in one central policy, where your security team can see and change them, instead of buried in each application's code.

This is what helps when an attacker is already inside. Being inside isn't enough anymore. They still have to get past a check that looks at who they are and what they're asking for, and anything unusual gets denied or held until a person approves it.

Think about one engineer at your company. If their laptop was taken over tonight, what's the worst thing an attacker could get your systems to do without stealing a single password? I'd like to hear your honest answer.

Identity Decoded publishes every week at identity-decoded.com