How the $6.3bn Binance Hack Started With a Fake Job Interview, and What Your Business Should Learn

On 29 October 2026, attackers drained around $6.3 billion from Binance, the world's largest crypto exchange, in what TRM Labs calls the largest hack in history. The headline number is extraordinary. The way it started is not. It began with a developer tool that was not what it seemed, and a job interview that was not a job interview. Those are tricks that reach ordinary employees at ordinary companies every week.

What happened, step by step

Binance's co-CEO, Richard Teng, described the attack to CNBC on 3 November.

1. 01June: a fake toolAttackers set up a fake version of a developer tool and lured an engineer into installing it.
2. 02September: fake recruitersPosing as recruiters, they ran job interviews with another engineer, ending in a coding exercise with hidden malware.
3. 03Inside: AI toolsFrom there they moved through internal AI tools to gain access to the system that authorised wallet transactions.
4. 0429 October: the drainTRM Labs says most of the funds left in about 20 minutes, across ten blockchains.

Binance's own report, quoted by CNBC, adds a detail that should worry every IT manager: one engineer downloaded a tampered installer "to install a popular AI coding tool after searching for it on a search engine". In other words, the starting point was a search result.

CNBC reports that the FBI has linked the attack to North Korean hackers tied to the TraderTraitor group, and TRM Labs makes the same attribution with high confidence. Binance pledged to cover all customer losses, and Teng said it had replenished 98% of the roughly $6.34 billion in affected assets. TRM Labs estimates about $2.7 billion has been frozen, with the attacker still holding around $2.4 billion.

Why this matters to a business that never touches crypto

Strip away the crypto and you have a template that works against any organisation:

• The fake job offer. Attackers pose as recruiters on LinkedIn or by email, run a convincing interview, then send a "take-home test" or project file. Running it on a work laptop hands over that laptop.
• The poisoned search result. Someone searches for a popular tool, clicks a convincing result, and installs a tampered version. AI coding tools are a favourite bait right now because demand is high.
• The over-powered account. Once inside, attackers look for any account or tool that can reach something valuable: payments, customer data, admin panels. Internal AI tools connected to many systems are an attractive stepping stone.

Seven defences you can put in place this month

Practical defences against the Binance playbook

Defence	What it stops	Effort
Never run job-interview files on work devices	Malware hidden in coding tests and project files	A one-line policy
Install software only from official sites or an approved list	Tampered installers found through search	Low
Use phishing-resistant sign-in (passkeys or hardware keys)	Stolen passwords and one-time codes	Low to medium
Give each account and tool only the access it needs	One compromise spreading everywhere	Medium
Require two people to approve payments and admin changes	A single compromised account moving money	Low
Review what your AI tools are connected to	AI assistants becoming a bridge into sensitive systems	Low
Keep software and devices updated	Known flaws attackers use after getting in	Ongoing

The AI point deserves emphasis. Many businesses connected AI assistants to email, documents, CRMs and code repositories this year, often with broad permissions. That convenience is exactly what attackers look for. Our guide to prompt injection and AI agent security explains how to give AI tools useful access without giving them the keys to everything.

If you think you have been targeted

Disconnect the affected device from the network, do not wipe it straight away (it holds the evidence), change passwords from a different device, and revoke any API keys or tokens that device could reach. Our checklist for what to do when a provider or account is breached walks through the first hour.

Building systems that assume someone will be fooled

The uncomfortable lesson from Binance is that well-trained engineers at a security-focused company were still fooled. Good security assumes a person will eventually click the wrong thing, and limits what one mistake can do. That means least-privilege access, separated environments, approvals for anything sensitive and software that is kept current, which is the same discipline our maintenance checklist applies to web applications.

If you would like a second pair of eyes on how your systems, integrations and AI tools are connected, our managed web application services include access reviews as standard, or get in touch for a one-off review.