Radiant Capital, a major player in the DeFi space, recently fell victim to a $58 million exploit that affected both Arbitrum and BSC chains. The attacker managed to gain control of 3 out of 11 multisig signers, just enough to upgrade the contract’s implementation and drain significant funds.

This post-mortem dives deep into how it happened, where things went wrong, and what can be done to prevent future attacks.

TL;DR: Giving You The Short Version

Here’s the condensed breakdown:

• Radiant Capital lost $58M through a multisig exploit across Arbitrum and BSC.
• The attacker took over 3 signers, transferred ownership, upgraded the contract, and drained the treasury.
• The incident raises concerns about multisig security and the complexity of cross-chain protocols.
• Immediate steps have been taken to revoke access, and future preventive measures are being discussed.

What Is Radiant Capital Exactly?

Radiant Capital is a decentralized finance (DeFi) protocol designed to offer cross-chain borrowing and lending solutions powered by LayerZero. Users can seamlessly borrow assets and earn interest across multiple blockchains, creating a liquid market with substantial liquidity locked into its smart contracts.

However, like most DeFi projects, Radiant’s smart contracts and multisig wallets are key to its security architecture — an area that was exploited in this attack.

How Did the Attack Unfold?

On 0xd97b93f633aee356d992b49193e60a571b8c466bf46aaf072368f975dc11841c tx, the attack started with a transaction involving over $303K in USDC, $451K in BUSDT, 160 BTCB, 220.6 wBETH, 8469 wBNB, and 470.4 ETH, all drained from Radiant pools. These assets were transferred to the attacker’s wallet (0x0629b1048298AE9deff0F4100A31967Fb3f98962).

Interestingly, 14 days before the attack, the attacker’s address deployed a contract (0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5) that played a key role.

At 0xd97b93f633aee356d992b49193e60a571b8c466bf46aaf072368f975dc11841c tx, address 0x0629b1048298AE9deff0F4100A31967Fb3f98962 called multicall function on this contract 0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5.

Using the multicall function on this contract, they upgraded the contract implementation, taking ownership of Radiant’s contract.

This multicall function executes multiple calls in one transaction, typical for contracts performing batched operations.

It requires the caller to be the contract’s owner, and uses msg.data to process input data.

Caller & contract owner both are at this case 0x0629b1048298AE9deff0F4100A31967Fb3f98962.

This way the attacker basically transfers the ownership to their own contract 0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5.

If you look into the contract code of 0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5, you will see

• The multicall() function loops through a list of contract addresses (v1), extracts data from msg.data, and calls each contract.
• msg.sender must be 0x629b1048298ae9deff0f4100a31967fb3f98962 (attacker address)
• Returns the returndata if the call results in any data.

At 0x28fb8778c3c1131026b4ee3b8634106a5c1aeaaf57273cc4515c59e65dfa7eb5 tx, the attacker called 0xfebb4f76 function on 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5 & created a new contract 0xf0c0a1a19886791c2dd6af71307496b1e16aa232.

If you look at the code of 0xf0c0a1a19886791c2dd6af71307496b1e16aa232, it verifies that varg1 (the address array) is valid and does not exceed the maximum memory size.

It ensures the contract calling this function is msg.sender, i.e., the admin (address 0x579145d6d1f26a460d9bdd3040c37517dac379ac).

Calls the balanceOf function on the token contract (varg0) to check the token balance of each address in the array.

Calls allowance to verify the token allowance of each address in the array.

If an allowance exists, it attempts to transfer the tokens from the respective addresses to a specific address (0x911215cf312a64c128817af3c24b9fdf66b7ac95), a predefined destination.

Attacker’s addresses:

0x911215CF312a64C128817Af3c24B9fDF66B7Ac95 0x9c5939AAC4f65A0eA233E657507C7b54acDE2841 0x0629b1048298AE9deff0F4100A31967Fb3f98962 0x97a05beCc2e7891D07F382457Cd5d57FD242e4e8 0x8B75E47976C3C500D0148463931717001F620887 0xA0e768A68ba1BFffb9F4366dfC8D9195EE7217d1 0x579145D6d1F26a460d9BDD3040C37517dac379ac

Attacker’s contract: 0x921B00Fa38911337aeD702Fb4857877c1aca1141 0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5 0xf0c0a1a19886791c2dd6af71307496b1e16aa232

What Was the Root Cause of the Exploit?

Compromised Multisig Control:

The primary vulnerability was the attacker gaining control of enough multisig signers to carry out critical operations like transferring ownership. The multisig setup at Radiant required a minimum number of signers to authorize upgrades, and the attacker managed to seize just enough of these to pass their malicious upgrade.

Inadequate Multisig Security:

While multisig setups are typically seen as more secure than single-signature wallets, this exploit shows that they’re not foolproof. Multisig requires that multiple signers authorize a transaction, but the minimum threshold of 3 out of 11 allowed the attacker to successfully carry out the exploit.

What Were the Immediate Steps Taken Post-Hack?

Radiant Capital and the broader DeFi community acted swiftly in response to the exploit:

Revoke Access: The first move was to revoke access to the compromised contracts on both Arbitrum and BSC to prevent further draining of funds.

Community Alerts: Radiant issued a public alert advising users to revoke approvals for the following contract addresses:

0xF4B1486DD74D07706052A33d31d7c0AAFD0659E1 (Arbitrum) 0xd50Cf00b6e600Dd036Ba8eF475677d816d6c4281 (BSC) 0x30798cFe2CCa822321ceed7e6085e633aAbC492F (Base) 0xA950974f64aA33f27F6C5e017eEE93BF7588ED07 (ETH) Investigation: Our investigation into how the attacker gained control of the multisig was launched, with possible leads suggesting a frontend attack & private key compromise.

How Could This Have Been Mitigated?

Stronger Multisig Requirements:

Radiant’s requirement for only 3 out of 11 signers was too low, considering the critical nature of these decisions. A higher threshold — say, 5 or 7 signers — would have made it more difficult for the attacker to gain enough control.

Enhanced Multisig Signer Security:

Multisig signers should have stricter security protocols in place. This could include hardware wallets, multisig signers spread across diverse geographic locations, and routine key rotations.

Decentralized Governance for Upgrades:

Instead of relying solely on multisig for contract upgrades, protocols should consider a time-locked decentralized governance process. This would allow the community to vote on upgrades and pause any suspicious activity before it’s executed.

Multisig Wallet Audit:

To further bolster security, teams can consider getting their multisig wallets and security processes audited by firms like QuillAudits, which specialize in identifying and mitigating such vulnerabilities before they become exploitable.