Radiant Capital (2024)

A $50M+ exploit in October 2024 against Radiant Capital, a cross-chain lending protocol on Arbitrum and BSC. The exploit involved compromising three multisig signers via malware, then using the legitimate-looking signatures to upgrade the protocol contracts to a malicious implementation that drained funds.

Timeline

  • October 16, 2024: Attacker drained ~$50M from Radiant's BSC and Arbitrum deployments.
  • Same day: Radiant team disclosed and paused remaining operations.
  • Subsequent weeks: Forensic analysis published. Attributed to a North Korean state-aligned actor; malware delivery via a malicious PDF disguised as a former Radiant contractor communication.
  • Recovery: None significant. Funds laundered through standard mixers.

Root Cause

Radiant Capital used a 3-of-11 multisig to control protocol upgrades. The attacker compromised three signers' devices via a sophisticated malware attack and executed a malicious upgrade.

The malware was particularly insidious: it intercepted the signers' wallet interfaces so that signers saw "normal" transactions on their device displays but were actually signing the malicious upgrade transactions. From the signer's perspective, everything looked legitimate; they signed knowingly but were deceived about what they were signing.

After three signatures were obtained, the attacker executed:

  1. An upgrade transaction that replaced Radiant's pool contract with a malicious implementation.
  2. The malicious implementation drained funds via standard "transfer everything to attacker" calls.

Exploit Path

Off-chain (over weeks):

  1. Reconnaissance: identifying who the signers were.
  2. Spear-phishing: a contract-related PDF, claimed to be from a known former contractor.
  3. PDF opened on signer's machine. Malware installed.
  4. Malware monitored the signer's wallet (likely Ledger or similar hardware-wallet integration), intercepting transaction-display calls.

When a signer connected to the legitimate Radiant multisig interface to sign a routine transaction, the malware intercepted: signer saw the routine transaction; the actual signature was over a different, malicious transaction.

This was done three times — once per compromised signer — building up the threshold needed.

On-chain:

  1. Upgrade transaction submitted with three legitimate-looking signatures.
  2. Contracts upgraded to malicious implementation.
  3. Funds withdrawn.

What an Audit Should Have Caught

The smart contracts and multisig mechanics were correct. A code audit would not have caught this. But broader security review should have flagged:

  1. 3-of-11 threshold may be too low for the value at stake. At ~$300M TVL, 3 compromised signers should not be sufficient. Higher thresholds (5-of-11, 6-of-11) raise the bar.

  2. No timelock on upgrades. A protocol upgrade should have a delay (24 hours, 7 days) during which a malicious upgrade can be detected and the signers (or an emergency multisig) can cancel. Radiant had immediate upgrades.

  3. Cold/hot signer separation. Operational signers (for routine ops) and upgrade signers (for code changes) can be separated. Even if hot signers are compromised, upgrade authorization requires the cold set.

  4. Signer-device hygiene. This is the murkier ground for audits, but: assessing whether signers use dedicated hardware, separate machines, no general internet browsing on signing machines, etc. is part of operational security review.

  5. Display-verification practices. When using hardware wallets, signers must verify what's shown on the hardware device's screen, not just the host computer's screen. The hardware device's display is harder to compromise. (Whether the Radiant signers properly verified hardware display is unclear from the public postmortem.)

Lessons

  1. State-aligned attackers are sophisticated. The Radiant attack involved weeks of reconnaissance, custom malware, and a believable phishing pretext. This is not a script-kiddie attack; it's a directed APT-style operation. Protocols holding tens of millions are targets.

  2. Multisigs must include timelock and rate limits. A multisig without a timelock can be drained in a single block once the threshold is met. With a 24-hour timelock, the same incident has a 24-hour window for response. The trade-off (slower routine operations) is worth it.

  3. Signer compromise is the dominant multisig risk. Not signature math, not on-chain logic — the signers themselves. Audits should ask about signer hardware, network isolation, training, and recovery procedures.

  4. Hardware wallets are necessary but not sufficient. Display-verification matters. Signing flow training matters. The most secure hardware wallet, if not verified on its own screen, can be deceived by malware on the host.

  5. Upgrades are the most dangerous operation. A single upgrade transaction can rewrite the entire protocol. Audit reports should treat upgrade authorization with the same scrutiny as withdrawal authorization — same multisig thresholds, same timelock, same monitoring.

  6. Pause functions matter, but only if reachable. Radiant did pause after the exploit. By then, ~$50M was gone. Pause functions are useful for limiting an ongoing attack, less useful for an attack that completes in a single transaction.

The Radiant incident is recent enough that the industry response is still in progress. Likely outcomes: more protocols moving to longer upgrade timelocks, more emphasis on signer opsec in audit scope, more anti-malware tooling for governance signers. These are partial mitigations; the deeper issue — that motivated nation-state-level adversaries can compromise individual people — does not have a clean technical solution.