How Trusted Crypto Whitelists Enabled $1.8B Attac

Your whitelist is not a wall. For nation-state attackers, it’s a map, showing exactly who to compromise to get to your assets.

$1,788,000,000
STOLEN FROM INSTITUTIONS WITH WHITELISTS, MULTISIGS, AND HARDWARE WALLETS IN PLACE

TL;DR

• When you hold significant assets on a public blockchain, nation-state groups will target you – not if, but when
• Your whitelist tells attackers exactly which vendors and counterparties to compromise to reach your funds
• Bybit ($1.5B), WazirX ($235M), and Radiant ($53M) all had whitelists. All were drained through whitelisted entities
• The correct assumption: every whitelisted address is potentially compromised. Trust must be verified in real time, on every transaction.
• Static access control must be replaced with continuous, real-time transaction validation and monitoring

Who Is Coming After You and Why Whitelists Help Them

When a bank or institution holds significant digital assets on a public blockchain, something unique happens: every aspect of their security posture becomes visible to attackers. On-chain balances are public. Transaction patterns are traceable. The addresses you interact with, your whitelist, are not a secret. They are broadcast to the entire world with every transaction.

For professional threat groups, particularly state-sponsored actors like North Korea’s Lazarus Group (responsible for over $2B in crypto theft since 2017), this transparency is a gift. They don’t need to guess your security architecture. They can map it.

The Attacker’s Perspective

A nation-state group surveilling a high-value target will: identify the target’s on-chain wallets and balances; map every address the target regularly interacts with (the whitelist); research each whitelisted entity – vendors, custodians, bridge contracts, DeFi protocols, and more – to find the weakest link, compromise that whitelisted entity, then use the pre-existing trust to complete the attack. The whitelist doesn’t slow them down. It tells them where to look.

This is not theoretical. It is the exact playbook that was executed three times in seven months against three separate institutions, resulting in $1.788 billion in losses.

How Nation-State Actors Use Your Whitelist Against You

The False Confidence Problem

Whitelisting creates a dangerous assumption: “If the address is on our list, the transaction is safe.” This assumption holds only if every entity on your whitelist is guaranteed to be uncompromised at all times. Against sophisticated adversaries with months of patience and nation-state resources, that guarantee is impossible to make.

The correct operating assumption is the opposite: any whitelisted address could be compromised at any time. Every vendor, every client, every protocol on your whitelist should be treated as potentially malicious. Not because they are, but because attackers will specifically target them to exploit the trust you’ve placed in them.

The Evidence: Three Attacks, One Playbook

Between July 2024 and February 2025, the Lazarus Group executed three attacks using exactly this strategy. In each case, the attacker compromised a trusted, whitelisted entity and used that trust to drain the target.

Bybit February 21, 2025 · 401,347 ETH stolen · $1.5B

Whitelisted entity compromised: Safe{Wallet} (wallet infrastructure vendor). Lazarus compromised a Safe developer’s macOS workstation via a malicious Docker project, hijacked AWS session tokens, and injected malicious JavaScript into the Safe UI served from S3. When Bybit’s signers initiated a routine cold-to-warm transfer, the UI displayed a legitimate transaction, but the actual payload replaced the wallet’s smart contract implementation with an attacker-controlled contract containing sweepETH() and sweepERC20() functions. The whitelist check passed because the target address was Bybit’s own wallet.

WazirX July 18, 2024 · 200+ tokens drained · $235M

Whitelisted entity compromised: Liminal (custody provider). Attackers exploited discrepancies between how transactions appeared on the Liminal custody interface and the actual on-chain calldata. Signers approved what looked like a small whitelisted transfer; the real transaction replaced the Safe multisig’s implementation with an attacker contract deployed 8 days earlier. Once the implementation was swapped, the multisig and whitelist ceased to exist; the attacker’s contract had no such restrictions.

Radiant Capital October 16, 2024 · Arbitrum + BSC · $53M

Whitelisted entity compromised: 3 team members (internal signers). A Lazarus operative posed as a former contractor on Telegram and sent a malicious PDF. Malware performed a man-in-the-middle attack on the Safe{Wallet} UI, displaying legitimate transactions while silently swapping the calldata sent to hardware wallets. Ledger/Trezor devices couldn’t parse the complex Safe payloads, so signers “blind-signed” a transferOwnership() call they never saw. Tenderly simulations also showed clean results; the malware sent different data to the simulator than to the signing flow.

The Pattern: Trust as a Weapon

In every case: the whitelist was intact. The multisig was intact. Hardware wallets were used. And the funds were drained, because the trusted party on the whitelist was the attack vector.

What Whitelists Can’t See

The fundamental flaw is that address whitelisting answers only one question: “Is this address approved?” It cannot answer the question that actually matters: “What will this transaction do?”

What the Whitelist Sees vs What Actually Happens

The transaction destination passes every whitelist check. The damage is in the call data, which whitelists don’t inspect.

The specific operations that enabled all three thefts (proxy implementation swaps, ownership transfers, blind-signed payloads) are invisible to any system that only validates addresses. These are state-change attacks, not destination attacks.

The Shift: From Approved Addresses to Verified Outcomes

If the whitelist can’t protect you against adversaries who compromise whitelisted entities, then the operating model must change. The industry needs to shift from static, address-based trust to continuous, real-time transaction validation that verifies what every transaction will actually do, regardless of who it comes from.

1. Real-time transaction simulation

Every transaction, no matter how routine, no matter how trusted the counterparty, should be simulated against current chain state before execution. The simulation produces a state diff: a complete list of every storage slot, balance, ownership, and approval that will change. Security decisions should be based on this diff, not on the destination address.

This simulation would have caught all three attacks: in Bybit and WazirX, the proxy implementation swap produces an unmissable state change in storage slot 0. In Radiant, the transferOwnership() call emits an OwnershipTransferred event to an unexpected address. None of these are visible through address whitelisting. All are trivially visible through simulation.

2. Continuous on-chain monitoring

Real-time protection isn’t only about the signing moment. It requires continuous monitoring of on-chain activity for pre-attack indicators and post-execution anomalies:

Pre-attack signals that were visible but unmonitored:

WazirX: Attacker deployed the malicious replacement contract 8 days before the attack – visible on-chain.

Bybit: Attacker contract with sweep functions deployed 2 days before – visible on-chain.

Radiant: Attacker practiced the exploit with test transactions days before – visible on-chain.

All of these would have triggered alerts in a monitoring system watching for suspicious contract deployments targeting known wallet addresses.

3. Independent verification at the signing layer

The man in the middle (MITM) attacks used against all three targets succeeded because the simulation and signing happened through the same compromised infrastructure. Inserting an independent verification layer that intercepts every transaction before it reaches the blockchain, performs its own simulation on separate infrastructure, and blocks execution if outcome deviates from expectations, breaks this attack chain entirely.

Complete Real-Time Defence Architecture

The Bottom Line

The $1.788 billion lost across these three attacks was not the result of negligence. Bybit, WazirX, and Radiant all operated with industry best practices: multisigs, hardware wallets, whitelists, custody providers. They were drained because best practices assume a threat model that no longer applies.

When your adversary is a state-sponsored group with the resources to spend months on reconnaissance, compromise your vendors, manipulate your signing infrastructure, and clean up their tracks within minutes of execution, your whitelist is not a wall. It’s a map.

The operating assumption must change.

The New Security Posture

Assume every whitelisted address is potentially compromised. Assume every vendor is a potential attack vector. Assume every transaction, no matter how routine, could be manipulated. Then build a system that validates transaction outcomes in real time, independently of the UI, the vendor, and the signer. Because the next attack won’t break your whitelist. It will use it.

Based on forensic reports from Sygnia, NCC Group, Mandiant, Chainalysis, and respective incident response teams. All on-chain data is publicly verifiable.