The ByBit hack wasn't a smart contract exploit. No reentrancy bug, no flash loan, no oracle manipulation. The multisig worked exactly as designed — every signer approved the transaction, the threshold was met — and 401,000 ETH walked out the door.
I've looked at hundreds of stolen-funds cases. This one stands out because the vulnerability wasn't in the code. It was in the signing interface.
What happened
On February 21, 2025, attackers drained ByBit's cold wallet. It ran a Safe{Wallet} multisig requiring three signers. None of them were compromised directly.
Weeks earlier, the attackers had socially engineered a Safe{Wallet} developer, stolen AWS session tokens, bypassed MFA, and injected malicious JavaScript into the signing frontend. When ByBit's team initiated a routine cold-to-hot transfer, the UI showed normal transaction details. The signers approved what they saw. But what hit the blockchain was a delegatecall that swapped the wallet's logic contract for an attacker-controlled version. Full control. All assets gone. From the outside, the transaction looked completely authorized.
Why delegatecall changes everything
Delegatecall lets external code run inside the calling contract's storage. The attacker rewrote the wallet's rules from inside the wallet. The proxy address stayed the same. The implementation behind it was now theirs.
The part I keep coming back to: EIP-712, the standard that makes signing requests human-readable, can't decode nested delegatecall payloads. The signers had no way to tell the difference between a normal transfer and a complete wallet takeover. Not with standard tools, not with careful review.
A valid signature proves someone pressed a button. It doesn't prove they understood what they signed.
What followed
Funds were dispersed across intermediary wallets within minutes — DEXs, cross-chain bridges, no-KYC swap services. By March 20, ByBit's CEO reported 86% of the stolen ETH had been converted to BTC. ZachXBT linked the attack to North Korea's Lazarus Group based on transaction clustering.
One pattern worth noting: some stolen assets went dormant for weeks before reactivating. Classic Lazarus. I've seen this in other cases too — people assume a cold trail is a dead trail. It usually isn't. If you've stopped watching, you miss the reactivation.
Why the forensics are hard
Delegatecall obscures the actual contract interaction. Standard block explorers can't fully decode what happened because the execution context is abstracted. You have to dig deeper than surface-level transaction data.
The off-chain compromise — the UI manipulation, the developer workstation breach, the AWS hijacking — leaves no on-chain trace at all. Without infrastructure logs and incident response artifacts, you're working blind.
And cross-chain laundering through no-KYC services breaks the tracing chain at every hop. You can't follow the money in a straight line. It takes cluster analysis and behavioral pattern matching — a different skillset than straightforward address tracking.
The uncomfortable part
This transaction was cryptographically valid. All required signers approved it. On-chain, it looks authorized. Any compliance framework that treats a valid multisig approval as proof of legitimate intent is not equipped for this type of attack.
If you're writing up a case like this, you need both layers. On-chain data tells you what was approved and where funds went. Off-chain evidence — interface behavior, signing logs, communication records — tells you whether the approval was genuine. Neither alone is enough.