Binance says its $6.3bn breach started with a tampered developer tool and a fake coding test on its engineers' machines. What that means for every security leader, and what to ask your team today.
Three questions to ask your team this week
What is the risk of attackers targeting our engineers?
If one of our engineers were compromised, what could the attacker reach? Do our security tools actually cover our engineers' machines, and would they catch a malicious repo or a misused AI agent?
Update (04/11/26): What we know about Binance #
On 29 October, attackers moved about $6.3bn out of Binance's hot wallets in what's thought to be the largest crypto theft on record. The FBI has attributed it to TraderTraitor, the North Korean unit it also blamed for the Bybit hack
When we first wrote this piece, Binance had said only that the attack started on an engineer's laptop. Its initial findings, published on 3 November, describe a campaign that ran for five months:June: An engineer on the wallet team searched for a popular AI coding tool and installed a tampered version, planted in a search ad. Binance caught it and replaced the device, but the attackers had already learned who worked on the wallet systems.September: A second engineer was approached by a fake recruiter, sat two interviews, and was asked to download a coding assignment onto his work computer, which contained malware. Binance says its endpoint tools didn't catch it at the time.20 October: The attackers used that machine and an internal AI tool to take over two more wallet engineers' computers. One had credentials that let him push code into Binance's systems.29 October: They deployed a container, reached the wallet signing service and moved the funds outside the normal withdrawal process.
Binance has covered customer losses from its own funds, and about $2.85bn has been frozen or intercepted so far. When the news first broke, we asked Nate Dunning and David Read, Ossprey's co-founders, what security leaders should take from it.
Why engineers are the target #
Attacking a company's systems directly is getting harder. "Companies are getting better and better at making sure they only release systems that are already secure," says David. "You do CVE patching. You do pen testing. You do bug bounties. What companies don't often do is lock down and secure the development environment."
That gap is where the access is. "If you compromise a production system, you only get access to whatever that part of the system has. That might be full admin access, or it might be a locked-down Docker container," David says. "But if you manage to compromise an engineer, suddenly you do have the keys to the kingdom, because engineers often have admin control over the platform."
Nate calls engineers "a double threat." "They're highly privileged users. Their laptops need to install and run things more than almost any other role, just so they can do their job," he says. "And they hold credentials to highly privileged systems, like their cloud providers. If that laptop is compromised, it's really easy for an attacker to use that access to do all kinds of damage."
The cost beyond the money #
The headline number is only the start. Once an engineer's laptop is compromised, Nate says, the investigation has to cover "all of the files, all of the credentials, all of the standing access that engineer's laptop had," then every system those credentials reach, and every system those systems reach.
"It's never step one, then two, then three. It's more likely step one, 13, alpha, back to one," he says. "That's what makes it so difficult to figure out and isolate."
Fixing it carries its own risk. "You will often have to rotate the credentials, and that could break production applications or disrupt customer applications," Nate says. "Then you get into remediation: new security controls, new operational controls. That pulls in incident response, leadership, audit, compliance, legal, maybe third parties. When you tally up the hours, you're talking thousands of hours of very expensive people's time."
And the reputational cost lasts. "This is the biggest one that's ever happened," he says. "It will be used as a yardstick to measure other incidents against."
Why this is now a board-level risk #
For years, attacks like this sat in the "too rare to plan for" column. David says that has to change. "When we first saw the Bybit attack, it was treated like a black swan event. People said it's so rare there's no point protecting against it, we should just accept the risk, even though it could be a company-ending event," he says. "Now they're not happening rarely. They're happening every year. They're no longer a black swan event. They're a regular occurrence that needs to be taken seriously."
The pattern is clear: Bybit lost $1.5bn in 2025 after a developer's machine at its wallet provider was compromised, LayerZero was hit in April 2026, and now Binance. And it isn't limited to crypto.
"This is definitely not a crypto-only problem," says Nate. "These incidents happen to critical national infrastructure, traditional financial institutions, start-ups and scale-ups. Crypto organizations are no more or less secure than anywhere else. We just hear about them because they come with flashy titles like six billion stolen."
Few companies could absorb a loss on this scale. Binance covered customers from its own reserves, and Bloomberg Law reported, citing a person familiar with the matter, that it had no cyber insurance to claim on.
AI agents on engineers' laptops #
AI coding agents are now on most engineers' machines, and they bring their own risk.
"Local AI agents are incredibly well credentialed, they have auto-approve on, and they can do all kinds of stuff," says Nate. "What used to be a very difficult task was just given jet fuel."
He has seen malware hijack a local AI agent and ask it to collect passwords and secrets from the machine. "Security tools would see that and assume, oh, that's just the AI being weird," he says. "But it's actually an attacker gathering up everything available on the laptop."
At Binance, an internal AI tool became part of the attack path. After compromising one engineer's machine, the attackers used it to take over two colleagues' computers. Binance hasn't reported a flaw in the AI model itself. The tool was useful to the attackers because of what it could reach.
How attackers get in #
Phishing still works, and Nate doubts there will ever be a day when it doesn't. But the attacks aimed at engineers tend to be more personal than a dodgy email. A recruiter sends over a coding test. A collaborator shares a GitHub repo. A package that looks like a familiar library turns up in a project. At Binance, it was a fake recruiter's coding test, plus a tampered developer tool found through a search ad.
"The thing about a lot of these attacks is they aren't that clever," says David. "It can be a seven-line code change. What's clever is what they do once they get access: how they move laterally and pivot."
The fake job interview is the one Nate finds most effective. An engineer is asked to download a coding test or clone a GitHub repo, and it's malware. "It plays on primal human emotions," he says. "When you're on a call, your nerves are up and you're focused on performing well, you might switch off the red flags in your brain that say: I shouldn't take candy from strangers. I shouldn't download executables from random people."
These fake interviews are now a well-documented North Korean tactic, often called Contagious Interview. We've written about a large campaign we uncovered here. In the past few weeks, we've seen two separate fake interview attempts like this. Both used a coding test that hid malware in the setup steps.
What CISOs should check on Monday #
David would walk in with two questions: "What is the risk of people targeting and hacking our engineers? And what could someone do if they did compromise one of our engineers?"
Nate would start with coverage. "Engineers often have local admin, which means they can sometimes disable tools and get around security controls," he says. "So what's our actual coverage of our engineering estate? Then, is it good enough? Would our tools detect a malicious GitHub repo before it's downloaded? Would they spot malicious AI agent usage on an engineer's laptop? Those are very difficult questions for a CISO, but they're critical in today's world."
David says the biggest blind spot is knowing what's on those machines at all. "We talk a lot about building SBOMs for production software so we can scan it for vulnerabilities," he says. "That doesn't work the same way for engineers. There's a blind spot around what software engineers are down and running every day, potentially with root credentials or access to change your platform."
How to protect engineers without slowing them down #
Locking engineers' machines down creates its own problem. "You're stuck between locking down the machines so you have a bunch of highly paid, highly intelligent engineers waiting for you to approve their job," says Nate, "or giving them way too much access, which makes them a juicy target for attackers."
"Engineers don't want to do things wrong," he adds. "If you give them tools that help them innovate securely, they'll use them. If the tools are hard to use, that's when engineers go off-piste. We hire these people to think outside the box. We can't expect them not to when it comes to their own laptops."
David's rules: fit into the workflows engineers already have, only block when it's really necessary, and be fast. "If you add 10 or 20 seconds to something an engineer does regularly, that might sound fine on paper, but it slowly builds up," he says. "Sometimes it's better to alert than to block. If you lose the goodwill of your engineers, you might lose the control altogether."
Final thoughts on Binance #
Speaking before Binance's findings were published, Nate said: "Until we have more information, I wouldn't blame Binance for this," says Nate. "These incidents happen because attackers are incredibly sophisticated and really good at what they do. That doesn't mean Binance was neglectful. They could be good and just not good enough."
Binance's own numbers support that. Its security team says it stopped 57 suspected North Korean attempts in 2026, including fake interviews, malicious developer tools and compromised packages. The one it missed cost $6.3bn. Binance also published its findings within a week, which gives other security teams a clearer picture of what they're up against.
"Look at the tools and companies we use every day. Do we expect all of them to be the best in the world at this? Probably not. We expect them to be good enough. And now we're asking more from good enough."
-
https://www.ossprey.com/blog/how-ossprey-uncovered-a-large-scale-dprk-contagious-interview-campaign
-
https://www.ossprey.com/blog/how-ossprey-uncovered-a-large-scale-dprk-contagious-interview-campaign
-
BC News, "Crypto giant Binance hit by $6.3bn hack suspected to be largest in history," October 30, 2026
-
Binance, initial findings and response update, November 3, 2026 (via Security Affairs )
-
Reuters, "Binance says hackers used fake job interview to compromise computer before $6.3 billion attack," November 3, 2026 ( link )
-
Reuters, "FBI says North Korea was behind the $6.3 billion Binance crypto hack," October 31, 2026
-
Bloomberg Law, via Insurance Business , on Binance's lack of cyber insurance
-
Safe{Wallet}/Mandiant findings on the Bybit breach (Feb–Mar 2025)
-
SentinelOne Labs, TraderTraitor report on LayerZero (2026)
Real World Attacks
Blankets, worms, and RATs: New worm targets NPM and AUR #
Ellie Jevon
29 Sept 2026
Real World Attacks
How Ossprey protects from novel AI-accelerated malware development, and cross-ecosystem supply-chain attacks. #
Ossprey Research Team
24 Sept 2026
Real World Attacks
The supply chain attack map keeps growing. Pub.dev just got added #
Ellie Jevon
8 Sept 2026