The DPRK Threat Model: Engineering Defense Against State-Sponsored Attackers

After the Bybit $1.5B hack in February 2025, I rewrote ZeroCopy’s threat model. Not because our architecture was wrong - it was not. But because the Bybit incident revealed exactly which assumptions I had been making about the adversary that were no longer valid.

The Bybit attack was executed by TraderTraitor, a DPRK (North Korean)-linked group operating under the Lazarus Group umbrella. By 2025, this group had stolen more cryptocurrency than any other actor in history - an estimated $3B+ cumulatively. Their tradecraft is now well-documented across FBI advisories, Chainalysis reports, and post-incident analyses. This post is the document that should exist for every engineer building custody infrastructure: a precise description of the adversary and the controls that stop them (and the controls that don’t).

Who TraderTraitor Actually Is

TraderTraitor is distinct from other Lazarus subgroups in its operational focus on cryptocurrency firms and developer targets. Key characteristics documented by the FBI, CISA, and Chainalysis:

Resources: State-level funding. DPRK’s cryptocurrency theft operations reportedly provide 10-40% of the regime’s foreign currency revenue. This means professional, persistent, multi-month operations that would not be funded by criminal groups operating on ROI timelines.

Patience: TraderTraitor operations routinely involve 3-6 months of relationship-building before the attack payload is delivered. They identify targets, research them, build realistic personas, and engage in genuine technical conversations for months before deploying malware.

Technical sophistication: Their malware is custom, actively maintained, and specifically designed to evade detection on macOS (the primary OS in crypto development environments). Their payloads have been found using Apple notarization bypasses, process injection techniques specific to macOS, and C2 infrastructure that mimics legitimate cloud traffic.

Scale: The FBI assessed that TraderTraitor compromised at least 50 organizations across the global cryptocurrency industry in 2023-2024 alone.

The Four Primary Attack Vectors

Vector 1: Fake Recruitment (Contagious Interview)

The most commonly documented TraderTraitor initial access vector in 2024-2025.

Mechanics:

1. TraderTraitor operators create LinkedIn profiles with realistic work histories (often stolen from real individuals, with details changed)
2. They approach engineers at crypto firms with unsolicited job opportunities - research roles, consulting contracts, senior engineering positions
3. Initial contact establishes rapport. They appear technically competent, ask intelligent questions about your work, and offer seemingly legitimate compensation
4. After 1-4 weeks of communication, they send a “coding challenge” or “technical assessment” - either a GitHub repository, a zip file, or a Google Drive link containing a project to evaluate
5. The “assessment” is malicious code that appears to be a legitimate npm/Python project but contains an obfuscated payload. Common packaging: a cryptocurrency arbitrage tool, a trading algorithm, or a portfolio tracker
6. Once the engineer opens the project and runs npm install or pip install, the malware is installed

What the malware does once installed:

• Persistence via Launch Agent on macOS
• Key extraction from Ledger, Trezor, and other hardware wallet companion apps
• Browser credential theft (MetaMask seed phrases are a primary target)
• AWS credential exfiltration from ~/.aws/credentials
• SSH key exfiltration from ~/.ssh/
• Screen recording for credential capture
• C2 communication to rotate infrastructure monthly

Defense:

Required:                          Not Sufficient:
────────────────────────────────────────────────────────────────────────────────
Hardware security keys for all     2FA via TOTP (TOTP codes are phishable)
commit signing (FIDO2/WebAuthn)

Dedicated clean VM for any code    Reviewing code before running it
from external parties (no          (obfuscated npm preinstall scripts run
credentials, no production access) automatically without visible review)

Sandbox execution of all external  Antivirus (signature-based AV misses
code (Docker with --no-network,    custom DPRK payloads)
no credential mounts)

Internal policy: no recruiting     "We don't accept unsolicited approaches"
conversations on personal accounts (easily bypassed - personal accounts are
                                   not monitored)

Vector 2: Supply Chain Injection

Documented in the Bybit attack and in multiple prior incidents.

Mechanics:

1. Target a widely-used npm/PyPI/gem package that your organization depends on
2. Compromise the maintainer’s account (via phishing or credential stuffing) or publish a typosquatted package
3. Inject malicious code into a new version
4. Wait for the target organization to update their dependencies

For the Bybit attack, the injection was into the live production deployment of Safe{Wallet}‘s web interface - not a public package, but the same class of attack: compromising a trusted software supply chain element.

Defense:

# Pin your dependencies precisely in package-lock.json / requirements.txt
# Not npm install (latest) - npm ci (exact locked versions)
npm ci  # reads package-lock.json, errors if it doesn't match

# Use Sigstore/Cosign for package integrity verification (2024+ standard)
# Verify npm packages are signed:
npm audit signatures  # verifies package signatures for npm packages

# Private npm proxy with allowlisted packages + integrity hash verification
# For Docker builds: verify each base image digest
FROM node:20@sha256:abc123...  # Pin to exact digest, not just tag

# Separate production build environments
# No developer credentials in CI/CD
# CI/CD infrastructure should not have access to production signing keys

# For Python projects: use hash-pinned requirements
# requirements.txt:
# cryptography==42.0.5 \
#     --hash=sha256:d73f419a828e3f...
pip install --require-hashes -r requirements.txt

Vector 3: Developer Machine Persistence

Once initial access is achieved (via either vector above), DPRK malware focuses on persistence and escalation.

macOS-specific persistence mechanisms used:

• LaunchAgents at ~/Library/LaunchAgents/com.apple.update.plist (mimics system naming)
• Login Items via macOS SMAppService API
• Cron jobs added to user crontab
• Shell profile modification (~/.zshrc, ~/.bash_profile)

Key targets once persistent:

• ~/.aws/credentials and environment variables with AWS credentials
• Keychain items (via macOS Keychain API, requires local auth but is available to persisted processes)
• Browser extension storage (MetaMask private keys are stored here, though encrypted)
• IDE configuration (IntelliJ/VSCode settings, SSH host configurations)
• Production VPN certificates and SSH private keys

Indicators of compromise for macOS:

# Check for suspicious Launch Agents
ls -la ~/Library/LaunchAgents/
# Look for: recently modified files, unusual naming patterns, plists
# that point to executables in ~/.npm, /tmp, or buried in ~/Library

# Check for unexpected scheduled tasks
crontab -l
launchctl list | grep -v com.apple | grep -v io.

# Check for unusual network connections
lsof -i | grep ESTABLISHED | grep -v browser_process_name

# Verify hardware security key is actually required for git operations
git log --show-signature -1  # should show a GPG/SSH signed commit

Defense - organizational policy:

All engineers with production access must:

• Use a dedicated work machine that has never been used for personal projects
• Never run unreviewed external code directly - use disposable VMs
• Use hardware security keys (YubiKey) for all authentication (GitHub, AWS, GCP, VPN)
• Not store production credentials on the local machine - use a secrets manager that requires hardware key authentication
• Commit signing must be enabled (git config --global commit.gpgsign true)

Vector 4: Long-Game Social Engineering

Documented in multiple Lazarus Group operations against exchanges and funds.

Mechanics: TraderTraitor operators have maintained cover identities as legitimate crypto developers for 6-18 months before executing an attack. They contribute to open-source projects, attend virtual conferences, write blog posts, and build genuine technical reputations. The eventual attack is a request that seems reasonable given the established relationship.

This vector is specifically effective against firms where:

• Technical decisions are made by individual engineers without security review
• There is a culture of open collaboration with the ecosystem
• New service integrations are approved without formal vendor security review

Defense: No technical control stops this completely. Organizational controls:

• Formal vendor security review for any new infrastructure dependency
• Signed contracts with security requirements for any vendor with production access
• Regular supply-chain audits (SBOM - Software Bill of Materials)
• Employee security awareness training specifically covering DPRK TTPs (not generic phishing awareness)

Controls That Work vs. Controls That Don’t

Control                             Against DPRK?    Why
──────────────────────────────────────────────────────────────────────────────────────
Hardware security keys (FIDO2)      YES              Phishing-resistant; can't be
for all authentication                               intercepted or replayed

TEE policy engine verifying         YES              Independently verifies transaction
transactions (Nitro/SGX)                            intent; not affected by compromised UI

Reproducible builds + SBOM          YES              Detects supply chain tampering
verification

Air-gapped signing for cold         YES              No software pathway to cold keys
storage

Dedicated clean machines for        YES              Limits blast radius of compromise
production operations

"We use Ledger hardware wallets"    NO               Bybit signers used Ledger; attack
                                                     bypassed via UI spoofing

"We have code review"               NO               Obfuscated postinstall scripts
                                                     run before review is possible

Antivirus / EDR                     PARTIALLY        Signature-based detection fails;
                                                     behavioral detection catches some

"We have 2FA"                       NO               TOTP is phishable; only FIDO2
                                                     hardware keys are phishing-resistant

VPN + IP allowlisting               NO               Attacker uses compromised engineer's
                                                     machine (already inside VPN)

SOC 2 certification                 NO               SOC 2 certifies controls exist,
                                                     not that they stop state actors

Implementing a DPRK-Aware Threat Model

The threat model I wrote for ZeroCopy post-Bybit:

Assume:

• One engineer’s machine will be compromised at some point
• One dependency will be supply-chain attacked
• A sophisticated attacker will have 3-6 months of patience and resources

Design accordingly:

• No single engineer’s credentials should be sufficient to move funds
• Production signing must happen in a TEE that independently verifies transaction intent
• Cold storage must be physically air-gapped with no software pathway
• Every signing operation must be verifiable after the fact with an immutable audit trail

Monitoring specifically for DPRK TTPs:

# anomaly_detection.py - DPRK-specific detection rules
DPRK_INDICATORS = [
    # New npm package installed without lockfile update
    {
        "rule": "package_installed_outside_lockfile",
        "description": "npm package installed without updating package-lock.json",
        "detection": "audit npm audit --omit=dev --json | check for unlocked deps",
        "severity": "HIGH",
    },
    # AWS credentials accessed by unexpected process
    {
        "rule": "aws_credentials_accessed_by_unknown_process",
        "description": "Process other than known list read ~/.aws/credentials",
        "detection": "auditd rule: -w /home/*/\.aws/credentials -p rw -k aws_creds",
        "severity": "CRITICAL",
    },
    # Browser extension storage accessed outside browser
    {
        "rule": "browser_extension_storage_read_outside_browser",
        "description": "MetaMask / hardware wallet extension storage read by non-browser",
        "detection": "File access monitoring on browser profile directories",
        "severity": "CRITICAL",
    },
    # New Launch Agent created
    {
        "rule": "new_launchagent_created",
        "description": "LaunchAgent plist created in user or system LaunchAgents",
        "detection": "File system event monitoring on LaunchAgents directories",
        "severity": "HIGH",
    },
]

How This Breaks in Production

Failure 1: Hardware security key required for GitHub but not for internal systems. Your engineers use YubiKeys for GitHub authentication but authenticate to your internal CI/CD and deployment systems with passwords. TraderTraitor compromises an engineer’s credentials via phishing and accesses the internal systems. Fix: hardware security keys must be required for every system with production access. No exceptions for “internal” systems - those are often more valuable targets.

Failure 2: Package lock file not enforced in CI. Developers run npm install locally (which updates package-lock.json) and CI uses npm install as well. A supply-chain attack introduces a malicious dependency. The CI build pulls the new package, builds successfully, deploys to production. Fix: all CI builds must use npm ci (reads exact lockfile). Any dependency change must go through a PR review that includes the full diff of package-lock.json.

Failure 3: “Clean machine” policy not enforced at hire. New engineers are told to use a dedicated work machine but company provisioning takes 2 weeks. In the meantime, they use their personal laptop. They run some code sent by a “potential partner.” Their personal laptop is compromised. They receive their work machine; the malware is never installed on it. But they have already accessed several staging systems and GitHub repos from their personal machine during onboarding. Fix: hardware security keys tied to the work machine identity. No production system access until the engineer is on a company-provisioned, freshly-imaged machine.

Failure 4: Vendor security review is a checkbox, not a real audit. Your vendor security review process asks vendors to self-certify they have SOC 2. A vendor with production access to your signing infrastructure is compromised via social engineering. Your “vendor review” did not evaluate their actual security controls - just their paper certifications. Fix: vendor security reviews for production-access vendors must include architecture review (how do they protect their infrastructure?), review of any software they ship to you (SBOM + hash verification), and contractual incident notification requirements.

Failure 5: Suspicious activity reported but not actioned. An engineer reports receiving an unusual job offer with an attached coding challenge from a LinkedIn contact they don’t know. The security team logs the report but takes no action - “we get these all the time.” The engineer, curious, runs the challenge code on their work machine. Fix: any report of a suspicious job offer or unsolicited attachment from an unknown party should trigger immediate review of that engineer’s machine for compromise indicators. This is not paranoia - it is the documented TraderTraitor initial access vector.

Failure 6: DPRK laundering addresses not blocked at withdrawal. After a custody compromise, funds are moved to DPRK-associated addresses. Your withdrawal system does not screen against the OFAC SDN list in real time. Several withdrawal transactions to laundering addresses execute before the incident is detected. Fix: every outbound transaction must be screened against the OFAC SDN list and known DPRK-associated addresses before execution. Chainalysis and Elliptic both maintain DPRK address databases. This is a regulatory requirement in most jurisdictions and a risk management requirement everywhere.

Related reading: The Bybit $1.5B Hack Postmortem covers the specific Bybit incident in forensic detail. Insider Threat and Collusion Resistance covers the organizational controls that complement technical defenses. AWS Nitro Enclaves for Wallet Signing covers the TEE-based policy engine that provides defense even if a machine is compromised.