Why Binance’s ‘kill switch’ couldn’t stop hackers from draining $6.3B — Explained!

There is a certain irony in pulling the emergency brake, only to discover that the machinery you’re trying to stop is operating beyond your reach.

Binance encountered a rather expensive version of that problem on 29th October. Attackers compromised its wallet signing infrastructure and obtained authority to move cryptocurrency through mechanisms that did not depend on the exchange’s ordinary withdrawal process. Suspending withdrawals could interrupt that process. It could do considerably less about permissions already established on Ethereum.

By the time the attack was contained, approximately $6.3 billion had been stolen and Binance’s engineers had developed a specialised procedure to revoke malicious on-chain authority. The exchange could shut down affected services, but Ethereum would continue recognising the delegation until it was explicitly cleared.

Brian Cubellis, Chief Strategy Officer at Bitcoin custody platform Onramp, offered his two cents to AMBCrypto,

Pausing withdrawals turns off the exchange’s own software, but it does nothing about permissions the attacker has already written to the blockchain

The distinction is an uncomfortable one for an institution entrusted with billions in customer assets.

Binance subsequently coordinated freezes of stolen funds and began replenishing the affected holdings, reporting approximately 98% replenishment by 4th November. Its financial response was substantial.

However, it still is worth questioning what remained possible while its emergency controls were taking effect.

The permission that wouldn’t disappear

By the way, for those unaware, the attack began well before 29th October and nowhere near a blockchain.

According to Binance’s 3rd November incident report, an engineer downloaded a tampered installation package for an AI coding tool in June. The exchange detected the anomaly and replaced the device, but the attackers had already gathered intelligence about its employees and infrastructure. Well into September, another engineer was approached through a fictitious recruitment process involving interviews and a malicious coding assignment.

By 20th October, the attackers had used compromised employee systems and internal AI tooling to access additional machines. In doing so, they ultimately obtained credentials that opened the way to Binance’s wallet signing infrastructure.

It all paid off on the 29th. Between 20:05 and 20:09 UTC, hot wallets transferred approximately 223.46 million XRP, 970,500 SOL and 44.2 million OP to attacker controlled addresses. Bitcoin and other assets followed. Chainalysis subsequently estimated the overall theft at approximately $6.4 billion.

What was the most consequential part of this intrusion though? The attackers gained access to Binance’s signing infrastructure, the very machinery responsible for authorizing transactions.

And, they used that trust against it.

On Ethereum, the attackers exploited EIP-7702, a mechanism that allows an externally owned account to delegate execution to smart-contract code.

Ordinarily, that flexibility expands what a wallet can do. Here, according to Binance, the compromised signing infrastructure was used to grant malicious code execution rights over an Ethereum hot wallet. The exchange described 50 signed transactions involved in manipulating the account’s nonce and establishing the delegation.

The unsettling part comes next though. Those permissions remained valid on-chain even after Binance suspended withdrawals and shut down its hot-wallet services. The exchange could stop its own systems from processing transactions, but it could not simply switch off the authority the attackers had already established on Ethereum.

Then came another complication. Binance’s hot wallet used multi-party computation (MPC), which distributes the production of cryptographic signatures across multiple participants or components rather than relying on a single conventional private key. That architecture can reduce certain risks, but it also meant there was no single private key available to revoke the malicious delegation immediately.

Binance’s engineers had to DEVELOP a specialised revocation procedure while the incident was UNFOLDING. Of course, this took additional time, prolonging the effort to contain unauthorized asset movements.

At 23:56 UTC, the final reported unauthorized Ethereum transfer, involving 2,961.9 ETH, was confirmed on-chain. Binance said it had been broadcast earlier and remained pending before confirmation. At 00:10 UTC on 30th October, the exchange cleared the malicious EIP-7702 delegation with a new authorization to the zero address.

The distinction between broadcast and confirmation matters. So does the absence of an established total for funds transferred after withdrawals were suspended.

Binance acknowledged that suspension alone could not stop every unauthorized movement, but its disclosures do not establish a reconciled post-suspension loss figure.

A kill switch… with conditions attached

There is a comforting simplicity to the idea of a kill switch. Something goes wrong, someone pulls the plug and the damage stops. Unfortunately, the blockchain has no particular obligation to respect an exchange’s internal emergency procedures.

Consider a hotel discovering that someone has obtained an unauthorized key card. Closing reception prevents new cards from being issued. The existing card still opens the door. Cancelling it, securing the valuables, and recovering what has already disappeared are separate jobs.

Now, this comparison has its limits, but it captures the dilemma facing exchanges whose wallet permissions outlive their own systems.

The problem surfaced in a public exchange between Haseeb Qureshi, Managing Partner at Dragonfly, and Tudor Anastasiu. Tudor Anastasiu is a blockchain infrastructure and security engineer and the founder of Anastasiu Labs.

The disagreement exposes a distinction that is easy to overlook in the middle of a breach.

A defensive sweep can move assets to safety, provided the exchange can authorize and execute it before the attacker does. However, moving funds does not necessarily invalidate permissions already granted on-chain and it certainly cannot retrieve assets that have already disappeared.

So, that leaves a rather awkward question: If the signing infrastructure itself has been compromised, how does an exchange authorize an emergency transaction without trusting the very system it suspects?

Carlos Vendrell, Founder of Zealynx Security, sees the answer in testing the procedure under exactly those conditions.

The drill should start from a list of every approval and delegation each hot wallet has given, then revoke one of them for real while assuming the normal signing service is the compromised part, and time it

Binance’s experience does not establish that MPC inherently prevents rapid revocation. Nor does its disclosure prove that no emergency procedure existed before the breach.

However, it does establish that engineers developed a specialised procedure during the incident and doing so took additional time.

The wallet that kept getting fed

There was another complication here, one that made the situation look almost absurd. The compromised wallet was reportedly STILL receiving money.

In an analysis dated 4th November, Four Pillars reported that Binance’s deposit-consolidation system continued collecting funds into a compromised Ethereum wallet identified as Binance 14. This allowed the attacker to sweep newly arriving assets.

Nexus Mutual’s reconstruction offers a particularly striking sequence.

At approximately 21:44 UTC, it says the attacker swept 200 million USDT that another Binance-labelled wallet had deposited roughly 72 seconds earlier. Seventy-two seconds! Barely enough time to make a cup of coffee, yet apparently sufficient for a fresh transfer to reach a compromised address and disappear.

The researchers’ findings raise a problem distinct from EIP-7702. An exchange can work to revoke an attacker’s authority while other operational systems continue directing funds towards a dangerous destination. Interrupting those internal asset flows is another containment task and requires its own controls and confirmation.

According to Brian Cubellis, emergency preparedness must account for the loss of the usual signing infrastructure.

An exchange should prove, before it is attacked, that it can cancel any permission on its wallets and move exposed funds to safety even if its own signing system has been taken over

That is easier prescribed than engineered though.

An independent emergency signing path may accelerate recovery, but it also introduces powerful authority that must be secured. Build too much dependence into the ordinary system and the emergency route may fail alongside it. Concentrate too much authority in the alternative and the supposed safeguard becomes another attractive target.

Money moves faster than the paperwork

Once stolen assets leave the exchange’s immediate control, containment becomes a race involving investigators, stablecoin issuers, blockchain networks and the attacker.

Chainalysis’s investigation also described an attempt to move approximately $500 million in stablecoins through a swapping address. Within roughly 20 minutes, the attackers reportedly converted around $325 million into assets less susceptible to issuer freezes, including Ether. The remaining $175 million was frozen.

There was a reason for the rush. Stablecoin issuers such as Tether and Circle can freeze certain tokens at designated addresses. Bitcoin and Ether, by contrast, have no equivalent central issuer with that power. Converting the stolen stablecoins into other assets could therefore put them beyond the reach of an issuer-imposed freeze.

This whole episode illustrates the limits of intervention once funds have escaped. Investigators may be able to follow the money on-chain, but knowing where it has gone does not necessarily give them the power to retrieve it.

Binance nevertheless managed to secure a substantial portion of the stolen assets. In its 3rd November report, the exchange said that approximately $2.85 billion had been frozen or intercepted through cooperation with issuers, law enforcement, and blockchain intelligence firms. By 4th November, it reported replenishing approximately 98% of the affected holdings through replacement purchases.

Of course, Binance had demonstrated considerable capacity to absorb the losses rather than pass them on to users. However, it tells us how much the exchange managed to secure or replace, not how effectively it prevented the attacker from continuing to move assets during the breach.

When valid signatures authorize a theft

A year earlier, Bybit had encountered a different version of the problem with compromised transaction authority. In February 2025, attackers stole approximately $1.5 billion after compromising the environment associated with its Safe{Wallet} approval process.

According to Bybit’s forensic disclosure, malicious changes deceived signers into approving an unauthorized transaction. It also said that investigators found no indication that its own infrastructure had been compromised.

Both incidents exposed how much depends on the integrity of the authority behind a transaction. Multiple signatures offer limited protection when signers are misled about what they are approving. And as Binance discovered, shutting down a signing service does not necessarily invalidate authority already established on-chain.

What does the “kill switch” actually kill?

An emergency kill switch sounds reassuring. Rather less reassuring is discovering, halfway through a breach, that the attacker has permissions your switch cannot revoke.

Binance’s experience raises an uncomfortable question for exchanges entrusted with billions in customer assets — Have they actually tested what happens when the systems responsible for protecting those assets become part of the attack?

An exchange should be able to demonstrate that it can revoke compromised permissions, move exposed assets to safety, and interrupt internal transfers without relying entirely on infrastructure it can no longer trust.

But what should customers make of an exchange’s public assurances when a breach is underway? AMBCrypto put that question to Vik Sharma, Founder and CEO of Cake Wallet,

A useful update names which approvals were revoked, which assets moved, and where, so customers can check it themselves

There are legitimate reasons to withhold sensitive operational details while an intrusion is underway. Once the immediate danger has passed, however, an exchange should be able to explain what its emergency controls actually stopped, when compromised authority was extinguished, and whether any assets remained exposed.

Binance deserves credit for publishing details of its response, coordinating substantial asset freezes, and committing its own resources to replenish affected holdings. Those measures helped absorb the financial damage. However, they also revealed why reimbursement and containment should never be confused.

A kill switch should buy defenders control, not merely time to figure out where control has gone.

Final Summary

• Binance’s signing infrastructure, unbeknownst to them, was compromised well before the hack.
• This episode and the one involving Bybit reveal that much depends on the integrity of the authority behind a transaction.