Security · Nov 4, 2026 · 7 min read

The Binance Attack Chain, Part 2: Homebrew, a Fake Job and an Internal AI Tool.

Binance's incident report shows how a tampered Homebrew install and an internal AI tool led to a $6.3B theft, and where endpoint AI security could stop it.

The Neo Team

Key Takeaways:

Binance's November 3 incident report shows the $6.3 billion theft was a five-month campaign across three engineers' laptops, not a single compromised machine.
AI tools sat at two turning points: the first infection was a tampered Homebrew install pulled while searching for an AI coding tool, and the attacker later used an internal AI tool to take control of two more engineers' machines.
Four of the five stages ran on developer laptops, where endpoint controls that inventory AI tooling, govern agent actions and gate access to secrets can break the chain.

Last week we wrote about the $6.3 billion laptop, based on Binance's preliminary finding that the largest crypto theft on record began on a developer's machine. On November 3, Binance published its incident report. The laptop story holds up. The report also adds two facts that matter to any company putting AI tools in front of its engineers.

Both facts involve AI tools. The first infection came from an engineer's search for an AI coding tool. Months later, the attacker used an internal AI tool to take over two more engineers' machines.

The attack took five months and compromised three engineers

Binance describes a campaign that ran from June to late October.

June. A Wallet DevOps engineer went looking for a popular AI coding tool and installed a tampered Homebrew. Binance spotted it, replaced the laptop and rotated his credentials. By then the attacker knew his role and the names of his colleagues.

September. Someone posing as a project director approached a second engineer about a job. The process ended in a chat interview with the "CEO" of a company that doesn't exist, followed by a take-home coding assignment. He ran it on his work laptop. The code swapped the Homebrew-managed pyenv binary for a malicious copy that took commands from the attacker's server.

October 20. Working from that laptop, the attacker "used an internal AI tool to gain control over" the Wallet DevOps engineer and a third engineer on the wallet software team. On the DevOps engineer's machine sat a container deployment token.

October 29. The attacker logged in to the third engineer's computer and used the stolen token to deploy a container. A script inside it called Binance's wallet signing service, which signed 50 transactions setting up an EIP-7702 delegation on a hot wallet. Funds left between 20:05 and 23:56 UTC.

About $6.34 billion was affected. Binance has frozen or intercepted roughly $2.85 billion and says it has replenished 98% of affected assets. The FBI attributes the attack to North Korea. In co-CEO Richard Teng's words: "This wasn't one mistake or one breach — it was a months-long campaign."

The first entry point was a malicious Homebrew install

Installing a new AI coding tool is ordinary developer work. New ones appear every week. Most arrive through a package manager or a one-line install script, and few companies review them before they run.

Binance caught this one. The attacker still left with a name, a role and a list of colleagues. Four months later, the same engineer's laptop held the deployment token used in the theft.

An internal AI tool gave the attacker two more laptops

Binance hasn't said how the attacker used the tool, and it reports no vulnerability in it. The attacker was signed in as a real engineer. Whatever that engineer could do through the tool, the attacker could do too, and that included reaching two colleagues' machines.

Teams connect internal AI tools to more systems every quarter, because that's how the tools become useful. Someone who compromises a laptop inherits all of that access.

EDR never flagged the swapped pyenv binary

Binance's report says the malicious pyenv "was not detected by the endpoint security protection tools at the time." Part 1 covered why. EDR sees a developer tool making network calls and finds nothing unusual. Identity checks passed because a real engineer's account was in use. The network saw a laptop talking to a server, and no tool was recording what the internal AI tool did on the engineer's behalf.

Each of those controls did what it was built to do. The attack went through the packages, tools and agents inside trusted software, and none of them inspects that layer.

Four of the five stages ran where Neo's sensor sits

Neo's sensor runs on the developer laptop. Here's how it applies to each stage in Binance's report.

June: the tampered Homebrew. Neo inventories the software on each endpoint and checks it against Neoverse, its library of more than 4 million profiled software artifacts. A package manager or AI coding tool that doesn't match a known artifact is raised as an Issue. Known-malicious software can be blocked across the fleet.
September: the replaced pyenv. Neo builds a full software inventory in under 15 minutes and keeps it current, so a swapped binary on a laptop that can reach production shows up while the attacker is still preparing. Session tracking adds context. A familiar tool that starts a shell and connects to an unknown server stands out.
October 20: the internal AI tool. Neo inventories the agents, MCP servers and Skills on each laptop and records which one performs each sensitive action. Risky agentic actions, such as package installs and secret reads, can require a person's approval first.
October 20 to 29: the deployment token. Neo enforces policy when software tries to read secrets such as cloud tokens, kubeconfig files and SSH keys, and it acts before the read completes. It also blocks a credential read followed by an outbound connection from the same process, even when each step would be allowed alone.

The final step, the container deploy and the calls to the signing service, ran on Binance's servers. Everything that made it possible happened earlier, on laptops, over five months.

Audit AI tool installs and internal AI access this week

Part 1's four steps still apply. The report adds three more:

Treat AI tool installs as a software supply chain. List the AI coding tools on your developers' machines, where each one came from, and whether it matches a known-good build.
Map what your internal AI tools can reach. For each tool, list the systems and machines it can act on for a user. Require approval before it touches someone else's machine or production.
Keep interview code and deploy credentials off work laptops. Run take-home assignments and other untrusted repos in an isolated environment. Make deployment tokens short-lived and narrowly scoped.

In Part 1 we said the attack depended on one early link, and that link was an endpoint. The report shows several such links. AI tools were involved in two of them. AI security starts at the endpoint.

To see how Neo maps to your own developer fleet, request a demo.

FAQs

How did the Binance hack happen?

According to Binance's November 3 incident report, the attack ran from June to October and went through three engineers. It started with a tampered Homebrew install and moved on to a malicious take-home coding test from a fake recruiter. An internal AI tool then gave the attacker access to two more engineers' machines. On October 29, the attacker used a stolen container deployment token to reach Binance's wallet signing service.

What role did Homebrew play in the Binance hack?

In June, a Wallet DevOps engineer searching for a popular AI coding tool installed a tampered Homebrew. Binance caught it, replaced the laptop and rotated credentials, but the attacker had already learned the engineer's role and colleagues. In September, a second engineer's laptop was infected, and the malware swapped the Homebrew-managed pyenv binary for a malicious copy.

How was an internal AI tool used in the Binance hack?

Binance says the attacker "used an internal AI tool to gain control over" two wallet engineers, working from an already compromised laptop. Binance hasn't described how the tool was used and reports no vulnerability in it. The attacker was signed in as a real engineer, so the tool acted with that engineer's access.

Who was behind the Binance hack?

The FBI attributes the attack to North Korea. TRM Labs and Chainalysis tie it 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.

How much was stolen in the Binance hack, and how much was recovered?

About $6.34 billion was affected. Binance says roughly $2.85 billion has been frozen or intercepted, and it has replenished 98% of affected assets.

How can security teams protect against attacks like the Binance hack?

Inventory the AI coding tools on developer machines and check where each one came from. Map what internal AI tools can do on a user's behalf, and require approval before they act on another person's machine or on production. Keep take-home tests and other untrusted code off work laptops, and make deployment tokens short-lived and narrowly scoped.

Sources

All posts