At a glance
- Our view: the US$6.34 billion theft was not the failure of one person or one tool. It was a chain of trusted access, followed patiently for four months.
- The wrong lesson: training staff to spot fake recruiters matters, but it would not have been enough on its own.
- Our advice: assume a laptop will fall, then limit what it can reach, control the transaction itself, rehearse the emergency stop, and test the whole chain.
Most headlines on the Binance theft lead with a fake job interview. We think a more useful question is how access to one engineer’s computer could, weeks later, reach the service that signs wallet transactions.
Wajahat Gondal, our Head of Risk Technology Development, puts the problem plainly:
“One of the biggest mistakes organisations make is treating cybersecurity as a technology problem rather than an organisational risk that spans people, processes, infrastructure and technology.”
What happened, briefly
On 29 October 2026, about US$6.34 billion left Binance’s hot wallets. The FBI has attributed the theft to North Korea’s TraderTraitor group, and Binance says it will absorb the loss rather than pass it to users.
Binance’s initial report traces the path back to June, when a wallet engineer installed a tampered software package. In September, a second engineer ran a malicious coding “assignment” after a fake recruitment process.
By 20 October, the attacker had control of further engineers’ machines, helped by an internal AI tool. Nine days later, stolen credentials and a deployment token led to the wallet signing service.
Why we think it worked
Binance was not an easy target. It says it detected and prevented 57 suspected North Korea-linked cases during 2026, and it caught the June download. For Wajahat, the concern lies elsewhere:
“What makes it concerning is not just the financial impact, but how the attackers managed to exploit multiple layers of trust and security over an extended period before reaching critical financial infrastructure.”
That is our reading too. At each stage, the attacker used something that was already trusted:
- A trusted setting: a legitimate job platform and a live video interview.
- A trusted colleague: a compromised employee’s environment, from which an internal AI tool was used to reach others.
- Trusted permissions: valid credentials and a container deployment token.
- A trusted service: a signing service used to start transactions outside the normal withdrawal process.
No single control was positioned to question all four. Binance’s findings are still under independent review, so this is our interpretation rather than an established finding.
What we advise
1. Train by role, not by calendar
The September lure was convincing, with a live call and a social media account full of personal photos and videos. Annual awareness training was not built for that. As Wajahat says:
“Employees, particularly developers but also DevOps engineers and privileged users, need continuous, role-specific security training to recognise impersonation, fraudulent recruitment campaigns, malicious software packages, fake developer tools and other increasingly convincing social engineering techniques.”
Our practical rule: code from a recruiter or outside contact never runs on a work machine. We would also show privileged staff what their public profiles reveal, because the September target’s profile referenced experience at Binance.
2. Assume the laptop falls, then limit its reach
This is the centre of Wajahat’s head of tech’s argument:
“Organisations must also assume that human error and endpoint compromise will eventually happen. The critical question is what an attacker can access once an employee’s device or credentials are compromised.”
Try this exercise: pick one developer’s laptop and map what it could reach today. Look for long-lived tokens stored on the device, and for internal tools, AI tools especially, that act with that user’s permissions.
The answer should sit comfortably with this standard:
“A compromised developer workstation should never become a pathway to production infrastructure, and possession of valid credentials should never automatically translate into unrestricted access to critical systems.”
3. Put controls on the transaction itself
Wajahat’s view is that the last line of defence belongs around the money, not only around the login:
“Financial platforms also require strong transaction-level security, independent authorisation, strict signing policies, withdrawal limits, anomaly detection and effective emergency revocation mechanisms.”
The test for any firm: could one set of valid credentials move a high-value sum without a second, independent approval? The same question applies to a treasury team releasing a bank payment.
4. Rehearse the emergency stop
Binance acknowledges that suspending withdrawals alone could not stop every unauthorised movement. The attacker had used an Ethereum feature, EIP-7702, to give their own contract partial rights over a hot wallet, and that permission sat outside the withdrawal systems.
Revoking it also took time, because the wallet’s multi-party design meant no single key could cancel it at once.
Our advice: list every standing permission that would survive a shutdown, such as API keys, tokens and delegated rights. Then practise revoking them before the day you need to.
5. Question every trusted connection
Wajahat makes the same point about telecoms, following the recent and unrelated Android “SMS of Death” flaw:
“Security teams should not simply assume that traffic reaching their messaging infrastructure is trustworthy because it originates from an established aggregator or authorised connection.”
For banks using SMS one-time passwords, the messaging chain is a dependency that belongs in the risk assessment. The principle holds for any supplier or integration: authorised does not mean safe.
6. Test the chain, not just the parts
A scan of public-facing systems would say little about a path like this one. Wajahat’s advice is that security testing should cover the complete attack surface, from employee endpoints and identity systems to development pipelines and third parties:
“More importantly, it should evaluate whether individual weaknesses can be chained together to achieve lateral movement, privilege escalation, persistence and ultimately access to sensitive systems or financial assets.”
This is how we approach testing. Our Vulnerability Assessment & Penetration Testing engagements begin with what an attacker could learn from the outside, drawing on our background in intelligence and investigations. An Advanced engagement links weaknesses together and follows realistic attack paths, under signed Rules of Engagement.
The measure that matters
Spending on security tells a board very little about how an organisation would hold up on a day like 29 October. Wajahat offers a better measure:
“A company is not secure simply because it has invested in security products; it is secure when its people, processes and technology can collectively prevent, detect, contain and recover from a sophisticated attack.”
If you would like to explore what that chain could look like in your own organisation, we are glad to have a confidential conversation.
Based on Binance’s initial report and public reporting as at 6 November 2026. Futurum Risk has no involvement in the investigation. Binance’s findings are subject to independent review, so parts of this picture may change.
