Binance says its $6.3bn breach started on one engineer's machine. Ossprey's founders on what that means for every security leader, and what to ask your team on Monday.
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?
What we know about Binance
On Thursday, Binance said $6.3bn in digital assets had been hit in what's thought to be the largest crypto theft on record. Co-CEO Richard Teng said the initial investigation pointed to a compromised engineer's laptop, which gave the attacker access to a service container where they submitted unauthorized withdrawals. He was clear it wasn't a single click or one engineer's permissions, and Binance has since found other breach points.
Binance hasn't said how the laptop was compromised, and this piece doesn't guess. We asked Ossprey's co-founders, Nate Dunning and David Read, 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."
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."
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. Binance hasn't said whether anything like this was involved.
"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."
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 downloading 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
"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."
"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."
Related Posts
Sources
BBC News, "Crypto giant Binance hit by $6.3bn hack suspected to be largest in history," 30 Oct 2026
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
