The $6.3 Billion Binance Heist: What We Actually Know

The largest crypto theft on record didn’t break any cryptography. It got Binance’s own systems to sign for the attacker, and that should worry companies far outside crypto.

Hi, I’m Patrik Žák, and welcome to Security Sunday.

The cryptography held. Binance says it has no evidence that any keys leaked. And yet roughly $6.3 billion in assets left the exchange in a single evening.

This is the largest crypto theft on record. Companies that have nothing to do with crypto can learn from it too, because the attacker apparently went through the people and processes around the wallets.

Here’s what we know, what’s still just estimates and claims, and what any company with a system that approves payments or signs anything important should take from it.

What happened

On Thursday, October 29, Binance said it was investigating a potential security issue and paused withdrawals. Overnight it shared its first numbers: an estimated total impact of around $6.3 billion, with roughly $3 billion frozen on-chain together with partners.

Much of the frozen money is stablecoins. Tether says it froze more than 1.5 billion USDT, and Circle more than 800 million USDC. USDT and USDC have issuers that can freeze their tokens. Bitcoin and ether have no such issuer.

Binance also promised to cover user losses from its SAFU fund, an insurance fund and company money. On Saturday it said it had restored backing for about 90% of the affected assets from its own resources, and is still buying the remaining less liquid tokens. That doesn’t mean 90% of the stolen money came back. On Sunday morning, Binance said it had covered about 95% of the impacted amount.

Confirmed vs. claimed

This is where you need to be careful. The numbers changed several times in two days, and the sources don’t agree.

Binance says $6.3 billion. TRM Labs counts $6.36 billion and Elliptic $6.43 billion. Chainalysis first estimated $5.9 billion, then raised it to $6.4 billion a few hours later. These are running estimates, calculated at different times and with different methods. Whichever number you pick, it’s several times the previous record, the roughly $1.5 billion Bybit theft in February 2025.

Then there’s the cause. Binance first said the incident may have started with a compromised laptop belonging to a DevOps engineer. From there, the attacker reportedly reached a service container and submitted unauthorized withdrawals. Binance added it had found no evidence of a wallet private key leak.

A few hours later, it revised that. Further investigation had uncovered additional points of breach. Co-CEO Richard Teng put it plainly: “the attacker did not simply use one engineer’s permissions, and this was not a single ‘one-click’ action.”

So the laptop is a possible entry point, not the full explanation.

How it played out, according to the analysts

Now for what Binance hasn’t confirmed, but blockchain analytics firms say.

According to TRM Labs, preparation started at least 36 hours earlier. The attacker obtained a batch of pre-signed authorizations for a Binance hot wallet, the one the exchange uses to pay out withdrawals. They fired them all at once, one went through, and with that they took control of the wallet and sent its balance to their own address.

Richard Teng confirmed part of this himself. In a video on Friday, he said the attacker abused EIP-7702 on the hot wallet. It lets a regular account, via a signed authorization, run the code of a chosen smart contract as if it were its own.

Elliptic sums it up this way: the attacker didn’t steal Binance’s keys, they got Binance’s own systems to sign transactions on their behalf. Elliptic compares it to Bybit, where attackers compromised a developer’s machine at the wallet provider and tampered with a transaction that Bybit’s own signers then approved.

The line that stuck with me most is Elliptic’s: in both cases, “it was the infrastructure and people around the wallets that were compromised, not the cryptography.”

And that’s the most important lesson in this whole story. Encryption is usually the strongest thing a company has. The weak spot is the laptop someone uses to reach the system that signs whatever it’s handed.

Who’s behind it

TRM Labs and Chainalysis both attribute the attack with high confidence to North Korea, specifically the group known as TraderTraitor, which the FBI officially blamed for the Bybit theft in February 2025. Chainalysis adds that the stolen funds are being mixed with money from the recent Bitget exploit.

Elliptic is more cautious. It considers North Korea likely, but points out that the laundering looks different this time, and that the overlap with Bitget funds is still small and doesn’t prove anything on its own.

As of Saturday night, this is no longer just an analyst estimate. On October 31, the FBI officially attributed the Binance theft to North Korea’s TraderTraitor group, and Binance shared the announcement. That still doesn’t settle how exactly the attacker got in.

Where things stand

Deposits on Binance are working, and this morning the exchange launched the first phase of withdrawals, starting with the Bitcoin network. Other assets and networks are being reopened gradually, subject to security checks. Binance has promised a full post-mortem and, by Tuesday, November 3, a proof that customer assets in its ten main tokens are backed 1:1.

By the way, Elliptic has also reconstructed the preparation. The day before, the attacker funded their wallet through Tornado Cash, and a few hours before, they tested their code on three wallets. According to Elliptic’s Tom Robinson, none of it looked suspicious at the time.

A note from the Czech Republic

Czech media covered the heist widely. Czech public broadcaster ČT24 called it the largest theft in crypto history, worth more than 130 billion Czech crowns.

One thing worth recalling for European readers: on July 1, the Czech National Bank noted that Binance hadn’t obtained an EU license under MiCA and therefore had to stop providing crypto-asset services across the entire EU, including the Czech Republic. If anyone at your company still uses it, it’s a good moment to ask why.

The second connection. On September 18, NÚKIB, the Czech national cybersecurity agency, warned about the North Korean group WaterPlum. According to the international analysis it cited, the group approaches IT professionals with fake job offers to compromise their devices and steal data.

To be clear, I’m not saying that’s how the Binance attack started. Nobody knows yet. But analysts describe it as a typical North Korean technique, seen in the Bybit and DMM Bitcoin hacks. If your company employs developers or admins, it applies to you just as much.

What to take from this

Most of you don’t run a crypto exchange. But almost every company has a system that approves or signs something important: bank payments, code signing, production deployments, access to backups.

First, find out which systems in your company can sign or approve a transaction without a human. That’s the spot an attacker is after.

Second, treat developer and admin laptops as the keys to the company. Separate the machine used to manage production from everyday work, run EDR, and never run interview assignments or unknown projects on a work machine.

Third, train the people who run hiring and technical interviews, and the developers themselves. A fake interview can be a way in just like a phishing email, it just gets talked about less.

And fourth, know how you’ll communicate during an incident. Binance updated its public information several times in the first hours: it clarified the status of deposits and disclosed additional points of breach. I appreciate that it did so publicly and quickly. Saying “here’s what we know, here’s what we don’t” beats silence.

The short version

An attacker moved roughly $6.3 billion in assets out of Binance, about $3 billion has been frozen, and the exchange says it will cover user losses. The root cause isn’t settled, and the FBI attributes the attack to North Korea.

The takeaway? Attackers today don’t break encryption. They convince your systems to sign what they slip in front of them.

If you want to know how far an attacker could get from a single developer’s or admin’s laptop in your company, get in touch at team@sysnetshield.com. That’s exactly what we test in our Compromised Machine Simulation.

See you next Sunday.

Also this week

Max-severity GitLab flaw: CISA confirms attacks

On October 29, CISA added GitLab’s CVE-2026–97229 to its catalog of actively exploited vulnerabilities. The bug sits in the regular expression compiler GitLab uses for CI/CD pipeline configuration. According to GitLab, under certain conditions it lets even an unauthenticated attacker run arbitrary code on the server. Both Community and Enterprise Edition are affected; fixed versions are 19.4.2, 19.3.5 and 19.2.8.

Citing Shadowserver, BleepingComputer reported nearly 2,800 internet-exposed GitLab Community Edition instances; how many are patched isn’t known. If you run your own GitLab, update now.

Critical Linux kernel flaw: Anthropic’s model wrote a working exploit

On October 27, Anthropic researchers described CVE-2026–98432 in the Linux kernel’s networking code, affecting kernels back to 4.4. No authentication is needed. On a server with a multipath TCP (MPTCP) listener, their unreleased internal model wrote an exploit that bypassed KASLR and ran commands as root. In Anthropic’s proof of concept, execution took about 53 minutes. Note that since Go 1.24, Go servers using net.ListenConfig can listen via MPTCP by default on Linux systems that support it, so you may be running it without knowing.

The Linux kernel CVE team and Red Hat both rate it 9.8 under CVSS 3.1. Upstream and Debian have fixes; the main Ubuntu and RHEL kernel packages don’t yet. No confirmed public exploitation outside Anthropic’s test has been reported so far.

A fake Claude Code extension in Cursor

On October 29, a fake Claude Code extension (versions 2.1.312 and 2.1.313) sat in the Cursor editor’s extension marketplace for about 11 hours. Anthropic didn’t build it. According to Cursor and Microsoft’s analysis, it tried to give the attacker persistent remote SSH access to developers’ machines. Cursor pulled it and estimates at most 5,000 users were affected; the key step of the attack failed on most machines without admin rights.

This wasn’t a flaw in Claude Code, and Anthropic says it wasn’t compromised. If you use the Claude Code extension in Cursor, check your version against Cursor’s October 29 security notice.