Trusted hardware and threat models

1. TL;DR

Secure hardware (trusted execution environments, or TEEs) lets a program run on data it never gets to see in the clear, and produce a cryptographic attestation that it ran correctly — Paradigm’s “5 Levels” framework argues the ecosystem already has the performance and developer experience to build most exciting applications, but has made “no security improvements” beyond trusting whichever manufacturer built the chip (Konstantopoulos, 2024-11-21). In practice, the threat that has cost the industry the most money isn’t a cryptographic break of any hardware at all: it’s North Korea’s Reconnaissance General Bureau-linked units (Lazarus Group, TraderTraitor, AppleJeus) and Munitions Industry Department-linked IT-worker operations (Contagious Interview, Wagemole), which have “no recorded or known incidents… deploying 0-days against the cryptocurrency industry” and instead win almost entirely through social engineering, supply-chain compromise, and infiltrating teams as employees (samczsun, 2025-03-31). A third, related boundary — who holds emergency or governance power over a protocol — rounds out this page, since attacks like Beanstalk’s flash-loan governance takeover and Drift’s 2026 social-engineered governance migration show that “who can legitimately change the rules” is as exploitable as any private key.

2. Explain it simply

Analogy

Picture a sealed vending machine built by a manufacturer you’ve never met: you can drop in a secret note and a set of instructions, the machine processes them internally without ever showing anyone the note, and it hands back a result stamped with a tamper-evident seal proving it followed your exact instructions. That’s secure hardware — powerful, but only as trustworthy as the company that built the sealed box, and only useful if nobody has quietly drilled a hole in the side. Compare that to a bank courier who is handed a sealed envelope to deliver, is shown a slip of paper that says “deliver $200 to branch A,” and dutifully signs for and delivers exactly what’s on the slip — except the slip was quietly swapped by someone at the front desk, and the courier, doing everything right, ends up delivering the entire vault’s contents to a stranger. Both stories are about trust boundaries: one is about trusting the box’s manufacturer, the other is about trusting that what you’re shown is what’s actually happening.

ELI5

Some computer chips are built so that a program can run secret information through them without anyone — even the person running the chip — being able to peek inside, and the chip proves it followed the instructions correctly. This is powerful, but you still have to trust whoever built the chip in the first place. Separately, a lot of the biggest thefts in crypto don’t come from breaking any chip or any code at all — they come from tricking a real person into signing something they didn’t mean to sign, or from a fake job applicant getting hired and then quietly stealing from the inside once they’re trusted.

Step-by-step walkthrough

Scenario: a company treasury is secured by a 3-of-5 multisig smart-contract wallet holding 10,000 ETH in cold storage, with a separate 50 ETH hot wallet for daily operations. Signers periodically approve routine transfers from cold to hot storage using a web interface that shows them the transaction details before they sign with their hardware wallets.

1. Before. Cold-storage multisig balance: 10,000 ETH. Hot wallet: 50 ETH. Five signers (Alice, Bob, Carol, Dave, Erin) hold hardware wallets; any 3 signatures execute a transaction.
2. A routine request arrives. Operations asks for the usual 200 ETH cold-to-hot rebalance, something that has happened dozens of times before without incident — this ordinariness is exactly what makes it a good moment to strike, since nobody expects anything unusual.
3. The front-end, not the keys, is compromised. An attacker has altered the code of the web interface signers use to review and sign transactions — not any signer’s private key or hardware device. When Alice, Bob, and Carol each open the interface, it displays “transfer 200 ETH to hot wallet 0xHOT…” — but the actual transaction payload being constructed transfers control of the entire multisig to an attacker-controlled address.
4. Signers sign exactly what they’re shown, correctly. Each hardware wallet does its job perfectly: it signs the payload it’s given and proves cryptographically that the legitimate key signed it. The problem is that the payload it was given does not match what was displayed on screen.
5. After. Once 3 valid signatures over the real (malicious) payload are collected, the transaction executes as constructed, not as displayed. Cold-storage multisig balance: 0 ETH. Hot wallet: unaffected, still 50 ETH. Every individual cryptographic check passed; the failure was entirely at the boundary between what a human was shown and what they actually authorized.

Common misconceptions

• Myth: A hardware wallet guarantees the transaction you approved is the transaction that executes. Reality: A hardware wallet only guarantees that whatever payload it was handed was signed by that specific key — if the software constructing the payload is compromised, the device faithfully signs something the user never intended (samczsun, 2025-03-31, describing both the WazirX and Bybit incidents).
• Myth: Secure hardware (TEEs) is already a solved, trustworthy foundation because Apple and the major clouds ship it widely. Reality: “There is no shortage of vulnerabilities against secure hardware, which have been repeatedly broken by researchers” (Konstantopoulos, 2024-11-21) — today’s widely-deployed level offers “no security improvements” over a much less capable baseline, only better performance and developer experience.
• Myth: “Lazarus Group” is one hacking team. Reality: It’s a media catch-all; DPRK cyber activity is organizationally split across several distinct units with different tactics — Lazarus Group, APT38, AppleJeus, DangerousPassword, and TraderTraitor under the Reconnaissance General Bureau, plus Contagious Interview and Wagemole under the Munitions Industry Department (samczsun, 2025-03-31).
• Myth: North Korea’s crypto hacks rely on advanced, novel exploits. Reality: “There have been no recorded or known incidents of North Korea deploying 0-days against the cryptocurrency industry” (samczsun, 2025-03-31) — their entire crypto-industry track record runs on social engineering and supply-chain compromise.
• Myth: A governance or admin key is a low-risk convenience feature as long as it’s held by “the team.” Reality: Beanstalk’s flash-loan governance attack ($77M, April 2022; see /governance/governance-and-tokenomics/) shows that voting power acquired and discarded within one transaction can be as dangerous as a stolen private key.

If you only remember one thing

The weakest link in a “secure” system is almost never the cryptography itself — it’s the boundary where a human has to trust what a screen tells them, or where one party holds unchecked power over the rules for too long.

3. How it works

The 5 Levels of Secure Hardware

Paradigm frames secure hardware as the practical path to “programmable cryptography” — computation over data that stays encrypted, with an attestation (typically signed by the hardware manufacturer) that the requested program actually ran (Konstantopoulos, 2024-11-21). The post explicitly weighs TEEs against the other major privacy-preserving techniques and finds each wanting for different reasons: “FHE does not address who holds the decryption key, MPC is based on non-collusion assumptions, ZK cannot handle share[d] state, and IO does not have a feasible construction yet” (Konstantopoulos, 2024-11-21) — the ZK limitation here is the same structural point argued independently in /privacy/privacy-and-compliance/. Three axes define progress: performance (overhead versus unprotected native execution), developer experience (can existing code run as-is, or must it be rewritten for the hardware’s constraints), and security model (what is actually being trusted, and against what threats).

Against those axes, Paradigm lays out five levels:

1. Level 1. Basic applications like oracles or bridges; poor developer experience but acceptable performance; security rests entirely on proprietary hardware supply chains.
2. Level 2. Slightly worse performance, better developer experience, enabling more expressive applications (e.g. social-account delegation); no security improvement over Level 1.
3. Level 3 — “we are here.” Great developer experience, near-native performance, GPU support; enables applications like private or verifiable ML inference; still no security improvement — the trust assumption is unchanged from Level 1, just more usable.
4. Level 4. Security actually improves via an open manufacturing process for the secure hardware itself, removing reliance on any single proprietary vendor, at unchanged performance and developer experience.
5. Level 5. Multiple, heterogeneous open secure-hardware implementations connected for redundancy, so no single vendor’s compromise breaks the system — described as the level needed for global-scale sensitive uses like voting or medical data.

The honest tension Paradigm names directly: improving developer experience tends to increase the trusted computing base (TCB — more code that must be trusted not to have bugs); open instruction sets can improve verifiability but reduce performance; and adding redundancy across heterogeneous hardware for Level 5 reduces performance further still. There is no level at which all three axes improve simultaneously.

Three distinct trust boundaries

Reading this page’s sources together, “threat model” for a crypto protocol or exchange decomposes into (at least) three structurally different boundaries, each attacked differently:

1. The hardware/cryptographic boundary — the secure-hardware stack in §3.1, attacked via side-channel or implementation vulnerabilities in the chip or its firmware.
2. The human/organizational boundary — the boundary this page’s North Korea material shows is, in practice, the one attackers overwhelmingly target: convincing or coercing a real person to run malware, sign something they don’t understand, or hire someone they shouldn’t.
3. The governance/admin-key boundary — who is legitimately empowered to change protocol parameters, pause the system, or move funds under emergency powers, and under what constraints that power can be exercised.

DPRK’s organizational structure and tactics

samczsun’s account of the Bybit investigation traces DPRK’s cyber apparatus through the state’s own command structure: the ruling Workers’ Party of Korea (WPK) sits atop all government institutions, including the Korean People’s Army (KPA) and the Central Committee. Within the KPA’s General Staff Department sits the Reconnaissance General Bureau (RGB), “responsible for almost all North Korean cyber warfare, including nearly all North Korean activity observed in the cryptocurrency industry” — spawning Lazarus Group, APT38, AppleJeus, DangerousPassword, and TraderTraitor. Separately, under the Central Committee, the Munitions Industry Department (MID) — primarily responsible for North Korea’s nuclear missile program — is “the primary source of North Korean IT workers,” tracked as Contagious Interview and Wagemole (samczsun, 2025-03-31).

Each unit has a distinct signature. Lazarus Group (first identified by Novetta during the 2014 Sony Pictures hack) later executed the 2016 Bank of Bangladesh SWIFT heist, exploiting a time-zone gap — the Bangladesh central bank closes for the weekend on Thursday, the New York Fed on Friday, and the receiving Philippine bank (RCBC) was then closed for Chinese New Year — to buy time for fraudulent transfer requests targeting almost $1B to clear before detection. APT38 spun out around 2016 to focus specifically on financial crime. AppleJeus specializes in malware distributed through complex supply-chain compromises, from cryptocurrency-trading-software trojans to the 2023 3CX supply-chain attack (potentially affecting over 12 million VoIP users) and the malware delivered to Radiant Capital in October 2024 via a Telegram contact impersonating a trusted contractor. DangerousPassword runs lower-sophistication phishing campaigns, from 2019-era emails to more recent Telegram lures — including one impersonating a security researcher and distributing a file named “Penpie_Hacking_Analysis_Report.zip,” also targeting Radiant Capital. Contagious Interview poses as recruiters, luring developers into a fake interview process that ends with a “coding challenge” repository containing a backdoor. Wagemole operatives instead try to get hired themselves, embedding as ordinary (if unremarkable) engineers inside real companies — sometimes for up to a year — before leveraging that access offensively, as in the Munchables incident (see /security/bug-classes/). TraderTraitor, the most sophisticated unit targeting the industry, “does not deploy 0-days against its targets, but rather employs highly sophisticated spearphishing” — reaching a senior Axie Infinity/Ronin engineer via a fake LinkedIn job offer, compromising WazirX’s signing pipeline and manufacturing a routine-looking cold-to-hot rebalance to disguise a malicious signature request, and ultimately compromising Safe{Wallet}‘s own infrastructure to deploy JavaScript targeting Bybit specifically during a similarly routine rebalance (samczsun, 2025-03-31).

4. Worked numeric example

Continuing the multisig scenario from §2 with concrete numbers, to make Paradigm’s “no single point of failure” recommendation quantitative rather than purely qualitative advice.

Assume ETH trades at $2,600 (illustrative) at the time of the attack, so the treasury’s 10,000 ETH is worth $10{,}000 \times \text{\textdollar}2{,}600 = \text{\textdollar}26{,}000{,}000$.

Single-Safe design (as in §2). One 3-of-5 multisig, one front-end interface, holds the full treasury. If the front-end is compromised, an attacker can construct one malicious payload that drains the entire balance once any 3 of the 5 signers approve it. Realized loss if the attack succeeds: $26,000,000 — 100% of the treasury.

Sharded design (the mitigation samczsun recommends: “ensure that no single point of failure exists such that a single compromise can cause total loss of funds,” 2025-03-31). Split the same $26,000,000 across five independent 3-of-5 multisigs of $5,200,000 each, each using a different signer set and, critically, a different front-end/tooling instance (different vendor, different deployment, or an independently-audited internal tool rather than a shared third-party interface). If an attacker compromises exactly one front-end instance — the realistic scope of the Bybit-style attack, which targeted one specific vendor’s infrastructure — only the multisig(s) using that compromised instance are at risk:

• Worst case (attacker’s compromised instance serves 1 of the 5 shards): realized loss = $5,200,000, or 20% of the treasury, an 80% reduction versus the single-Safe design.
• If the same compromised third-party vendor happens to serve all five shards (i.e., sharding signer sets without also diversifying tooling), the mitigation provides no protection at all — loss remains $26,000,000. The numeric benefit of sharding is entirely conditional on also diversifying the tooling/vendor a signer relies on to see what they’re signing, not just splitting funds across separate keys.

This makes explicit why samczsun’s advice is phrased as “no single point of failure” rather than simply “use a multisig”: Bybit already used a multisig (and a well-regarded one, Safe{Wallet}) — the single point of failure was the shared front-end infrastructure every signer trusted to display the truth.

5. Where it’s used

Ethereum

• Safe{Wallet} (formerly Gnosis Safe) — the dominant multisig standard for treasuries and protocol admin keys; the same infrastructure whose compromise enabled the Bybit and (per samczsun’s account) closely mirrored WazirX attacks (samczsun, 2025-03-31).
• TEE-based MEV and order-flow infrastructure — Intel SGX/TDX and similar secure-hardware deployments are used in encrypted-mempool and MEV-protection designs; covered in depth at /mev/encrypted-mempools/ rather than re-derived here.
• Timelock-gated governance (e.g. Compound-style timelocks) — a structural mitigation for the governance/admin-key boundary, forcing a delay between a proposal passing and its execution so that an attack requiring an atomic, single-transaction power grab (Beanstalk’s pattern) cannot succeed even if the vote itself is manipulated.
• Oasis Protocol — referenced in this cluster’s privacy research as an EVM-compatible chain pushing confidential smart contracts with TEE-backed data privacy built into the protocol layer (cited via /privacy/privacy-and-compliance/‘s sources; not independently verified against Oasis’s own documentation here).

Solana

• Squads and similar multisig infrastructure — Solana’s equivalent of Safe{Wallet} for treasury and program-upgrade-authority management; the same front-end-trust boundary described in §2 applies structurally regardless of chain.
• Program upgrade authority as the governance/admin-key boundary — Raydium’s December 2022 incident (a compromised private key controlling the AMM’s pool-owner authority, letting the attacker siphon inflated fees from 8 pools before the key was rotated to hardware, per contemporaneous incident tracking) is Solana’s direct parallel to Ethereum’s admin-key risk.
• Drift Protocol’s Security Council — a governance-security design that nonetheless was defeated in April 2026 when, per Chainalysis’s incident report, “weeks of social engineering got multisig Security Council members to pre-sign transactions via durable nonces, enabling a zero-timelock governance migration that whitelisted a fake token as collateral,” an incident investigators (TRM Labs, Elliptic) attributed to North Korea-linked actors — see §6.
• Arcium — referenced only secondhand in this cluster’s privacy research as a separate confidential-computation network taking an “orthogonal approach” to Solana privacy (cited in /privacy/privacy-and-compliance/; not independently verified against Arcium’s own documentation for this page).

6. Risks, attacks, and incidents

• Bybit, 21 February 2025 (Ethereum, Safe multisig), $1.46–1.5B. The largest crypto theft on record. samczsun’s own account: SEAL 911 first noticed “over 1B USD of tokens” leaving Bybit’s cold wallet into a brand-new address, followed by liquidation of “over 200M USD of LSTs.” The team initially assumed a compromised multisig signer or malware on a signer’s device — “this couldn’t have been further from the truth.” DPRK’s TraderTraitor unit had instead compromised Safe{Wallet}‘s own infrastructure and deployed a payload “specifically targeting Bybit,” activated when Bybit’s engineers went to perform a routine cold-to-hot rebalance (samczsun, 2025-03-31). FBI attributed the attack to TraderTraitor (Lazarus/APT38/BlueNoroff/Stardust Chollima).
• WazirX, 18 July 2024 (Ethereum, multisig custody), ~$235M. TraderTraitor compromised “an yet-to-be-identified component of the signing pipeline,” then manufactured the pretext for a signing event by artificially depleting WazirX’s hot wallet through repeated deposits and withdrawals, forcing a routine-looking cold-to-hot rebalance — during which engineers were “tricked into signing a transaction that transferred control of their cold wallet over to TraderTraitor” (samczsun, 2025-03-31). Elliptic attributed the attack to Lazarus Group.
• Axie Infinity / Ronin bridge, 23 March 2022 (Ethereum sidechain), ~$625M. TraderTraitor’s earliest widely documented crypto-industry technique in this page’s source: a fake LinkedIn job offer to a senior engineer, “through a series of interviews” ending in an “offer” document that delivered malware — see /cross-chain/bridge-designs/ for the bridge-trust-model analysis of the same incident.
• Radiant Capital, 16 October 2024 (Ethereum, multisig custody), $50–58M. Attributed by Mandiant to AppleJeus: malware delivered via Telegram from an attacker impersonating a trusted contractor; the same protocol was separately targeted by DangerousPassword’s phishing campaign using a file disguised as security research (samczsun, 2025-03-31).
• Munchables, 26 March 2024 (Blast L2), $62.5M (fully returned). A Wagemole-linked operative who had been legitimately hired onto the team “leveraged their privileged access to the smart contracts in order to steal all the assets” (samczsun, 2025-03-31) — no exploited code bug at all, purely the human/organizational boundary; see /security/bug-classes/.
• Drift Protocol, 1 April 2026 (Solana), $285M. Weeks of social engineering targeted the protocol’s own governance Security Council, obtaining pre-signed transactions via durable nonces that enabled a zero-timelock governance migration whitelisting a fake token as collateral — a governance-boundary attack investigators attributed to North Korea-linked actors, and Solana’s clearest parallel to Ethereum’s Beanstalk-style governance risk, but executed through social engineering of humans holding legitimate power rather than a flash loan.
• Beanstalk Farms, 17 April 2022 (Ethereum L1), $77M. A flash-loan governance attack rather than a DPRK-attributed incident, included here as the canonical example of the governance/admin-key boundary being exploited purely through protocol mechanics with no human deception required; full mechanism covered on /governance/governance-and-tokenomics/.
• Sony Pictures (2014) and WannaCry (2017). Not crypto incidents, but the formative Lazarus Group operations that established the group’s capability and intent before it turned to cryptocurrency: the Sony hack cost “at least 15MM USD in investigation and remediation” per contemporaneous reporting cited by samczsun, and WannaCry’s ransomware, built on a leaked NSA-developed Windows 0-day, caused billions in damages before a security researcher found and activated its kill switch within eight hours.

7. Open problems

• Can secure hardware reach Level 4–5 without giving up Level 3’s usability? Paradigm names the tension directly: better developer experience increases the trusted computing base, open instruction sets trade performance for verifiability, and cross-vendor redundancy for Level 5 reduces performance further — no source here claims a way to improve all three axes simultaneously (Konstantopoulos, 2024-11-21).
• Is “blind signing” a fixable problem or only patchable incident-by-incident? Bybit and WazirX share the same root cause — a front-end showing one thing while a different payload gets signed — despite being years and organizations apart; no source reviewed here describes a general, ecosystem-wide fix beyond individual organizations adopting “no single point of failure” practices.
• How do you defend against an adversary that doesn’t need 0-days? samczsun’s own framing implies most conventional technical hardening (patching, code audits) addresses a threat DPRK largely doesn’t use against the crypto industry — the actual gap his post identifies is organizational: least-privilege access, device hygiene, and verifying who you’re actually talking to.
• Can governance/emergency power ever be fully de-risked without also making it too slow to matter? Timelocks mitigate Beanstalk-style atomic attacks but did not stop Drift’s 2026 incident, where attackers instead spent weeks socially engineering the humans who held legitimate authority over the timelock/migration process itself — suggesting the tradeoff between speed and safety in governance design remains unresolved even with structural mitigations in place.

8. Ethereum vs Solana

Aspect	Ethereum	Solana
Dominant governance/admin-key incident	Beanstalk — flash-loan governance attack, $77M, purely mechanical	Drift Protocol — socially-engineered pre-signed governance transactions, $285M, human-boundary attack on a governance security council
Dominant multisig/signing-boundary incident	Bybit ($1.46–1.5B) and WazirX ($235M) — both via Safe{Wallet}-adjacent front-end/infrastructure compromise	Raydium ($2–4.4M) — direct private-key compromise of a pool-owner authority, smaller scale
DPRK attribution documented here	Multiple, spanning financial-crime (TraderTraitor: Ronin, WazirX, Bybit) and infiltration (Wagemole: Munchables) tactics	One 2026 incident (Drift) attributed by investigators to North Korea-linked actors — a newer, still-emerging pattern in this page’s sources
Secure-hardware ecosystem maturity	“Level 3” per Paradigm’s framework: TEEs widely deployed in MEV/OFA infrastructure (see /mev/encrypted-mempools/)	Not comparably documented in this page’s sources; Arcium referenced only secondhand as a separate confidential-compute approach

The two ecosystems face the same three trust boundaries, but this page’s sourced incidents differ in emphasis: Ethereum’s largest documented failures are pure infrastructure/signing-pipeline compromises against exchanges and protocols with no need to defeat any governance mechanism at all, while Solana’s most striking 2026 incident shows attackers instead patiently working through a protocol’s own legitimate governance and security-council process — suggesting that as governance tooling matures and gets harder to attack mechanically (via flash loans), attackers increasingly target the humans who operate it instead.

9. Reference doc

The reference

The 5 Levels of Secure Hardware — Georgios Konstantopoulos (Paradigm), 21 November 2024. paradigm.xyz/writing/the-5-levels-of-secure-hardware

Summary of the reference

The post frames “programmable cryptography” — computing over data without exposing it, with attested integrity of the computation — as one of the most important problems of the next decade, and argues secure hardware (TEEs) is the practical path to it at scale, since the alternatives each have a specific, currently-unsolved gap: FHE doesn’t resolve who holds the decryption key, MPC depends on assuming enough parties won’t collude, ZK proofs can’t handle shared state that many parties must jointly update (the same limit this page’s privacy reference discusses), and indistinguishability obfuscation has no practical construction yet. The author illustrates the appeal of programmable cryptography with concrete examples already shipping in some form: Apple’s on-device Secure Enclave and its Private Cloud Compute announcement, and a live example (Teleport) letting anyone with a magic link post to a Twitter account under enforced rules, without that account’s actual credentials ever being exposed.

The post’s analytical core is a three-axis framework — performance, developer experience, and security model — used to define five levels of secure-hardware maturity, reproduced in full in §3. The headline claim is that the ecosystem is currently at Level 3: developers already have near-native performance, GPU support, and a good enough developer experience to build “most of the exciting things that ‘endgame’ programmable cryptography enables,” but Level 3 offers no security improvement over Level 1 — trust still rests entirely on the hardware manufacturer’s proprietary supply chain. Moving to Level 4 requires an open manufacturing process (reducing reliance on any one vendor); Level 5 requires heterogeneous, redundant secure hardware from multiple such open manufacturers cross-checking each other, which the post frames as necessary before secure hardware could be trusted for genuinely high-stakes, global-scale uses like voting or medical data. The post is candid that each step up trades against the others: better developer experience grows the trusted computing base, open instruction sets can cost performance, and redundancy for Level 5 costs performance again — there is no level where all three axes improve at once.

Key quotes

“We think that achieving that will require utilizing secure hardware which gives guarantees about the integrity and the confidentiality of the computation running on it.” (opening)

“FHE does not address who holds the decryption key, MPC is based on non-collusion assumptions, ZK cannot handle share state, and IO does not have a feasible construction yet.” (§ Secure Hardware is necessary)

“There is no shortage of vulnerabilities against secure hardware, which have been repeatedly broken by researchers.” (§ Secure Hardware is necessary)

“We can build great applications with secure hardware today; the stack is ready for developers with good performance. To make things more secure, we’ll need innovation at the hardware layer.” (opening summary)

How to read the original

Background needed: a rough sense of what a TEE/secure enclave does (isolate and encrypt computation, with hardware-backed attestation) and passing familiarity with FHE, MPC, and ZK proofs as alternative privacy techniques. What to skip on a first pass: the specific consumer-app examples (Teleport, the Cursive dating-app demo) — vivid but not load-bearing for understanding the 5-level framework itself. The hardest part to parse is why Level 3 counts as “no security improvement” over Level 1 despite being dramatically more usable: the answer is that the security model axis is untouched — you are still trusting the same proprietary manufacturer’s supply chain either way, just running more expressive programs on top of that same trust assumption.

What changed since

• samczsun’s “Demystifying the North Korean Threat” (2025-03-31, the second reference below) postdates this piece and, while not about secure hardware directly, reinforces its underlying caution: even mature, widely-deployed infrastructure (Safe{Wallet}) was compromised not through a hardware-level break but through the exact “proprietary supply chain” trust assumption this post flags as Level 3’s unresolved weakness — just applied to software infrastructure rather than a chip.
• Public dstack-style tooling for building on TEEs (referenced in the original post as “exciting initial work”) has continued to mature, per the post’s own framing, though this page’s sources do not document a move to Level 4 or 5 as of 2026-08.

The reference

Demystifying the North Korean Threat — samczsun (Paradigm), 31 March 2025. paradigm.xyz/writing/demystifying-the-north-korean-threat

Summary of the reference

Written in the aftermath of the Bybit hack, this post opens with samczsun’s own real-time account of the investigation: watching Bybit’s cold wallet empty into a new address and over $200M of LSTs get liquidated within minutes, and initially assuming a routine multisig-signer compromise — “this couldn’t have been further from the truth.” DPRK had instead compromised Safe{Wallet}‘s own infrastructure, a “level of sophistication that no one had considered or been prepared for.”

The bulk of the post is a structured taxonomy of DPRK’s cyber apparatus, organized by the state’s own chain of command (WPK → KPA’s General Staff Department → Reconnaissance General Bureau, and separately the Central Committee → Munitions Industry Department), reproduced in full in §3. Each subsequent section profiles one named threat actor with its own history and signature tactic: Lazarus Group’s origin story (Sony Pictures, 2014) and its Bank of Bangladesh SWIFT heist (2016), which exploited a cross-timezone bank-holiday gap to delay detection of nearly $1B in fraudulent transfer requests; APT38’s 2016 spinout to focus on financial crime; AppleJeus’s supply-chain malware distribution (the 2023 3CX compromise, the 2024 Radiant Capital Telegram malware); DangerousPassword’s long-running, comparatively low-sophistication phishing; Contagious Interview’s fake-recruiter, backdoored-coding-challenge technique; Wagemole’s strategy of getting hired directly into target organizations (with Munchables cited as an example of an embedded operative acting offensively); and finally TraderTraitor, “the most sophisticated DPRK threat actor targeting the cryptocurrency industry,” walked through in detail across the Ronin, WazirX, and Bybit incidents, each showing an escalating level of infrastructure-level sophistication culminating in compromising Safe{Wallet} itself.

The post closes with concrete defensive advice, explicitly scoped to the fact that DPRK’s crypto-industry success has never required a 0-day: individuals should be alert to social-engineering pressure tactics; organizations should apply least-privilege access, mandate password managers, 2FA, and separate personal/work devices with MDM/EDR tooling; and large, high-value targets should specifically design against any single point of failure that could cause total loss of funds, since “TraderTraitor defies expectations and norms even without the need for 0-days.”

Key quotes

“Someone had pulled off the biggest hack in cryptocurrency history, and we had a front-row seat.” (opening)

“DPRK had actually compromised the infrastructure of Safe{Wallet} itself, and had deployed a malicious payload specifically targeting Bybit.” (opening)

“There have been no recorded or known incidents of North Korea deploying 0-days against the cryptocurrency industry.” (§ Staying Safe)

“For organizations, apply the Principle of Least Privilege where possible.” (§ Staying Safe)

“Ensure that no single point of failure exists such that a single compromise can cause total loss of funds.” (§ Staying Safe)

How to read the original

Background needed: what a multisig wallet and a hardware-wallet signing flow are, and a general sense of what “spearphishing” and “supply-chain attack” mean. What to skip on a first pass: the extensive footnoted citations to individual news reports for each historical incident (Sony, Bank of Bangladesh, WannaCry) — useful for verification, not for understanding the organizational taxonomy. The hardest part to internalize is the Wagemole distinction from every other unit profiled: unlike Lazarus, APT38, AppleJeus, DangerousPassword, or TraderTraitor, Wagemole’s operatives aren’t trying to breach a perimeter at all — they are the perimeter, hired in good faith, sometimes for up to a year, before acting; no conventional technical control (firewalls, patching, phishing training) addresses this pattern, only organizational access controls applied to your own legitimately-hired staff.

What changed since

• The Drift Protocol incident (April 2026, covered in §6) postdates this piece and extends its central thesis into a new pattern: rather than compromising a signing pipeline or infiltrating as an employee, attackers spent weeks socially engineering members of a protocol’s own governance security council directly — a variation this post’s taxonomy doesn’t yet name, but which fits its overall argument that DPRK-linked actors consistently attack the human/organizational boundary rather than cryptography.
• OFAC’s broader North Korea sanctions posture and FBI attribution practices (e.g. the public FBI attribution of Bybit to TraderTraitor) have continued to formalize since this post, providing government-level confirmation of attributions samczsun’s post treats as high-confidence industry consensus.

Secondary references

1. Chainalysis, “Drift Protocol Hack: How Privileged Access Led to a $285M Loss” (2026-04) — read for the clearest documented case, at time of writing, of DPRK-linked social engineering targeting a protocol’s governance process directly rather than a custodial signing pipeline.
2. FBI Public Service Announcement on the Bybit hack (2025-02-26, via secondary reporting) — read for the U.S. government’s own formal attribution language for TraderTraitor/Lazarus, complementing samczsun’s practitioner account.
3. Mandiant’s attribution reporting on the Radiant Capital compromise (via secondary reporting, 2024-12) — read for a second investigator’s independent confirmation of AppleJeus’s role, cross-checking samczsun’s account.

10. Sources

• The 5 Levels of Secure Hardware — Georgios Konstantopoulos (Paradigm) — 2024-11-21 — https://www.paradigm.xyz/writing/the-5-levels-of-secure-hardware
• Demystifying the North Korean Threat — samczsun (Paradigm) — 2025-03-31 — https://www.paradigm.xyz/writing/demystifying-the-north-korean-threat
• FBI Confirms North Korea’s Lazarus Group as Bybit Hackers — Infosecurity Magazine (secondary) — 2025-02 — https://www.infosecurity-magazine.com/news/fbi-confirms-north-koreas-lazarus/
• $235 million lost by WazirX in North Korea-linked breach — Elliptic (secondary) — 2024 — https://www.elliptic.co/insights/235-million-lost-by-wazirx-in-north-korea-linked-breach/
• Drift Protocol Hack: How Privileged Access Led to a $285M Loss — Chainalysis (secondary) — 2026-04 — https://www.chainalysis.com/blog/lessons-from-the-drift-hack/
• Detailed Post-Mortem and Next Steps — Raydium (secondary) — 2022-12 — https://raydium.medium.com/detailed-post-mortem-and-next-steps-d6d6dd461c3e
• Munchables Exploited for $62M — CoinDesk (secondary) — 2024-03-27 — https://www.coindesk.com/tech/2024/03/27/munchables-exploited-for-62m-ether-linked-to-rogue-north-korean-team-member