The Laptop in the Signing Path

At about 20:05 Coordinated Universal Time (UTC) on October 29, 2026, Binance wallets began sending funds to an attacker. TRM Labs traced approximately $6.36 billion leaving across ten blockchains, most of it within roughly 20 minutes.

Binance’s investigation now describes a multi-stage attack involving compromised engineer devices, an internal AI tool, deployment credentials, and a wallet signing service. The findings remain initial and are subject to further review.

For enterprise IT and security teams, the incident raises a practical question: which devices, identities, and services can reach the systems that authorize high-value actions?

What Happened

Preparation for the theft began well before the first transfer. TRM reconstructed at least 36 hours of on-chain staging, including funding an operator wallet, testing attack code, and rehearsing its execution.

The transfers began on the XRP Ledger. Between 20:05 and 20:09 UTC, five Binance wallets sent 233.46 million XRP to an attacker-controlled address. Wallets on Solana and Optimism followed shortly afterward.

At approximately 20:20 UTC, a Binance Bitcoin hot wallet sent 18,270 Bitcoin (BTC) to the attacker. Around the same time, the attacker submitted Ethereum authorizations that delegated control of a Binance hot wallet to an attacker-controlled contract.

The principal Ethereum sweep followed at about 20:24 UTC. It moved 167,464 Ether (ETH) and 63 tokens, including 1.615 billion Tether (USDT), according to TRM. Later transfers reached other networks, including Avalanche and Polygon.

TRM’s $6.36 billion estimate values assets at the time they left Binance wallets. Binance’s initial security update estimated the impact at around $6.3 billion and said the company would cover losses using its funds and the Secure Asset Fund for Users.

The Signing Mechanism

The Ethereum transfers involved Ethereum Improvement Proposal 7702 (EIP-7702), introduced in the Pectra upgrade in May 2025. It allows a wallet to delegate execution behavior to a smart contract through a signed authorization.

TRM reported that the attacker submitted 50 authorizations signed by the Binance hot wallet. Each pointed the wallet toward a contract that accepted instructions from the operator.

Each authorization depended on a transaction count called a nonce. The attacker prepared signatures for consecutive counts, increasing the chance that one would match when submitted. Once an authorization matched, the attacker used the delegated contract to move assets.

Binance’s November 3 initial report said suspending withdrawals did not immediately stop all unauthorized transfers. Existing on-chain authorizations operated outside the normal withdrawal process and required separate revocation.

On the other networks, TRM observed ordinary signed transfers using different key types and signing schemes. It assessed that the attacker likely gained the ability to request signatures from Binance’s hot wallet signing infrastructure.

Binance later confirmed unauthorized access to an internal wallet signing service in its initial findings. The company said its investigation remains ongoing.

What the Investigation Found

Binance’s first update identified a potentially compromised DevOps engineer’s laptop and access to a service container. A later company statement said the investigation had identified additional points of breach. The BBC reported that update, including Binance’s statement that the attack was more complex than the use of one engineer’s permissions.

The company’s November 3 initial findings described a longer path. An engineer downloaded a malicious coding assignment during a fake recruitment process. Binance said the attacker used that compromised computer and an internal AI tool to gain control of two other engineers’ computers.

The attacker found a container deployment permission token on one engineer’s computer. Binance reported that the attacker used stolen credentials from that device, accessed another engineer’s computer, and deployed a container before the theft.

The company has not disclosed every technical detail of that progression. It also said independent security firms would review the incident and its findings.

The FBI attributed the theft to North Korean actors associated with the activity it calls TraderTraitor. That attribution identifies the actor the FBI holds responsible. It does not establish that every technical step has been publicly resolved.

What the Freezes Covered

Issuer and network interventions restricted part of the stolen assets. TRM counted approximately $2.7 billion frozen or moved out of the attacker’s reach by 00:30 UTC on October 30.

That estimate included approximately 1.77 billion USDT frozen by Tether and about 825 million USD Coin (USDC) frozen by Circle. Ripple and World Liberty Financial also froze assets. The Arbitrum Security Council moved 8,426 ETH and 74.6 million ARB out of the attacker’s reach.

The attacker converted some freezable assets while those actions were underway. TRM reported that approximately 325 million USDT was exchanged for roughly 122,300 ETH through market makers and other counterparties. Another attacker wallet supplied 60 million USDT to Aave and borrowed approximately 19,760 ETH.

In its November 3 findings, Binance reported approximately $2.85 billion frozen or intercepted, subject to reconciliation and market-price changes. It also said 98% of affected token assets had been replenished as of October 31.

Replenishment and recovery describe different outcomes. Binance said it replaced affected assets using its own resources. That statement does not mean investigators had recovered the corresponding stolen funds.

TRM’s November 3 tracing update described subsequent movements through lending receipt tokens, liquidity pools, and cross-chain swaps. Its observations were time-specific, and asset positions can change.

A Pattern Across Twenty Months

The Binance case is one of several attacks involving people or systems with authority over valuable transactions. The entry points and execution methods differ, so the incidents should not be treated as identical.

In the Drift Protocol investigation, TRM described signers being socially engineered into pre-signing transactions with hidden authorizations. Those transactions supported subsequent administrative changes and withdrawals.

For Binance, the reported path involved compromised devices, stolen deployment credentials, and access to signing operations. In both cases, the attack reached systems or people with authority to approve consequential actions. The controls and evidence behind each path still need separate examination.

Who Can Reach the Signing Service?

A signing service may sit behind several layers of access. A service catalog can identify the application owner. An identity directory can identify accounts. Endpoint records can identify managed devices.

The remaining work is to establish how those records connect. A team investigating one high-value service can start with four relationships:

1. A person uses an identity on a device.
2. That device or identity can reach an internal service.
3. A service or container can submit an authorized request.
4. A signing or approval system processes the request.

A network connection alone does not establish permission to request a signature. A documented dependency does not prove that a person held an active session. Security teams need identity, authorization, endpoint, and service evidence to verify each relationship.

Useful questions include:

• Which hosts can reach systems that sign, approve, or release high-value actions?
• Which identities and service accounts have permission to use those systems?
• Which devices are managed, and which require separate review?
• Which services or containers sit between those devices and the approval system?
• Who owns each system, and when was its access last reviewed?

Virima’s Trusted Runtime Truth approach brings asset and service context together: what exists, how it is connected, what changed, what could break, and who owns it. Security teams can use that context alongside their access-control evidence.

What Teams Can Map This Quarter

Start with one signing or approval service and work backward. Choose a service where an unauthorized action would have a material business consequence, such as a payment release, production deployment, or sensitive database change.

First, identify the service owner and the systems that support it. Record the application, hosting infrastructure, relevant containers, and any known upstream callers. Mark each relationship with its source and the date it was last checked.

Second, ask the identity and access teams for the accounts authorized to call or administer the service. Include service accounts and deployment credentials, not only named employees. Match those accounts to the devices and systems from which they can be used.

Third, compare the list with endpoint-management records. A device may appear in inventory while its current management state or assigned user requires confirmation. Escalate unknown owners and unmanaged devices that have production access.

Fourth, review the approval service itself. Confirm who can change its configuration, deploy a container into its environment, or modify the policy that controls requests. Test whether teams can revoke access without relying on the affected service.

Finally, repeat the review when ownership, deployment methods, or access policies change. Scheduled discovery cycles can help refresh infrastructure records, while access and session evidence must come from the systems that hold those records.

Where Inventory Fits

A configuration management database (CMDB) can hold records of infrastructure components and their documented relationships. Discovery data helps populate those records, subject to the environment, credentials, and scope configured for each run.

Virima Discovery uses agent-based and agentless techniques to collect infrastructure data. The Virima CMDB records configuration items and relationships that teams can use as a starting point for investigation.

Once a customer provides service definitions, ViVID™ builds service maps from the available relationship data. Those maps can help teams review documented application and infrastructure dependencies around a selected service.

The distinction matters during a security review. A service map can identify components and relationships available to it. Identity systems, endpoint-management tools, access policies, and logs remain necessary to establish effective permissions and active sessions.

Scheduled discovery cycles provide later observations for comparison. The interval should reflect how quickly the relevant environment changes and what the discovery configuration can observe. A missing relationship deserves investigation rather than an assumption that no path exists.

Start With One Approval Path

Select a signing or approval service and identify its owner. Trace the supporting systems and known callers, then validate identities, permissions, and device status against their authoritative records.

Bring that service to a Virima discovery and mapping demo to review how its infrastructure relationships could support the investigation.

Frequently Asked Questions