Radiant Capital cross-chain lending compromise — Arbitrum / BNB Chain — 2024-10-16

Summary

Radiant Capital is a cross-chain DeFi lending protocol operating on Arbitrum and BNB Chain. On October 16, 2024, attackers drained approximately $50M from Radiant's lending markets via a routine multisig signing operation that, at the on-chain layer, executed a transfer-of-ownership call against Radiant's lending-pool contracts rather than the routine parameter update Radiant's signers believed they were authorising.

Per Radiant's own post-mortem (2024-12-06) and the Mandiant-led on-device forensic investigation, the entry vector was a software supply-chain compromise of multiple Radiant developer workstations. On 2024-09-11 a Radiant developer received a Telegram message from what appeared to be a trusted former contractor; the message delivered a ZIP file (Penpie_Hacking_Analysis_Report.zip) that, on execution, displayed a legitimate-looking decoy PDF while installing INLETDRIFT — a persistent macOS backdoor. The malware spread laterally to additional Radiant developer machines over the following weeks. By 2024-10-16 the attackers had implanted a man-in-the-middle layer on the compromised devices that modified the transaction payload between the signer's wallet UI and the broadcast channel: signers approved transactions whose Tenderly simulations and wallet-UI displays showed the expected routine operations, while the on-chain transactions actually broadcast executed a transferOwnership() call seizing control of Radiant's lending-pool contracts. Roughly three minutes after extraction the attackers tore down the second-stage backdoor and associated browser extensions; approximately $52M was moved on 2024-10-24 in the first major laundering hop.

For OAK's purposes the entry vector is off-chain: a software supply-chain compromise of personnel laptops via a malware-laden recruitment-style Telegram message. OAK v0.1 does not have an on-chain Tactic that captures this entry vector — it is documented here, in the worked example, because the attribution is on the public record, the on-chain manifestation (the surreptitious transferOwnership() call) is unambiguous, and the structural lesson (the developer laptop is a supply-chain surface in its own right, not merely an extension of the vendor perimeter) is operationally distinct from the Ginco / Liminal / Safe{Wallet} vendor-side cases.

Timeline (UTC)

When	Event	OAK ref
2024-09-11	Radiant developer receives Telegram message from impersonated former contractor; ZIP delivered (Penpie_Hacking_Analysis_Report.zip) containing INLETDRIFT macOS backdoor + decoy PDF	(off-chain entry vector — out of OAK on-chain scope)
2024-09-11 to 2024-10-16	INLETDRIFT establishes persistence; lateral movement to additional Radiant developer machines; second-stage payload installs MITM layer between wallet UI and signing pipeline	(off-chain)
2024-10-16	Routine Radiant multisig signing session: signers approve what wallet UIs and Tenderly simulations show as benign parameter updates	(off-chain — manipulated at signing time)
2024-10-16	On-chain transactions settle: transferOwnership() calls executed against Radiant lending-pool contracts on Arbitrum and BNB Chain; attackers seize pool-controller authority	T11.001-equivalent (developer-laptop-mediated signing redirection)
2024-10-16	Attacker-controlled pool authority drains lending markets (~$50M across Arbitrum + BNB Chain)	T5-equivalent (extraction event)
2024-10-16 (T+~3 min)	Attackers tear down second-stage backdoor and browser extensions on compromised Radiant devices	(anti-forensics)
2024-10-16 onward	Radiant pauses lending markets; engages SEAL 911, ZeroShadow, Hypernative, and Mandiant for incident response	(response)
2024-10-24	~$52M moved across attacker addresses in first major laundering hop	T7.003 (cross-chain laundering, OAK-G01 pattern)
2024-12-06	Radiant publishes incident update naming Mandiant's high-confidence DPRK attribution (UNC4736 / AppleJeus / Citrine Sleet)	G01 attribution

What defenders observed

• Pre-event: Radiant operated a multisig signing process aligned with industry SOPs — Tenderly simulation of transactions, payload-data verification, hardware wallets in the signing chain. The post-mortem is explicit that the signers followed standard procedure and that the breach succeeded in spite of those procedures, not because they were skipped. The defensive surface that failed was upstream of the wallet UI: the developer workstation itself.
• At-event (off-chain): the load-bearing step was the MITM modification of the transaction payload after the signer's review and before the broadcast. Both the wallet UI and the Tenderly simulation showed the benign operation; the transaction that hit the RPC endpoint was the malicious transferOwnership(). This is a distinct sub-vector from the Bybit / Safe{Wallet} pattern (where the malicious JS was inside the third-party signing platform's web UI) and from the DMM / Ginco pattern (where the vendor's internal communications were compromised). At Radiant, the perimeter that mattered was the developer's own laptop — neither a vendor's web UI nor a vendor's internal infrastructure.
• At-event (on-chain): the extraction was visible immediately as a transferOwnership() call on the lending-pool contracts followed by drain transactions. On-chain monitoring at Hypernative and other providers fired within blocks; by then the ownership transfer was final and the pool authority was attacker-controlled.
• Post-event: the attackers' three-minute teardown of second-stage tooling materially complicated forensic reconstruction. Mandiant's on-device forensic engagement was the load-bearing step in establishing the MITM-on-laptop mechanism; without it, the case would likely have been read publicly as a generic "multisig compromise" rather than a developer-workstation supply-chain compromise. Direct on-chain recovery has been minimal; Radiant has worked through token-issuer freezes and forensic tracking against the OAK-G01 cluster watchlists.
• Attribution timeline: roughly seven weeks from event to public attribution (2024-10-16 to 2024-12-06). The Mandiant-led on-device forensic engagement is the reason the attribution is confirmed rather than inferred-strong — without the laptop-level evidence the public case for DPRK attribution would have rested on the wallet-cluster forensics alone.

What this example tells contributors writing future Technique pages

• The developer laptop is a supply-chain surface in its own right. The Radiant case is the canonical OAK example of T11.001 in the developer-laptop sub-vector. Defenders evaluating multisig custody risk in 2024 generally enumerated "third-party signing platform" (Bybit / Safe{Wallet} pattern) and "third-party wallet-software vendor" (DMM / Ginco; WazirX / Liminal patterns) but rarely enumerated "our own developers' laptops." Radiant closes that gap.
• Tenderly simulation + hardware-wallet signing is necessary but not sufficient against a MITM on the signing host. If the host displaying the simulation is the same host whose RPC connection is compromised, the simulation gives no independent assurance. The OAK lesson is operational: for high-value multisig signing, the verification surface must be air-gapped from the broadcast surface — independent confirmation of the broadcast transaction (e.g., reading the destination and call-data from a hardware wallet's own display, on a device not in the day-to-day developer environment) is the mitigation path. This is the same lesson as Bybit, restated for the developer-laptop sub-vector.
• The Telegram-delivered recruitment-pretext payload is the same playbook as the LinkedIn variant. The Ronin (2022) and DMM Bitcoin (2024) cases delivered the malicious "coding test" via LinkedIn; Radiant's 2024 variant delivered an "audit report" via Telegram. The channel rotates; the social-engineering shape is constant. Contributors writing future OAK-G01 examples should not treat the delivery channel as load-bearing.
• Anti-forensic teardown matters for attribution standard. Radiant's three-minute teardown of second-stage tooling is the reason the case required Mandiant on-device forensics rather than operator-side log review to establish the MITM mechanism. Contributors writing examples for similar 2024-2026 incidents should expect attacker anti-forensics to determine whether attribution lands at confirmed or inferred-strong.

Public references

• Radiant Capital — Incident Update (2024-12-06) — primary post-mortem; describes the Telegram-delivered INLETDRIFT payload, multi-developer compromise, MITM modification of signed transactions, and Mandiant on-device forensic engagement. [radiantpostmortem2024]
• Mandiant attribution — UNC4736 / AppleJeus / Citrine Sleet, DPRK-nexus (referenced in the Radiant post-mortem) — high-confidence DPRK attribution; cluster aligned with DPRK Reconnaissance General Bureau and TEMP.Hermit. [mandiantradiant2024]
• CoinDesk — Radiant Capital Says North Korean Hackers Behind $50 Million Hack in October — secondary confirmation of attribution. [chainalysisradiant2024]
• SecurityWeek — $50 Million Radiant Capital Heist Blamed on North Korean Hackers — independent press confirmation.
• BleepingComputer — Radiant links $50 million crypto heist to North Korean hackers — INLETDRIFT malware-family detail. [microsoftcitrineradiant2024] (for the Citrine Sleet / AppleJeus naming context)
• Decrypt — Radiant Capital Says DPRK Actor Posed as Ex-Contractor to Pull Off $50 Million Hack — pretext-shape detail (former-contractor impersonation).
• [chainalysis2024dprk] for category context and cumulative DPRK figures.

Discussion

Radiant Capital is the third confirmed multi-tens-of-millions OAK-G01 supply-chain attack of 2024 and the connective case that makes the 2024-2025 wave legible as a single pattern rather than four discrete incidents:

1. DMM Bitcoin (May 2024) — vendor-side wallet-software-supply-chain sub-vector. Ginco employee's personal GitHub compromised via LinkedIn-delivered "coding test"; vendor's internal communications used to manipulate a legitimate DMM transaction request. ~$305M.
2. WazirX (July 2024) — third-party-custody-vendor sub-vector chained to T11.003 contract modification. Liminal Custody surface compromised; in-use multisig contract modified to remove signer threshold; ~$234.9M drained.
3. Radiant Capital (October 2024) — developer-laptop sub-vector. INLETDRIFT macOS backdoor delivered via Telegram impersonation of a former contractor; MITM layer on developer machines modified signed transactions between wallet UI and broadcast; ~$50M drained via transferOwnership() on lending-pool contracts.
4. Bybit (February 2025) — third-party-signing-platform sub-vector. Safe{Wallet} developer workstation compromised; malicious JS in the signing UI altered destination of cold-to-warm internal transfer at signing time; ~$1.46B drained.

The shape repeats across all four: an off-chain compromise upstream of the on-chain event modifies a transaction the legitimate signers believe they are authorising correctly. The sub-vector rotates — wallet-software vendor (DMM), custody vendor (WazirX), developer laptop (Radiant), signing-platform vendor (Bybit) — but the OAK-G01 cluster, the social-engineering-led delivery, and the single-transaction extraction shape are constant. The laundering rail is selected per-chain (BTC CoinJoin for DMM; cross-chain swap protocols for WazirX; cross-chain hops for Radiant; THORChain for Bybit) and is captured at OAK-T7.003 with operator continuity tracked at OAK-T8.001.

For OAK's broader credibility, including Radiant Capital in v0.1 closes the chronological gap between WazirX (July 2024) and Bybit (February 2025) and — more importantly — surfaces the developer-laptop sub-vector as a distinct T11.001 shape. A worked-example corpus that covered DMM, WazirX, and Bybit but not Radiant would read as if the supply-chain surface ended at the vendor perimeter; the Radiant case is the case that makes the developer laptop legible as part of that surface in its own right.