Open in app

Sign in

Write

Sign in

Radiant Capital Post-Mortem

Radiant Capital
10 min readOct 18, 2024

--

Events Summary

On October 16, 2024, Radiant Capital experienced a security breach resulting in the loss of approximately $50 million USD. The attack compromised three Radiant developers, all of whom are long-standing, trusted contributors to the DAO. These developers used hardware wallets and were geographically distributed, reducing the likelihood of a coordinated physical attack.

Attackers were able to compromise the devices of at least these three core contributors through a sophisticated malware injection. These compromised devices were then used to sign malicious transactions.

Although three compromised devices have been confirmed, it is likely that more were targeted — the means by which they were compromised remains unknown and under investigation. The devices were compromised in such a way that the front-end of Safe{Wallet} (f.k.a. Gnosis Safe) displayed legitimate transaction data while malicious transactions were signed and executed in the background. This breach occurred during a routine multi-signature emissions adjustment process, which takes place periodically to adapt to market conditions and utilization rates.

The DAO contributors adhered strictly to industry standard operating procedures (SOP) throughout the process. Each transaction was simulated for accuracy on Tenderly and individually reviewed by multiple developers at each signature stage. Front-end checks in both Tenderly and Safe showed no anomalies during these reviews.

To underscore the significance of this point, the compromise was completely undetectable during the manual review of the Gnosis Safe UI and Tenderly simulation stages of the routine transaction. This has been confirmed by external security teams, including SEAL911 and Hypernative.

Front-end verification of all three multi-signature transactions showed no signs of compromise, aside from Safe App transaction resubmissions due to failures. It is important to highlight that resubmitting Safe transactions due to failures is a common and expected occurrence. Transactions submitted on the Safe front-end can fail due to gas price fluctuations, nonce mismatch, network congestion, insufficient gas limit, smart contract execution errors, token insufficiency, pending transactions, front-end synchronization issues, timeouts, or permission/signature errors in multi-signature setups. As a result, this behavior did not raise immediate suspicion. The malicious actors exploited this normalcy, using the process to collect multiple compromised signatures over several attempts, all while mimicking the appearance of routine transaction failures.

The attackers subsequently drained approximately $50 million USD from the core markets on Arbitrum and BSC. Additionally, they exploited open approvals to withdraw funds from users’ accounts. All users of the Radiant platform were strongly advised to revoke any approvals on ALL chains — Arbitrum, BSC, Ethereum & Base.

The DAO has been working very closely with U.S. law enforcement and ZeroShadow and maintain an excellent relationship with both groups. They are fully informed of the breach and are actively working to freeze all stolen assets. The DAO is deeply devastated by this attack and will continue to remain available 24/7 to assist the respective agencies working to identify the exploiter and recover the stolen funds as quickly as possible.

Attack Vector and Methodology

The attackers’ objective was to obtain three multi-signature approvals from hardware wallets to authorize a transferOwnership action. They successfully compromised multiple developers’ devices — at least three, though the exact number remains undetermined. It is not yet known how the devices were compromised. The attack exploited a sophisticated method whereby developers using Safe{Wallet} for transaction verification were presented with legitimate-looking transactions on the front-end.

When they approved the transaction, the compromised devices intercepted the approval and instead relayed a malicious transaction to the hardware wallets for signature. Afterward, the Safe wallet interface would then display an error message, prompting the users to attempt the signature again. This process provided the attackers with three valid but malicious signatures.

Despite multiple layers of verification, including reviewing transactions via Tenderly and other auditing tools, the signed transactions appeared normal on the interface. The displayed blind-signing signatures on the Ledger hardware wallets also appeared valid, adding another layer of obfuscation to the attackers’ methodology. These tactics enabled the attackers to execute the transfer unnoticed.

Security Implications

The most concerning aspect of this attack is the high level of sophistication involved. The compromised devices presented no obvious warning signs beyond minor glitches and error messages during the signing process — issues commonly encountered when interacting with hardware wallets and Safe. These seemingly routine error messages were the only indicators of a deeper issue, which, under normal circumstances, would not have raised immediate concern.

Preventative Recommendations:

The groups working to assess the exploit believe this was one of the most sophisticated hacks ever recorded in DeFi and many protocols are at risk. To mitigate similar attacks in the future, the following strategies should be considered:

  1. Multi-Layer Signature Verification: Implement a governance layer where, if one or more signers encounter issues or anomalies, the process is halted for further verification before proceeding. This should trigger a review when even one signer experiences an error. An error can be as simple as a transaction that *should* have been accepted not going through, and then prompting for a new signature
  2. Independent Device for Verification: Utilize an uncompromised, independent device to verify transaction data before signing. This device should generate a readable signature verification code that matches the data presented to the hardware wallet.
  3. Enhanced Ledger/Trezor Security: Avoid using blind signing for critical transactions. If unavoidable, ensure that any contract interactions involving hardware wallets require a separate layer of visible verification, such as displaying transaction data in a readable format on the hardware wallet itself.
  4. Error-Triggered Auditing: Integrate a mechanism where recurring transaction errors or glitches automatically trigger a full audit of the transaction before additional signing attempts can be made.
  5. Manually review transaction payloads: Take raw transaction data out of your wallet provider when a signature is prompted (e.g., Metamask, Rabby) and plug it into https://etherscan.io/inputdatadecoder. Confirm that the function you are calling, and the ToAddress all match up with the intended behavior. If a device were to be compromised, like in the case above, it would either not decode at all, call a different function than the one you thought you were calling, or it would result in a different owner address than the one you intended. It is also highly recommended to double-confirm each message hash on HW wallets with Gnosis: https://help.safe.global/en/articles/40831-how-to-verify-safe-transactions-on-a-hardware-wallet

Post-Incident Conclusion

The attack compromised three Radiant developers, all of whom are long-standing, trusted contributors to the DAO. The attackers used malware to manipulate transaction data at the device level, bypassing manual checks and simulations in Tenderly, which returned normal results. The compromised devices allowed the attackers to gather multiple poisoned signatures through fraudulent transactions that appeared legitimate to the signers.

While hardware wallets are typically secure, the use of blind signing, especially in DeFi environments, creates significant risks. The attackers exploited this by presenting normal-looking transactions in Gnosis Safe, with no visible anomalies, aside from routine transaction failures — a common occurrence, making detection difficult.

As immediate preventative measures, each member of the safe has created fresh cold wallet addresses using new, uncompromised devices, ensuring no residual vulnerabilities remain. The DAO has significantly tightened security on the Admin & DAO multisigs (other safes to follow in due course) by reducing the number of signers to 7, with a new signing threshold of 4 out of 7, ensuring that nearly 60% of signers must approve a transaction before it can be executed.

In addition to this, contributors will now double-confirm transaction data for every transaction using the input data decoder on Etherscan, providing an additional layer of accuracy before transactions are signed.

It is expected that the DAO will be able to unpause Base & Eth markets within days.

The DAO will also be creating new Safes for the RIZ markets and transferring ownership of the RizRegistry contracts to these secure safes, to ensure separation from the core markets.

All contract upgrades and ownership transfers will also be subject to a minimum 72-hour delay through newly implemented timelock contracts. This delay will provide the community and developers sufficient time to review and verify changes before they take effect. However, this can also delay responses to critical vulnerabilities and it is not clear that timelocks would have prevented this attack given the devices of three signers were compromised.

Permissioned roles are being separated out in our key contracts to ensure no single role holds “super” powers. By distributing responsibilities across multiple roles, the DAO significantly reduces the risk of any one individual or group gaining excessive control.

Finally, to reinstate the core markets on Arbitrum and BSC, the DAO will be redeploying the entire Aave V2 Lending Suite, which is comprised of the following contracts:

  • LendingPoolAddressesProvider
  • LendingPoolAddressesProviderRegistry
  • LendingPool
  • LendingPoolConfigurator
  • LendingPoolCollateralManager
  • LendingRateOracle
  • AaveOracle
  • AaveProtocolDataProvider

Throughout this process, the DAO has been working very closely with the U.S. law enforcement and ZeroShadow and maintains an excellent relationship with both groups. They are fully informed of the breach and are actively working to freeze all assets whenever possible. The DAO is deeply devastated by this attack and will continue to remain available 24/7 to assist the respective agencies working to identify the exploiter and recover the stolen funds as quickly as possible.

Detailed Events Timeline

2024–10–02

  • 01:12:37 UTC

Arbitrum: A malicious contract was deployed via tx: https://arbiscan.io/tx/0x149bd3b684cf63decffbdd1865a20fddf131fb59469d093b2b6d9aa57a0ce4c2. This contract was to be used for malicious purposes a few days later.
Contract: https://arbiscan.io/address/0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5.

  • 08:22:46 UTC

BSC: A similar malicious contract was deployed on Binance Smart Chain via tx: https://bscscan.com/tx/0x65419cd822bb616f2d9dacbcfacf81714761f9815cc26b9451cd70f0348232fa.
Contract: https://bscscan.com/address/0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5

The same or similar malicious contracts were deployed on both Base and Ethereum Mainnet, but ultimately were not successfully executed:

2024–10–16

  • 15:46 UTC: Developer “C1” proposed a transaction with ARB Nonce 230 to update supply and borrow caps. During this process, the transaction signature failed at least three times, initially attributed to RPC issues.

To troubleshoot, C1 replaced the Arbitrum RPC using the first available option from chainlist.org, eventually succeeding in signing the transaction. Then, in line with SOP, this transaction was announced in the #admin channel of the “RADIANT — Multisig” group on Telegram. The following message was posted to the Telegram group:

This was the original Nonce 230 transaction that C1 had constructed:

However, ARB Nonce 230 was subsequently overridden at 17:09 UTC (see entry below) and replaced by a malicious transaction that called the transferOwnership function:

One odd point to note–as of publication, when viewing the URL linking to the canceled ARB Nonce 230, the timestamp in the UI appears to be the viewer’s current time. Hence the UI timestamp of “less than a minute ago” despite this not being chronologically accurate.

  • 17:04 UTC: Developer C2 proposed changes to Ethereum Mainnet via ETH Nonce 127, Arbitrum, and BSC Chain for updating the RDNT token distribution rate. However, Nonce 127 was replaced to transfer ownership and execute malicious code. C2 noted that his Rabby wallet experienced issues during this time.
  • 17:09:18 UTC: The aforementioned malicious transaction replaced ARB Nonce 230, transferring ownership of the LendingPoolAddressesProvider to the new owner. Transaction: https://arbiscan.io/tx/0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1.

Considering the potential threat of a “man-in-the-middle” style of attack, it was determined by the security team that any subsequent actions to remove compromised wallets must be done after a proper risk assessment.

Notes

  • Some developers reported issues signing transactions in Safe{Wallet} app. Dev C3 mentioned:
    “During the past weeks, I’ve had to sign transactions twice in Rabby. C2 also noted RPC problems. After the hack, my Rabby wallet stopped functioning and disappeared, similar to C2’s experience.”
  • C1 also reported having to re-sign transactions after initial failures.
  • Routine updates in the Radiant protocol require transactions from the Admin multisig, which holds the most critical permissions in the system.

Compromised wallets

  • 0x20340c2a71055FD2887D9A71054100FF7F425BE5 (Ledger hardware wallet managed via Rabby)
  • 0x83434627e72d977af18F8D2F26203895050eF9Ce (Ledger hardware wallet managed via Rabby)
  • 0xbB67c265e7197A7c3Cd458F8F7C1d79a2fb04d57 (Trezor hardware wallet managed via Frame)

Admin multisig wallets and signature threshold (at time of exploit)

  • Ethereum: 0x0235a22a38Dd09291800e097bD2ebE6e3b4d5F04 (3/9)
  • BSC Chain: 0xE4714D6BD9a6c0F6194C1aa8602850b0a1cE1416 (3/11)
  • Base: 0xBBf7eDF92926b775A434f9DF15860f4CD268B0A0 (3/9)
  • Arbitrum: 0x111CEEee040739fD91D29C34C33E6B3E112F2177 (3/11)

Known attackers wallets

  • 0x0629b1048298AE9deff0F4100A31967Fb3f98962 (Main attacker)
  • 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5 (Main attack contract)
  • 0x911215CF312a64C128817Af3c24B9fDF66B7Ac95 (Testing address)
  • 0x97a05becc2e7891d07f382457cd5d57fd242e4e8 (Laundering address)
  • 0x9c5939AAC4f65A0eA233E657507C7b54acDE2841 (Laundering address)
  • 0x8B75E47976C3C500D0148463931717001F620887 (Funds consolidated on Arb + Eth)
  • 0xcF47c058CC4818CE90f9315B478EB2f2d588Cc78 (Funds consolidated on BSC)
  • 0xa0e768a68ba1bfffb9f4366dfc8d9195ee7217d1 (GMX interactions / swaps)
  • 0xc24927Bd40Bab67CcfB2ca0A90d6cbB8Edb21302 (Approvals drainer on Arbitrum)
  • 0x579145D6d1F26a460d9BDD3040C37517dac379ac (Approvals drainer on BSC)
  • 0xC4173a794122644870C8fd07c226acF992507897 (Approvals drainer on BSC + ARB)
  • 0x3D4C56cdB97355807157F5C7d4F54957f0E9af44 (Contract created on 17th October)
  • 0x3c09Ae8571db07a3347c1D577BB9a54F96bFfa24 (Contract created on 17th October)
  • 0xbc20e84d80a684dAEa4468be6F199a233A3d2363 (Test contract)
  • 0x5eb63694A18B618C4EbDd9CA3333fa7f9b8B9cB4 (Related to test contract)
  • 0xD899F3d8ff2A723642d5C55eD1998713C530b7b3 (Related to test contract)

--

--

Radiant Capital
Radiant Capital

Written by Radiant Capital

692 Followers
1 Following

Radiant is building the first omnichain money market atop LayerZero. Deposit & borrow across multiple chains, seamlessly. https://twitter.com/RDNTCapital

Responses (8)

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams