In late October, Binance disclosed a security incident affecting about $6.3 billion in assets, by most counts the largest crypto theft on record. On November 3 it published its initial findings, and they read less like a crypto story than a case study every engineering team should read. It started with a job interview. And the attacker never needed a wallet's private key: a legitimate internal signing service moved the money for them.
What happened
Binance's initial report lays out a chain that took months to build.
- June: a tampered developer tool. A wallet DevOps engineer looking for an AI coding tool installed a tampered Homebrew package. Binance says it caught the anomaly, replaced the device and rotated credentials, but the engineer's role and team had already been exposed to the attacker.
- September: a fake job interview. A second engineer was approached on a job-hunting platform, interviewed by people posing as a recruiter and a company CEO, and asked to download a coding "assignment" onto his work computer. Its setup script quietly swapped part of a common developer tool, pyenv, for a malicious version.
- October 20: an internal AI tool as a springboard. From that machine, the attacker used an internal AI tool to gain control over the first engineer and a third. On the first engineer's computer, they found a container deployment permission token.
- October 29: one container. Working from the third engineer's computer with the stolen credentials, the attacker deployed a container and ran a script that reached an internal wallet signing service. They used it to sign transactions outside the normal withdrawal process, including authorizations that gave an attacker-controlled contract partial control of a hot wallet. Outflows started at 20:05 UTC; Binance cleared the malicious authorization at 00:10 UTC on October 30.
Binance says some technical details will stay confidential, and an independent third-party review is still to come.
How it played out
Binance paused withdrawals on October 30 and began restoring them in phases on November 1, starting with 15 networks. As of its November 3 update, about $2.85 billion of the affected assets had been frozen or intercepted, and Binance says 98% of the impacted token assets had been replenished as of October 31, with the less liquid remainder still being bought back. On October 31, the FBI attributed the theft to North Korea's TraderTraitor activity. North Korea has denied it.
Binance also says it has rebuilt the affected wallet system in a new environment, rebuilt the internal AI tool and its access controls, replaced affected devices, retired the engineers' credentials and tokens, and scanned every employee device. Its users were made whole quickly. That's the exception, not the rule.
Why it matters if you don't run an exchange
Strip away the crypto and every step is familiar. A developer installed a tool from the wrong place. Another ran a stranger's code on a work laptop. An internal AI tool could reach other people's machines. A deployment token sat on a laptop. And a workload was allowed to sign something valuable without a second check. No key had to be stolen, because the system that held the keys did the work.
Most AWS environments have a path like that somewhere: a laptop with long-lived access keys or deploy tokens, an internal assistant with broad access, a service role that can move money, data or permissions on its own. Encryption and key management protect the keys. They don't protect against a legitimate system being told to use them.
Five things worth checking in your own environment
- No long-lived credentials on laptops. That includes deploy tokens, not just access keys. Engineers should sign in through IAM Identity Center and get short-lived credentials. Find IAM users with active access keys and retire them.
- Production changes go through the pipeline, not a laptop. Keep production in its own AWS accounts, deploy through a pipeline that needs a review, and reach workloads through AWS Systems Manager Session Manager with session logging.
- Treat internal AI tools as privileged. Give them their own narrowly scoped roles, log what they do, and don't let them act on other people's machines or accounts.
- Two people for high-value actions. Anything that moves money, exports data or changes permissions should need a second approval and have a limit. Build it into the workflow, not just a policy document.
- Watch the runtime, not just the perimeter. Turn on Amazon GuardDuty Runtime Monitoring for containers and instances, and alert on unusual API calls from workload roles in AWS CloudTrail.
The lesson that outlasts the headlines
Binance could absorb a loss this size. Most companies couldn't. Protecting the keys isn't enough. You also have to protect everything that's allowed to use them, and assume one of those things, a laptop, a developer tool or an AI assistant, will be compromised eventually. Design so that when it happens, the damage stays small and someone notices fast.
Want a second pair of eyes on these paths in your AWS environment? Our security reviews start with one question: what could a compromised laptop reach?
Sources: Binance, 29 October 2026 Binance Security Incident: Initial Findings and Response Update (November 3, 2026); The Hacker News (October 30 and November 3, 2026); TechCrunch (October 29, 2026); CNN and Al Jazeera (November 1, 2026); CSO Online (November 2, 2026). Figures are Binance's and may change as its review continues.