On 29 October 2026, Binance’s own signing service signed away about $6.34 billion from wallets on 10 blockchains. Most of it left in about 20 minutes. Nobody stole a key. The attacker spent five months working on the people who run Binance’s wallets, placed a container next to the signing service and asked it to sign. On Ethereum, one of those signatures was something other than a transfer. It gave an attacker’s contract standing control of a hot wallet. That control survived every switch Binance pulled for close to four hours.
This is the third post in a series about how signing fails. At Bitget, the signer trusted the host that spoke to it. At NEAR Intents, the signer trusted a ledger that had been corrupted. At Binance, the signer trusted the workload that asked it to sign. It then signed a payload it did not understand.
Binance is the victim of a crime. It has also been more open than most victims. This analysis is about controls rather than people. Claims from Binance, from the FBI or from the chain are marked as confirmed. Claims from analysts or the press are marked as reported. When we read something into Binance’s words that Binance itself has not said, we say so.
What happened
Binance runs hot wallets on every chain it supports. A hot wallet is an online wallet that pays customer withdrawals automatically. Every row in the table below is confirmed.
| When (UTC) | Event |
|---|---|
| June | A wallet team engineer installs a tampered developer tool. It is detected, the device is replaced and credentials are rotated. The attacker now knows who works on the wallet team |
| September | A second engineer is recruited by a fictitious company. A coding assignment carrying zero day malware runs on his work computer |
| 20 Oct | Through an internal AI tool, the attacker takes control of two more wallet engineers’ machines and finds a container deployment token |
| 29 Oct, 17:15 to 19:56 (zone not stated by Binance) | With the stolen token, the attacker deploys a container and runs a script against the wallet signing service |
| 29 Oct, 20:05 to 20:10 | Five XRP Ledger wallets send 233.46 million XRP. Solana and Optimism follow. Binance receives an internal alert and begins investigating |
| 29 Oct, 20:20 | 18,270 BTC leave in a single transaction. Tron follows within two minutes |
| 29 Oct, 20:20:59 | One transaction carries 50 EIP-7702 authorizations signed by the wallet known as Binance 14. One takes effect |
| 29 Oct, 20:24 | A single call sweeps 167,464 ETH and 63 tokens |
| 29 Oct, 20:41 to 23:56 | 823 million USDC leaves a smart account the wallet owned. Four more sweeps follow as deposits land. Issuers freeze about $2.67 billion from 21:01 |
| 30 Oct, 00:10 | Binance clears the delegation with an authorization to the zero address |
| 31 Oct | The FBI attributes the theft to North Korea |
| 1 Nov onwards | Withdrawals resume in phases: 15 networks and assets on 1 Nov, further batches on 3 Nov and from 5 Nov, with the remaining tokens targeted for the following week. Binance publishes its initial findings on 3 Nov |
Ethereum accounts for about $3.79 billion of the loss. Bitcoin accounts for $1.47 billion, Tron for $628 million, XRP for $296 million, Solana for $96 million and five other chains for the rest. Binance puts the frozen or intercepted total at $2.85 billion. At 00:30 UTC on 30 October, TRM counted more than 420,000 ETH and 18,270 BTC in the attacker’s hands, about $2.4 billion that no issuer can freeze. Elliptic’s count on 6 November put about $3.1 billion across all chains in addresses linked to the theft, most of it still in ETH and bitcoin, and by 7 November the attacker had bought about 2,300 more BTC with stolen altcoins. A negligible amount has been cashed out. USDT and USDC can be frozen because their contracts give Tether and Circle a blacklist function that blocks transfers from an address. ETH and BTC are native assets with no issuer and no such function. By 4 November, Binance said it had replenished about 98% of the affected tokens from its own reserves and was still buying the rest. Its full post-incident report and an independent review are still pending. Pyongyang denies the FBI’s attribution.
How it worked
The attack is best understood as seven steps. Three were aimed at people. Two were aimed at a system. The last two are what followed once the signatures existed: Binance’s containment and the attacker’s race against the freezes.
Reconnaissance by supply chain. In June, a wallet DevOps engineer searched for an AI coding tool and installed a tampered copy of Homebrew, the package manager for Macs, from a malicious advertisement. Binance caught the infection and cleaned the device. By its own account, though, the engineer’s role and the names of his colleagues on the wallet infrastructure team were now known to the attacker. This is confirmed.
A recruitment lure. In September, a second engineer whose public profile mentioned Binance was approached on a job platform by a fictitious project director. He was interviewed twice and asked to complete a coding assignment on his work computer. The repository he downloaded replaced a development tool component with a malicious one, called a server the attacker controlled and erased its own traces. Binance says the malware was a zero day, meaning a flaw nobody yet knew about, so its endpoint protection tools did not detect it at the time. Confirmed.
Lateral movement into production. On 20 October, the attacker used that machine and an internal AI tool to take control of two more wallet engineers’ computers, including the one belonging to the engineer from June. On one of them, the attacker found a container deployment token, the credential that lets someone launch software into a production environment. Binance has not said what the AI tool is. Nine days later, the attacker logged into the third engineer’s computer, used the token to deploy a container and ran a script against the wallet signing service. Confirmed.
The service signed. Binance describes the attacker using unauthorized access to an internal wallet signing service to initiate transactions outside the normal withdrawal process. Wallets on nine chains, plus a second Ethereum wallet, signed ordinary transfers to fresh addresses. Those wallets use different chains, different key types and different signing schemes. All of them produced valid signatures for the attacker within about half an hour. Confirmed onchain.
A signature that was not a transfer. This step needs a short explanation. EIP-7702 is an Ethereum feature that lets an ordinary account hand its behaviour to a smart contract by signing an authorization. The authorization names a delegate contract, a chain, and one specific value of the account’s nonce, the counter that orders its transactions. A chain id of zero makes it valid on every chain where that nonce matches. The attacker’s transaction carried 50 authorizations signed by Binance 14 for fifty consecutive nonces. Binance says the fifty were submitted to manipulate the account nonce and establish the delegation. Analysts read them as a window: the wallet was still paying customers and moving its counter forward, so the attacker could not know which nonce would be current and signed fifty. One matched. Three minutes later, a single call moved 167,464 ETH and 63 tokens, including 1.615 billion USDT. A delegation inherits every permission the address holds on other contracts. That is why 823 million USDC also left a smart account the wallet owned, and why the attacker’s sweeper emptied the wallet four more times as new deposits kept arriving. Confirmed.
Containment hit its ceiling. Binance explains that because the hot wallet used multi-party computation, there was no single private key that could immediately revoke the malicious authorizations. The team had to design and carry out a special procedure to do so. Suspending withdrawals and shutting down hot wallet services did nothing to an authorization that was already onchain. The revocation came 3 hours and 49 minutes after the delegation. Confirmed.
One thing the zero-address authorization did not do. It ended the delegation in force, but it did not consume the authorizations the attacker still held for the nonces above the one that matched. The protocol skips an authorization whose nonce does not match and leaves it intact, an authorization carries no expiry, and each one becomes valid the moment the wallet’s counter reaches its nonce. The revocation itself, being an authorization at the wallet’s current nonce, moved that counter forward. Until Binance 14’s counter passed the last of the fifty or the address was retired, anyone holding those signatures could delegate the wallet again by paying the gas. Binance has not said whether the remaining nonces were burned or the address retired. This reading is ours.
The race against the freezes. About 325 million USDT went through UniswapX and other intent-based contracts in exchange for about 122,300 ETH. The amounts and the route are onchain. TRM identifies the counterparties as professional fillers and market makers and puts the discount at more than 10% against the market price of ETH at the time. Over the following week came a peel chain for the Bitcoin and cross-chain swaps, and TRM reports the first over-the-counter broker activity. Amounts and route confirmed onchain. Counterparties, discount and brokers are TRM’s analysis.
Reading Binance’s statements
Binance has published more than most victims. Its words deserve a careful reading. The readings below are ours. Binance has not made them.
“No evidence of any wallet private key leak.” This is true. It is also beside the point. The keys never needed to leak, because the signer signed. We read the sentence as written to prevent a panic about key rotation, which would have been the wrong response.
Binance says the attacker worked outside the normal withdrawal process. We read that to mean the controls lived in the withdrawal process rather than at the signer. Anything that reached the signer by another route was signed. Binance has not said what the signer checked. We think the answer is the identity of the caller.
In Binance’s own account, the internal alert sits between the XRP leg and the 18,270 BTC, with no time attached, followed by the start of an investigation. Detection worked. Most of the money left afterwards.
Binance notes that suspending withdrawals alone could not stop all unauthorized movements. The switch was built for customer flows. The attacker was not a customer. Bitget hit the same wall five weeks earlier.
Binance explains the four-hour delay by the absence of a single private key that could revoke the authorizations. We read it differently. The attacker’s script obtained signatures on arbitrary payloads from the same service in seconds, so the signing path was entirely capable of producing a revocation. MPC did not slow the attacker down. What Binance lacked was a revocation procedure built and tested before it was needed. The special procedure it describes reads as an emergency ceremony designed during the incident, on a signing path the attacker had just used. Four hours is what that costs.
The dimensions of the failure
Key management and signing architecture. The signing service signed for a trusted workload, whatever the payload, on whatever chain. Nothing public shows a check on the authority behind a request, a rule on the type of payload or a quorum on the warm tier. Binance describes one internal wallet signing service and one script, and wallets on ten chains signed within about half an hour, so we read one compromise as having become ten.
Infrastructure security. Binance’s deployment access does not appear to have been standing. The attacker found a deployment token on 20 October and used it nine days later, which reads as an attacker with persistent control of an engineer’s machine, waiting for the window in which that engineer could deploy to production. Short-lived credentials narrow that window. They do not close it when the attacker already controls the machine that receives them. The workload that landed in that window reached the signing service and was served. No deployment approval is described, and the signer asked nothing of the workload beyond the fact that it could reach it.
Application security. The service produced valid signatures over EIP-7702 authorization digests for the same script that was obtaining transfers. An authorization is signed over a different preimage from a transaction, so the service either signs raw digests on request or has a path for authorizations with no rule against them. Binance has not said which. Either way, nothing refused a payload type that turns a single signature into standing control. The hot wallet was also the sole owner of a smart account holding 823 million USDC, so one delegation reached both.
Identity and corporate security. The perimeter was the wallet team. A tampered installer, a fake recruiter, a zero day on a work machine and an internal AI tool that could act on colleagues’ machines. Binance says its security team detected and prevented 57 suspected North Korea-linked cases during 2026. The June incident was closed as an endpoint event. We read it as the first move against the team.
Policy and governance. No allowlist bound hot wallet destinations, so every chain paid a fresh address. No cap or velocity rule stopped 18,270 BTC in one transaction. No quorum stood between a request and a signature. Fifty authorizations for consecutive nonces raised nothing. A signing service without policy is a signing oracle.
Detection and response. The alert came within minutes. Most of the money left afterwards. The response hit the withdrawal switch, which did nothing to the attacker’s path. The delegation stood for close to four hours while the procedure to revoke it was built live. Containment is now an onchain action. It needs its own rehearsed ceremony. Tracing and freezing, on the other hand, worked. Issuers froze funds within 37 minutes of the sweep.
GRC and process. Binance had the right threat model, 57 blocked cases and endpoint protection that a zero day defeated.
What would have caught this: a review asking what the signing service verifies and whether it signs payloads other than transfers, an inventory of every machine from which a production deployment can be launched, and a tabletop exercise for a delegated hot wallet with the revocation timed.
What to do about it
In order of impact.
- Make the signer verify authority rather than origin. Require a client-controlled signature over the request and a proof bound to the destination, the asset, the amount and the payload type. Reject anything a workload merely asserts.
- Treat every signature kind as a transfer until proven otherwise. Deny delegation by default. Where an EIP-7702 authorization is needed, isolate it on a dedicated key behind approval, with the delegate contract and the chain allowlisted.
- Put the owner keys of smart accounts behind approval rather than behind an allowlist alone. Decode the transaction data before signing.
- Segregate signing by chain and by tier, so that one compromise cannot reach ten chains.
- Rehearse the onchain emergency. Decide in advance who decides, which quorum signs the policy change, which funded wallet carries the revocation and where funds sweep. Then time it.
- Put allowlists, caps and velocity rules on operational wallets, including internal moves. Many signatures requested over consecutive nonces is a sign of compromise.
- Bind deployment to identity and approval rather than to a session. Short-lived credentials are necessary and were not enough here. Require a second approval for any deployment that can reach a signer, run signed images only and make workloads authenticate to signers with an identity rather than with reachability.
- Threat model the team as well as the system. Scope AI tools and agents as privileged identities, run fake interview drills and treat a remediated endpoint incident on a wallet engineer as the first move rather than the last.
How DFNS approaches it
DFNS is a core banking platform for digital assets. Signing is one of many components we provide. For each control below, we state which deployment model it holds in.
Key management and signing architecture. A key on DFNS may be an MPC threshold key, where no machine or operator ever holds a usable key, or a single key held in an HSM the client controls. The model below holds for both, because it does not depend on where the key lives. It depends on what must be true before any signer will use it. A DFNS signer takes part in a signature only after two things have been verified.
- The first is a User Action Signature, made on the user’s own device with a passkey or with an API signing key the client holds, and checked by the authentication service.
- The second is a signing integrity proof from the Governance Engine. The engine keeps its own tamper-evident record of every credential, permission, policy and approval in the organization, and it checks that record for integrity continuously rather than trusting the platform’s database. Before any signature, it independently re-verifies the user action signature, confirms that the credential is registered and the user holds the permission, confirms that the policy in force was approved by the required quorum, and checks the amount, asset, source, destination and time against that governed history. Only then does it issue a proof over the digest of the exact payload to be signed. The signer will not participate without that proof. We described how the engine verifies the platform’s own integrity in our Governance Engine post. At Binance, the equivalent question was never asked. A workload reached the signer and the signer signed.
In the DFNS hosted model, this is an integrity check. In hybrid and on-premises deployments, the client runs the signers and the Governance Engine, and the same verification becomes a veto that holds even if the DFNS control plane is compromised. Where Binance ran one signing service for ten chains, DFNS can orchestrate keys across diverse key stores. A client can register one key store for one chain and another for the next, or separate stores by tier, so a compromise of one store does not reach ten chains.
Infrastructure security. Hosted signers run in hardware-attested AWS Nitro Enclaves and receive their key shares only when the running build matches the approved one. Signers run signed images only, and human access to the control plane is brokered just in time under dual approval. Where a client runs its own signers, in a hybrid or on-premises deployment or against an HSM it controls, the enclave is defence in depth and the checks that follow do not depend on it. A workload that reaches a signer is not served simply because it can reach it. It needs an authorized mutual TLS identity, the full key record, the signing integrity proof and, in hybrid and on-premises deployments where it is configured, an approval from the Validation Gate, a service the client operates that sees the full transaction, the key identifier and the payload digest before every signature and fails closed. A container deployed in a stolen window has none of these.
Application security. Every signature kind is a governed operation on DFNS, whether it is a transfer, a serialized transaction, a typed message, a raw digest or an EIP-7702 authorization. The Policy Engine’s allowlist, amount and velocity rules fail closed on any payload they cannot read, and a rule that triggers on every request routes all of them to approval. Fee-sponsored EVM transfers on DFNS are the one place delegation happens by design: the first time a wallet is sponsored, the sending wallet signs an EIP-7702 authorization to DFNS’s published and independently audited smart account contract, later sponsored transfers from that wallet carry no authorization at all, and a wallet found pointing anywhere else is refused. A client that needs delegation gets it on a dedicated key behind approval and, where it runs its own signers, with the delegate allowlist and the chain rule enforced in its Validation Gate. Two things are worth stating plainly about how this works today. The Policy Engine cannot yet filter by payload type, so the rule “approve transfers, block delegations” is expressed through fail-closed rules and approval on every request until expression-based filters ship (contact product@dfns.co for more information on our roadmap). The DFNS smart account contract is also deliberately minimal and has no pause switch, because a switch is a target too. When a new version ships, each delegated account is re-pointed inside its next transfer.
Identity and corporate security. Every action is signed on the user’s device. A service account is a registered public key plus a token. The token alone cannot write. If the key lives in a KMS, as our documentation describes, a compromised laptop yields nothing. If the key lives on the laptop, the attacker is that service account until an administrator deactivates it, which is immediate. In the meantime, the IP allowlist, the account’s permissions and the policies on its keys bound what it can do. AI at DFNS is a productivity tool rather than a component of any signing or policy path. No AI tool has commit access to production. No model takes part in signing or policy decisions. Agents are inventoried, their credentials are governed and they have no path to production.
Policy and governance. The platform provides recipient allowlists, amount limits, velocity limits by count and by amount per source wallet and approval quorums held on separate devices. Changes to policies and permissions sit behind approval groups that exclude the person who initiated them by default. A transaction to a smart account the client owns is evaluated on its destination, the smart account itself. That is why DFNS recommends approval on the owner key rather than an allowlist alone, with the transaction data decoded in the Validation Gate where the client runs one.
Detection and response. Revocation under MPC is a signing request like any other. One authorization to the zero address, carried in a type 4 transaction from any funded wallet, can be built, signed and broadcast through DFNS in seconds. The clock is the procedure around it, which means detection, decision, the policy change under its quorum and broadcast. A client with a rehearsed runbook can revoke within minutes, and DFNS will run that drill with clients on sandbox on request. Velocity rules and webhooks on every signature request and policy trigger feed the client’s own monitoring. A burst like Binance’s fifty authorizations is refused by a fail-closed policy at the first request, and every attempt shows up in the audit log. One more point of precision. A key refresh re-randomizes the shares of the same key. That defeats the theft of shares and nothing else. It does not undo a delegation already onchain, an approval, a permit or anything pre-signed over future nonces. After a compromise, the right order is to revoke credentials, lock down policies, revoke onchain permissions, move funds to fresh wallets and only then refresh keys.
GRC and process. DFNS holds SOC 2 Type I and II and ISO 27001, 27017 and 27018. Every user-action-signed event is stored in an audit log with the credential’s public key and signature, which the client can verify.
Dangers, limits and nuances
Everything in this section applies to any provider, whatever its architecture.
What no provider prevents. A valid credential in the wrong hands signs. If a service account key sits on a laptop instead of in a KMS, the attacker is that service account within its permissions. If an approver approves without reading, the quorum is met. Binance’s attacker spent five months on people before touching a system. No platform makes a wallet team unphishable.
Where responsibility sits with the client. Every control a provider offers is configuration. Allowlists never set, a delegation signature left on a shared key without approval, a smart account owner on an allowlist alone, deployment access from machines the attacker already controls, a runbook never rehearsed. Each of these reproduces part of what failed at Binance.
Where every hosted model has residual risk. When policy evaluation and proof generation run in the provider’s own infrastructure, the proof that a signature was authorized is an integrity check performed by the provider rather than an independent veto held by the client. Hosted key stores also share an orchestration layer. The failure mode is a compromise that reaches both the API tier and the proof producer. The cryptographic guarantee that a provider alone can never sign comes only from deployments where the client runs the signers and the verification itself.
An allowlisted smart account allowlists everything it can do. Policy reads the destination of a transaction. It does not read the beneficiary hidden inside the transaction data. That is the Binance 14 and smart account pattern, reachable through a perfectly legitimate path. Approval on the owner key and decoding of the transaction data close it. Approval is available in every deployment model. Decoding at the moment of signing happens in the Validation Gate, which only a client that runs its own signers has. Both are the client’s to set up.
Minutes depend on the drill. Without a named decision owner, a quorum, a funded wallet and a sweep destination, any institution is in Binance’s position. It can sign a revocation in seconds. It cannot decide to.
Deterministic controls are not anomaly detection. Allowlists, limits and velocity rules enforce what you wrote down. They do not score a request for strangeness. That layer belongs to the institution or to a vendor, and it needs to exist.
AI tools cut both ways. A provider can keep its own AI out of production. An institution’s own agents, with reach into its engineering systems, are a risk no provider can see.
Insurance is a liability instrument rather than a recovery plan. Against a loss in the billions, no provider’s cover restores anything. Binance’s backstop was its own capital. So is every institution’s.
A checklist for this week
- Write down what your signer checks before it signs, and whether it can tell a transfer from a delegation.
- List every signature kind your platform will produce and which policy rule reads each one.
- Find every smart account your wallets own and put the owner keys behind approval.
- Inventory every machine that can launch a production deployment, and put an approval between that machine and any signer.
- Time your onchain revocation drill end to end, with the people who would actually run it.
- Check whether one compromise reaches all your chains. Segregate if it does.
- Run a fake recruiter exercise on the team that runs your wallets.
- Confirm your alerts reach someone who can stop signing rather than someone who investigates.
Sources
- Binance, 29 October 2026 Binance Security Incident: Initial Findings and Response Update, 3 November 2026. https://www.binance.com/en/blog/community/3229153443759566763
- TRM Labs, North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History, 29 October 2026, figures to 30 October 00:30 UTC. https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history
- Hypernative, Inside the Largest Crypto Theft of All Time, 30 October 2026. https://www.hypernative.io/insights/blog/inside-the-largest-crypto-theft-of-all-time-the-6-3b-binance-hot-wallet-drain
- FBI Cyber, North Korea Responsible for $6 Billion+ Binance Attack, 31 October 2026. https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack
- Binance, Security Incident Recovery Update #4, 1 November 2026. https://x.com/binance/status/2116744986096292263
- Binance, Security Incident Recovery Update #7, 4 November 2026. https://x.com/binance/status/2118001921252347938
- Elliptic, How North Korea is laundering the $6.4 billion stolen from Binance, 3 November 2026, updated 7 November 2026. https://www.elliptic.co/insights/how-north-korea-is-laundering-the-6-4-billion-stolen-from-binance/
- Binance, Security Incident Update, 30 October 2026 02:23 UTC, amended 11:36 UTC. https://www.binance.com/en/support/announcement/detail/c5a8729a97ac486d963784d96c5642d7
- Binance, Security Incident Update #2, 30 October 2026. https://x.com/binance/status/2116258356109496479
- SANS Internet Storm Center, Malicious Ad for Homebrew Leads to MacSync Stealer, 1 May 2026. https://isc.sans.edu/diary/32942
