Stealing $6.3B
without entering
the building
Every step, from the first infected laptop to the last transfer, was done remotely.
Cash taken from Iraq’s central bank
on Saddam Hussein’s orders.
Stolen from Binance by an attacker
working entirely remotely.
If your company moves large sums, through a payments system, a treasury team or a transaction signing service, Binance’s report on its 29 October hack describes the attack you are most likely to face. That evening an attacker moved about $6.34 billion out of the wallets Binance keeps online to pay out withdrawals on multiple blockchains. Setting aside that it was cryptocurrency, it is the largest known financial theft in history, ahead of the roughly $1 billion Saddam Hussein took from Iraq’s central bank in 2003.
Binance published its initial report on 3 November. Early reports blamed a single compromised laptop. The report describes a campaign that ran for five months and passed through three engineers’ computers before any funds were stolen. And almost none of it depended on cryptocurrency: the attacker got in through developer laptops, stolen access tokens and a software deployment, the same way they could have reached any company’s payment systems.
How the attacker reached the signer
- ENGINEER A
In June, Engineer A on Binance’s wallet infrastructure team installed a tampered copy of Homebrew, a common tool for installing software on Macs, while looking for an AI coding tool. Binance detected it, replaced his computer and changed his passwords and access keys. But the attacker had already learned who A was and who he worked with.
- ENGINEER B
In September, Software Engineer B was approached on a job platform by someone posing as a project director. After two interviews, one by video and one in a chat app, B downloaded a coding assignment onto his work computer. It installed malware that Binance’s security software did not detect.
- A, B & C
On 20 October the attacker used B’s computer and an internal AI tool to take control of A’s computer and that of a third engineer, C. A’s computer held an access token that let him deploy new software to Binance’s systems.
- 17:15–19:56 UTC
On 29 October, between 17:15 and 19:56 UTC, the attacker logged onto C’s computer and used A’s stolen token to deploy a malicious program onto Binance’s systems. It reached Binance’s wallet signing service, the system that approves payments out of Binance’s wallets.
Deployment from Engineer C’s computer
What the signer signed
From 20:05 UTC the signing service approved the attacker’s transfers, bypassing Binance’s normal withdrawal checks. Over the next few hours it sent funds from wallets on several blockchains to accounts the attacker controlled, including 18,270 bitcoin.
On one wallet, Binance 14, the attacker did something more lasting. They had the signer hand control of the wallet itself to a program the attacker had written. This handover is called a delegation. According to the security firm Hypernative, the program emptied the wallet in a single transaction a few minutes later. After that, the attacker no longer needed Binance’s systems, so suspending withdrawals and shutting down Binance’s wallet services did not stop them. The last transfer finalised at 23:56 UTC, and Binance cancelled the delegation at 00:10 UTC on 30 October.
Changing passwords and keys wouldn’t have helped
The usual first step after a breach is to change every password and key that was exposed. Here that would not have stopped the theft. Changing passwords and access tokens would not have cancelled the delegation. Binance had to revoke it explicitly. To cancel it, Binance had to sign a new instruction from the wallet. The wallet’s key is split across several machines, so no single key could sign that instruction quickly. Binance had to work out how to do it, which took close to four hours.
Why the controls failed together
Binance’s security programme did its job in several places. It caught Engineer A’s compromised machine in June. Binance says it stopped 57 suspected North Korea-linked attempts this year. An internal alert fired on the first transfers within minutes.
Every one of those controls runs on Binance’s own computers and network. So do the passwords and tokens, the rules that decide which payments are allowed, the systems that flag unusual activity, and any location check based on IP address. Once the attacker was on C’s computer, the chance of beating each of them rose at the same time. That one machine gave the attacker A’s token, a Binance IP address, access to internal systems and a path to the signer.
A check that needs a specific person’s phone to physically prove it is at an approved place is different. Taking over more of the network does not help an attacker pass the location check, because nothing on the network controls where that phone is. At Octet, we call this proof of location. To approve an action, a specific person uses their own enrolled phone, at an approved site, to approve that one action. An approved site can be an office or an employee’s registered home, so people who work from home can still approve. The phone produces a proof of where it is, signed with a key held in the phone’s secure hardware, and anyone can check that proof without trusting the company’s own records.
Consider this applied to Binance. Taking over C’s computer, or every computer Binance owns, does not move A’s phone. To pass the check, the attacker needed A’s phone, in A’s hands, at one of A’s approved sites. Nothing the attacker did in five months of remote work got them closer to that.
Proposed control
Every consequential action needs a phone, on site.
Every step of the attack was done remotely, through computers the attacker controlled. Under the proposed control, any consequential action, on those computers or anywhere else, needs approval on the responsible engineer’s enrolled phone, with fresh proof that the phone is at an approved site. The attacker controlled the computers but never had the phones.
- Take control of Engineer A’s and C’s computers20 OctoberAllowedNo approval needed
- Use Engineer A’s stolen token from C’s computer29 OctoberAllowedNo approval needed
- Deploy new software to the signing service29 OctoberAllowedNo approval needed
About $6.34 billion leaves Binance’s wallets.
- Take control of Engineer A’s and C’s computers20 OctoberStill possibleMalware doesn’t ask for approval
- Use Engineer A’s stolen token from C’s computer29 OctoberBlockedNot approved from a phone proven on site
- Deploy new software to the signing service29 OctoberBlockedNot approved from a phone proven on site
The signing service is not changed.
The attacker could still take over the computers. Requiring on-site phone approval to use the token or to deploy would have stopped the attack, because each needed a phone the attacker never held, at a site the attacker never entered.
The phone proves it is inside the boundary.
An approved site can be an office or an employee’s registered home.
- 1Define the boundaryThe approved area follows the building.
- 2Locate the enrolled phoneThe phone supplies a signed proof.
- 3Verify presenceThe proof places the phone inside.
Engineer A must still approve the specific deployment on the phone.
The obvious objection is that an attacker who can take over a laptop can take over a phone too. They can, but it is a separate and harder job. It takes a working exploit for a current iPhone or Android phone, which is rare and expensive. Even then, the phone has to be at an approved site when the request arrives. The key in the phone’s secure hardware can be set to require the approver’s face or fingerprint for each approval. Apple puts the chance that a random person can pass Face ID at about one in a million. To get an approval through, the attacker needs three things to line up in the same place at the same moment: the enrolled phone, the approver’s face or fingerprint, and an approved site, all at the second the request arrives. A compromised phone in the wrong place fails. So does the right phone in the right place without the approver. Each of these is a separate problem.
Proof of location is a primitive: one check that can sit wherever a team already makes these decisions. Octet offers it two ways. Location Factor Authentication (LFA) adds it to an existing sign-in, so logging in or opening a privileged session requires a fresh proof. Octet’s mobile SDK puts it inside the apps teams already use to approve or send funds, so the proof is requested at the moment of approval.
Where proof of location would have stopped the theft
At the deploy. Suppose deploying new software to the signing service required a fresh proof from the phone of the engineer whose token is being used, at one of that engineer’s approved sites, tied to that specific deployment. The attacker was using A’s token from C’s computer. Without that proof and approval, the deployment would fail between 17:15 and 19:56, before the first transfer.
At the signer. Suppose the signing service held any transfer above a set size, and any change to who controls a wallet, until two approvers released it. Each uses their own phone, at an approved site, to approve that exact transfer, so the proof can’t be reused for a different one. That rule covers every transfer in this attack, including the handover of Binance 14, because all of them went through the signer.
With two approvers in two places, the attacker has to defeat two separate people, phones and locations. The verifier must enforce both approvals on a path the attacker cannot bypass.
Where proof of location wouldn’t have helped
- It does not stop the compromise of the engineers’ computers. That is the job of security software on the computers, and it failed first.
- It does not stop a deceived approver. Someone on site who approves a request the malware created produces a valid proof. The phone has to show what is being signed, and the approver has to read it.
- It does not help against an insider, coercion, or an attacker who controls an approver’s phone while the approver is on site.
- It does not cover automated payments below the size limit set at the signer.
- It does nothing after a transfer or handover has been signed. It only works as a check before signing.
The question to ask about your stack
The attacker did all of this from machines they had taken over. If you sign transactions or send large payments, check whether any step in that process can only be done by a specific person at an approved place, such as an engineer approving from their own phone at their office or home. If every step can be done from any computer with the right passwords and tokens, an attacker who gets far enough into your network can sign the transactions or send the payments themselves.
Sources. Binance’s preliminary findings, 3 November 2026; Hypernative’s on-chain analysis; CNN’s reporting on Iraq’s central bank, 6 May 2003. All times are UTC. The location checks described here are proposed controls, not controls known to have been deployed at Binance.
Visuals. Loading footage: digitally altered, the people shown had no part in the theft. The geofence is illustrative and does not mark a known Binance office.