---
title: "How the Binance Hack Happened: From a Search Ad to $6.3 Billion"
description: "The $6.3B Binance theft didn't start on-chain. It started with two engineers. Here is the full attack chain from the post-mortem."
category: "Attack breakdowns"
date: 2026-11-05
canonical: https://www.brside.com/blog/how-binance-hack-happened-search-ad-to-6-3-billion
source: "Brightside AI"
image: https://www.brside.com/assets/how-binance-hack-happened-search-ad-to-6-3-billion.BAjcQoXI.jpg
---

# How the Binance Hack Happened: From a Search Ad to $6.3 Billion

The largest crypto theft on record started with an engineer clicking a search ad. Months later, a second engineer sat through a job interview with attackers posing as recruiters, then ran their "assignment" on a work laptop. On the night of 29 October 2026, attackers used the access gained through those compromises to move about $6.3 billion out of Binance hot wallets in under four hours. The [FBI attributes the theft](https://www.fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack) to TraderTraitor, a North Korean group with a long record of exchange heists.

On 4 November, Binance co-founder Changpeng Zhao acknowledged that "serious security failures occurred" and that "some details are embarrassing". Binance's post-mortem describes how the attackers reached its wallets. Most of the steps involved compromised employees and internal systems, and those failures apply to companies outside crypto too. We'll examine each step and what could have stopped it.

## What happened in the Binance hack

The theft began late on 29 October and was over in under four hours. Binance's first figure was $6.3 billion, and its post-mortem puts the loss at $6.34 billion. TRM Labs counts $6.36 billion. [Elliptic](https://www.elliptic.co/insights/binance-largest-hack-in-history/) counts $6.43 billion because it includes 11 chains. The numbers differ because each firm counts a slightly different set of chains and prices.

Recovery figures also differ. About $3 billion was reported frozen as of 30 October, while the post-mortem says $2.85 billion. Binance says it has replenished 98% of the affected balances, [CNBC](https://www.cnbc.com/2026/11/03/binance-co-ceo-teng-says-hackers-used-fake-job-interviews-to-steal-6point3-billion-in-crypto.html) reported 90%, and [Hacken](https://hacken.io/insights/binance-hack/) reported 95%. The reports describe different points in the recovery.

On 2 November, Elliptic said automated laundering was moving the funds through about 12,000 wallets across 11 chains, with $3.24 billion still in linked addresses. Co-CEO Richard Teng told CNBC that the hackers got in through fake job interviews. To see how, we have to go back to June.

## June: a search ad and a poisoned installer

In June, an engineer on Binance's wallet DevOps team searched for a "popular AI coding tool" and installed a tampered Homebrew installer from the results. Crypto investigator @khalidoncrypto reported on X that the link was a sponsored lookalike, meaning a paid search ad made to look like the real download page. Homebrew's creator, Max Howell, blamed Google's ads. The [SANS Internet Storm Center](https://isc.sans.edu/diary/32942) had already documented the tampered-Homebrew technique, and Binance cites that diary in its post-mortem.

Binance detected the compromise, replaced the device and rotated the engineer's credentials. Security researcher Tay, who posts as @tayvano_, calls June "tangentially related" and a "(small) contributing" factor to what came later. The attacker still knew who worked on Binance's wallet infrastructure. The cleanup addressed the infected laptop without treating the rest of the team as potential targets. We'll come back to that engineer later.

What failed here was a habit of relying on search results, and more specifically of trusting sponsored results (and not having an ad blocker). Engineers install tools all day, and a sponsored result at the top of the page looks like the fastest route. After all, many companies use ads to promote their software. And if you think bad actors don't use ads to promote their tampered software, you're in for a rude awakening. That's why relevant training materials for employees are so important. Brightside's course library includes a malware course, and every Brightside course is designed around one primary goal, with behaviour change among them. Brightside courses run in a chat-based format, and employees take them in English, French, German, Italian or Spanish. Training needs technical controls alongside it, including software allowlisting and an internal package mirror.

## September: the fake job interview

In September, the attacker went after a second wallet engineer. The engineer's profile on a legitimate job platform mentioned Binance, which was enough to make them a target. Someone calling themselves a "Project Director" got in touch and arranged a video interview with an "HR" person. That HR person shared a social media account full of personal photos and videos, the kind of detail that makes someone feel real. A second interview, with a fake "CEO", ran in a chat app and ended with an instruction to download a coding "assignment", and the engineer ran it on their work computer.

Every step was built to lower the engineer's guard. The first contact came through a platform they already used and trusted. The interviews moved from HR to a CEO, as they might in a real hiring process. The personal social account answered the question "is this person real?" before the engineer thought to ask it. And a take-home coding task is normal for engineering roles, so the request to run code didn't stand out.

This pattern has a name. [Chainalysis](https://www.chainalysis.com/blog/binance-hack-dprk-employment-fraud/) framed the Binance theft as a North Korean "contagious interview" operation, and CISA has warned since 2022 that TraderTraitor uses fake job offers to reach people at crypto firms. Binance says it blocked 57 North Korea-linked attempts in 2026, fake interviews among them. One succeeded against an engineer whose work device had privileged access.

Two things went wrong at once. An employee was job hunting on a corporate device, and that employee ran unverified code from people who were essentially strangers on it. Both are familiar risks that can be addressed through [role-based training](https://www.brside.com/blog/train-employees-against-ai-phishing-attacks) that tells people in privileged roles what an approach aimed at them looks like. The rule that would have helped was short: interview code goes in a throwaway virtual machine or a personal sandbox, never on a work machine, and an unsolicited recruiter gets reported.

## From one laptop to the signing service

Code that ran during the assignment's setup replaced the `pyenv` tool inside Homebrew with a malicious script, opened a channel to the attacker's server and erased its own traces. Binance called it a zero-day that its endpoint protection didn't detect. Researcher @vrycmfy pushed back on X, saying the "zero-day" was just a pyenv shell script. Other posters pointed out that Binance runs SentinelOne and osquery, and Tay said SentinelOne doesn't detect this North Korean tooling. On a Mac, the Homebrew folder under `/opt/homebrew` is writable by the user, so swapping a tool there needs no privilege escalation.

On 20 October, from the second engineer's machine, the attacker "used an internal AI tool to gain control over" the machines of two colleagues, according to Binance. The post-mortem doesn't say how. One of those colleagues was the engineer from June. That engineer's laptop held a token for deploying containers. As @vrycmfy noted, the person compromised four months earlier was still holding a standing deploy token. The attacker then stayed inside for about nine days without being spotted.

On the evening of 29 October, the attacker logged on to the third engineer's computer, used the June engineer's credentials to deploy a container, and ran a script that reached the wallet signing service. That service then signed transactions "outside the normal withdrawal process". The on-chain preparation started earlier still. [The Block](https://www.theblock.co/news/business/2026-10-30-binance-hack-largest-crypto-hack-north-korea-432225), citing TRM Labs, reported that staging began at least 36 hours before the theft, funded through Tornado Cash, with test transactions on three wallets.

## The night of the theft, and why stopping it took hours

The outflows started minutes later. Binance lists 233.46 million XRP leaving in about four minutes, then about 970,500 SOL, 44.2 million OP and 18,270 BTC. On Ethereum, the attacker used a newer mechanism. EIP-7702 lets an ordinary account hand its behaviour over to smart-contract code, and 50 signing transactions installed a malicious EIP-7702 delegation on the Binance14 hot wallet. From then on, the wallet did what the attacker's contract told it to. The last transfer was 2,961.9 ETH.

Elliptic and Hacken put the losses across 10 to 11 chains, including Tron, Arbitrum, Base, Avalanche and Polygon, with a second wave near the end of the night. @vrycmfy counted five separate sweeps of Binance14 over the course of the theft. The same researcher said deposits stayed open until after the last transfer, and said Avalanche and Polygon were drained without any delegation.

Binance detected the theft late. Its large-transfer alert fired only after the XRP, SOL and OP outflows had already occurred. Pausing withdrawals didn't help with the Ethereum side, because the delegation lived on-chain and kept working on its own. The wallet used MPC, or multi-party computation, which splits signing authority so that no single private key exists. That meant there was no one key to revoke quickly. The delegation was cleared only after the last transfer had gone through. As @vrycmfy put it, the MPC signer had signed the 50 malicious authorisations, but revoking the delegation took hours.

Chainalysis said funds from last month's Bitget exploit were mixed in with the Binance proceeds, and that North Korea's all-time crypto theft total now stands at about $6.75 billion.

## Was this an AI attack?

AI had a limited role in the reported attack. The June lure exploited demand for an AI coding tool, though the tool itself wasn't the attack. Binance's internal AI tool was abused to take over colleagues' machines, and Binance hasn't said how. Binance's response also includes "AI-based behavioural anomaly detection" and an AI security fund.

Binance's account describes the HR interview as live video with a real-looking social account and doesn't say it was synthetic. Nothing public shows deepfaked interviewers, AI-written lures or attackers using AI coding assistants. @vrycmfy argues the AI angle explains nothing, writing that "Everything it does explain is older than AI agents". The reported role of AI was in the download lure and the internal tool the attackers abused. We've written before about [how AI changes phishing and vishing](https://www.brside.com/blog/how-ai-makes-phishing-and-vishing-attacks-more-dangerous). Here, the documented entry points were a malicious download and a fake job interview.

The role of EIP-7702 is also disputed. [Coverage in Cointelegraph](https://cointelegraph.com/news/binance-hack-security-ethereum-eip-7702-role) argues that once the signing service was compromised the wallets could have been drained anyway, and that 7702 amplified the failure. The Avalanche and Polygon losses without any delegation support that reading.

## What would have stopped the human steps

The attack had two human entry points, and both had simple rules that would have closed them. Never install tools from search results or ads. Never run interview or take-home code on a work device. Treat an unsolicited recruiter as a possible attacker, especially if you hold privileged access, and report the approach. And remember that a video call and a social profile prove nothing about identity. None of these rules is new, and CISA's warnings about fake job offers go back to 2022.

Security teams also need to identify likely targets and check whether employees follow those rules under pressure. TraderTraitor didn't target the whole company. It went after the wallet team, found one engineer through a search for a tool and another through a public profile, and targeted the same team again. Brightside's Workspace ranks risk by employee and by group, based on simulation behaviour, course progress and exposure factors such as data breaches, with the highest-risk people listed first. Security teams can use those rankings to prioritise training. It's worth understanding [how human risk scores are built](https://www.brside.com/blog/human-risk-scoring-best-practices) before acting on one. We'd prioritise employees with privileged access and a history of exposure.

A generic phishing email sent to everyone gives a wallet engineer little practice with an attack tailored to their job. Brightside's AI OSINT spear-phishing, available in the Pro package, matches each simulated attack to the employee's role and context, the way a real attacker would target them. A wallet engineer gets a lure shaped for a wallet engineer, addressed to them by name, instead of the same template as the sales team. [Realistic simulations](https://www.brside.com/blog/why-phishing-simulations-fail-realistic-simulation-2026) show which employees engage with a test attack. To be fair, a simulated email isn't a three-stage fake interview, and nothing in a training platform stops a container deploy. It gives employees practice recognising targeted approaches before they act on them.

## After the first compromise, treat the whole team as targeted

Binance handled the June incident as a single compromised laptop. A fuller response would have treated the wallet team as a group the attacker had already studied and would come back for. That means briefings for the team about what had happened and what a follow-up approach might look like, extra monitoring on their devices and accounts, and a review of every standing credential they held, the June engineer's deploy token included. Deployments near signing systems need two-person approval. Teams need to rehearse revoking EIP-7702 delegations and MPC authorisations. Hot-wallet balances need caps, and deposits should close during an incident. Employees should keep personal activity, including job hunting, off work devices.

## The technical controls that would have broken the chain

Every step in this attack had a technical control that would have stopped or slowed it. Software allowlisting and an internal package mirror would have kept the June installer off the laptop. Developer tools stored where the user can't overwrite them, with integrity checks, would have prevented or detected the pyenv replacement. Egress filtering would have made it harder to contact the attacker's server. Short-lived, hardware-bound tokens instead of a standing deploy token would have left nothing useful on the June engineer's laptop in October. Least privilege and isolation for AI tools would have stopped an internal assistant from handing over colleagues' machines.

## FAQ

### How did Binance get hacked?

Two wallet engineers were compromised months apart. One installed a tampered Homebrew installer from a search ad in June. The other ran a malicious coding "assignment" from a fake job interview in September. From there, the attacker used an internal AI tool to take over two colleagues' machines, found a standing deploy token, deployed a container and got Binance's wallet signing service to sign transactions outside the normal withdrawal process.

### Who hacked Binance?

The FBI attributes the theft to TraderTraitor, a North Korean hacking group. Chainalysis describes it as a North Korean "contagious interview" operation, which uses fake job offers to reach employees.

### How much was stolen from Binance?

Binance's post-mortem puts the loss at $6.34 billion. TRM Labs counts $6.36 billion, and Elliptic counts $6.43 billion across 11 chains. Every estimate makes it the largest crypto theft on record.

### Did Binance users lose money?

Binance says it has replenished 98% of the affected balances with its own funds. CNBC reported 90% and Hacken 95%, so the figure depends on the source and the date. About $3 billion was reported frozen as of 30 October.

Engineers with privileged access should treat a recruiter's request to run code as a possible attack until they've verified it. Take-home assignments belong in an isolated personal environment, never on a work machine.