The $6.3 billion Binance attack started on a DevOps laptop

Binance, the world's largest cryptocurrency exchange, suffered the largest crypto theft on record on the evening of 29 October 2026. In roughly half an hour, attackers drained the exchange's hot wallets on ten separate blockchains. Binance put the total impact at approximately $6.3 billion, about four times the $1.5 billion stolen from Bybit in February 2025. According to Binance's preliminary findings, the attack started on a DevOps engineer's laptop and no private key was leaked. The attacker never reached the keys; they took the money out by seizing the authority to use them. In this post we bring together how the incident unfolded hour by hour, how the attack worked technically, where the funds went and how organizations can close the same path in their own environments.

The evening of 29 October

Preparation started a day earlier. According to TRM Labs, the attacker's operator wallet was funded on 28 October through three small Tornado Cash withdrawals. On the afternoon of 29 October the attacker rehearsed the same technique with $2 to $6 test transactions on their own wallets, and at 15:59 UTC deployed the sweeper contract that would be used in the attack. These rehearsals, reported by Blockaid and by CertiK engineer Dickson, show that the attack was planned step by step in advance.

The draining began around 20:05 with 233 million XRP withdrawn from five wallets on the XRP Ledger. Over the next fifteen minutes the Solana, Optimism, Bitcoin and Tron wallets were emptied one after another. The Bitcoin side alone lost 18,270 BTC and the Tron side 612.7 million USDT. At 20:20:59 an EIP-7702 delegation transaction was submitted on-chain for Binance 14, one of the largest hot wallets on Ethereum. Three and a half minutes later, about $2.5 billion worth of ETH and tokens left the wallet in a single transaction. Sources differ on the start time: TRM places the first outflow at 20:05, while Arkham's CEO told CoinDesk the breach began around 20:30.

The drop in BNB and the stablecoin freezes started before Binance said anything. BNB hit the evening's low of $692 at 20:50. Tether froze 971 million USDT at 21:01 and Circle froze 823 million USDC at 21:04. Binance's first corporate statement came at 21:24 and only said it was looking into reports of a possible security issue. Roughly 80 minutes passed between the first outflow and the exchange's first statement. Withdrawals were halted network by network between 22:15 and 22:32. Binance co-founder Yi He announced around midnight that all deposits and withdrawals had been suspended.

Technically, the most striking detail was that the delegation on Ethereum was persistent. Funds that arrived in Binance 14 afterwards were also forwarded to the attacker through the same contract at 20:41, 21:44 and 22:39. Binance began withdrawing the remaining balance itself around 22:55, yet TRM's records show the last withdrawal through the delegation took place at 23:56. In other words, for about three and a half hours the attacker could take every new fund that landed in the wallet.

Binance's full statement was published around 02:30 on 30 October. It put the total impact at about $6.3 billion and the frozen amount at about $3 billion, and named a DevOps engineer's laptop as the entry point. The company said the losses would be covered by the SAFU fund and its own resources and that withdrawals were expected to reopen within 48 hours. As of the morning of 30 October, when this post was written, withdrawals were still closed. Some news sites' "withdrawals reopened" headlines contradict even their own articles.

From a laptop to the signing infrastructure

The only technical explanation Binance has shared so far is short and cautious. The initial investigation indicates that the incident may involve a compromised DevOps engineer's laptop, that the attacker used this device to access a service container and that unauthorized withdrawal transactions were submitted from there. The company adds that it has found no evidence that any wallet's private key was leaked. How the laptop was compromised, which container was used and how the attacker reached the signing service have not yet been disclosed. Binance says it will publish a technical review.

On-chain data fills in some of the missing pieces. Bitcoin and the EVM chains use the ECDSA signature algorithm, while Solana uses Ed25519. The XRP Ledger and Tron also have their own transaction formats. Even so, wallets on all ten chains produced valid signatures for the attacker's transactions within half an hour. Each of the eleven Bitcoin outflows CoinDesk examined looked like an ordinary Binance withdrawal, and the change outputs went back to Binance addresses. TRM Labs concludes from this that the hot wallet signing infrastructure was compromised. Based on the available data, the attacker most likely reached a service authorized to request signatures, and that service passed the attacker's payloads to an MPC- or HSM-based signer. The keys stayed where they were, but the signer trusted the request it received.

Analysts do not fully agree on this. Blockaid CEO Ido Ben-Natan says he does not believe a key was leaked, while the same company's blog post uses the phrase "stolen key". SlowMist's CISO, contrary to Binance's statement, leans towards a private key leak and suggests risk controls may have been bypassed with a purpose-built withdrawal tool. The definitive answer will come with Binance's technical report.

There is no finding yet on how the laptop was compromised, but the closest public precedent is instructive. In the UNC4899 case described in Google's Threat Horizons report published in March 2026, an archive sent to a crypto company's developer over AirDrop was opened in an AI-assisted IDE and ran a backdoor disguised as kubectl. From there the attacker changed the MFA policy on a bastion server, tampered with Kubernetes deployments, had CI/CD service account tokens written to logs and broke out of a privileged pod to reach database credentials in environment variables. The case ended in withdrawals worth millions of dollars. The path Binance summarizes as "laptop, container, withdrawal" largely matches this chain, and the similarity gives an idea of the steps the attacker may have followed.

Persistent access with EIP-7702

EIP-7702 arrived on Ethereum with the Pectra upgrade in May 2025. It lets an ordinary wallet address, an EOA, point its code at another smart contract through an authorization signed with its own key. Once the authorization is included on-chain, every call to that address runs the delegated contract's code against the wallet's own balance. Anyone can submit a signed authorization on-chain, and the delegation stays in place until the wallet signs a new authorization.

In the Binance incident, the attacker's operator address sent a single transaction at 20:20:59 containing 50 separate authorizations signed by Binance 14. Each authorization was signed for a different nonce between 18,914,775 and 18,914,824. Because Binance 14 was still processing normal customer withdrawals at the time, its nonce kept increasing. Spreading across 50 consecutive values guaranteed that one of the authorizations would match when the transaction landed in a block. The delegation pointed to an unverified sweeper contract that only the operator could call. Its sweep function moved the wallet's ETH and every listed token to the attacker's address in a single call. According to Blockaid, the first sweep took out 167,464 ETH and 63 different tokens, including 1.615 billion USDT. About 823 million USDC was also withdrawn through Hot Wallet 34, a smart account that treated Binance 14 as an authorized party.

On Ethereum, EIP-7702 acted as a multiplier that amplified the attack's impact. The root cause was access to the signing infrastructure. No similar mechanism was used on the other nine chains; ordinary signed transfers were enough there. Still, the way EIP-7702 sidestepped value limits stands out. An authorization signature does not move money; it only points the wallet's code at another contract. Per-transaction or hourly value limits cannot catch it, because the money then moves outside Binance's withdrawal flow, through the contract called from the attacker's own address. A signer policy that only allowed standard transfer types to be signed would have rejected these authorizations outright. Since EIP-7702 authorizations are signed with a separate domain prefix (0x05), making this distinction is technically possible.

Blockaid was the first to detect the attack. Its detection system flagged the delegation and the sweep transaction as malicious within about two minutes. However, this detection came from a third party and was not tied to any automated stopping mechanism.

Breakdown of the loss

Estimates of the total loss range from $5.5 billion to $6.4 billion. Most of the gap comes from whether assets are valued at the price at the time of transfer or at the current price, which chains are counted and when the measurement was taken. The table below brings the main estimates together.

TRM's per-chain breakdown largely matches Arkham's. Sixty percent of the loss, $3.79 billion, comes from Ethereum. That amount includes 200,630 ETH, 1.875 billion USDT, 823 million USDC and 88.5 million RLUSD. Bitcoin accounts for $1.47 billion with 18,270 BTC, Tron for $628 million, the XRP Ledger for $296 million and Solana for $96 million. No source mentions a BNB Chain loss. This may be a clue to the scope of the compromised service, but it has not been explained yet. For context, the loss amounts to 4 percent of Binance's roughly $144 billion in assets.

About half of the stolen value was in stablecoins such as USDT, USDC and RLUSD that a central issuer can freeze. That is why recovery started so quickly. Tether and Circle made their first freezes before Binance's first statement. Sources give different figures for the total frozen: Binance says about $3 billion, TRM about $2.7 billion and Arkham $2.80 billion. Binance's figure probably also covers funds held in or tracked by its own wallets, but the company has not confirmed this.

According to TRM, the attacker still holds more than 420,000 ETH and 18,270 BTC, that is, about $2.4 billion in assets that cannot be frozen.

Following the funds

In the first hours the attacker tried to get rid of the freezable assets first. According to TRM, about 325 million USDT was converted into about 122,300 ETH through intent-based protocols such as UniswapX. The effective price was around $2,650 per ETH while the market price was between $2,300 and $2,350; the attacker was willing to pay a premium of about 13 percent for speed. 60 million USDT was deposited into Aave as collateral to borrow ETH. On Tron, 300 million USDT was moved to JustLend and 200 million USDT was swapped on Uniswap through intermediate wallets. Of the 88.5 million RLUSD, 48 million was sold on DEXs between 21:42 and 22:01.

On the Bitcoin side a classic peel chain began. Funds are being split into 1,000 and 100 BTC chunks, and according to CoinDesk $1.4 billion worth of bitcoin has already been spread across 19 separate wallets. According to ZachXBT, the next stage has also begun: funds from Binance and from the September 2026 Bitget attack converged on the same address after passing through THORChain. Tornado Cash has so far been seen only in the pre-attack funding. In the Bybit and KelpDAO cases THORChain carried most of the stolen funds, and Chinese OTC brokers stepped in at the final stage. The same pattern is expected to repeat here in a THORChain, Bitcoin and OTC cycle lasting months.

TraderTraitor suspicion

Most security firms attribute the attack to North Korea, specifically to the TraderTraitor group tracked under the Lazarus umbrella. TRM Labs attributes it to TraderTraitor with high confidence, based on on-chain and off-chain intelligence. A Chainalysis spokesperson told CNN they have high confidence about North Korea, while the company's CEO used the word "likely" in a post on X. ZachXBT points to Lazarus, and Blockaid says the tactics are consistent with North Korean operations. Binance has not named a perpetrator. The FBI and the US Department of Justice did not respond to requests for comment, and as of 30 October no government has made an official attribution.

The attribution has a weak point. The strongest public on-chain link is the convergence with Bitget funds, but the Bitget attack's own attribution was never confirmed either. In other words, the attribution chain is partly self-referential. For now it is more accurate to assess North Korean responsibility at medium to high confidence. In the Bybit case, the FBI's official attribution came five days later together with a list of addresses. A similar announcement in the coming days would not be surprising.

Tactically, the Binance incident looks like a scaled-up repeat of Bybit. At Bybit, attackers compromised a Safe{Wallet} developer's macOS device, used stolen AWS session tokens to inject malicious JavaScript into the signing interface and got human signers to blindly approve the modified transaction. In the 2024 DMM Bitcoin case, an employee of wallet provider Ginco was deceived through a fake LinkedIn recruitment process. In all three cases the attack starts on a developer or operations device with privileged access, extends to the system that prepares transactions and ends with legitimate signers signing the attacker's payload.

The Binance incident escalates this pattern in two ways. First, there was no human signer to deceive; the signer was automated. Second, EIP-7702 gave the attacker persistent control over a treasury wallet. According to Chainalysis, North Korea stole a total of $2.02 billion in 2025, and its cumulative total since 2022 was about $6.75 billion. The Binance incident alone almost equals that total.

Market reaction

The market shock was sharp but short-lived. According to The Block and CoinDesk, BTC fell from around $80,000 to below $77,000 and hit its low of $76,418 at 02:07 on 30 October. ETH lost between 5 and 6 percent. Reports of BNB's drop range from 6.3 percent to about 10 percent depending on the source. According to CoinGlass, $1.55 billion in positions were liquidated in 24 hours. AFP reported that BTC and ETH recovered most of their losses by 04:00 GMT, while BNB was still down about 5 percent in the morning.

Binance says user funds are safe and that all losses will be covered by the SAFU fund and company resources. Since the loss came from Binance's own hot wallets, the company is expected to close the gap. However, according to CoinDesk the SAFU fund holds about $1 billion in bitcoin, roughly one sixth of the total impact. When and how the frozen stablecoins will be returned to Binance has not been announced either. As NBC News noted, assets on exchanges are not automatically insured, and covering losses is entirely at the exchange's discretion.

Large incidents like this are almost always followed by fake refund and support scams. Users should be warned about forms promising to "recover your loss", messages posing as the Binance support team and fake announcements on social media, and should follow only Binance's official channels.

Measures organizations should take

The first lesson is that the MPC versus multisig versus HSM debate is the wrong starting point. All three approaches protect the key material. Yet at both Bybit and Binance the attackers targeted the approval flow. What mattered was which service requested the signature and what the signed content actually was. The signing policy should therefore run inside a trust boundary separate from the service requesting the signature, and its rules should not be changeable without the approval of more than one authorized person. The policy engine should check destination address allowlists, a waiting period for new addresses, per-asset and per-wallet velocity limits and the permitted transaction types, and it should simulate the outcome of a transaction before signing. TRM Labs' post-incident recommendations target the same layer: unexpected EIP-7702 authorizations should be rejected, a request for multiple authorizations spread across a nonce range should be treated as an IOC on its own, signing flows should be separated by chain and wallet tier, and a pre-tested method for revoking a delegation should be kept ready. The last point proved decisive at Binance, because the delegation was set up at 20:20 and withdrawals continued until 23:56.

The second lesson is the need for automated circuit breakers. Eight to ten chains draining at the same time within half an hour is the clearest signal a risk engine should catch. If more than a certain share of the hot wallet balance leaves within a given period, or simultaneous outflows appear on more than one chain, the system should stop without waiting for human approval. The size of the balance held in hot wallets is a separate risk; Binance 14 alone was holding about $2.5 billion. In 2024 the FBI also advised crypto companies to require multi-factor approval over separate, unconnected networks before moving financial assets.

The third lesson is removing the bridge between developer devices and production. Since 2022 TraderTraitor has targeted system administrators, developers and DevOps engineers; CISA advisory AA22-108A describes the group with exactly this target audience. Fake recruitment processes, malicious npm packages and trojanized coding tests are its most common methods. The controls below cut this path at different points.

Any organization whose engineers' kubeconfig or cloud session can reach payment, ERP, SWIFT or code signing services has a path similar to Binance's. In banks, payment institutions and large enterprises as well, the service that initiates a payment should not be able to approve its own transaction, the approval flow and limits should sit outside the application team's administrative domain, new beneficiaries should be verified through an out-of-band channel and the emergency stop authority should rest with the treasury function.

Detection guide for MDR and SOC teams

In an attack like this, individual alerts often stay at medium severity and are easily missed. The real value lies in catching the sequence that forms around the same identity. Credential access on a developer device, then the same identity's session appearing from a new IP address or device, then an action on the production control plane and finally unusual use of a payment or withdrawal API. If these steps follow one another for the same identity within 24 hours, the incident should be escalated straight to critical.

Developer devices and cloud logs

The rule set Elastic Security Labs published for the Bybit case is a good starting point for macOS developer devices. The "Self-Deleting Python Script", "Potential Python Stealer" and "Cloud Credential Files Accessed by Process in Suspicious Directory" rules target the behavior of TraderTraitor's known tools. According to Unit 42's Slow Pisces report, the group's payloads create and run ~/Public/__init__.py and then delete it, after which they collect credentials from login.keychain-db, ~/.ssh, ~/.aws and ~/.kube. A Node or Python process accessing these directories, spawning a shell or creating a new LaunchAgent should be closely monitored on developer devices. A binary launched from an IDE that looks like kubectl but whose signature or path differs from what is expected, as in the UNC4899 case, should also be investigated immediately.

On the cloud side, the AWS CloudTrail rules "STS Temporary IAM Session Token Used from Multiple Addresses" and "IAM Attempt to Register Virtual MFA Device with Temporary Credentials" are designed to catch stolen session tokens being used from elsewhere. In GCP environments, MFA policy changes on bastion servers and Cloud SQL Auth Proxy connections from unusual identities should be monitored for the same purpose.

Kubernetes audit logs

There is a container in the middle of the path Binance describes. A user running commands inside a pod in the namespaces where production signing and payment services run should not be routine. The rule below narrows SigmaHQ's "Potential Remote Command Execution In Pod Container" rule to these namespaces. Namespace names should be adapted to the environment.

title: Command execution inside pods in signing and payment namespaces
status: experimental
description: >-
  Direct access to production signing services via exec, attach or
  port-forward
logsource:
  product: kubernetes
  service: audit
detection:
  selection:
    verb: create
    objectRef.resource: pods
    objectRef.subresource:
      - exec
      - attach
      - portforward
    objectRef.namespace:
      - signing
      - wallet
      - payments
  condition: selection
falsepositives:
  - Approved and recorded break-glass access
level: high
tags:
  - attack.execution
  - attack.t1609

For the rule to work, the audit policy must record these requests at least at the Metadata level. In EKS, GKE and AKS environments, it should also be verified that control plane audit logs are enabled and flowing into the SIEM. The commands below can be used for retrospective hunting and permission checks.

# Identities, source IPs and target pods performing exec and attach in audit logs
jq -r 'select(.objectRef.subresource=="exec" or .objectRef.subresource=="attach")
  | [.requestReceivedTimestamp, .user.username, (.sourceIPs | join(",")),
     .objectRef.namespace, .objectRef.name] | @tsv' audit.log

# Whether a user has exec permission in the signing namespace
kubectl auth can-i create pods --subresource=exec -n signing \
  [email protected]

In addition, a human identity creating serviceaccounts/token, anyone other than the CI/CD service account adding a command containing curl, wget or bash -c to a deployment in the signing namespace, and the creation of a pod with privileged: true or hostPath should also raise alerts.

Signing and withdrawal layer

For every service account that calls withdrawal and payment APIs, a baseline should be drawn up of which destinations, amounts, frequencies and chains it transacts with. Sending an above-threshold amount to a destination seen for the first time, simultaneous outflows on more than one chain, a call from a container image never seen before and a signing request type never seen before should all be treated as critical. That last category covers EIP-7702 authorizations, contract delegations and approval policy changes.

Organizations transacting on Ethereum can monitor whether their treasury addresses carry an EIP-7702 delegation with a simple check. An ordinary EOA should have empty code. Under the standard, code starting with 0xef0100 means the address has been delegated to another contract.

# An empty result (0x) is expected.
# A value starting with 0xef0100 means an EIP-7702 delegation.
cast code <treasury_address> --rpc-url "$ETH_RPC_URL"

This check should run on every block, or at least every few minutes, and be wired to automation that halts the withdrawal flow as soon as an unexpected value appears.

On-chain IOCs

The addresses published by Blockaid are listed below. Crypto asset service providers and payment institutions should screen for interaction with these addresses and add the FBI's list to their screening once it is published.

The gap between detection speed and response speed in this incident is striking. Blockaid flagged the delegation and the sweep in about two minutes, Tether and Circle started freezing about an hour after the first outflow, and Binance's own recovery step came about two and a half hours after the delegation. Detection that is not wired to an automated circuit breaker and a pre-approved revocation step is not enough to stop the loss.

Open questions

The most critical questions about the incident remain open. How the laptop was compromised, which credential was carried into the container, why Binance's risk engine did not stop simultaneous outflows on ten chains and why BNB Chain was not affected are still unknown. It has also not been disclosed whether the EIP-7702 authorizations were signed to be valid only on Ethereum mainnet or on all EVM chains.

Fatih Purtaş
Purple Team Lead, InfinitumIT