On Oct. 29, attackers moved $6.36 billion out of Binance wallets across 10 blockchains Opens a new window , most of it in roughly 20 minutes. It’s the largest cryptocurrency theft on record, and Binance’s first explanation didn’t involve broken encryption. It involved one engineer’s laptop.
Picture that laptop on a desk in your own office. It belongs to someone you trust, it passed every login check, and someone else is now driving it. What actions might that individual be able to prompt your systems to approve before anyone became aware?
You don’t have to run a crypto exchange to ask that question. If your systems release payments, push code, or delete backups when told to, you have the same type of exposure. The answer comes from audit basics that ISACA has taught for decades, including separation of duties and multi-person approval. By the end, you’ll have a one-workflow test your team can run this month.
Ultimately, verifying who is accessing a system is only half the battle if the system blindly trusts whatever actions they request .
What Binance has disclosed
Start with what the company has said in public. Binance’s initial statement said the incident “may involve a compromised DevOps engineer’s laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions.” It also said it had found no evidence of a wallet private-key leak Opens a new window . Blockchain analysts at TRM Labs said the attackers had compromised the signing infrastructure that authorizes transactions Opens a new window .
Since then, the story has grown more complicated. Binance later said its investigation had uncovered additional points of breach Opens a new window . Co-CEO Richard Teng added that “the attacker did not simply use one engineer’s permissions, and this was not a single ‘one-click’ action,” as he told Mashable Opens a new window .
So don’t read this as “one laptop cost $6.3 billion.” The full attack path isn’t public yet. What is clear is where the money left through the systems that approve withdrawals, not stolen keys.
Logins don’t approve actions
Frances Zelazny, general manager of new market initiatives at identity firm Prove, highlighted the critical distinction between identity verification and permission in to the International Business Times Opens a new window .
“At the same time, authentication does not equate to authorization,” Zelazny said. “A legitimate user or service may have access it should not have.”
She went a step further on digital signatures. “A digital signature does not establish intent,” she said. “It establishes that the required cryptographic authorization occurred, not that the transaction or the person behind it was legitimate.”
In short, verifying identity confirms who logged in, but it cannot confirm whether a requested action is appropriate or separately approved. Auditors rely on specific controls to address this gap.
Who can ask, who can approve
That control is separation of duties. ISACA’s guidance says no employee or group should be in a position to both commit and conceal errors or fraud Opens a new window in their normal work. The guidance separates asset custody from transaction approval, ensuring both are distinct from those who record and verify them. One ISACA Journal writer called it “ the great-granddaddy of all controls Opens a new window .”
This is where modern IT becomes complicated. Your DevOps engineer might not personally authorize a payment. However, the service accessible from an engineer’s laptop could potentially submit one. If that laptop can also modify the service, then the separation is only theoretical and not practical.
ISACA published this automated pipelines. Once automation replaces the human “extra set of eyes,” pipeline integrity becomes the stand-in for separation of duties Opens a new window . The article adds that exceptions should be rare and monitored while they’re active.
You can check this with a sheet of paper. Write down who and what can start your riskiest action, then who and what can approve it. If the same account, laptop or service shows up on both lists, you have a conflict, no matter how good its multifactor authentication is.
When every signer is fooled
The usual fix for one person holding too much power is to require two or more people to sign off. In crypto, that’s a multisignature wallet. In your shop, it might be dual approval on wire transfers or a second reviewer on production changes. It works well right up until every approver is looking at the same bad screen.
Bybit learned that in February 2025. Attackers broke into a developer machine at Safe{Wallet}, Bybit’s multisig provider, and planted code that showed signers a routine transfer while they actually signed away control of the wallet Opens a new window . Three signers approved it. Bybit’s CEO later said he didn’t check the transaction details on his hardware wallet before signing Opens a new window . $1.46 billion was signed away.
The approval rule was followed to the letter, and it still failed. Every signer trusted one compromised screen. For your approvals, ask a simple question: If the system making the request lied it, would the approver ever find out? If the answer is no, give approvers a second way to see the request, or add rules the requester can’t edit, such as limits on amount and destination.
The process behind the vault
Jayant Dave, Asia-Pacific CISO at Check Point, summed up the Binance case for the BBC Opens a new window .
“The attackers didn’t break the encryption or steal the private keys. They took over the system that tells the keys what to sign,” Dave said. “That’s the lesson: a strong vault doesn’t matter if someone controls the process that opens it.”
He doesn’t think the risk stops at crypto. “Banks, payment providers, cloud platforms: any organization whose automated systems move money or data on instruction carries the same risk,” he told The Independent Opens a new window . He also pointed to a smaller exchange, Bitget, which lost $388 million five weeks earlier with “ keys untouched, control layer abused Opens a new window .”
ISACA’s COBIT framework covers that process under business process controls, which call for checks on what goes into and comes out of key processes, monitored end to end Opens a new window . Most security spending goes to guarding the vault. Far less goes to controlling who can tell it to open.
Proving it in 20 minutes
From there, the question becomes evidence. A control that lives in a policy binder won’t help during a 20-minute theft. You need two things you can show an auditor: a log someone can act on, and a person who can hit stop.
Logs come first, and they need their own separation. ISACA guidance says administrators shouldn’t be able to modify or destroy the logs Opens a new window of the systems they run. Otherwise, the person who made the change can also erase the record of it.
The stop button comes . Binance paused withdrawals and revoked authorizations for the affected address Opens a new window once it knew. Decide now who in your company can freeze a payment run or pause a deployment without waiting for a full diagnosis. Then make sure that person can actually do it at 4 p.m. on a Thursday, which is roughly when Binance’s money started moving on the U.S. East Coast.
Go back to the laptop on that desk. Pick one action your company can’t afford to get wrong, such as a backup deletion or a large payment. In an approved test environment, try to complete it using only the access that one engineer’s laptop has. Note what stopped you, if anything, and who would have known.
If nothing stopped you, you found your Binance problem before an attacker did. That’s a much cheaper way to learn it.
Categories: Articles , Security
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
