Binance’s initial investigation linked a possible compromised DevOps laptop to access to a service container and unauthorized withdrawal transactions, according to StepSecurity’s account of the exchange’s disclosures. Binance later identified additional breach points. StepSecurity says the exchange estimated about $6.3 billion in affected assets and reported that partners helped freeze approximately $3 billion.
For teams running exchanges or other services that submit transactions to a protected signer, the immediate question is which machine and service identities could request a withdrawal. Binance’s laptop lead is preliminary; scope the container and the other reported breach points while investigators determine how the device was reached. Follow the identities and requests that reached the withdrawal service.
The reported service-container path
StepSecurity describes the preliminary route as a possible DevOps laptop compromise, access to a service container, then unauthorized withdrawal submissions. A service container is an isolated environment for an application, but the meaningful privilege is the authority its running process has to request and approve transactions. An attacker who reaches that process may be able to send a transaction through the ordinary signing workflow. The service boundary and its allowed requests deserve the same scrutiny as custody of the key.
StepSecurity puts the distinction plainly: “A private key signs transactions. A separate set of systems decides which transactions should reach that key.” Binance reported finding no evidence of a wallet private-key leak. That finding directs the investigation toward request authorization and signing-service access; it leaves the exchange’s additional breach points in scope.
The source recounts blockchain researchers’ observations separately from Binance’s preliminary device lead. According to StepSecurity’s account of TRM Labs, the Ethereum portion included 50 signed authorizations across consecutive account nonces. A nonce is the counter that orders transactions for an account; preparing consecutive values can accommodate a changing counter. The reported EIP-7702 authorizations allowed the wallet to delegate execution to contract code after a valid authorization. The Ethereum feature itself does not authorize an arbitrary wallet without that wallet’s authorization.
StepSecurity also relays Elliptic’s observation that an attacker-controlled delegation persisted after the first transfer and supported at least six later sweeps when funds arrived over the next three and a half hours. TRM observed conventional signed transfers on other chains and assessed that the attacker reached signing infrastructure. Treat the Ethereum delegation as one observed mechanism, alongside those other transfers, while Binance completes its root-cause analysis.
Developer tools warrant separate checks
StepSecurity places the laptop lead beside compromises it investigated in developer tooling. In the August 2025 Nx package incident, a post-install script collected credentials and tried to use installed AI command-line tools to locate sensitive files. In May 2026, Nx Console extension version 18.95.0 fetched a credential stealer when a workspace opened; the reported macOS backdoor could outlast the extension’s short publishing window. In October 2026, attackers replaced OVHcloud CLI release binaries after obtaining contributor access that OVHcloud traced to a malicious editor extension on a personal laptop.
These are documented examples of how an installed developer tool can run code under a developer’s identity. StepSecurity presents those incidents as developer-machine context while Binance investigates how its laptop may have been compromised. StepSecurity sells a developer-machine monitoring product alongside its analysis, so its product recommendations are vendor claims. The access path described in Binance’s initial disclosure is enough to justify a focused review of developer identities and their reach into withdrawal services.
Trace requests to the signer
Start with the identities that could administer the service container, deploy code to it, or submit a withdrawal request. Preserve the container’s deployment and access history, session and token records, approval logs, signer request logs, and wallet transaction identifiers for the incident window. Compare the request initiator and approved destination against the identity, service role, and review path expected for each withdrawal. Look for new or changed authorizations after the first transfer when investigating the reported Ethereum delegation.
Review developer workstations with access to those identities for installed extensions, package history, authenticated CLI sessions, SSH access, and cloud roles. A current clean inventory alone can miss a previously installed malicious version. If a machine or credential matches an affected component, isolate the device, preserve its evidence, and revoke sessions and rotate exposed credentials from a clean machine. Then inspect repository changes, package publishes, cloud API activity, and sensitive service requests made by that identity during its exposure window.
Verify withdrawal authorization after containment
Restrict which developer and service identities can call the withdrawal service or change its deployment; separate ordinary development access from transaction approval. For each recovered identity, compare signer request logs and approval records with chain transactions and approved withdrawals. Verify the withdrawal service rejects a revoked credential and records the denied attempt in its access log; confirm new requests follow the intended approval path. A rebuilt laptop helps with device integrity, but the wallet and signer still need their own authorization and transaction review.