The $6.3 billion Binance hack may have started with one engineer's laptop: what happened, and what every IT team should take from it

On Thursday evening, attackers drained an estimated $6.3 billion from Binance's hot wallets in a few hours. That's around four times the $1.5 billion taken from Bybit in February 2025, which had been the largest crypto theft on record.

You don't need to care about crypto for this one to matter. Binance's early findings describe something that could happen in almost any organisation: an engineer's laptop was compromised, and the access on it was enough to make the company's own systems do the rest.

What happened

1. About 36 hours beforeThe attacker funds a wallet and rehearses the theft on test wallets
2. Thu 29 Oct, 20:20One transaction hands control of a Binance Ethereum hot wallet to the attacker's contract
3. Within half an hourHot wallets on nine other chains send funds out with valid signatures
4. Until 23:56New deposits are swept as soon as they arrive
5. Thursday eveningFounder Changpeng Zhao says it "does look like a hack". Withdrawals are suspended
6. Fri 30 OctBinance confirms about $6.3 billion affected and about $3 billion frozen with partners

Stablecoin issuers moved fast. Tether and Circle froze more than $2.3 billion between them, and Ripple and others froze smaller amounts. The attacker still holds billions in ether and bitcoin, which can't be frozen the same way.

Binance says it will cover every customer loss from its Secure Asset Fund for Users and its own money, and that "user funds are safe". It expects withdrawals to resume within 48 hours, once it has rebuilt the security of its withdrawal service.

How they got in, as far as we know

Binance's preliminary statement says the incident "may involve a compromised DevOps engineer's laptop", which gave the attacker access to a service container and let them submit unauthorised withdrawals. It says it has found no evidence that wallet private keys were leaked.

That last point is the important one. Blockchain analysts at TRM Labs and Elliptic reached the same conclusion from the on-chain evidence: wallets on ten different blockchains, with different key types, all produced valid signatures within about half an hour. The attacker didn't steal the keys. They got Binance's own signing system to sign whatever they asked it to.

Binance's CEO, Richard Teng, has since said it wasn't as simple as one laptop: the attacker "did not simply use one engineer's permissions, and this was not a single 'one-click' action." Binance says it has found additional points of breach. A full post-mortem is promised, so expect some of this to change.

Who investigators think did it

TRM Labs attributes the attack with high confidence to TraderTraitor, a North Korean group. Chainalysis has reached the same view. It's the same group the FBI blamed for the Bybit theft. Microsoft tracks it as Jade Sleet.

How the laptop was compromised hasn't been confirmed. But this group's known approach is worth knowing, because it targets engineers, not mailboxes. In 2023, GitHub warned that Jade Sleet was posing as developers and recruiters on LinkedIn, Slack and Telegram, inviting people to collaborate on a repository, and persuading them to clone and run it. The repository pulled in malicious npm packages that installed malware. Elliptic says a fake coding test or project is a likely route this time too, based on the group's past attacks.

Elliptic's summary of both Bybit and Binance is the line to remember: "it was the infrastructure and people around the wallets that were compromised, not the cryptography."

What IT teams should take from it

Swap "signing system" for "Azure subscription", "Entra tenant" or "payments platform" and the shape of this attack fits most organisations. Here's what's worth checking this week.

1. A laptop that can reach production is as sensitive as production

If an engineer's everyday laptop can reach production, an attacker who compromises it can too. The same laptop that runs a "take-home coding test" from a recruiter shouldn't be the one that can deploy to production.

Microsoft's Conditional Access documentation describes exactly this setup: admins accessing Azure management must use MFA and a compliant device, and any device not marked as a secure admin workstation is blocked. It uses a device filter on an extension attribute, such as device.extensionAttribute1 -eq "SAW", so only the devices you've tagged can manage Azure.

2. Nobody should hold standing access to production

Teng's point that the attacker needed more than one engineer's permissions cuts both ways. The more people who permanently hold production access, the more laptops an attacker can choose from. Make privileged Azure and Entra roles eligible through PIM, not active, and require approval for the ones that can move money or change who has access. If you need a quick way to activate roles, there's a PIM PowerShell guide on this site.

3. Make stolen sessions worthless

Malware on a laptop usually goes after browser sessions and tokens, which get past MFA. Conditional Access token protection only accepts sign-in tokens bound to the device they were issued to, so a stolen token replayed from somewhere else fails. It covers Exchange, SharePoint and Teams on Windows, macOS and iOS today, and access to Azure Resource Manager from the browser is in preview.

4. Systems that move value need their own limits

Binance's signing system did what it was told. The withdrawals were valid; they just weren't legitimate. Anything that can move money, data or access in bulk should enforce its own rules, whoever asks: rate limits, value thresholds, a second person for large or unusual requests, and an alert when output jumps from normal to everything. Ask the owners of those systems what would stop them signing 50 requests in a row.

5. Treat "just run this repo" as phishing

Tell engineers what this group does: a friendly recruiter or collaborator, a small project to look at, and a repository to clone and run. Anything like that should run in a throwaway virtual machine or cloud dev environment that holds no work credentials, never on a work laptop.

6. Know how far one account can reach

The real question this hack raises is: if one engineer's account were taken over tonight, how far could the attacker get? For Entra ID, the Attack Path Explorer answers that for Global Administrator. It maps every route from an ordinary account, app or group to full control of the tenant, and shows which link to cut first.

The checklist

1. List who can reach production systems that move money, data or access, and from which devices.
2. Require a compliant, tagged admin workstation for Azure management with a Conditional Access device filter.
3. Make privileged Azure and Entra roles PIM-eligible, with approval for the most powerful ones.
4. Turn on token protection where it's supported, starting with admins.
5. Ask the owners of payment, signing and bulk-change systems what limits they enforce on their own.
6. Brief engineers on fake recruiter and "run this repo" lures, and give them a safe place to run unknown code.
7. Run the Attack Path Explorer and close the shortest routes to Global Administrator.

This is a developing story, and Binance has promised a full post-mortem. This post will be updated when it's published.

Sources

• North Korea steals USD 6.36 billion from Binance (TRM Labs)
• Binance suffers security breach affecting $6.3 billion in assets (The Hacker News)
• Binance hit by $6.3 billion theft (Help Net Security)
• Binance loses over $6 billion in the largest crypto hack to date (CoinDesk)
• Binance says $6.3 billion impacted in record crypto hack (Forbes)
• GitHub attack attributed to North Korean Jade Sleet group (The Record) and GitHub's security alert
• Conditional Access: filter for devices (Microsoft Learn)
• Token protection in Conditional Access (Microsoft Learn)