The Binance hack didn't need a stolen key. That is the lesson.

On Thursday, October 29th, roughly $6.3 billion in cryptocurrency left Binance, the world's largest crypto exchange. As CBC News reported from The Associated Press, blockchain intelligence firms quickly linked it to a North Korean unit, and the FBI has since said North Korea was responsible. It is the largest cryptocurrency theft on record.

Most of the coverage will focus on the size of the number and the attribution. I want to focus on a single line in Binance's initial findings, published November 3rd: the attacker "exploited unauthorized access to an internal wallet signing service to initiate transactions outside the normal withdrawal process." Billions moved, and Binance has found no evidence that anyone stole a key.

That detail matters well beyond crypto, because it describes how most serious breaches actually work.

What we know, and what we don't yet

Binance published its initial findings on November 3 and has committed to an independent third-party review, so some details may still move.

Here is what we know:

• Scale and speed. Binance puts the impact at approximately $6.34 billion. Blockchain analytics firm TRM Labs says an attacker moved approximately $6.36 billion out of Binance wallets on 10 blockchains, "most of it in about 20 minutes."
• Attribution. On October 31 the FBI said North Korea was responsible, and Binance's findings now cite that conclusion. TRM attributes the attack to TraderTraitor, which it describes as North Korea's elite hacking unit, "with high confidence," and Chainalysis CEO Jonathan Levin wrote that it was "likely done by DPRK group TraderTraitor."
• Attack chain. In June, an engineer downloaded a tampered Homebrew installation while installing a popular AI coding tool. In September, a fake job interview put 0-day malware on a second engineer's work computer. On October 20, the attacker used that computer and an internal AI tool to gain control over two more engineers, one of whom had a container deployment token on his computer. On October 29, a container the attacker deployed used unauthorized access to the internal wallet signing service.
• Containment. Binance says it froze or intercepted approximately $2.85 billion, subject to reconciliation, and that it will absorb the loss, not its users. It says it set aside more than 100% of the funds required and had replenished 98% of the impacted token assets as of October 31. Deposits resumed the next day, and withdrawals began reopening network by network on November 1.
• Precedent. In February 2025, the FBI attributed the roughly $1.5 billion Bybit theft to North Korea's TraderTraitor operation. TRM says several features of this attack match it.

Binance now has a root cause, at least in outline. It says some technical details will stay confidential, and the independent review may add more.

The shape of the attack is clear enough to learn from now.

No key was stolen, and that is the problem

TRM's analysis of the Ethereum side is the most technically interesting part. The attacker used EIP-7702, a feature added to Ethereum in the Pectra upgrade that lets a standard account delegate its behaviour to smart contract code.

According to TRM, the operator submitted one transaction containing 50 pre-signed authorizations, each valid for a different nonce. Because the hot wallet's nonce advanced with every normal withdrawal, signing for 50 consecutive values guaranteed one would match. Within about three and a half minutes of the delegation, that hot wallet's entire balance had moved.

Those authorizations had to be signed by Binance's own infrastructure, and Binance now confirms how: the attacker used unauthorized access to an internal wallet signing service. TRM's assessment is that this let the attacker make the signing system sign transactions of its choosing, across chains.

Kok Tin Gan, CEO of NyxLab, put it more bluntly to the AP: "This looks like one signature that gave the attacker a never-expiring, full-access token to a Binance hot wallet."

Put plainly, the cryptography held.

Binance's findings describe access to a signing service, and it has found no evidence of a key leak. What failed was the control over what the keys would be used for. The signing service did exactly what it was built to do, for whoever could reach it.

One detail in the findings deserves more attention than it will get. Binance's hot wallet used MPC, so there was "no single private key that could be used to immediately revoke the malicious EIP-7702 authorizations." The delegations kept moving assets after withdrawals were suspended, until Binance cleared the delegation code at 00:10 UTC on October 30. The design that spreads key risk across parties also slowed the emergency stop. Revocation is a control path too, and it needs a rehearsed plan before the incident, not during it.

Attackers rarely break the lock. They find the system that holds the key and ask it nicely.

The laptop was the front door, again

The pattern is familiar. In the Bybit case, Safe{Wallet} said attackers had compromised a developer's laptop and hijacked AWS session tokens to get past multifactor authentication, then tampered with the wallet interface Bybit's signers relied on. Different victim, same group by most accounts, same first step.

Binance's chain started in the same place. Engineers hold cloud credentials, deployment tokens and live session tokens because they need them to do their jobs. Those sessions have already passed MFA. To every downstream system, an attacker holding them looks exactly like the engineer.

None of this is a criticism of the engineer.

It is a design question.

If one workstation, or one engineer's set of permissions, can reach a path that ends in an irreversible transfer, the architecture has made that person's laptop part of the vault. Binance's chain ran through three engineers and an internal AI tool, which matches Teng's early comment that the attacker "did not simply use one engineer's permissions."

That is still the question every security team should ask about its own environment.

Your systems have a signing oracle too

It is tempting to file this under crypto problems. Most enterprises do not run hot wallets.

But nearly every enterprise runs a service whose job is to turn protected data back into usable data on request: a key management service that decrypts, a database with transparent encryption, a service account that reads the customer table, a payment service that can detokenize a card number.

Encryption at rest is invisible to any process the system already trusts. That is by design, and it is also why the perimeter-first model keeps disappointing. An attacker who owns an authorized identity does not need to defeat AES. They ask the service, and the service answers.

The same is now true of AI agents with tool access, which are simply new identities with standing permission to ask. Binance's attacker used an internal AI tool as a springboard to reach other engineers.

So the useful question is not whether your data is encrypted. It is: which systems can make your data readable again, who can reach them, and what would stop one of them from doing it 50,000 times in 20 minutes?

Controls that change the outcome

None of these is exotic. Most are a matter of deciding that the reveal path deserves the same scrutiny as the storage layer.

1. Separate the request from the approval. The service that asks for a signature, decryption or detokenization should not be the one that approves it. High-value actions need a policy check the requesting service cannot influence.
2. Bound the volume. A legitimate process rarely needs to reveal every record or move every balance at once. Rate and volume limits on reveal operations turn a 20-minute event into an alert.
3. Treat unusual authorizations as compromise. TRM's guidance for wallet operators is to reject unexpected EIP-7702 authorizations and treat requests spanning many nonces as an indicator of compromise. The enterprise version is alerting on any credential or token that is long-lived, broadly scoped or requested in bulk.
4. Shrink the blast radius by tier. TRM recommends separating signing and approval paths by chain and wallet tier. For data, that means one compromised service should expose one dataset, not the estate.
5. Keep standing credentials off developer machines. Short-lived, narrowly scoped credentials limit what a stolen session is worth, and conditional checks on location and time catch sessions used from somewhere new.
6. Reduce how much needs revealing at all. Most systems that touch sensitive data never need the real value. If they work on substitutes, the number of paths an attacker can abuse drops sharply.

Where data-centric protection fits

That last point is where we spend most of our time at DataStealth. The argument is simple: if stolen data isn't real, the attacker who walks out with it has nothing to sell.

Our platform runs inline, without agents or changes to application code. Discovery finds where sensitive data lives. Vaulted tokenization replaces sensitive values with substitutes that have no mathematical relationship to the originals, so applications, analytics jobs and test environments can work on tokens instead of the real values. Originals are held in a separate vault, split across storage nodes, and returned only to systems that policy authorizes.

Dynamic masking can weigh role, location and time before deciding whether a user sees a full or masked value. Inline components can be set to fail closed, so that if one cannot reach the policy engine or vault, it holds the traffic rather than passing data through unprotected.

The relevance to Binance is architectural, not literal.

The point is to put the reveal decision in a separate policy layer with its own conditions, and to make most of the environment hold nothing worth taking. Compromising one engineer's laptop then gets an attacker into a system full of tokens, which is a much worse day for the attacker than for you.

We covered the tradeoffs between approaches in vaulted vs. vaultless tokenization, because the choice matters for exactly this threat model.

To be clear about the limits: DataStealth does not secure crypto wallets, signing infrastructure or blockchain transactions, and nothing here suggests it would have stopped this attack.

It is not endpoint protection, and it will not stop malware landing on a developer's laptop.

An attacker who fully compromises a system that is legitimately authorized to retrieve original values can still request them, which is why reveal policies, volume limits and monitoring still matter.

What data-centric protection changes is how many systems hold real data, and how narrow the path to it is.

The question to take into what happens next

Binance has published its initial findings and promised an independent review. The frozen totals will change, and the laundering will play out over months.

The specific mechanism, a pre-signed delegation on Ethereum, is a crypto detail. The underlying failure is not. A trusted system was reachable, it was authorized to make irreversible decisions, and nothing outside it asked whether those decisions made sense.

So map your own version. List every service that can decrypt, detokenize, sign or export sensitive data in bulk.

For each one, write down who can reach it, what it would take to make it act, and how long it would run before anyone noticed.

If the honest answer to that last question is "about 20 minutes," you have found your next project.

Security doesn't end at detection, and it doesn't start at the perimeter either.

Find out which of your systems can make sensitive data readable again.

DataStealth helps you discover sensitive data, replace it with tokens or masked values inline, and narrow the paths that can reveal the original.

Book a demo with our team to get started.