Binance Hack 2026: How One Laptop Lost $6.3 Billion and How Not to Be Next

Let's do the math. On October 29 at 20:05 UTC, money started leaving Binance wallets. About $6.36 billion of it, and most of that went out in roughly 20 minutes.

That works out to an average of $300 million a minute. Five million dollars a second. In the time it took you to read this paragraph, someone could have bought a small island. With palm trees.

I'll admit it: when I read a hack breakdown, I usually expect something straight out of a movie. A zero-day, a genius exploit, a hacker in a hoodie. This one is way more mundane, and that's exactly what makes it scarier. According to Binance's own preliminary account, it all started with one engineer's laptop.

Not the blockchain. Not the cryptography. A laptop. Quite possibly one just like yours.

The short version: the Binance hack was an attack in which the intruders used a compromised DevOps engineer's laptop to reach the exchange's internal infrastructure and get the exchange itself to sign transfers to their addresses. According to Binance, not a single private key leaked. The attackers didn't need one: the system dutifully signed everything it was asked to sign.

Let's break down how this works, who's behind it, and, most importantly, why this story matters to anyone who writes code or is just learning to.

Binance hack timeline: 36 hours of prep, 20 minutes of work

The most striking thing about this attack isn't the amount. It's how calm and methodical it was. TRM Labs analysts reconstructed it from blockchain data almost minute by minute.

• Morning of October 28. The operator's wallet gets topped up with three small amounts via Tornado Cash, a mixer that makes the origin of coins impossible to trace. Think of it as pocket money for gas fees.
• October 29. The operator deploys the attack code and tries it out on two test wallets. Then they rehearse the final version on a third one and send the test money back to themselves. Very tidy.
• About four hours later, the rehearsed code shows up on a Binance hot wallet.
• 20:05–20:23. Money drains from ten blockchains at once: XRP, Bitcoin, Solana, Tron, Ethereum, and others. The Bitcoin wallet alone gives up 18,270 BTC in a single transaction.
• From then until midnight, the exchange's Ethereum wallet "hands over" fresh incoming funds to the attacker's address several more times.

The prep took at least 36 hours. With tests, a dress rehearsal, and a rollback of the test funds. If every release got tested this carefully, half the production incidents in the world would simply vanish.

For scale: the previous record was the $1.5 billion Bybit hack in February 2025. Binance lost roughly four times as much.

How one laptop turns into billions

To understand what happened, you need to know one thing about exchanges.

Every crypto exchange has cold wallets: offline storage where most of the money sits. And it has hot wallets: connected to the network and running automatically. Those handle the everyday customer payouts. You hit "Withdraw," the exchange's service checks the request, signs the transaction, and the money goes out.

A hot wallet is like a bank teller with a rubber stamp. The teller doesn't make any decisions. They stamp whatever gets slid through the right window.

According to Binance's first account, the attacker's path looked like this:

1. A DevOps engineer's laptop is compromised. Exactly how, the exchange hasn't disclosed yet.
2. Through it, the attacker gets into a service container, an isolated environment where one of the exchange's internal services runs.
3. From inside, they submit withdrawal requests that the system treats as its own and signs.

So the attacker didn't have to steal the stamp. They just walked up to the right window.

Binance later said it had found additional points of entry, and the exchange's co-CEO Richard Teng stressed that this wasn't a "one-click action" and that the attacker didn't simply ride on one engineer's permissions. The exchange has promised a technical report once the investigation wraps up. TRM Labs, looking at valid signatures appearing across ten blockchains within half an hour, considers a compromise of the hot-wallet signing infrastructure itself to be the most likely explanation.

But the entry point Binance named first stays the same. A laptop.

EIP-7702 explained: how the wallet started working for someone else

The most technical and, honestly, most elegant part of the attack happened on Ethereum. This is where EIP-7702 came in.

The short version: EIP-7702 is an Ethereum mechanism that lets a regular wallet temporarily "put on" a smart contract's code and run its logic. It arrived with the Pectra upgrade in May 2025. The idea is a good one: bundle several actions into one transaction, let someone else pay the fee for the user, make wallets easier to use.

But for a wallet to "put on" someone else's code, it needs a signed authorization. And that authorization includes a nonce, the wallet's transaction sequence number. The wallet sends a new transaction, the number moves forward, and the old authorization no longer fits.

An exchange hot wallet sends transactions nonstop. Guessing which number it'll be on at the exact right second is next to impossible. So how did the attacker solve that?

They prepared 50 authorizations for 50 consecutive nonces. All signed by the Binance wallet. Like a burglar who shows up at the door not with one key but with a ring of fifty: one of them is bound to fit.

One did. A little over three minutes later, the wallet had handed over its entire balance: 167,464 ETH plus 63 other tokens, including more than 1.6 billion USDT.

And then came the nastiest part. The authorization stayed in effect. The wallet was now running "vacuum" code that only took orders from the attacker. Every time new money landed on the Binance address, the attacker scooped that up too. It's like setting up forwarding on someone else's mailbox: people keep mailing the owner, but you're the one reading the letters.

The takeaway for developers: every powerful feature is also a powerful way to do damage. EIP-7702 isn't a "hole." It works exactly as designed. The problem is who got the chance to use it.

The race for the money: freezes vs. swaps

As soon as the attack came to light, the race was on.

Stablecoins have a feature Bitcoin doesn't: the companies that issue them can freeze tokens at a specific address. Tether, Circle, Ripple, and others started blocking the attacker's addresses. The Arbitrum Security Council forcibly moved funds out of the attacker's wallet. By Binance's estimate, about $3 billion was frozen.

Meanwhile, the attacker was frantically swapping stablecoins into ETH, which can't be frozen. And by TRM's count, they overpaid by more than 10% above market price to do it. When Tether is on your tail, there's no time to haggle.

Binance halted deposits and withdrawals and promised to cover the hole with its SAFU insurance fund and its own capital: "These losses will not be passed on to users." By November 1, the exchange said it had covered about 95% of the affected amount and announced a phased reopening of withdrawals.

Looks like customers will come out of this okay. And the question of "who did it" already has an answer.

TraderTraitor and the Lazarus Group: hackers who hack people, not code

On October 31, the FBI officially stated that North Korea was behind the hack, specifically the group TraderTraitor. It's also known as Lazarus Group, Jade Sleet, and APT38. TRM Labs and Chainalysis had reached the same conclusion even earlier. Binance itself hasn't publicly named the perpetrators yet.

Look at this group's previous high-profile attacks and you'll see a pattern.

Bybit, February 2025, $1.5 billion. The attackers didn't go after the exchange itself but after its wallet provider, Safe{Wallet}. A Safe developer's Mac got infected through a Docker project with an innocent-sounding name about a stock-investing simulator, apparently with the help of social engineering. From there: access to AWS, stolen session tokens, and tampered JavaScript in the interface that showed Bybit's signers a "normal" transaction.

DMM Bitcoin, May 2024, $308 million. According to the FBI, the attacker posed as a recruiter on LinkedIn and sent an employee of Ginco, the Japanese company that managed the wallets, a Python script disguised as a pre-employment take-home test. The employee ran the script. Game over.

See the pattern? North Korea doesn't crack cryptography. That's slow and expensive. It's much easier to hack a person with access: a developer, a DevOps engineer, an admin. And the most reliable way to get a developer to run someone else's code is to offer them their dream job.

Exactly how the Binance engineer's laptop got infected is still unknown, and nobody can claim it was a fake take-home test. But this group's playbook is well documented. And it directly affects anyone looking for a job in tech.

Fake job interview malware: the most dangerous take-home test you'll ever get

Back in 2023, Palo Alto Networks researchers described a North Korean campaign with a very on-the-nose name: Contagious Interview. The scheme has only gotten more refined since then, and its victims are no longer just exchange employees but regular developers who are job hunting.

Here's roughly how it goes:

1. A "recruiter" reaches out on LinkedIn, Telegram, or by email. The company sounds legit, the pay is pleasantly above market, and the process is fast.
2. After a quick call, you get a take-home test. You need to download a repo, "run the project locally and fix a couple of bugs." Or install "our video call app."
3. You run npm install or fire up a Python script. And at that moment, someone else's code runs on your machine, and you haven't seen a single line of it. Its author, on the other hand, thought very carefully about every one.

From there, the malware goes looking for anything left lying around: browser passwords, session cookies, SSH keys, cloud tokens, crypto wallets. If it's a work laptop with access to production, congratulations: your laptop just became the front door into someone else's company.

The worst part is that a take-home test is the perfect bait. You want to run it. You're nervous, you're rushing, and the last thing on your mind is what's sitting in package.json.

Red flags:

• The pay is noticeably above market and the process is suspiciously fast: "let's skip straight to the take-home."
• The test has to be run, not just written from scratch.
• You're asked to install a "special app for the call" instead of Zoom or Google Meet.
• The repo has weird install scripts, obfuscated code, or dependencies with typos in their names.
• They rush you: "we need it today, this role has to be filled ASAP."

How to safely run a coding take-home test and still sleep at night:

• Never on your work laptop. Especially not on a machine with access to production, the cloud, or other people's money.
• In isolation. A virtual machine or a Docker container with no access to your home folder. If you can spin up a container for someone else's project, you already have a layer of protection the Safe developer didn't. In the Docker course, that's one of the first things you do hands-on.
• Read first, run second. Open package.json and check the scripts section, especially preinstall and postinstall. For the first install, there's npm install --ignore-scripts.
• No wallets or keys nearby. A crypto wallet, production SSH keys, and a take-home test from strangers should never live on the same machine.
• Check out the company. The website, real employees on LinkedIn, the history of the job posting. Five minutes of googling can be worth more than five years of salary.

And a special note for 2026: if you hand a take-home test to an AI agent, remember that the agent can run npm install too. Malware doesn't care who hit Enter, you or Claude Code. Letting an agent run code from an unfamiliar repo calls for the same isolation you'd use yourself.

If you already have production access

For anyone working in DevOps, backend, or infrastructure support, the Binance lesson hits even harder: your laptop is part of the company's perimeter. Not "my personal computer that I also happen to work on," but literally a door into production.

Here's what that means in practice:

• Separate your environments. Your work machine is for work. Side projects, take-home tests, games, and sketchy browser extensions go anywhere else.
• Least privilege. You need access to exactly what you're working on right now, and only for as long as you're working on it. Permanent admin access "just in case" is a gift to attackers.
• Hardware keys and short sessions. In the Bybit case, the attackers got around two-factor authentication by stealing already-active session tokens. The shorter a session lives, the less time whoever stole it has to use it.
• Critical operations need at least two sets of eyes. No single account should be able to withdraw money or push changes to the payment pipeline on its own.

None of this sounds like rocket science. And that's exactly why it so often doesn't get done.

What this means if you're still learning to code

You could read this story as a thriller about billions and North Korea. But for a developer, there's a different takeaway.

Security isn't some separate profession off in the distance. It's understanding what the code you run actually does. What happens when you run npm install. What a container is and why it doesn't always isolate things the way you think. Where tokens are stored and why a session cookie is worth more than a password.

That's the foundation. No AI can replace it: it'll write you a Dockerfile in a second, but deciding whether to trust a repo from a "recruiter" is still on you.

Where to learn this stuff

To read stories like this as a clear chain of steps rather than magic, you need the fundamentals.

In the Docker course, you build containers with your own hands and figure out what they isolate and what they don't. Python and Java give you a real understanding of how the code you run works, including the code that arrives in a zip file from your "dream recruiter." And Web explains how those very npm packages and front-end JavaScript work.

And if you're prepping for interviews right now (real ones, not the North Korean kind), we break down what actually gets asked in Java interviews in 2026 in our Java developer interview guide.

Hackers only need one careless person with access. Make sure it isn't you.

Binance hack FAQ

What happened in the Binance hack in October 2026? On October 29, 2026, about $6.3 billion was stolen from Binance hot wallets across ten blockchains, making it the biggest theft in crypto history. According to the exchange's preliminary account, the attack began with a compromised DevOps engineer's laptop, which the attacker used to reach an internal service and submit unauthorized withdrawal requests.

Who hacked Binance? According to the FBI, the attack was carried out by the North Korean group TraderTraitor, also known as Lazarus Group, Jade Sleet, and APT38. TRM Labs and Chainalysis analysts reached the same conclusion. The same group was behind the $1.5 billion Bybit hack in 2025.

Were Binance users affected by the hack? Binance has promised to cover everything itself, using its SAFU insurance fund and its own capital, and not to pass the losses on to customers. About $3 billion was frozen with the help of stablecoin issuers. As of November 1, the exchange announced a phased reopening of withdrawals.

What is EIP-7702? It's an Ethereum mechanism introduced in May 2025 that lets a regular wallet hand control of its operations to smart contract code. In the Binance hack, it was used to make the exchange's hot wallet run the attacker's code and forward even new incoming funds to them.

How do you spot a fake recruiter's take-home test? Be on guard if the pay is noticeably above market, the process is suspiciously fast, the test has to be run rather than written, or you're asked to install a special app for the call. Only run someone else's code in a virtual machine or container, never on your work laptop, and check the install scripts first.

Can an AI coding agent run malware from a take-home test? Yes. If an agent runs commands like npm install in an unfamiliar repo, malicious install scripts will fire exactly as if a human had run them. That's why you should only let an agent work with someone else's code in an isolated environment.