Binance's preliminary November report gives a more useful explanation of its roughly $6.3 billion breach than the first account of a compromised laptop. It describes a route through developer access and internal tooling to the service authorised to sign wallet transactions. That path is the part other organisations need to understand.
The financial scale is exceptional. The security question is recognisable: what authority can a stolen developer credential acquire after its first successful login, and which independent controls still stand between it and the consequential action?
Put the dates in one time zone
Binance's 30 October update places the compromise at approximately 20:05 UTC on 29 October. Its later account calls this the 30 October incident using UTC+8. Those descriptions can refer to the same event: 20:05 UTC on the 29th is 04:05 the following morning in UTC+8.
That small conversion matters when comparing alerts, transactions and announcements. A date mismatch is not automatically a contradiction. Readers should first establish the time zone and whether a figure represents an initial observation or a subsequently revised total.
The 30 October statement put the loss at approximately $6.3 billion. It said the company would absorb the impact through SAFU and corporate treasury funds, described additional breach points beyond its initial laptop theory, and said it had found no evidence of wallet private-key leakage at that stage. Those were the company's statements during an active investigation.
The newer account follows the permission path
In its preliminary investigation report, updated through 3 November, Binance describes social engineering involving fake interviews and malicious software, compromised employee devices, an internal-AI-tool pivot and access to credentials with container-deployment permissions. It says the attackers reached the internal wallet signing service and bypassed normal withdrawal processes.
That is a much more specific account than “somebody clicked something.” It identifies transitions between systems with different purposes and different permissions. A review should ask what enabled each transition and what evidence would reveal it occurring again.
The report remains preliminary and says further independent review is planned. It therefore provides a current working account from the affected company, not a completed independent reconstruction of every control failure. Its value is in the concrete path it now describes and the questions that path makes possible.
A valid signature can still authorise the wrong thing
TRM Labs' early forensic analysis estimated $6.36 billion in transfers, using its stated observation cutoff of 00:30 UTC on 30 October. It observed activity across ten blockchains and assessed the cross-chain valid signatures as evidence pointing towards signing infrastructure. Its Ethereum analysis described abuse of EIP-7702 delegation.
The EIP-7702 specification explains a mechanism by which an externally owned account can authorise delegated code. That is a legitimate protocol capability. Security depends on who can obtain an authorisation and what the resulting delegation permits.
The engineering consequence is that protecting key material and controlling signing requests are related jobs. A service can keep the underlying secret within its intended boundary while an attacker obtains a signature for an unauthorised action. “No evidence the private key leaked” consequently cannot, by itself, establish that the wallet's effective authority stayed under control.
For another organisation, the useful review follows a request all the way through: who submitted it, how its meaning was interpreted, which policy approved it and what authority persisted after it was signed. A diagram ending at a box labelled “secure signer” leaves the most consequential questions unanswered.
Stopping withdrawals did not revoke every permission
Binance's November account says stopping its normal withdrawal systems did not immediately neutralise delegations already placed on-chain. Revoking those permissions required additional transactions. This distinction explains why an exchange-side shutdown and blockchain-side containment need separate completion criteria.
The general pattern extends beyond wallets. Suspending an account does not necessarily remove every permission, session or delegated capability that account previously created. An incident team needs an inventory of durable authority, with a way to identify and retire it during containment.
This is my operational inference from the reported sequence, rather than a claim about an undisclosed Binance control. For a hypothetical signing service, an emergency plan should cover both disabling new signing requests and dealing with previously issued authorisations. The test is whether the plan accounts for the system's actual semantics.
Attribution now has an official source
The FBI's notice attributes the theft to North Korea and identifies the activity as TraderTraitor. That is a government attribution statement. TRM's assessment is a separate source with its own methods and confidence language.
Attribution helps explain the threat context. It does not substitute for answering the affected organisation's access-control questions. An attacker label and a reconstruction of the internal permission path provide different kinds of information, and both should keep their source attached.
Keep three financial questions separate
Reports about this incident use amounts for assets stolen, assets frozen and assets replenished. These measures describe different things. A restriction on an attacker-held asset is not the same event as returning that asset, and company funds acquired to meet customer obligations are not recovered stolen funds.
Binance's 1 November recovery announcement described phased withdrawal restoration and asset replenishment. Those are important service and funding milestones. They do not, by themselves, complete the technical investigation or establish that every affected asset was recovered.
When a figure changes, ask for its cutoff, valuation basis and definition. Comparing a later company freeze estimate with an earlier analyst total without those details can produce confident arithmetic with no coherent meaning.
The next useful report will make the authority transitions and the corresponding repairs inspectable: which developer and deployment permissions changed, how signing policy was strengthened and how residual delegations were handled. Those are the details that turn a very large loss into lessons another team can actually evaluate.
A thought worth keeping?
