The $6.3 Billion Laptop: Where Neo Breaks the Binance Attack Chain
The $6.3B Binance theft began on a DevOps engineer's laptop. See why EDR, MDM, and identity tools missed it, and where Neo breaks the attack chain.
The Neo Team
Key Takeaways:
- The $6.3 billion Binance theft began on a compromised DevOps engineer's laptop, not with a smart contract bug or leaked private keys, according to Binance's preliminary findings.
- EDR, MDM, network, and identity controls all worked as designed, but none of them covers the extensions, packages, MCP servers, and Skills running inside trusted developer tools.
- Endpoint controls that inventory developer tooling, gate access to secrets, and track behavior across a session can break the attack chain before it reaches production.
According to Binance's preliminary findings, the largest crypto theft on record started on a DevOps engineer's laptop. No smart contract bug. No leaked private keys.
If you run security anywhere, not just at a crypto exchange, that should get your attention. Your engineers' laptops hold a path to production. The software on them changes every day, most of it never shows up in your existing tools, and most of it now takes actions on its own. Agentic apps behave less like applications and more like small operating systems running inside trusted ones. Below is the attack chain as it's known today, and where Neo's sensor would have cut it.
What we know so far
On October 29, roughly $6.3 billion left Binance hot wallets across ten blockchains, most of it within about 20 minutes. Partners including Tether and Circle froze about $3 billion within hours, and Binance has pledged to cover all user losses.
Binance says a compromised DevOps engineer's laptop let an attacker reach a service container inside its withdrawal infrastructure, and that container could submit withdrawals. Binance found no evidence that private keys leaked. On Ethereum, the attacker used EIP-7702 authorizations to make a hot wallet run a sweeper contract.
TRM Labs and Chainalysis attribute the attack to TraderTraitor, the North Korean unit blamed for the $1.5 billion Bybit theft in 2025. The group is known for targeting developers through fake job interviews, trojanized code, and malicious packages. Binance noted that staging began well before the theft.
Binance hasn't confirmed the attribution, and its leadership says there were additional points of breach beyond the laptop. The full technical post-mortem isn't out yet, so some of what follows may change.
Why the stack trusted the attacker
TraderTraitor's playbook is to get developers to install the attacker's code themselves: a take-home coding test, a useful-looking package, an IDE extension. To controls built around scanning binaries, none of that looks unusual.
- EDR sees a signed IDE or terminal reading files and making network calls. An approved process doing approved things raises no alert.
- MDM sees the application, not what gets loaded into it. Extensions, packages, MCP server configurations, and Skills sit in the user's home directory, below what MDM inventories.
- Network controls see traffic to approved destinations: package registries, code hosts, cloud APIs.
- Identity controls see a valid engineer, authenticated, using the access they legitimately hold.
Every one of these tools worked as designed. None of them covers the software running inside trusted applications, under a trusted identity. A DevOps laptop that can reach production deserves the same scrutiny as the hot wallet it can reach. Most companies treat it like any other laptop.
Where Neo breaks the chain
Neo's sensor sits on the laptop, exactly where this attack began. That gives SecOps three places to stop it before it reaches production.
- Stopping the way in. TraderTraitor's known entry points are malicious packages, trojanized interview repos, and poisoned developer tooling. Neo inventories every piece of software on the endpoint, including the non-binary pieces other tools miss: extensions, libraries, MCP servers, and Skills. Each one is checked against Neoverse, Neo's library of more than 4 million profiled software artifacts. A known-malicious artifact raises a Critical Issue and can be blocked across the fleet. Package installs started by coding agents can require a human to approve them first.
- Protecting the keys to production. The attacker needed the laptop's path into production: cloud tokens, kubeconfig files, SSH keys. Neo enforces policy at the moment an extension, agent, or MCP server tries to read secrets like these, before the read completes. Neo can block the read or require a human to approve it, and it records which piece of software attempted it.
- Catching the sequence. On its own, a credential read can be routine, and so can an outbound connection. Back to back from the same process, they're an exfiltration pattern. Neo tracks state across the session, so a request that would be allowed on its own is blocked when the same actor has just touched sensitive secrets.
Then there's the staging, which Binance says started well before the theft. Neo builds a full software inventory in under 15 minutes and keeps it current. New, unrecognized software or a fresh MCP configuration on a production-adjacent laptop would surface as an Issue while the attacker was still pre-positioning, not after the money moved.
No single product stops a nation-state crew. But this attack depended on one early link, and that link was an endpoint. AI security starts at the endpoint.
What to do this week
Any engineer whose laptop can reach production is a target. Four things to do now:
- List your production-adjacent endpoints. Find every laptop holding credentials or tooling that can touch production, deployment pipelines, or payment systems.
- Inventory what runs on them. Cover extensions, packages, MCP servers, and Skills, not just installed applications. If you can't produce this list today, that is the first gap to close.
- Put a human in the loop for risky steps. Require approval for package installs and secret access by agentic tooling on those machines, while leaving low-risk work untouched.
- Test your session visibility. Ask whether any control you own would notice a credential read followed by an outbound connection from the same process.
To see how Neo maps to your own developer fleet, request a demo.
FAQs
How did the Binance hack happen?
According to Binance's preliminary findings, an attacker compromised a DevOps engineer's laptop and used it to reach a service container inside Binance's withdrawal infrastructure. That container could submit withdrawals, and roughly $6.3 billion left Binance hot wallets across ten blockchains on October 29, most of it within about 20 minutes.
Who was behind the Binance hack?
TRM Labs and Chainalysis attribute the attack to TraderTraitor, the North Korean unit blamed for the $1.5 billion Bybit theft in 2025. The group is known for targeting developers through fake job interviews, trojanized code, and malicious packages. Binance hasn't confirmed the attribution.
Were Binance's private keys stolen?
Binance says it found no evidence that private keys leaked. The attacker used a service container that could already submit withdrawals, and on Ethereum used EIP-7702 authorizations to make a hot wallet run a sweeper contract.
How can security teams protect developer laptops that can reach production?
Start by listing every endpoint that holds credentials or tooling for production. Inventory everything that runs on those machines, including extensions, packages, MCP servers, and Skills. Require human approval for package installs and secret access by agentic tools, and confirm that a control would notice a credential read followed by an outbound connection from the same process.