The $6 Billion Binance Hack: What North Korea’s Record Heist Teaches Every Business About Cyber Security

On the evening of Thursday 29 October 2026, an attacker moved approximately $6.36 billion out of Binance, the world’s largest cryptocurrency exchange. Most of it left within about 20 minutes.

The Binance hack is now the largest theft in crypto history, roughly four times the size of the $1.5 billion Bybit breach in February 2025. Blockchain investigators at TRM Labs and Chainalysis attribute both incidents to the same group: TraderTraitor, a North Korean state-sponsored unit operating under the broader Lazarus Group umbrella.

Although the target was a crypto exchange, the attack itself followed a pattern that applies to any organisation: a compromised employee laptop, trusted internal infrastructure used against its owner, and an attacker who spent more than a day preparing before acting. Those are the same weaknesses found in banks, law firms and small software companies.

This article covers what happened, what is currently known about how it was done, and what it means for organisations assessing their own defences.

What happened in the Binance hack

At 20:05 UTC on 29 October, Binance wallets on the XRP Ledger began emptying into a single attacker-controlled address. Within minutes, hot wallets on Ethereum, Bitcoin, Tron, Solana, Arbitrum, Optimism and Base followed. A second wave hit Avalanche and Polygon around 23:05 UTC. Ten blockchains in all.

The headline numbers, per TRM Labs’ on-chain tracing:

Binance initially said it was looking into a “potential security issue”, then suspended deposits and withdrawals across several networks while it investigated. The exchange has pledged to cover all customer losses and says user funds are safe. Co-founder Changpeng Zhao echoed that position publicly.

Binance has also said it found no evidence of a private key leak. Its early findings instead point to a compromised engineer’s laptop, which is the detail most relevant to organisations outside the crypto sector.

Who is behind the Binance hack?

Binance has not named a culprit and says it is working with law enforcement. Independent blockchain intelligence firms have been more specific.

TRM Labs attributes the attack “with high confidence” to TraderTraitor, citing both on-chain and off-chain intelligence. That is the same group the FBI publicly blamed for the Bybit breach. Chainalysis CEO Jonathan Levin said his firm reached the same conclusion, and investigators found proceeds from September’s Bitget exploit mixed in with funds taken from Binance. Singapore-based Pangolin Intelligence has independently pointed at North Korea too.

TRM identified three characteristics consistent with earlier North Korea-linked attacks:

• Small withdrawals from Tornado Cash to fund an “operator” wallet, a pattern seen before Bybit and the April 2026 KelpDAO hack
• Staging that began well before the theft itself
• Transaction signatures obtained in advance, then executed in a single burst

Cryptocurrency theft is one of the North Korean regime’s most significant sources of foreign currency under international sanctions. The Bybit theft alone was equivalent to a substantial share of the country’s reported annual GDP; this incident is four times larger. The most detailed public account of the attack is TRM Labs’ incident analysis.

How the attack worked

The technical detail matters here, because it shows how little of this attack was specific to crypto.

The entry point: an engineer’s laptop

Binance’s initial investigation says the intrusion came through an engineer’s laptop, which gave the attacker access to a service container and the ability to submit unauthorised withdrawal transactions. There is no indication of a cryptographic weakness or a blockchain-level exploit. The path ran from a single endpoint into the systems that move funds.

That fits the group’s established tradecraft. TraderTraitor has a long record of targeting developers and engineers through social engineering: fraudulent recruiter approaches, coding assessments that deliver malware, and compromised open-source packages.

Preparation: 36 hours of staging

TRM’s timeline shows the operator wallet being funded with small Tornado Cash withdrawals on the morning of 28 October. Early on 29 October the attacker deployed an initial version of their code and tested it against two wallets. Later that day they ran the final version against a third wallet, then returned the test funds. The same code was installed on a Binance hot wallet roughly four hours after that final test.

That preparation left observable traces on a public ledger. The same is true inside corporate networks, where attackers typically validate access and tooling before acting.

Execution on Ethereum: EIP-7702 delegation

On Ethereum the attacker used EIP-7702, introduced in the May 2025 Pectra upgrade, which allows a standard wallet to delegate its behaviour to a smart contract by signing an authorisation. At 20:20 UTC the attacker submitted one transaction containing 50 such authorisations, each signed by the Binance hot wallet and each pointing it to a sweeper contract only the attacker could call.

The number is deliberate. An authorisation is only valid at a specific transaction count (nonce), and a hot wallet processing live withdrawals advances that count constantly. Pre-signing 50 consecutive nonces guaranteed at least one would match at execution time. Three minutes and 24 seconds after the delegation took effect, the wallet’s full balance, 167,464 ETH and 63 tokens, was sent to the attacker. Because the delegation remained in place, incoming deposits were swept again six more times over the following three and a half hours.

The cross-chain evidence

The Ethereum activity alone could be explained by phished authorisations. It does not explain what happened elsewhere. Within the same half-hour window, Binance wallets on nine other chains, each using different key types and signing schemes, produced valid signatures for the attacker through ordinary transfers.

TRM’s assessment is that the attacker gained the ability to have Binance’s hot wallet signing infrastructure sign transactions of its choosing, across chains. The batch of 50 pre-signed authorisations suggests that access may have been time-limited or mediated by a request system. Binance has not yet published a root cause.

Frozen funds and laundering activity

Stablecoin issuers responded quickly. Tether froze 971 million USDT in the main receiving wallet 37 minutes after the primary sweep. Circle froze 823 million USDC within an hour, in coordination with law enforcement. Ripple froze 40.5 million RLUSD, World Liberty Financial froze 27.8 million USD1, and Arbitrum’s Security Council used its emergency powers to move 8,426 ETH and 74.6 million ARB out of the attacker’s wallet.

By 00:30 UTC on 30 October, TRM counted roughly $2.7 billion frozen on-chain. Binance’s own figure sits around $3 billion as freezes continue.

The attacker anticipated the freezes and moved quickly to convert stablecoins into assets that no issuer can block. Around 325 million USDT was sold to market makers through UniswapX at a discount of more than 10%. A further 60 million USDT was deposited into Aave as collateral to borrow ETH before the protocol froze the affected markets. The 18,270 BTC was split into round 1,000 and 100 BTC amounts, a technique known as a peel chain that makes the funds harder to trace.

The result: the attacker still controls more than 420,000 ETH and all 18,270 BTC, about $2.4 billion beyond any issuer’s reach. Even after the freezes, what North Korea is still holding exceeds every previous crypto theft on record.

What the Binance hack means for your business

Most organisations do not operate a crypto exchange. But any organisation that runs systems which sign, approve or release something of value, whether payments, deployments, access tokens or customer data, is exposed to the same attack chain. Four points stand out.

1. Employee devices are the most likely entry point

Binance has one of the largest security budgets in its industry, and the initial access still came through an engineer’s laptop. TraderTraitor’s methods against developers are well documented: fraudulent job offers on LinkedIn, coding assessments that deliver malware, and compromised open-source packages. Technical controls are only properly validated when the human attack path is tested against real staff. That is the purpose of a social engineering assessment, and the findings typically reveal gaps that automated scanning cannot.

2. Test the full attack path, not individual systems

A conventional penetration test may well have confirmed that Binance’s web application, API and network segmentation were sound. None of that addressed an attacker who moved from a laptop to a service container to the signing infrastructure and then across ten blockchains. An objective-based red team assessment, where testers are given a goal such as reaching the systems that move funds rather than a list of hosts to scan, is the only way to exercise that full path. Our recent analysis of CISA’s two-SOC red team report covers similar lessons.

3. Assume your signing and approval systems are a target

The most alarming finding is that one actor obtained valid signatures across ten different chains and key types within half an hour. That points to a single over-trusted system. Ask yourself where the equivalent sits in your organisation: a CI/CD pipeline that can push to production, a service account that can approve payments, a cloud identity app with far more permission than its job needs. TRM’s recommendation for exchanges applies to everyone: separate signing and approval paths by tier, and treat an unusual batch of authorisation requests as an indicator of compromise. A cloud configuration review across AWS, Azure or GCP is the fastest way to find over-permissioned identities before someone else does.

4. Attackers test their access before they use it

The Binance attacker spent more than a day staging the operation: funding a wallet, deploying code, testing it against throwaway addresses and confirming the final version worked, all before touching a Binance wallet. That activity was visible on a public blockchain. Inside a corporate network the equivalent steps are visible in logs, if anyone is watching for them: an unusual account exercising new permissions, tooling being staged on a host that doesn’t normally run it, small test transfers of data out of the estate. Detection that only triggers on the final act gives an attacker all the time they need to get it right. Our security testing services are designed to show you which of those early signals your environment would actually surface, and which it would miss.

Binance hack FAQ

How much was stolen in the Binance hack? Approximately $6.36 billion, valued at the moment each asset was taken, across ten blockchains on 29 October 2026. That makes it the largest cryptocurrency theft on record.

Who hacked Binance? Binance has not named a suspect. TRM Labs and Chainalysis both attribute the attack with high confidence to TraderTraitor, a North Korean state-sponsored hacking unit associated with the Lazarus Group and previously blamed by the FBI for the 2025 Bybit hack.

Are Binance customer funds safe? Binance says user funds are safe and has committed to covering all losses. Deposits and withdrawals on affected networks were temporarily suspended during the investigation.

How did the hackers get in? Binance’s initial findings point to a compromised engineer’s laptop, which gave the attacker access to a service container used to submit withdrawals. Investigators believe the attacker was ultimately able to make Binance’s hot wallet signing infrastructure sign transactions across multiple chains.

How much of the stolen crypto has been recovered? Roughly $2.7 to $3 billion has been frozen by Tether, Circle, Ripple, World Liberty Financial and Arbitrum’s Security Council. The attacker still holds around $2.4 billion in ETH and BTC that cannot be frozen by any issuer.

Could this happen to a non-crypto company? The entry point (a compromised employee device) and the escalation path (abusing a trusted internal signing or approval system) are common to breaches across every sector. The crypto element only changed how quickly the money left.

Assess your own exposure

Binance has the financial reserves to reimburse customers and the industry relationships to secure stablecoin freezes within the hour. Most organisations have neither, which makes prevention and early detection far more important than recovery.

What an organisation can control is how direct, and how well tested, the path is from a single compromised device to its most critical systems. Aardwolf Security’s CREST-accredited testers have carried out realistic attack simulations for UK businesses since 2015. To understand how far a determined adversary could get inside your environment before being detected, get in touch for a free, no-obligation quote.