Cowrie Research

radiant-capital-admin-multisig-compromise-malicious-ownership-transfer-upgrade-drain-2024-10-16

15 min read

Radiant Capital Admin Multisig Compromise / Malicious Ownership-Transfer Upgrade Drain (2024-10-16)

  • Name: Radiant Capital admin multisig compromise / malicious ownership-transfer upgrade drain
  • Date: 2024-10-16
  • Protocol: Radiant Capital
  • Chain: Arbitrum + BNB Smart Chain, with staging on Base + Ethereum
  • Category: signer-quorum compromise / privileged upgrade abuse / admin multisig compromise / malicious ownership transfer
  • Loss: approximately 53M across Radiant core markets on Arbitrum and BNB Smart Chain, plus additional user-wallet losses from approval-drainer follow-on theft
  • Summary: On 2024-10-16, attackers used malware-compromised developer devices to capture three valid signatures from Radiant’s admin Safes while the signers believed they were approving ordinary emissions and cap-management transactions. Radiant later said the intrusion began with a Telegram message from a trusted former contractor persona carrying Penpie_Hacking_Analysis_Report.zip, which installed the INLETDRIFT macOS backdoor while showing a decoy PDF. The Safe UI and Tenderly simulations still showed benign payloads, but the compromised devices relayed different calldata for signing under blind-signing flows and repeatedly surfaced the sort of Safe resubmission failures contributors were used to seeing. Onchain, the decisive action was not a lending-market arithmetic bug: attacker-controlled transactions replaced the intended Safe nonces with transferOwnership calls that handed LendingPoolAddressesProvider control to attacker contract 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5. From there the attacker upgraded or redirected the Aave-v2-style Radiant suite on Arbitrum and BSC, drained core market liquidity, and then used separate drainer contracts to steal from wallets that still had open approvals. The real invariant failure was that three poisoned admin signatures were enough to redefine what the protocol considered authoritative ownership of its core lending stack.
  • Trigger / entry point:
    • On 2024-09-11, a Radiant developer received a Telegram message apparently sent by a trusted former contractor, asking for feedback on a zipped PDF about a new smart-contract-auditing role.
    • The ZIP, Penpie_Hacking_Analysis_Report.zip, carried the INLETDRIFT macOS malware payload while showing a legitimate-looking decoy PDF to the user.
    • Radiant’s 2024-12-06 incident update says the malware used AppleScript inside Penpie_Hacking_Analysis_Report.app, presented itself as com.atokyo.News, called out to atokyonews[.]com/CloudCheck.php, and established persistence through LaunchDaemons/com.apple.systemextensions.cache.plist.
    • Mandiant attributed the intrusion with high confidence to UNC4736 / AppleJeus / Citrine Sleet, a DPRK-nexus threat actor cluster.
    • In the weeks before the theft, the attacker staged malicious owner contracts on Arbitrum, BSC, Base, and Ethereum at the shared address 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5.
    • The attack was finally cashed out when Radiant contributors performed routine admin Safe operations for emissions and risk-parameter updates and three compromised signer devices produced signatures for hostile transactions instead of the payloads shown in Safe and Tenderly.
  • Root cause:
    • Radiant’s core lending suite inherited an Aave-v2-style privileged control surface in LendingPoolAddressesProvider, so whoever owned that contract effectively controlled the live market stack.
    • Admin Safe thresholds of 3-of-11 on Arbitrum and BSC meant three poisoned signatures were enough to transfer that ownership and then retarget or upgrade the system.
    • The operational trust model assumed that hardware wallets, Safe UI review, and Tenderly simulation would reveal malicious admin actions. The attack broke that assumption by altering what the compromised endpoints actually sent for signing while continuing to display benign transactions.
    • Blind-signing and endpoint-level compromise turned a nominally distributed signer set into a smaller practical compromise domain: once enough signer devices were subverted, the protocol’s real authority boundary belonged to the attacker.
    • Because the admin multisig controlled top-level ownership rather than a narrowly scoped maintenance role, quorum capture immediately became upgrade authority and then direct custody risk.
  • Exploit path:
    1. The attacker socially engineered Radiant contributors into opening a trojanized ZIP that installed INLETDRIFT on multiple macOS devices while displaying a harmless-looking PDF.
    2. Between 2024-10-02 and 2024-10-16, the attacker predeployed malicious contracts, including owner contract 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5, on the chains where Radiant admin multisigs operated.
    3. On 2024-10-16, Radiant signers initiated normal admin Safe actions to update supply caps, borrow caps, and RDNT emissions. Multiple signers observed failed signatures, Rabby glitches, and Safe resubmission behavior, but those symptoms resembled ordinary Safe / RPC friction.
    4. Instead of signing the displayed admin-maintenance payloads, at least three compromised endpoints relayed malicious transactions for hardware-wallet signature collection.
    5. At 17:09:18 UTC on Arbitrum, the attacker replaced intended Safe nonce 230 with transaction 0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1, transferring LendingPoolAddressesProvider ownership to the attacker-controlled contract.
    6. At 17:11:00 UTC on BSC, transaction 0xd97b93f633aee356d992b49193e60a571b8c466bf46aaf072368f975dc11841c transferred BSC LendingPoolAddressesProvider ownership to the same attacker contract and upgraded implementation control despite the protocol already trying to pause.
    7. With ownership of the addresses provider captured, the attacker controlled the Aave-v2-style suite beneath it — including the LendingPool, LendingPoolConfigurator, LendingPoolCollateralManager, LendingRateOracle, AaveOracle, and related data-provider surfaces that Radiant later said it had to redeploy completely.
    8. The attacker drained core-market liquidity on Arbitrum and BSC, then pivoted to user-wallet theft through approval-drainer contracts such as 0xc24927bd40bab67ccfb2ca0a90d6cbb8edb21302, 0x579145d6d1f26a460d9bdd3040c37517dac379ac, and 0xc4173a794122644870c8fd07c226acf992507897.
    9. Radiant paused unaffected Base and Ethereum markets before the prepositioned malicious contracts there could be used successfully, then began removing compromised signer wallets from the remaining Safes later that day.
  • What the attacker needed to be true:
    • Radiant admin Safes had to retain live ownership over the core lending-suite control plane rather than only over slow, heavily delayed governance actions.
    • Three compromised signer devices had to be enough to satisfy the effective threshold on Arbitrum and BSC.
    • Signers had to rely on Safe/Tenderly front-end verification plus blind-signing flows that could be spoofed by endpoint malware.
    • Routine Safe friction — failed signatures, wallet glitches, RPC issues, retried submissions — had to be common enough that the malicious signature collection would not immediately halt the process.
    • User funds and approval allowances had to remain accessible once the attacker captured admin authority and later deployed drainer contracts.
  • Technical anatomy worth remembering:
    • Radiant is a useful non-bridge signer-quorum case because the core exploit primitive was still enough valid signatures = protocol truth; the only difference is that the signatures controlled upgrade and ownership authority over a lending stack rather than a bridge vault.
    • The memorable onchain step is transferOwnership on LendingPoolAddressesProvider, not some obscure money-market math path. In Aave-v2-derived systems, whoever owns the provider can retarget the entire suite beneath it.
    • This makes Radiant simultaneously a signer-quorum-compromise incident and a privileged-upgrade-abuse incident. The attacker did not need a user-callable vulnerability once admin ownership had been captured.
    • The attack also preserves a wallet-security lesson that many bridge and multisig incidents do not: hardware wallet + Tenderly simulation + Safe UI review is not enough if the signing endpoint can change the calldata before blind signing while leaving the review surface looking normal.
    • The attacker’s chain-by-chain staging matters. Deploying the same malicious owner contract on Arbitrum, BSC, Base, and Ethereum ahead of time reduced the exploit day to a quorum-capture and execution problem rather than an improvisational one.
    • Radiant’s later Mandiant-backed update preserved unusually concrete operator-compromise artifacts for a DeFi postmortem: the lure archive was Penpie_Hacking_Analysis_Report.zip, the second-stage backdoor used atokyonews[.]com, and the malware reportedly removed traces of its second-stage backdoor and related browser extensions within minutes of the theft.
  • Representative transactions and addresses:
    • Malicious owner / attack contract: 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5
    • Main attacker address cited by Radiant: 0x0629b1048298ae9deff0f4100a31967fb3f98962
    • Arbitrum malicious-contract deployment tx: 0x149bd3b684cf63decffbdd1865a20fddf131fb59469d093b2b6d9aa57a0ce4c2
    • BSC malicious-contract deployment tx: 0x65419cd822bb616f2d9dacbcfacf81714761f9815cc26b9451cd70f0348232fa
    • Arbitrum ownership-transfer tx replacing intended Safe nonce 230: 0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1
    • BSC ownership-transfer / upgrade tx: 0xd97b93f633aee356d992b49193e60a571b8c466bf46aaf072368f975dc11841c
    • Mainnet automated pause tx: 0xa5dc1b97d72d11940d186596cb7478dedc27c8812c9d3bdf78eba5e8cf4f1006
    • BSC automated pause tx: 0x873c2382689cad921427e30f16a814ffb2c1e2550e316e767e66759f7abf4a34
    • Base pause tx: 0xdeee13d47eca82c8a774ec792f823360013f001e93b5abc17cb939f25187d00e
    • Compromised signer wallets published by Radiant:
      • 0x20340c2a71055fd2887d9a71054100ff7f425be5
      • 0x83434627e72d977af18f8d2f26203895050ef9ce
      • 0xbb67c265e7197a7c3cd458f8f7c1d79a2fb04d57
    • Admin Safe thresholds at exploit time published by Radiant:
      • Ethereum: 0x0235a22a38dd09291800e097bd2ebe6e3b4d5f04 (3-of-9)
      • BSC: 0xe4714d6bd9a6c0f6194c1aa8602850b0a1ce1416 (3-of-11)
      • Base: 0xbbf7edf92926b775a434f9df15860f4cd268b0a0 (3-of-9)
      • Arbitrum: 0x111ceeee040739fd91d29c34c33e6b3e112f2177 (3-of-11)
  • Response / mitigation:
    • Radiant paused markets, warned users to revoke approvals on Arbitrum, BSC, Ethereum, and Base, and coordinated with SEAL 911, Hypernative, ZeroShadow, law enforcement, and later Mandiant.
    • The team removed compromised wallets from Safe membership later on 2024-10-16 across Mainnet, Base, and BSC.
    • Radiant said it would redeploy the entire Aave-v2 lending suite for the affected core markets rather than attempt to trust the existing ownership path again.
    • Post-incident, the DAO reduced the admin Safe set to 4-of-7, moved signers onto fresh devices, added a 72-hour delay for contract upgrades and ownership transfers, and split out permissioned roles so fewer actions sat behind one super-admin boundary.
    • On 2024-12-06, Radiant published Mandiant findings tying the intrusion to the INLETDRIFT malware family and a DPRK-nexus threat actor, making the exploit one of the clearest DeFi examples of endpoint compromise defeating nominal multisig hygiene.

Pattern tags

  • signer-intent spoofing
  • Signer-quorum compromise
  • Privileged upgrade abuse
  • Routine-looking emissions and cap-management transactions were only the representation layer; the signed root-control action was transferOwnership over LendingPoolAddressesProvider
  • One captured admin quorum rewrote suite-level authority across several chains because the same root-control pattern still sat above the live Aave-v2-derived lending stack
  • Endpoint compromise plus familiar Safe retry / signature-friction noise let hostile calldata collection hide inside an otherwise ordinary multisig maintenance ceremony

Why the exploit worked

  • Radiant’s signing ceremony failed to preserve one machine-checkable object across displayed emissions/cap-management action → signed Safe hash → executed admin payload. The compromised endpoints kept the review surfaces looking routine while the actual transactions sent for signature performed transferOwnership against LendingPoolAddressesProvider.
  • The admin Safes did not just own a narrow maintenance lane. In an Aave-v2-style stack, ownership of LendingPoolAddressesProvider is effectively suite-root authority, so three poisoned signatures were enough to retarget upgrade, oracle, configurator, and lending-pool control all at once.
  • Routine Safe friction helped the attacker. Repeated resubmissions, wallet glitches, and failed signatures were already familiar enough that the compromised-signature ceremony did not automatically stop when those symptoms appeared again under hostile control.
  • Radiant also left too much immediate power behind one successful signer-intent failure. There was no slower independent lane between three signatures collected and root ownership of the live lending stack changes now, so the malicious owner handoff became same-session custody authority.
  • The attacker staged the same malicious owner contract across Arbitrum, BSC, Base, and Ethereum before exploit day, which meant the live operation reduced to harvesting quorum over root-control envelopes that the signers believed were harmless admin maintenance.

Detection and audit pivots

  • Preserve and compare the exact Safe proposal payload, nonce, Tenderly simulation, browser-rendered summary, signer-device prompts, and executed calldata whenever a multisig incident involves we thought we were updating caps or we thought we were signing emissions. The central forensic question is whether every review surface still described one identical admin transaction.
  • Treat transferOwnership, proxy-admin changes, addresses-provider owner changes, configurator rewires, and unexpected implementation-control moves during routine parameter-maintenance windows as privileged-shape drift, not as ordinary admin noise.
  • Audit whether admin multisigs sit directly above live suite-root control or only above delayed, narrowly scoped governance lanes. If three or four signatures can instantly replace ownership of the contract that names the whole market stack, the real custody boundary is much closer than many teams think.
  • Escalate repeated Safe / wallet anomalies during privileged ceremonies — unexplained resubmissions, failed signatures, device-link glitches, simulator mismatches, or wallet reconnect oddities — as possible signer-intent incidents rather than only as operational friction.
  • Inventory prepositioned same-address malicious deployments across every chain where an admin Safe operates. Radiant is a reminder that cross-chain staging can reveal that the attacker is targeting one reusable root-control pattern rather than one chain-local bug.

Failure-prevention checklist

  • Split routine parameter-maintenance authority from root-control envelopes such as transferOwnership on LendingPoolAddressesProvider, proxy-admin changes, implementation rewires, and oracle/configurator replacement. A cap-update ceremony should not also be able to rewrite the suite that defines market truth.
  • Require an independent, machine-checkable comparison across displayed Safe proposal, Safe hash, raw calldata, target address, and final executed transaction before any privileged signature counts. If one signer sees retries, hash drift, or device-prompt mismatch, abort the whole ceremony rather than collecting replacement signatures until threshold is reached.
  • Treat repeated signing glitches during privileged flows as compromise indicators, not as background UX noise. Radiant’s own postmortem is unusually explicit that attackers hid inside the team’s familiarity with Safe resubmissions.
  • Add stronger ceremony escalation for root-control actions: slower execution, higher quorum, fresh out-of-band review, and explicit classification that addresses-provider ownership move is not operationally equivalent to emissions adjustment.
  • Keep signer workstations, browser/runtime artifacts, and wallet-side review tools inside the custody boundary. Fresh devices, signer-facing artifact attestation, and rollback proof matter because hardware wallet + Safe + Tenderly only helps if every layer is still rendering the same bytes.
  • Minimize post-quorum blast radius: restrict open approvals where possible, pre-stage emergency pause authority on unaffected chains, and design root-admin capture so it cannot immediately become both protocol-upgrade control and downstream wallet-drainer opportunity.
  • Treat retried or partially collected root-action signatures as dormant authority after any signer-intent anomaly. A Safe ceremony that produced unexplained resubmissions should not leave pending privileged proposals or partially signed ownership-transfer objects live by default.

Audit prompts

  • Can a signer cohort performing routine emissions, cap, or risk-parameter maintenance accidentally authorize root-control moves like transferOwnership or proxy rewires through the same signing lane, or is there a hard protocol-level split between maintenance and future-authority mutation?
  • What exact object does each review surface authenticate: the Safe UI summary, Tenderly simulation input, wallet prompt, Safe hash, raw calldata, or executed transaction? Where could a compromised endpoint still show one object while signing another?
  • Which contracts are the real suite-root authority on each deployment? In Aave-v2-derived stacks, can ownership of LendingPoolAddressesProvider still rewrite lending, oracle, configurator, and collateral-manager truth in one step?
  • What is the protocol’s policy when even one signer sees unexplained Safe retries, wallet disconnects, resubmission prompts, or signature failures during a privileged ceremony? Does the process fail closed, or does operational pressure encourage collecting more signatures until the transaction finally goes through?
  • After a suspicious admin-signing session is aborted, what exact control proves there is no still-executable queued proposal, partial signature set, or cached ownership-transfer payload waiting for a later broadcast window?
  • If one chain’s signer workflow or browser bundle is compromised, can responders quickly inventory prepositioned attacker contracts, pending proposals, same-address staging on sister chains, and still-live user approvals before the attacker pivots across the rest of the estate?

Lessons that should already be standard

  • Three valid signatures is not the same claim as three humans approved the same admin action.
  • Routine maintenance lanes must not quietly inherit future-authority mutation. If a flow is meant to tune caps or emissions, it should fail closed on ownership transfer, implementation rewiring, or equivalent root-control payloads.
  • Repeated signing friction during privileged operations is already a security signal. Attackers know teams normalize retries, wallet glitches, and resubmissions.
  • Clean source code, correct Tenderly simulations, and real hardware wallets do not preserve signer intent if the signer-facing runtime can still swap the bytes being signed.
  • Cross-chain staging is part of the exploit, not a postscript. When the same malicious root-control contract appears across several deployments before the attack, the defender should assume one reusable authority pattern is being hunted everywhere it exists.
  • Containment after signer-intent compromise is not only device rotation and pause authority. It also means proving that every suspicious proposal, retry artifact, or partially collected root-action approval has expired or been revoked.

Why this incident matters

  • It fills an important gap in the signer-quorum corpus because it is not a bridge. The same threshold-capture logic can drain a lending protocol when the signer set owns the upgrade and ownership path above pooled user funds.
  • It also sharpens the relationship between multisig compromise and upgrade abuse: many protocols treat these as separate risk buckets, but Radiant shows how stolen quorum usually cashes out through some deeper privileged control plane.
  • It is also a clean case for keeping several healthy-side questions separate: signer intent truth as a single security object explains why Safe UI review, Tenderly simulation, hardware-wallet confirmation, and collected signatures all needed to stay bound to one admin transaction; stored-privileged-approval expiry and revocation discipline explains why suspicious retried proposals and partially collected root-action signatures should not have remained live after the ceremony first looked wrong; execution-envelope identity pinning explains why transferOwnership over LendingPoolAddressesProvider should have been treated as a privileged root-control envelope rather than routine emissions maintenance; privileged-action lane separation and ceremony escalation explains why cap/emissions maintenance should not share a ceremony with future-authority mutation; and exact production artifact attestation and rollback discipline explains why signer-facing runtime integrity and rollback proof belonged inside the same custody object.
  • Finally, it preserves a hard operational lesson for DeFi teams: when hardware wallets rely on blind signing and the host endpoint is compromised, Safe simulations and friendly UIs can become theater while the attacker quietly collects real admin signatures.

Internal linkages

Control surface

Graph View

Backlinks