TL:DR: the $6.3 billion Binance hack may have started with a compromised DevOps engineer's laptop. Binance has since said its investigation found additional points of breach, and it has not said how the laptop was compromised. We see attacks on developer devices every day - just last week Aikido blocked nearly 500 malware attacks. Here is how one compromised laptop can lead to a service that moves money.
How did the Binance hack happen? What we know so far
Binance puts the total impact at about $6.3 billion and says the incident may have started with a compromised DevOps engineer's laptop. Binance says that access lets an attacker reach a service container and submit unauthorized withdrawal transactions. About $3 billion has been frozen on-chain so far, and Binance says it will cover all losses.
Co-CEO Richard Teng wrote on X that the attacker did not simply use one engineer's permissions, and that the attack involved more than a single click. So far, Binance has found no evidence of a wallet private key leak.
In a later investigation update, Binance said further work had uncovered additional points of breach beyond the laptop. The update gave no details of the other points. Binance has promised a technical post-mortem once every fact is verified, and we will update this post when it arrives.
TRM Labs and Chainalysis have attributed the incident to TraderTraitor, a North Korean hacking unit. Binance has not confirmed that attribution.
The public statements say nothing about how the attacker got onto the laptop in the first place. Everything below describes how attacks like this typically unfold.
What we see on developer laptops
Just last week, Aikido blocked nearly 500 malware attacks on developer devices, around 70 a day.
North Korea-linked groups are known for targeting developers directly, often with a fake job interview that includes a take-home coding test, where running the project runs the attacker's code. Another common route is code that runs the moment it is installed or opened. A malicious package can include an install script, which runs automatically when the package is installed, and a malicious editor extension runs inside the developer's own tools. In May, a malicious VS Code extension on one developer's device enabled an attacker to breach GitHub's internal repositories.
In March 2025, our malware detection flagged an npm package, react-html2pdf.js, that posed as a popular library. In under two hours the attackers pushed four versions and debugged their own code in public, never fixing a missing import for the HTTP library their payload relied on, so the package could not run as published. It used no install script and was built to fetch its payload from a remote server when the code ran. Once decoded, the payload was built to take crypto wallets and browser data from the machine, then pull down more code to run. Fingerprints in the code and its infrastructure led us to attribute it to North Korea's Lazarus Group, as we covered in Spying on North Korean hackers.
PolinRider, a campaign researchers link to North Korea and one we keep seeing, hides deliberately scrambled code in ordinary project config files. It can run when a developer opens a project in VS Code. It then uses that developer's own access to rewrite commit history and overwrite the shared copy of every repository they can push to.
What a developer laptop gives an attacker
A developer laptop holds working credentials for every system its owner maintains. Typically that means cloud credentials, SSH keys, git credentials and Kubernetes configs, often sitting on disk where any process running as that user can read them.
It also holds live session tokens from the tools the developer is already logged into. A session token can outlive a password reset and can skip multi-factor authentication (MFA), because the login that required it already happened.
An attacker with that material can act as the engineer. Their activity shows up in logs under the engineer's name, so it looks like normal work.
How a compromised laptop can lead to stolen funds
One plausible chain from a compromised laptop to a withdrawal looks like this:
- Malicious code runs on the laptop and collects credentials and session tokens.
- The attacker uses them, from their own machine or by routing through the laptop itself, to reach an internal system the engineer can access, such as a build server or a cloud account.
- From there, they move to systems with broader reach, collecting more credentials at each step.
- They reach a service trusted to submit withdrawals and send transactions through it.
Other breached systems may also have been reachable from outside, with no laptop involved.
That would also explain why no keys had to be stolen. In a typical setup, the keys sit in a vault or hardware device, and an approval service asks the vault to use them without ever seeing them, so whoever controls the service can have transactions approved while the keys stay where they were. Blockaid’s CEO reached the same preliminary view: a compromise of signing infrastructure.
The 2025 Bybit theft followed a similar shape, over about two and a half weeks. According to Safe's preliminary findings, as reported by heise, a developer's laptop was compromised on February 4, attackers used a stolen AWS session token to work inside the company's cloud, and on February 17 they injected malicious code that enabled the theft on February 21. Bybit's forensic update, summarized by Cointelegraph, says signers were deceived into approving a malicious transaction.
How to protect developer devices
Start at the device. Aikido Device Protection is a lightweight agent that sits on the developer's machine. It blocks malicious packages, editor extensions and AI tools before they install, and by default holds back any package or extension published in the last 48 hours. It also flags anything already on the machine that later turns out to be malicious.
The device is only the first link, so the other layers need to hold as well:
- Keep long-lived credentials off developer disks and issue short-lived ones that expire in hours.
- Require approval outside the service for high-value actions such as withdrawals, so a compromised service cannot approve its own transactions.
- Alert on credentials and sessions used from places or at times the engineer never works from.
- Bring contractor and personal machines that reach production under company management, so the same controls apply to every laptop.
Frequently asked questions about the Binance hack
Was the Binance hack caused by an employee's laptop?
Binance's first findings pointed to a compromised DevOps engineer's laptop. A later update said further work had uncovered additional points of breach, so the laptop was not the whole story.
Were Binance's private keys stolen?
Binance says it has so far found no evidence of a wallet private key leak. An attacker can still move funds through a service that is already authorized to do so, without ever holding the keys.
How can one laptop lead to billions in losses?
Credentials and sessions on the laptop open internal systems, and from there an attacker can chain to a service trusted to send withdrawals. The section above walks through that chain.
Who is behind the Binance hack?
Analysts at TRM Labs and Chainalysis point to TraderTraitor, a North Korean hacking unit. Binance has not confirmed it.
