November 2026 Binance Hack: When a Bank Gets Robbed, I Look at the Vault, Not the Whole System
By Jean-Hugues Migeon
When a bank gets robbed, I look at the vault, the access logs and the credential that failed. I do not ask whether banking as a system should exist. That is the distinction missing from most of what I have read about the Binance hack this week, and it is worth making explicit before the "crypto is not safe" commentary calcifies into conventional wisdom.
Binance lost an estimated $6.3 billion on 29 October. TRM Labs traced roughly $6.36 billion moved across ten blockchains in about twenty minutes, the largest cryptocurrency theft on record. Early lessons, from where I sit as a security officer rather than a crypto trader: this was a credential and access control failure, and it deserves exactly the scrutiny any custodian breach deserves. What it does not deserve is treatment as evidence that an entire asset class is structurally unsound.
My thesis: judge Binance the way you would judge any custodian that got breached, on the control that failed and whether it gets fixed, not on the ledger technology underneath it.
What actually failed
Binance's own account points to a compromised DevOps engineer's laptop that reached a service container, which then submitted unauthorized withdrawal transactions. Kok Tin Gan, CEO of cybersecurity firm NyxLab, described it as one signature handing the attacker a never-expiring, full-access token to a hot wallet. Binance later said its investigation had found additional points of breach beyond the laptop. TRM Labs and Chainalysis independently attribute the attack, with high confidence, to TraderTraitor, the North Korean unit the FBI already named for the $1.5 billion Bybit hack in February 2025.
None of that is a property of blockchains. A standing credential with no expiry, reached through one compromised endpoint, is the same failure mode that has emptied vaults long before anyone had heard of a hot wallet.
The strongest version of "but crypto is different"
I want to give this argument its full weight before I answer it, because the weak version is easy to wave off and the strong version is not. Crypto exchanges hold customer assets the way a bank does, but without deposit insurance, without a lender of last resort, and with settlement that is final the moment it clears a block. A bank wire can sometimes be recalled. A blockchain transaction cannot. When Binance's hot wallet signed those withdrawals, the money was gone in the time it takes to make coffee, with no central bank standing behind the loss and no deposit insurance scheme for the customers. Binance has pledged to cover it from its own balance sheet, which is a promise, not a guarantee structure.
That is a real structural difference and I am not going to pretend otherwise.
Why it still is not an indictment of the asset class
Here is what the "crypto is not safe" framing misses: the attacker is not new to this, and neither is the method. Blockchain intelligence firms attribute both this hack and the 2025 Bybit hack to the same North Korean unit the US government already held responsible for the 2016 Bangladesh Bank heist, in which fraudulent SWIFT messages moved $81 million out of a correspondent account at the New York Fed. That heist was caught mid-flight, by a malfunctioning printer and a routing-bank clerk who flagged a misspelled beneficiary name, not by any structural safeguard built into the SWIFT system or the banking relationship it ran through. The same adversary has now run the identical playbook, credential compromise, privileged access, move the money before anyone notices, against a correspondent bank account in 2016 and a hot wallet in 2026. The asset class changed. The method did not.
What also does not fit the "lawless and irreversible" narrative: Tether and Circle froze a combined roughly $2.38 billion in stolen stablecoins within hours of the hack, part of about $3 billion Binance says has been frozen in total. That is a centralized circuit breaker operating inside a system that is supposedly immune to one. Crypto's settlement finality is real, but the ecosystem around it has built workarounds that a wire transfer routed through a chain of correspondent banks often does not have.
What a security officer actually takes from this
I am not arguing Binance's controls were adequate. A credential that never expires and a service account with standing write access to a hot wallet are findings I would flag in any audit, crypto or otherwise. But "flag it in the audit" is itself the weaker version of the lesson, because a finding from a quarterly review would have told you about this gap months after an attacker already found it. The actual access control issue is not that the credential existed. It is that nothing in the architecture put a ceiling on what a single compromised credential could do, and nothing in the monitoring noticed the result in real time.
Three questions I would put to any custodian running this kind of audit, crypto exchange or otherwise:
- Does any single credential have standing, unsupervised authority over the sensitive action? A hot wallet that can be fully drained by one signature is a single point of failure by design. Quorum signing, multi-party approval, or a second system that has to independently attest before a withdrawal executes would have turned a twenty-minute theft into a blocked transaction.
- Do privileged tokens expire, and is "never expires" ever an acceptable answer? A long-lived, full-access token is a liability the moment it is issued, not just the moment it is stolen. Short-lived, just-in-time credentials, reissued for each sensitive action rather than held indefinitely, shrink the blast radius of exactly this kind of laptop compromise.
- Is withdrawal behavior itself being watched, independent of whether the credential used looks valid? Six billion dollars moving across ten blockchains in twenty minutes is an anomaly on volume and velocity alone, regardless of whose signature authorized it. A system that can flag and pause that pattern in real time does not need to already know the credential was stolen.
None of these are blockchain-specific controls. A mature security program asks the same three things of a bank's treasury operations, a cloud admin console, or a SaaS vendor holding standing API keys into your environment: who owns this control, is it watched continuously rather than checked at the next audit cycle, and does an anomaly reach someone who can act on it in minutes rather than at the next governance committee meeting. A program that only produces findings is documenting risk, not managing it.
Detecting that $6 billion moved in twenty minutes is a lagging signal. It is useful for the postmortem, not for stopping the theft. The harder question is whether the risk could have been scored before that credential was ever used: a token with no expiry, full access and no second approval is a predictable liability the day it is issued, not just the day it is stolen. That is the shift insAIght is built around for AI systems and vendor access: scoring a system's or a grant's risk continuously against the frameworks that apply to it, so an unreviewed, over-privileged credential shows up as an open finding before an attacker finds it, not in the postmortem after. The second half of that shift is enforcement inside the workflow itself rather than a dashboard someone has to remember to check: a control that can require a second approver, time-box an access grant, or block an action once a risk threshold is crossed, instead of one that only raises an alert for a human to triage once the money is already gone.
The lesson is about where to point the scrutiny: at the specific control that failed and whether the fix holds, not at a blanket verdict on an entire category of financial infrastructure because one operator's privileged access management had a gap.
Judge the vault. Fix the lock. Do not condemn the bank because a window was left open.
Learn more
- insAIght: continuous tracking of the vendors, systems and access sitting inside your risk register, instead of a point-in-time review.
- Your Chatbot Is Not a Feature. It Is a Legal Exposure.: the same argument, judge the specific control, applied to AI vendor risk.
- ExplAIn: making the behavior of the AI and automated systems your firm relies on explainable to auditors and regulators, the same instinct applied one layer up from access control.
Want a second opinion on where your own access controls would hold up under this kind of scrutiny? Book a demo.