Binance says a compromised engineer’s laptop exposed its withdrawal pipeline. The exchange is restoring services and covering customer losses.

The reported $6.3 billion Binance theft began with a compromised DevOps engineer’s laptop, according to the exchange’s preliminary investigation. That account points to a failure at the boundary between employee access and automated withdrawals—an operational path that can put digital assets at risk even when wallet private keys remain secure.
Binance says it found no evidence that private keys were exposed. It has pledged to cover customer losses through its Secure Assets Fund for Users (SAFU) and company funds, and says user assets are safe.
The exchange froze approximately $3 billion in on-chain assets as it investigated, temporarily paused withdrawals, and revoked authorization for the affected address. Withdrawals are now returning in stages across 15 networks, including Bitcoin, Ethereum, Solana, and XRP. Binance says it has replenished about 95% of the affected assets; sourcing the remaining 5%, made up of less-liquid tokens, may take longer.
The route from laptop to withdrawals remains unclear
Binance’s preliminary findings indicate that attackers accessed a service container involved in withdrawals after compromising an employee device. The company hasn’t yet released technical details explaining the intrusion path or how the attackers moved through its internal systems.
That gap matters. As Tim Rawlins, senior advisor and director of security at NCC Group, put it, “security is a critical element of every operational stage and personnel level.” Trusted identities and administrative access can give attackers opportunities beyond exploiting software flaws, he said.
Mario Rivas, blockchain and digital assets security lead at NCC Group, argued that a single compromised employee laptop shouldn’t be enough to authorize a transfer. His point gets to the central control question: whether independent checks can stop an intrusion from crossing into the withdrawal process.
The incident has drawn comparisons with the February 2025 Bybit breach, when attackers compromised a developer’s machine at Safe{Wallet} and altered the interface shown to transaction signers. The reported Binance method appears different. F6’s Threat Intelligence Department (TID) said the attackers targeted an automated withdrawal process rather than deceiving authorized signers.
F6’s Evgeniy Yanov, head of its Audit and Consulting Department, pointed to details identified by security platform Blockaid: a batch of 50 EIP-7702 authorizations in one transaction and delegation to a malicious “sweeper” contract. Yanov said that mechanism “has not been seen before in large-scale breaches of this size.”
Attribution and on-chain indicators
The FBI has attributed the theft to TraderTraitor, a North Korean hacking group associated with the broader Lazarus infrastructure. The agency said it had observed the attackers privately converting stolen assets into Ethereum and warned that the funds could later pass through decentralized finance platforms and instant-swap services.
F6’s TID said its attribution drew on both on-chain and off-chain intelligence. The researchers cited patterns they associate with previous thefts: small Tornado Cash withdrawals used to fund an operator wallet, extensive preparation ahead of the attack, and pre-signed transactions executed in a burst. They also noted similarities to other North Korean-linked incidents, including the Bybit and KelpDAO thefts.
Those comparisons aren’t the same as a public technical record. Binance hasn’t independently identified the perpetrators, and the full evidence behind the attribution hasn’t been published. The exchange did not immediately respond to a request for comment.
Rawlins said attackers targeting cryptocurrency firms may invest substantial effort in reaching people with access to the systems exchanges depend on. He also warned that AI could help adversaries combine vulnerabilities with operational weaknesses. For exchange operators, the practical takeaway is less about any single tool than about limiting what one compromised device or trusted account can authorize—and making the withdrawal path resilient to failures upstream.
Discussion
Sign in to join the discussion.