Curriculum·G206 Running a Security Review for a Small Team·about 31 min
The review a small team can actually run
By the end of this lesson you can
- →Distinguish a small team's realistic security review from a formal audit, and state what each can and cannot do
- →Explain how Radiant Capital lost about 50 million dollars with every recommended control in place
- →Compute why a control is only as good as the step that verifies it was actually followed
- →Assemble a repeatable review a small team can run over the risks it actually controls
Graduate · enrolled learners
This lesson opens with Radiant Capital, 16 October 2024.
- What happened
- Radiant Capital is a cross-chain lending protocol run by a small distributed team. On 16 October 2024 about 50 million dollars was taken, by Radiant's own count. At least three long-standing, trusted contributors, geographically distributed, each signing on a hardware wallet, approved what their Gnosis Safe front-end displayed as a routine transaction. Malware on their machines showed legitimate transaction data on screen while sending malicious transactions to the hardware wallets for signature, and the protocol's 3-of-11 multisig handed ownership of the lending pools to the attacker's contract. Mandiant attributed the operation with high confidence to a North Korea-nexus actor, UNC4736, which had begun in early September with a Telegram message impersonating a trusted former contractor. Every control a careful small team is told to use, hardware wallets, a multisig, geographic spread, was in place. The transactions were even simulated on Tenderly and reviewed, but the devices were blind signing, so no step verified what each device was actually being asked to sign.
- The decision point
- Radiant did not fail for lack of controls; it had the ones every checklist recommends. It failed because having a control and verifying the control was followed are different things, and its process checked the first and not the second. A hardware wallet protects a key only if the signer verifies, on the device, that the payload matches the intent, and Radiant's review had no such step. This is the lesson of the whole course: a small team cannot run a formal audit, and it can run a review, a short, repeatable check of the risks it controls, provided the review verifies that each control actually did its job rather than assuming it did. The value is not in listing controls a team already knows to want. It is in the step that catches the day a control was present and defeated.
- Recorded loss
- $50,000,000
What you will be able to answer
- →What controls did Radiant have when it was drained?
- →How was the Radiant multisig defeated?
- →What can a small team's security review realistically be?
- →Having a control versus verifying it?
Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.
It is free. We do not sell the list and there is nothing to buy at the end of it.
Sources and review
- https://rekt.news/radiant-capital-rekt2
- https://www.halborn.com/blog/post/explained-the-radiant-capital-hack-october-2024
- https://therecord.media/crypto-platform-radiant-capital-50-million-stolen
- https://decrypt.co/295545/radiant-capital-says-dprk-actor-posed-as-ex-contractor-to-pull-off-50-million-hack
- https://medium.com/@RadiantCapital/radiant-capital-incident-update-e56d8c23829e
Confidence high·Volatility medium·Reviewed 2026-09-14·Owner unassigned
Contested
Radiant put the loss at about 50 million dollars; Rekt and Halborn estimate over 53 million. The mechanism, malware showing legitimate data in the Safe front-end while malicious transactions went to the hardware wallets, is Radiant's account as reported by Halborn and The Record. Radiant said at least three devices were compromised and could not give the exact number. The Mandiant attribution to UNC4736 is quoted from Radiant's December update as reported by Decrypt; the Radiant Medium posts refuse automated reads and were not read directly.
This lesson uses Radiant for the distinction between having a control and verifying it; the exact malware and delivery details were still being analyzed after the incident and some specifics may be refined.