Binance’s $6.3 Billion Heist Ran Through an Internal AI Tool

The Binance heist shows how attackers exploited developer access and an internal AI tool to steal billions. Learn how to secure AI agents and credentials.

Tal Lessin

Nov 6, 2026

On Oct. 29, attackers stole $6.34 billion from Binance in four hours, the largest crypto heist on record. The story behind how the attack developed highlights the new risks AI coding tools can pose and steps security leaders can take to secure their agents.

Starting four months before the heist, attackers worked their way into Binance’s developer toolchain. They didn’t touch a wallet system until the day of the theft. Two engineers were tricked into running malicious software, and an internal AI tool let the attackers access a third.

A timeline of what happened

The FBI has attributed the theft to TraderTraitor, a North Korean hacking group. Here’s the timeline from Binance’s initial report:

Date	What Binance says	What it means for defenders
June	A wallet DevOps engineer (Engineer A) searched for a popular AI coding tool and installed it on his work computer through a tampered Homebrew installation. Security caught it, replaced the device, and rotated his credentials.	AI coding tools can now be bait if they’re installed outside of an approved software list and especially if they came from the web. Binance followed the standard protocol here.
September	A second engineer (Engineer B) was approached on a job platform by a fake “project director,” went through two rounds of interviews (HR on video, the “CEO” over chat), and downloaded a take-home assignment onto his work computer. The setup script for the assignment swapped the real pyenv for a lookalike file and connected to an attacker server.	This is North Korea’s well-known fake-recruiter playbook. Swapping out `pyenv` likely gave the attackers persistence, since `pyenv` is often loaded every time a terminal opens. And they replaced a trusted tool instead of dropping a new file, which is why endpoint tools missed it.
Oct. 20	Using Engineer B’s computer and an internal AI tool, the attackers “gained control over” Engineer A and a third engineer (Engineer C). They found a container deployment token on Engineer A’s computer.	This is where the incident veers from previous crypto heists. Binance hasn’t said how the AI tool was used, but it was what let attackers access other engineers’ computers. And despite June’s rotation, a valid credential still lived on that person’s machine.
Oct. 29, 17:15–19:56 UTC	The attackers logged into Engineer C’s computer, used Engineer A’s stolen token to deploy a container, and ran a script against an internal wallet signing service.	None of the three compromised engineers was a malicious insider. A single deployment credential could reach production signing infrastructure.
Oct. 29, 20:05–23:56 UTC	Five hot wallets drained across several chains. About $6.34 billion affected, and Binance says it froze or intercepted about $2.8 billion.	The attackers spent four months carefully arranging the pieces to execute an attack that took a few hours.

Matching a pattern from our research

Cyera Research scanned more than 1 million AI skills, the instruction files that tell coding agents how to do a task, and found hundreds built to steal credentials or open a shell using the same lure the Binance attackers did: install something that promises to make the work easier. Developers install and run things all day, and that reflex is what both the attackers and the malicious skill authors we tracked are exploiting. In our analysis of the AMOS infostealer campaign across 516 skill samples, developer tools were the most common lure, at roughly 36%.

In a separate investigation, we examined a fake version of Anthropic’s PDF skill in which 11 of 14 files were byte-for-byte identical to the original, with a 5 MB obfuscated binary added to give a remote operator a bash shell. The Binance malware made the same bet: it deleted the real pyenv and put its own copy at the same path under the same name, 70 bytes heavier. Both counted on no one checking a file that looks like one they already trust.

There’s no indication at this point that a poisoned skill was part of the Binance chain. But Binance says it blocked 57 suspected North Korea-linked attempts this year and lists “malicious software disguised as popular developer tools” and “compromised software packages” among the techniques.

What security teams should do

Binance’s remediation list makes sense: rebuild the wallet system, rebuild the AI tool and its access controls, revoke the tokens, re-scan every device, and add behavioral detection. Here are other best practices if your developers use AI coding tools:

Lock down your internal AI tools. In the coding-agent deployments we see, three gaps come up most often:

One identity for everyone. The agent runs as a shared service account, so anyone who can reach the agent gets its access. Run it as the person using it, or scope the service account to the minimum it needs.
A hub between machines. The agent runs on a server or container that several engineers connect to, which makes it a path from one person’s laptop to everyone else’s. Harden, monitor, and segment that host the way you would a bastion.
No record of what it did. Tool calls aren’t logged, or they are and nobody reads them. Log every call with the identity behind it and make sure someone checks the logs.

Watch the tools your developers already trust. Nobody can hash-check every package on every laptop, but you can alert on behavior that shouldn’t happen: a package manager binary replaced or relinked outside an install, or a tool like pyenv opening an outbound connection it never made before. Apply the same thinking to agent skills and MCP servers, and track them like a dependency tree: what changed, when, and from where.

Keep credentials that reach production off endpoints. Binance hasn’t said whether the deployment token on Engineer A’s machine survived June’s rotation or was issued afterward. Either way, any team with a deploy token, a cloud key, or a CI secret at rest on a laptop has the same exposure. Make those credentials short-lived, scoped to one job, and issued at the moment of use.

Treat engineers on sensitive teams as targets. Engineers on wallet, payments, and deploy teams get approached one by one, and the fake-recruiter playbook used here has been public for years. Brief them on it, and set a policy that interviews, take-home tests, and side projects never touch a work machine. When one of them is compromised, widen the response: review who that engineer works with and what credentials they share, and ask whether anyone else on the team has come across anything similar.

What to look for

If you want to hunt this week, start here.

On developer endpoints: /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv at 3,414 bytes instead of 3,344; recent modifications under /opt/homebrew/Cellar/*/libexec/ and /opt/homebrew/bin/; new symlinks into those paths; outbound connections from pyenv when it isn’t installing a Python version. Start with wallet, payments, and deploy teams.

In agent configuration: a binary inside a skill directory; a SKILL.md that has shrunk sharply compared with upstream; Base64 or otherwise encoded commands; a “Prerequisites” step that installs something the upstream README doesn’t mention.

On credentials: Look for identities that hold massive access permissions to sensitive processes and data. Check those identities for any suspicious endpoint behavior or token usage that could point to emerging threats.

How Cyera helps

Most companies adopted AI tools faster than they could track them, so many don’t know what agents are running, what they can reach, or what they did. Cyera Agent Guardian covers those three areas.

It inventories the agents, skills, and MCP servers in your environment and the identities and data each one is linked to. That helps you spot a privileged identity shared across many agents before an attacker finds it. Agent Guardian checks skill files for vulnerabilities and embedded secrets, evaluating agent actions against your policies in real time to flag or block unapproved tool calls before they happen.

See the full malicious skills research, including an interactive game, a video overview, and technical blogs.