The Radiant Capital Hack Explained: $50M

Video transcript

Radiant Capital's signers used hardware wallets, simulations and multiple reviewers. In October 2024, they still signed the attacker's transactions.

It started with a Telegram message from a fake former contractor. A zipped PDF spread among developers, carrying malware that set up a macOS backdoor.

Safe showed signers the legitimate transaction while malware sent a different one to their Ledgers. Then Safe showed an error, and the retries gave attackers the signatures they needed.

Three signatures were enough. On October sixteenth, the attackers took over Radiant's core markets on Arbitrum and BNB Chain, draining about fifty million dollars.

A hardware wallet protects the key, not the decision. A check on a compromised machine inherits the compromise. Errors are signals. And low thresholds multiply device risk.

Radiant has since moved to fresh cold wallets, a four of seven threshold, a seventy two hour minimum timelock, and split privileged roles.

But Radiant says it is not clear that timelocks would have prevented this attack, given three signers' devices were compromised. Verification has to run on a device the attacker does not control.

Signers' devices, what they can see, and a low threshold are the subject of Guardian's OpSec Audit. You get a ranked list of changes, each tied to the path it closes.

Read the full breakdown, or talk to Guardian about what your signers actually see, at guardian.security.

Radiant Capital is a multichain lending protocol. Its admin multisig holds "the most critical permissions in the system," Radiant says.

Its signers followed the usual advice: hardware wallets, simulations in Tenderly, and review by several developers at each signature. They still signed the attacker's transactions.

That makes this a case about signing devices and what signers can verify, not about contract code.

What Happened

On September 11, 2024, a Radiant developer got a Telegram message from what looked like a trusted former contractor.

It linked to a zipped PDF about the contractor's supposed new work in smart contract auditing, and asked for feedback. The file was shared with other developers.

It carried INLETDRIFT, malware that set up a persistent macOS backdoor while showing a legitimate-looking PDF. The download domain spoofed the contractor's real website.

The lure fits a pattern covered in our guide to social engineering attacks on multisig signers.

On October 16, the attackers used the infected devices to take over Radiant's core markets on Arbitrum and BNB Chain. About $50 million was drained.

They also used open token approvals to pull funds from users' wallets, Radiant says.

How the Attack Worked

Radiant's admin multisigs needed three signatures: 3 of 9 on Ethereum and Base, and 3 of 11 on Arbitrum and BNB Chain.

The attackers wanted three hardware wallet approvals for a transferOwnership call. They got them during a routine emissions adjustment.

What the signers saw

Radiant's post-mortem describes the swap step by step:

1. Safe{Wallet} showed the legitimate transaction.
2. On approval, the malware sent a different transaction to the hardware wallet.
3. On the Ledger hardware wallets, the blind-signing data "also appeared valid."
4. Safe then showed an error and asked the signer to try again.

Over several attempts, the retries gave the attackers the valid signatures they needed. Failed Safe transactions are common, Radiant notes, so this "did not raise immediate suspicion."

Every transaction was simulated in Tenderly. The malware worked at the device level, so the simulations "returned normal results," Radiant says.

For why a device shows a hash instead of the action, see what blind signing is.

Pauses fired; the attacker went around them

At 17:09 UTC, a malicious transaction transferred ownership of the Arbitrum LendingPoolAddressesProvider. Automated pauses fired on Ethereum and BNB Chain within 22 seconds.

At 17:11, the attacker took ownership on BNB Chain anyway, "bypassing the pause and upgrading the implementation."

Three minutes after the theft, the attackers removed traces of their backdoor and browser extensions, Radiant's December update says.

Timeline and Loss

Every entry below comes from Radiant's post-mortem and its December update.

The loss figures differ slightly:

• Radiant: about $50 million, from core markets on Arbitrum and BNB Chain.
• DefiLlama: $50 million.
• Rekt: over $53 million.

In September 2025, Radiant said the stolen funds "have remained unspent across several Mainnet addresses." It launched a recovery bounty.

On June 1, 2026, Radiant announced an orderly wind-down. It said affected users "have not been remediated, and recovery efforts remain ongoing and uncertain."

Attribution

Mandiant attributes the attack to UNC4736, also known as AppleJeus or Citrine Sleet. It assesses with high confidence that the group has a North Korea nexus, per Radiant.

What It Shows

A hardware wallet protects the key, not the decision

On the Ledger devices, signers saw blind-signing data, not the action they approved. Radiant's December update points to "the reliance on blind signing and front-end verifications that can be spoofed."

A check on a compromised machine inherits the compromise

The malware worked on the signers' own devices, so Safe and Tenderly showed nothing wrong. Verification has to run on a device the attacker does not control.

Errors are signals

The attackers disguised signature collection as routine failures. "During the past weeks, I've had to sign transactions twice in Rabby," one developer said in the post-mortem.

Low thresholds multiply device risk

Three devices were enough to take the core markets. Radiant has since raised its admin threshold.

Radiant's changes after the incident:

• Fresh cold wallet addresses, made on new, uncompromised devices.
• A 4 of 7 threshold on the Admin and DAO multisigs.
• A minimum 72-hour timelock on upgrades and ownership transfers.
• Privileged roles split, so no single role holds "super" powers.
• Transaction data double-checked in Etherscan's input data decoder.

Radiant itself notes that "it is not clear that timelocks would have prevented this attack given the devices of three signers were compromised."

Our guides cover the routines: how to verify a Safe transaction before signing, and what to do when a signer is compromised.

How Guardian's OpSec Audit Maps This

Radiant's loss ran through signers' devices, what they could see, and a low threshold. Those are the subject of Guardian's OpSec Audit.

Its first area is the threat model: the contracts that hold your funds, the roles that can move them, and the keys, signers and multisigs behind each one.

Radiant's gaps line up with the audit's other areas:

You receive the threat model of your funds and a ranked list of changes to make, each tied to the path it closes.

Paired with Managed Security, that threat model stays current, with every multisig transaction and deployment reviewed as it lands.

Frequently Asked Questions

How much was lost in the Radiant Capital hack?

About $50 million, per Radiant and DefiLlama; Rekt reported over $53 million. Funds were drained from core markets on Arbitrum and BNB Chain, and from users' wallets through open token approvals.

Who hacked Radiant Capital?

Mandiant attributes the attack to UNC4736, also known as AppleJeus or Citrine Sleet, per Radiant's December 2024 update. It assesses with high confidence that the group has a North Korea nexus.

How did the Radiant attackers get valid signatures?

Malware on at least three developers' devices showed normal transactions in Safe{Wallet} while sending malicious ones to their hardware wallets. Safe then showed an error, and the retries gave the attackers more valid signatures.

Did Radiant's simulations catch the attack?

No. Each transaction was simulated in Tenderly and reviewed by several developers. The malware manipulated data at the device level, so the checks showed nothing wrong. Radiant said contributors would double-check payloads in Etherscan's input data decoder.

Sources

• Radiant Capital: Radiant Post-Mortem (October 2024)
• Radiant Capital: Radiant Capital Incident Update (December 6, 2024)
• Radiant Capital: Radiant Capital Recovery Bounty Program (September 8, 2025)
• Radiant Capital: Sunsetting Radiant Capital DAO: Entering Recovery Phase and Lessons for the Future of DeFi (June 1, 2026)
• Rekt: Radiant Capital, Rekt II (October 17, 2024)
• DefiLlama: Hacks dataset API (read November 6, 2026)
• Guardian: OpSec Audit
• Guardian: Managed Security