At about 20:05 UTC on October 29, funds began leaving Binance wallets across multiple blockchains. Most of the main outflow happened in roughly twenty minutes, according to TRM’s investigation.
Binance’s estimated impact: $6.3 billion.
As a DeFi security engineer, the detail that caught my attention was its preliminary explanation: a DevOps engineer’s laptop may have opened a route into a service container and unauthorized withdrawals. Binance said it had found no wallet private-key leak. Binance’s announcement
That’s a frightening possibility. An attacker may be able to use a company’s signing system without taking the keys out of it. The systems meant to move money for the business become the route used to drain it.
I followed the public reports from the suspected laptop compromise to the Ethereum authorization and the response that followed. I wanted to understand where access to an employee’s computer could become permission to move funds, and what could still stop the attacker.
Reporting cutoff: 30 October 2026, 09:00 UTC. Binance’s technical post-mortem is still pending; the laptop compromise remains a preliminary finding.
Where things stand
Binance reports about $3 billion frozen. It says it revoked affected authorization, engaged investigators and will cover losses using SAFU and company funds. A technical report and updated Proof of Reserves are promised. Official security update
A subsequent Binance News update says deposits are operating normally while withdrawals remain paused for changes to the withdrawal service and associated addresses. The stated expectation is to begin restoring withdrawals within 48 hours. That is a target, rather than confirmation that withdrawals have reopened. Latest service update
The timeline we can reconstruct
The table combines Binance’s public response with the transaction chronology reported by investigators. All times are UTC. A transfer timestamp tells us when a transaction happened; it doesn’t tell us when Binance’s staff first saw an alert.
| Time | Reported event | Source |
|---|---|---|
| October 29, about 20:05 | The main cross-chain outflow begins, according to TRM. | TRM investigation |
| 20:20:59 | An Ethereum transaction installs a delegation on Binance 14. | Bitquery chronology, transaction |
| 20:24:23 | The major Ethereum sweep executes. | Bitquery chronology, transaction |
| 21:01 | Bitquery records Tether’s first freeze on the main Ethereum receiver. | Bitquery chronology |
| 21:04 | Circle freezes the USDC in the main receiver, according to Bitquery. | Bitquery chronology |
| Around 23:05 | TRM reports a later wave on Avalanche and Polygon. | TRM investigation |
| October 30, 00:10:35 | Bitquery identifies the Ethereum delegation revocation transaction. | Bitquery chronology, transaction |
| 00:18 | Bitquery records Arbitrum Security Council action to lock the attacker’s ARB and ETH. | Bitquery chronology |
| Subsequent October 30 update | Deposits normal; withdrawals remain paused, with restoration expected within 48 hours. | Binance service update |
Transaction interpretations are attributed to Bitquery; I have not independently replayed them. Binance also reported initially suspending deposits and withdrawals and engaging investigators, without publishing the internal action times.
How could a laptop reach the withdrawal service?
A DevOps engineer helps operate the systems that build, deploy and run software. Depending on the role, their device might have access to cloud accounts, deployment tools or production services. Those permissions make the device relevant even when it contains no wallet key.
A service container is an environment running a backend service. Binance’s preliminary explanation follows this path:
I’d separate the investigation into three questions. First, how did the attacker gain access to the laptop? Second, which identity or connection allowed access to the service? Third, why could the resulting request produce an accepted transaction?
Those questions need different records. Device analysis can show execution and credential access. Cloud and service logs can show the identity used. Signing logs can show the requested operation, policy decision and resulting signature. The chain then shows what executed.
A valid signature alone cannot answer who was entitled to request it. A signing system can correctly protect a key while accepting a request that the business would never approve.
The public material does not establish the initial infection method, whether credentials were stolen, what the container could access or which approval checks failed. A phishing email, malicious coding exercise or stolen session would each require its own supporting records. I’d avoid naming one as the cause until those records are published.
The permission that kept the Ethereum wallet exposed
TRM describes an Ethereum-specific step: an EIP-7702 delegation changed the behavior of a Binance hot wallet. It reports prepared authorizations on Ethereum and ordinary signed transfers on the other affected chains. It also describes repeated sweeps as more funds reached the Ethereum wallet. TRM interprets the combined activity as a compromise of signing infrastructure. TRM technical assessment
EIP-7702 lets an ordinary Ethereum account authorize code deployed elsewhere to run as its own account logic. That code can act on the account’s assets. The delegation stays installed until replaced or cleared. Malicious delegated code can therefore allow later calls to move funds without a fresh withdrawal approval from the exchange. EIP-7702 specification
A team can stop its application from accepting new withdrawal requests while a permission already installed on-chain remains usable. The response therefore has to inspect both the service and the account’s current state.
I’d want confirmation that new unauthorized requests are rejected, that the affected account’s delegation has been inspected, and that any outstanding signed authorizations have been considered in the recovery plan.
The signer-security guide examines this boundary in more detail: what the process can request, what the signer permits and what the account or contract actually enforces.
Detecting the drain and stopping the next transfer
Blockaid says its detector flagged the drain 1 minute and 55 seconds after the sweep, with automated analysis within eleven minutes. This is the vendor’s reported performance; it does not establish when Binance received an alert or acted on it. Blockaid’s incident report
That gap is what I would want to understand in the response review: who received an actionable alert, what authority they had, and when their containment action took effect.
The response has two simultaneous jobs: stop further loss and restrict movement of assets already taken.
For the first job, the team needs control over its own identities, services and account permissions. For the second, it needs the organizations that can act on the assets’ current locations. A token issuer may be able to freeze its token; an exchange receiving funds may be able to restrict an account. Each route has different requirements and response times.
Bitquery’s review reports about $2.7 billion frozen under its methodology and cutoff, compared with Binance’s announced figure of about $3 billion. It describes the attacker swapping stablecoins before freezes took effect. Its holdings snapshot is dated 03:54 UTC on October 30. Bitquery’s tracing and methodology
I’d read those totals with their timestamps attached. Prices move, investigators expand their address sets, and freezes happen at different times. Subtracting one investigator’s frozen total from another source’s impact figure would create a misleading estimate of final loss.
TRM counts ten chains; Bitquery counts nine. Their totals should retain their original scope and reporting time. TRM scope, Bitquery scope
Who was behind it, and how strong is the attribution?
TraderTraitor, a North Korea-linked operation, is the leading published attribution. TRM assigns high confidence, citing both on-chain and off-chain intelligence. Its public explanation points to advance preparation, pre-signed authorizations and funding patterns seen in earlier thefts. TRM’s assessment
AP also reports that Chainalysis CEO Jonathan Levin assessed TraderTraitor as likely responsible. Binance had not named an attacker in the statements reviewed here. AP’s attribution reporting
There is relevant history behind the name. The FBI attributed the February 2025 Bybit theft to North Korea and described the activity as TraderTraitor. That establishes a previous attribution; it does not identify the Binance attacker by itself. FBI’s Bybit notice
What the addresses let us inspect
I’d start with the roles of the addresses. A victim wallet, malicious contract and receiving wallet tell different parts of the story. The following Ethereum addresses are identified in Bitquery’s investigation. The links open their public explorer records; the role descriptions come from that investigation.
| Reported role | Ethereum explorer |
|---|---|
| Binance 14: affected wallet | View wallet |
| Code selected by the delegation | View contract |
| Attacker’s caller wallet | View caller |
| Main receiving wallet | View receiver |
The setup, sweep and revocation transactions are linked in the timeline above. Read together, those records help investigate which account executed code, where assets moved and when permissions changed. An explorer label alone cannot establish who controlled an address.
My assessment
The reported coordination across chains and repeated use of the Ethereum permission are consistent with a prepared theft operation. They justify investigating an organized attacker with access to signing capabilities. They don’t, on their own, identify a country or a named group.
I’d therefore treat TraderTraitor as the leading attributed suspect, with the confidence level belonging to TRM’s investigation. I haven’t reproduced its private intelligence or established an independent identity match. A shared technique or use of a mixer is too broad to make that leap.
To strengthen the attribution independently, I’d look for specific links to previously attributed infrastructure, malware from the compromised device, or a documented funding connection to known operators. The published material reviewed here does not expose enough of that chain for me to independently confirm who was behind the keyboard.
What I’d want the final report to explain
The phrase “compromised laptop” identifies a possible starting point. A useful technical account also needs to explain the permissions that connected that starting point to the funds.
| Question | Why it matters |
|---|---|
| How was the device compromised, and when? | Establishes the initial access route and the period that needs investigation. |
| Which identity reached the service container? | Shows whether access came through a session, credential, deployment path or another mechanism. |
| What operations could that service request? | Defines whether compromise exposed ordinary transfers, authorizations or broader signing capabilities. |
| Which independent checks applied? | Explains recipient controls, limits, approvals and how they behaved during the incident. |
| What triggered detection? | Shows whether the first actionable signal came from the endpoint, service, signer or chain. |
| What remained executable after the pause? | Identifies permissions and signed requests that survived the first containment action. |
| How was recovery tested? | Shows why the restored service and addresses can be trusted to enforce the intended restrictions. |
I’d also want the report to distinguish a control that was missing from one that existed but was bypassed or misconfigured. Each leads to different engineering work. Buying another product before understanding that distinction can leave the same route open.
What a crypto team can check today
Start with one employee role that can change production software. Trace its actual access to services that request signatures. Include emergency access and deployment identities, because a routine role review can miss those routes.
Then test the signing boundary with the process assumed compromised. Can it ask for an unexpected recipient, a larger amount or a delegation? Which independent component refuses, and does the refusal produce an alert someone owns?
Finally, rehearse containment with a permission already active on-chain. The exercise should force the team to reach the right signers, submit the authorized response and read back the resulting state. An alert in a chat channel is only useful when someone can perform that next action. The monitoring guide covers how to test the complete response path.
In a review, I’d test what a compromised developer account can make the signing system do. Then I’d test how the team removes permissions that are already active. Those are the two boundaries I want to understand before trusting the next withdrawal.
If your team needs help tracing employee access through production and signing permissions, get in touch about a security review.