The $1.4B Hack a Single Automation Would Have Caught
A $1.4 billion hack that a single automation would have flagged, and why manual review is the vulnerability, not the solution.
On February 21, 2025, the Lazarus Group stole $1.4 billion from Bybit's Safe multisig wallet. The signers checked the transaction. They reviewed it in the Safe UI. They approved it. They did everything right.
The problem: the Safe UI was the attack. The attackers had compromised a Safe developer's laptop weeks earlier, injected malicious JavaScript into the web application, and swapped the transaction data underneath the interface. The signers saw a routine transfer. What they actually signed was a delegatecall to a malicious contract that rewrote the wallet's implementation pointer and handed the attacker full control.
Every signer looked at the screen. Every signer approved. The manual review process didn't fail. It was the attack surface.
What actually happened, step by step
A Safe multisig works like this: someone proposes a transaction, it sits in a queue, owners review and sign it one by one, and once enough signatures are collected (the threshold), it executes on-chain.
Every transaction has an operation field. It's either 0 (a normal call) or 1 (a delegatecall, which runs the target contract's code with full access to the Safe's storage). A delegatecall from a Safe is almost never legitimate in day-to-day operations. It lets the target contract rewrite anything inside the Safe: the owner list, the threshold, the implementation pointer, everything.
The Bybit attack worked in three stages:
-
Compromise the UI. The attackers got access to a Safe developer's machine and injected JavaScript into the Safe web app. The code detected when Bybit's specific signers were using the app and only activated for them.
-
Swap the transaction. When a routine transaction was proposed, the malicious JavaScript replaced the actual parameters: it changed
operationfrom0to1(delegatecall), pointedtoat the attacker's contract, and replaced thedatafield with malicious calldata. The UI continued to show the original, legitimate transaction. -
Collect signatures. The signers opened Safe, saw what looked normal, and signed. Their hardware wallets showed the real EIP-712 data, but as raw hex that most humans can't parse. Once enough signatures were collected, the transaction executed: a delegatecall to the attacker's contract, which overwrote the Safe's implementation pointer and gave the attacker arbitrary control over $1.4 billion in assets.
The attack succeeded because the review happened inside the compromised environment.
The tools that appeared after Bybit, and what they miss
Since the hack, a wave of products has launched to address multisig security. Tenderly deepened its Safe simulation integration. Blockaid shipped Cosigner, an automated co-signer that screens raw transaction data before adding its signature. Hypernative Guardian analyzes transaction intent before signing. CoolWallet added simulation previews to their hardware wallets.
These are good products. Some would have caught the Bybit attack. But they all assume a human is sitting at a desk, about to sign, with time and context to review a simulation result or wait for a co-signer to clear.
That's not how DeFi operations actually work. A protocol team managing a Safe treasury is processing dozens of transactions per week: payroll, grant disbursements, liquidity provisioning, parameter updates. Signers are spread across time zones, signing asynchronously, often on mobile, often between other tasks. The 50th transaction gets less scrutiny than the 1st. And the attacker only needs to win once.
This problem gets worse with autonomous agents. Coinbase has shipped Agentic Wallets. Protocols are building AI agents that manage DeFi positions and execute trades autonomously. These agents sign programmatically. A simulation tool that requires a human to look at it is useless when the signer isn't human.
The post-Bybit tools solve verification: better ways to inspect a transaction before signing. They don't solve monitoring: who is watching the transaction queue when nobody is looking? Who alerts the team when a delegatecall appears at 3am on a Saturday?
What's missing is a background process that watches continuously and pushes alerts through an independent channel, before anyone signs, before anyone opens the UI, whether the signer is a human or an agent.
The automation that would have caught it
There is a single piece of data that exposes this attack: the operation field in the pending transaction.
The Safe Transaction Service, the off-chain API where pending transactions sit before they're signed, stores the raw transaction data independently from the web UI. It doesn't go through the compromised JavaScript. It doesn't render anything for a human to misread. It just holds the data.
An automation that polls the Safe Transaction Service, reads the operation field, and sends an alert through an independent channel (Discord, Slack, PagerDuty, anything that isn't the Safe UI) would have caught the Bybit attack before the first signer approved.
The alert would have arrived in Discord:
CRITICAL: Pending transaction uses delegatecall
Safe: 0x...Bybit
To: 0x96221423681A6d52E184D440a8eFCEbB105C7242
Operation: DELEGATECALL
Risk: 94/100
Analysis: This transaction executes a delegatecall to an unverified
contract. The target contract can modify any storage slot in the Safe,
including the implementation pointer. Do NOT sign unless you fully
understand and trust the target contract.
Signatures: 0/3
safeTxHash: 0x...
The signers would have seen this in Discord before they opened the Safe UI. Before the compromised JavaScript had a chance to show them a fake transaction. Before they touched their hardware wallets.
The question isn't whether a human can check the operation field. They can. The question is whether they're checking it through a channel the attacker doesn't control.
Why automation, not better tools
The instinct is to say "just check the transaction more carefully." And now there are AI agents: give one a calldata-decoding skill, point it at your Safe, and ask it to verify before you sign.
But the Bybit attack didn't exploit a lack of tools. It exploited the gap between having a tool and using it. Every signer had the ability to verify independently. None of them did, because the compromised UI gave them no reason to. Better tools, including AI agents, widen the toolkit but leave the same vulnerability intact: someone has to initiate the check.
The attack waited weeks after initial compromise to activate. It was patient. It was waiting for the 51st transaction, the one where the signer glances at the screen and approves without a second thought. A better tool doesn't help if nobody picks it up.
What changes the equation is removing the human from the initiation loop entirely. An event-driven workflow that polls every minute, queries the Safe Transaction Service API directly (never loading the compromised web app), and pushes alerts to Discord or PagerDuty through a completely independent channel. No step where a human decides "I should check this one." The check is the default. Silence is the anomaly.
How it works on KeeperHub
This is a production workflow running today on KeeperHub:
Every 1 minute (scheduled):
1. Poll Safe Transaction Service for pending transactions
2. Check: any new transactions since last poll?
3. For each new transaction:
a. Check deduplication database (skip if already alerted)
b. Decode the calldata and analyze the operation type
c. Run AI risk assessment -- score 0-100, plain-English explanation
d. Send Discord alert with:
- Risk level and score
- Decoded function name and parameters
- Operation type (CALL vs DELEGATECALL)
- Target address and value
- Current signature count vs threshold
- safeTxHash for independent verification
e. Record in database (never alert on the same tx twice)
Low-risk alerts are ambient. "LOW (12/100): ERC-20 transfer of 500 USDC to known payroll address." You glance at it in Discord and move on. It's a heartbeat that tells you the system is watching.
High-risk alerts escalate. "CRITICAL (94/100): delegatecall to unverified contract, target can modify Safe storage." That one pages the on-call signer at 3am, because a delegatecall to an unverified contract is not something that should wait until morning.
Same workflow, two modes: background monitoring that builds passive awareness, and active escalation that interrupts you when it matters.
Deploy it now
The Safe Signing Alert workflow is live on KeeperHub as a public template:
- Go to app.keeperhub.com
- Find the Safe Signing Alert template
- Enter your Safe address
- Connect your Discord
- Enable
It polls every minute. It deduplicates alerts. It decodes calldata and scores risk. It runs 24/7 without anyone remembering to check.
Your Safe is holding real value. The attacker is patient. Your automation should be running before they are.
Sources:
- NCC Group: In-Depth Technical Analysis of the Bybit Hack
- Sygnia: Investigation into the Bybit Hack
- Check Point: What the Bybit Hack Means for Crypto Security
- Certora: The Bybit Hack and Multisig Wallet Security
- Blockaid: How to Prevent the Next $1.5B Bybit Hack
- Hypernative: How Guardian Would Have Stopped the Bybit Hack
- Coinbase: Introducing Agentic Wallets
- Chainalysis: 2025 Crypto Theft Reaches $3.4 Billion
