PENTESTY · EDITORIAL ANALYSIS · · 4 min read
Binance: evidence for validating withdrawal authorization
An operation accepted by a system should match the authorization the business intended. Verify that connection before accepting the recovery of a sensitive workflow.
By Pentesty
What the statements support
In its October 30, 2026 statement, Binance estimated losses of approximately US$6.3 billion and reported other points of compromise beyond the initial laptop hypothesis. This is the operator’s statement during an ongoing investigation, without independent technical verification by Pentesty.
TRM Labs’ October 29 analysis attributed the attack to TraderTraitor with high confidence. Elliptic’s version updated October 31 considered that attribution likely. We retain those qualifications rather than present them as a government conclusion. This article proposes an enterprise assessment model without establishing the incident’s full cause.
Map who can turn a request into execution
In your environment, identify the person or application initiating a request, the service identity transmitting it and the component deciding whether to execute it. List the effective permissions at each stage. An account used to monitor a queue may have a different role from one authorized to approve execution.
Document the expected conditions: asset, destination, amount, environment and any additional approval required. Check who can modify those conditions and whether a later change invalidates earlier approval. This is a test proposed by Pentesty, not a description of missing Binance controls. Our analysis of claims and evidence helps maintain that distinction during an investigation.
Compare an allowed operation with one that should be denied
Define an exercise using synthetic identities, destinations and data in a representative, authorized environment, without moving real assets. Agree on the expected outcome and exercise boundaries with technical and operational owners beforehand. Also record the legitimate behavior that needs to keep working.
- Valid request: check that execution preserves the destination and conditions that received approval.
- Action outside the assigned role: use a test identity lacking the required permission and observe the denial at the executing component.
- Change after approval: modify a relevant field in the synthetic request and check whether the workflow requires a new decision.
- Revoked credential: repeat a pending operation using the revoked identity and record the expected result, without reusing real compromised credentials.
Define the evidence needed to accept recovery
Connect each result to the test request, application version, identity used and approval record. Look for evidence at the component that received the operation, including denials. A success screen alone does not establish which permission was applied or whether another integration retained an earlier authorization.
Check scheduled jobs, queues and integrations that remained active during containment. After changing a permission, repeat the relevant scenarios and record exceptions with an owner and deadline. Our beneficiary-change exercise addresses a similar boundary in another context: connecting the approved request to the destination actually used.
Keep the operational decision separate from public communication
NIST SP 800-61 Rev. 3 integrates incident response with risk management. In the assessment proposed here, the service owner accepts an explicit set of results and limitations. Define how remaining failures will be monitored and under what conditions the workflow should be stopped again.
An announcement of financial coverage, an expected resumption date and a frozen amount provide different information from completed recovery and verified operation. Record the source, date and scope of each update. Avoid treating a provider’s expectation as evidence that your own integration is ready to resume.
Frequently asked questions
Does an absence of evidence of leaked keys end the review?
No. Acceptance also needs to consider who can request an operation and which conditions the executing component checks. The proposed tests assess that authorization without assuming how Binance was compromised.
Is North Korean attribution presented as an official conclusion?
No. This article attributes the assessment to TRM Labs and Elliptic, retaining their confidence levels. The enterprise analysis does not independently establish who was responsible.
Can a frozen asset be counted as money already returned?
These are different states. Record the restriction observed, who controls the asset and which document establishes any subsequent return. Do not add announcements from different sources as though they were independent amounts.
What evidence should be requested before reopening the workflow?
Request the connection between a synthetic request, its approval and the result at the executing component, including the expected denial for an identity lacking permission. Also document legitimate operation, limitations and who accepted the result.
Sources and references
- Binance: October 30 statement
- TRM Labs: October 29 analysis
- Elliptic: analysis updated October 31
- NIST SP 800-61 Rev. 3: incident response
Original Pentesty analysis, published October 31, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.