Radiant’s Automated Incident Response Was Not Ready for Access Control Attack

Was it possible to prevent an $18M loss on BNB Chain?

PART 1 – Root Cause and Arbitrum Attack

On October 16, 2024, Radiant Capital suffered a security breach resulting in a more than $50 million USD loss ($48M in the attack itself and $5-6M via infinite approvals).

The attackers infiltrated the devices of at least three developers through a sophisticated malware injection, despite the developers using hardware wallets. The malware intercepted legitimate transaction approvals, displaying correct data in Safe Wallet, but executing malicious transactions in the background. The attackers exploited the normal transaction process, collecting multiple signatures over several attempts.

The exploit involved transferring ownership of Radiant’s LendingPoolAddressesProvider contract, which controls updates to the Lending Pool’s implementation. Attackers managed to get this malicious operation signed with malware injection.

The Arbitrum attack transaction occurred at 17:09:18 UTC. The exploit was executed atomically using a multicall-type transaction, allowing attackers to specify multiple target addresses and assign execution instructions to each. Among the instructions included in the multicall were:

1. Transfer ownership over LendingPoolAddressesProvider to malicious contract (0x57ba89).
2. Call LendingPoolAddressesProvider to upgrade implementation on LendingPool with malicious code.
3. Iterate over Radiant Markets contracts responsible for different assets (WBNB, WETH, etc.) to withdraw the underlying asset from the Market to a malicious EOA.

Radiant Market (aToken contract) is a copy of Aave Market, as Radiant is Aave’s V2 fork. Each aToken has a function transferUnderlyingTo(target,amount), which is responsible for transferring the underlying asset (from the Lending Market) to the target address. Due to Aave’s core logic, this function is supposed to be called only by LendingPool in the functions’ execution like borrow(), withdraw(), flashloan().

As attackers managed to upgrade the LendingPool implementation with the malicious one, the loop was executed through all the Markets, and all underlying assets from all the Markets were drained. 

PART 2 – Radiant’s Automated Incident Response

According to Radiant’s post-mortem, they had received the alerts of attack on Arbitrum and Radiant had the Automated Incident Response pre-configured, which is a crucial part of Web3 protocols security systems.

In their post-mortem, Radiant showed three alerts fired from their security partner Hypernative:

1. Ownership transfer over LendingPoolAddressesProvider.
2. LendingPool contract upgrade.
3. $32M in different assets drained from Radiant’s markets.

Radiant’s Automated Incident Response did not prevent the $18M loss from the BNB Chain. Why?

Radiant had Automated Incident Response pre-configured, and it was “pausing” the pool as an action for intervening in the ongoing exploit. As Radiant is a cross-chain protocol, it was crucial to detect the exploit on one chain in order to prevent it on the other chains. After the attack on Arbitrum, where all Markets were drained, Radiant’s security system paused the Lending Pool on BNB Chain and Ethereum with the following timeline: 

• 17:09:18 UTC – attack on Arbitrum (tx)
• 17:09:35 UTC – “pause” Lending Pool on Mainnet (tx)
• 17:09:40 UTC – “pause” Lending Pool on BNB Chain (tx)

But 80 seconds after “pausing” the Lending Pool on BNB Chain, the attack was nevertheless successfully executed (tx).

As was stated in PART 1, the second operation in the multicall transaction was upgrading the implementation of the Lending Pool with the malicious code. That operation is possible regardless of whether the current implementation of the Pool is “paused” or “unpaused”.

That’s the main reason why pausing the contract does not help with the Access Control exploits — you lose control of your protocol.

Another spot-on detail in Radiant’s Incident Response is the decision to pause the Lending Pool on the Ethereum Network before pausing it on the BNB Chain. Note that the BNB Chain held a significantly higher TVL ($18.3 million vs. $5.9 million on Ethereum).

PART 3 – How BNB Chain $18M Loss Was Possible to Prevent?

What should have been in place to stop the exploit and save $18 million on the BNB Chain? Monitoring of a MultiSig contract should have been set up to watch for Access Control attacks.

If an unexpected transaction to the MultiSig was detected, the signatures from that transaction should have been analyzed, the specific owners (EOAs who signed the transaction) identified, and those accounts should have been immediately removed from MultiSig management on BNB Chain and other chains.

This exact action was taken on the BNB Chain, Mainnet, and Base 4 hours and 27 minutes after the Arbitrum attack.

Unfortunately, Radiant’s Automated Incident Response was not prepared for a scenario of Access Control where MultiSig is compromised and a malicious transaction is executed. If the attack had been a smart contract exploitation instead of an Access Control attack, pausing the Lending Pool might have stopped the exploit, but that was not the case.

However, automatic protection against access control compromise is not impossible. With Extractor’s Wallet Actions, you can set up an automated removal of a compromised owner from the MultiSig as a part of your Automated Incident Response Strategy (AIRS). 

At Hacken, we’ve proven that nearly 30% of all Q3 DeFi losses could have been saved, even with a simplified AIRS. Learn more in our Q3 2024 Security Report or unlock the full power of AIRS with Hacken Extractor.