Executive Summary: Lazarus Group: the state-sponsored hacking organisation operating on behalf of the Democratic People's Republic of Korea (DPRK): has stolen more than $3 billion in cryptocurrency since 2017. That figure makes North Korea one of the most prolific financial criminals in history. But the more operationally important insight is how they achieved it: not primarily through smart contract exploits or cryptographic attacks, but through patient social engineering, supply chain compromise, and exploitation of the systematic operational security failures that characterise the Web3 industry. This guide dissects their playbook, analyses what the Bybit hack reveals about their current capabilities, and provides a framework for building an operational security programme capable of resisting nation-state-level threats.
Who Is the Lazarus Group
Lazarus Group is a DPRK state-sponsored advanced persistent threat (APT) actor, designated by the US Department of Justice as operating under the direction of the Reconnaissance General Bureau: North Korea's primary intelligence and special operations agency. The group has been active since at least 2009, with early operations including the 2014 Sony Pictures hack and the 2016 Bangladesh Central Bank heist ($81 million stolen via fraudulent SWIFT transfers). From approximately 2017, Lazarus Group began systematically targeting cryptocurrency exchanges, DeFi protocols, and blockchain infrastructure companies.
The FBI has attributed Lazarus Group activity to North Korean state actors in multiple public indictments and advisories. The US Treasury's Office of Foreign Assets Control (OFAC) has sanctioned multiple Lazarus Group-linked entities and individuals. The UN Panel of Experts has documented North Korea's use of stolen cryptocurrency to fund its weapons of mass destruction programme: the proceeds of Lazarus Group operations are not merely criminal profits, they directly fund ballistic missile development.
Sub-groups within the broader Lazarus cluster include BlueNoroff (financial system targeting), Andariel (South Korean infrastructure targeting), and TraderTraitor (cryptocurrency-specific operations). The TraderTraitor designation is particularly relevant for Web3 security: it specifically covers Lazarus operations targeting blockchain developers, crypto exchanges, and DeFi protocols.
The Full Kill Chain: How Lazarus Operates
Lazarus Group operations follow a structured kill chain that can span months from initial target selection to final exfiltration. Understanding each stage is essential for building effective defences.
Stage 1: Reconnaissance
Lazarus conducts extensive open-source intelligence (OSINT) on target organisations before any contact is made. This includes: LinkedIn profiling of all technical staff, mapping organisational hierarchies and identifying individuals with privileged access, reviewing public GitHub repositories to understand the technical stack and deployment practices, monitoring public blockchain activity to understand wallet structures and transaction patterns, and analysing job postings that reveal internal tooling and infrastructure details. This reconnaissance phase typically lasts weeks to months and produces a detailed target profile.
Stage 2: Social Engineering and Initial Access
Using the intelligence gathered in Stage 1, Lazarus constructs personalised social engineering campaigns against identified targets. The most consistently documented vector is the fake job offer: a convincing recruiter persona (complete with a plausible LinkedIn profile and professional history) contacts a developer or engineer at the target organisation with a job opportunity at a legitimate-sounding company in the Web3 space. The conversation proceeds over weeks, building trust, before the target is asked to complete a "technical assessment": a coding exercise that contains concealed malware.
Stage 3: Lateral Movement
Once initial access is achieved on a developer's workstation, Lazarus moves laterally within the target's internal network. Their tooling: including custom malware families such as AppleJeus, BLINDINGCAN, and DTrack: is specifically designed to operate on both Windows and macOS (the predominant developer platform in crypto), avoid detection by standard endpoint protection, and establish persistent footholds that survive system reboots.
Stage 4: Privilege Escalation and Asset Identification
Within the target environment, Lazarus seeks to identify and access private keys, seed phrases, and administrative credentials for high-value systems. They conduct systematic searches of file systems, code repositories, password managers, browser credential stores, and cloud storage for key material. They map the multisig wallet structure and identify which team members control which signing keys.
Stage 5: Exfiltration
The final stage involves executing the theft. Depending on what was discovered in Stage 4, this may involve: directly signing and broadcasting transactions using stolen private keys, manipulating the signing process through compromised software (as in the Bybit hack), or slowly extracting funds over time to minimise detection. Stolen cryptocurrency is typically laundered through a combination of Tornado Cash (prior to sanctions), ChipMixer, cross-chain bridges, and centralised exchanges in jurisdictions with limited AML enforcement.
The Bybit Hack Through the OpSec Lens
The Bybit hack of February 2025: in which approximately $1.4 billion in ETH and staked ETH was stolen: is the largest cryptocurrency theft in history. Our detailed technical post-mortem is available in the Bybit hack analysis. Here, we focus specifically on what the attack reveals about Lazarus Group's current operational capability and the nature of the security failure.
Bybit's cold wallet custody used a Safe (formerly Gnosis Safe) multisig architecture. To execute the theft, Lazarus did not break the multisig cryptography or exploit a smart contract vulnerability. Instead, they compromised the interface through which Bybit's authorised signers reviewed and approved transactions. The Safe front-end infrastructure was manipulated so that when signers reviewed the transaction details in their signing interface, they saw a legitimate routine transfer: while the actual transaction they were signing was a delegatecall to a malicious contract that replaced the Safe's implementation with attacker-controlled logic.
This was an operational failure, not a code failure. The attack vector was the human review process and the trust placed in the signing interface. The multisig architecture was sound; the operational processes around it were not. Specifically:
- Signers reviewed transaction data in a software interface rather than independently verifying transaction parameters through a hardware wallet's tamper-evident display.
- There was no out-of-band verification protocol requiring signers to independently confirm the transaction hash through a separate, isolated channel before signing.
- The compromise of the Safe front-end infrastructure was not detected: indicating insufficient monitoring of the integrity of the signing infrastructure itself.
"The Bybit hack was not a cryptography problem. It was not a smart contract problem. It was a process problem, and process problems are not fixed by code audits."
Lazarus Tactics in Detail
Fake Job Offers Targeting Crypto Developers
The FBI's public advisory on TraderTraitor specifically documents the use of fake job offers as a primary initial access vector. Lazarus creates detailed LinkedIn personas for fictional recruiters at real-sounding companies, complete with plausible connection networks, prior role histories, and endorsements. Targets: particularly developers with GitHub profiles demonstrating relevant skills: are contacted with highly specific opportunities calibrated to their background. The engagement is patient and professional, often lasting weeks before any malware is delivered. Technical assessments may arrive as a GitHub repository, a Google Drive link, or a PDF: any of which may contain or link to malicious payloads.
Supply Chain Attacks via Malicious npm Packages
Lazarus has specifically targeted the developer toolchain through malicious npm packages. Several documented cases involve typosquatting legitimate crypto development libraries, inserting malicious packages into open-source project dependency trees, and contributing backdoored code to legitimate repositories. Once a developer's environment is compromised via a malicious dependency, all subsequent operations on that machine: including contract compilation, deployment, and key operations: are potentially observable or modifiable by the attacker.
Spear Phishing with Fake VC and Investor Identities
Beyond technical staff, Lazarus targets founders, business development leads, and finance team members with spear phishing campaigns posing as venture capital investors, strategic partners, or institutional clients. These campaigns are tailored to recent fundraising activity (discoverable via Crunchbase and press coverage), reference real investors and market events, and direct targets to malicious document downloads under the guise of investment term sheets, partnership agreements, or due diligence questionnaires.
Clipboard Hijacking and Browser Extension Injection
Post-compromise malware deployed by Lazarus frequently includes clipboard monitoring and modification capabilities, replacing cryptocurrency addresses copied to the clipboard with attacker-controlled addresses. Browser extension injection: inserting malicious code into the browser environment: enables real-time manipulation of transaction parameters in dApp interfaces, overriding what is displayed to the user while submitting different parameters to the network.
Targeting Finance and Operations Staff, Not Just Developers
A critical and frequently overlooked aspect of Lazarus's targeting strategy is their focus on non-technical staff in high-privilege roles. Finance team members with authority to initiate large transfers, operations managers with admin access to exchange platforms, and community managers with social media and communication access are all targeted. These individuals typically have less security training than developers and may be more susceptible to social engineering: making them a preferred initial access vector even when the ultimate objective is technical in nature.
Why Most Web3 Teams Are Completely Unprepared
The Web3 industry's security culture has developed almost entirely in response to smart contract vulnerabilities. Audit culture, bug bounties, formal verification, and competitive audit platforms have all emerged in response to code-level attacks. This is appropriate and has raised the baseline quality of smart contract security significantly. But it has also created a false sense of comprehensive security protection that leaves teams almost entirely unprepared for the actual threat model Lazarus Group represents.
A Web3 team that has passed a Tier-1 audit, runs a comprehensive bug bounty programme, and uses a multisig for all treasury operations has addressed the code layer. They have addressed exactly the layer that Lazarus Group does not primarily attack. Meanwhile:
- No developer has received any training on how to identify a Lazarus social engineering campaign.
- No policy exists regarding how developers respond to job offers from unknown recruiters.
- Developer workstations have no endpoint detection and response (EDR) monitoring.
- The signing process for multisig operations has no out-of-band verification step.
- No one has ever reviewed what browser extensions are installed on the workstations used to access the team's Safe interface.
- npm dependencies are installed without integrity verification.
In this environment, a $500 million protocol sits entirely within reach of a patient, well-resourced nation-state actor who has been developing their techniques against the crypto industry for eight years. The Lazarus Group does not need to defeat your cryptography. They just need to find one developer willing to download a coding test.
The Three Layers Lazarus Exploits: People, Process, Technology
People: The Primary Attack Surface
Lazarus Group consistently prioritises human targets over technical vulnerabilities. Their investment in social engineering: creating detailed personas, building rapport over weeks, crafting context-specific lures: reflects a clear strategic assessment that people are more reliably exploitable than code. Every individual on a crypto team with access to keys, repositories, production systems, or funds is a potential initial access vector. The attack surface expands with every new hire, every conference attendance, and every public profile that reveals organisational structure.
Process: The Execution Layer
Even when an initial compromise is limited in scope, inadequate processes allow Lazarus to escalate that initial access to the full theft. If the transaction signing process requires only that signers approve a request in a software interface without independent verification, a compromised interface defeats the entire multisig security model. If the deployment process does not include integrity verification of the code being deployed, a compromised developer machine enables deployment of malicious contracts. Process failures are what allow technical exploits to succeed, and they are almost entirely absent from standard security assessments.
Technology: Infrastructure Gaps
The technology layer attacks Lazarus employs: malware on developer machines, malicious browser extensions, compromised npm packages: succeed because the target technology environment lacks the controls standard in institutional financial services: EDR on all endpoints, software signing and integrity verification, approved software lists enforced via MDM, and isolation of key operations to hardened environments. These are not exotic controls. They are standard practice in any environment with a serious security posture.
Building an OpSec Programme That Can Withstand Lazarus-Level Threats
Security Awareness Training
All team members: developers, finance staff, operations, community management: should receive regular security awareness training that specifically covers Lazarus-style social engineering tactics: how fake job offers work, how to verify recruiter identities, how to safely handle unsolicited documents and code, and how to report suspicious contact. Training should be specific and scenario-based, not a generic annual compliance tick-box.
Verification Protocols for Sensitive Operations
Every high-value operation: multisig transactions, contract deployments, large fund movements: should require an out-of-band verification step in which the transaction parameters are independently confirmed through a channel that is separate from the primary signing interface. This could be a voice call between signers confirming the transaction hash, hardware wallet display verification (checking the hardware wallet screen rather than the browser interface), or a documented approval workflow in a separate, isolated system.
Compartmentalisation
Security-critical operations should be conducted on dedicated, isolated devices that are never used for general browsing, communication, or software development. Key management, contract deployment, and treasury operations should be separated from day-to-day work environments. Access to production infrastructure should be limited to the minimum number of individuals necessary, with all access logged and monitored.
Endpoint Security
All developer and operations workstations should have enterprise-grade EDR deployed, with alerts reviewed by personnel who understand what Lazarus-family malware looks like in telemetry. Software installation should be controlled via policy: developers should not have unrestricted ability to install arbitrary software on machines that have access to production systems. npm packages should be installed with lockfiles and integrity hashes verified.
Incident Response Planning
Assume compromise will occur. Have a documented, rehearsed incident response plan that includes specific scenarios for key compromise, multisig manipulation, and social engineering of team members. Know in advance who has authority to pause contracts, who contacts law enforcement, who handles public communications, and how fund recovery and forensic analysis will be conducted. Lazarus Group moves quickly once initial access is established: response capability in the first hours of an incident is decisive.
The Institutional Imperative
The Lazarus Group threat is not a problem that Web3 protocols can solve alone by improving their individual operational security. It is a systemic challenge that requires the industry to adopt the same operational security standards that have been standard practice in defence, intelligence, and institutional finance for decades: because those are the sectors that have historically faced the same calibre of adversary.
Security4Web3 was founded specifically to bring that defence-industry-grade methodology to the Web3 ecosystem. Our team has direct experience securing systems against the most capable and motivated adversaries in the world. We understand what rigorous operational security looks like not as a theoretical framework, but as a practical discipline built from years of working in environments where failure has consequences far beyond financial loss.
The question for every Web3 protocol is not whether Lazarus Group is capable of targeting them: they are. The question is whether the team has built a security posture worthy of the assets they manage and the investors who trust them. For context on documented Lazarus attacks and their methods, see our dedicated analysis of the Bybit hack and our broader coverage of the threat actor landscape in crypto.
Frequently Asked Questions
Has Lazarus Group been stopped?
No. Lazarus Group remains active as of 2026 and continues to target cryptocurrency exchanges, DeFi protocols, and Web3 companies. FBI and international law enforcement attributions have been made, and some cryptocurrency seizures and sanctions have been implemented, but the group operates under the protection of the North Korean state and has shown no reduction in operational tempo. The Bybit hack in February 2025: the largest single cryptocurrency theft in history: was attributed to Lazarus Group.
What industries does Lazarus Group target?
While Lazarus Group has historically targeted a broad range of industries including defence contractors, media companies, and financial institutions, cryptocurrency and Web3 companies have been their primary focus since approximately 2017. The combination of high-value assets, pseudonymous transactions, limited regulatory oversight, and relatively immature operational security practices makes the crypto industry an extremely high-yield target for state-sponsored theft.
How do I protect my crypto company from state-sponsored hackers?
Protection against state-sponsored threats requires a systematic operational security programme covering People (security awareness training, background screening, social engineering resistance), Process (multisig verification protocols, insider threat detection, incident response planning), and Technology (hardware security modules for key management, endpoint detection and response, network monitoring, phishing-resistant MFA). No single control is sufficient: state-sponsored adversaries will probe every layer of your security posture to find the weakest point.
What is the Lazarus Group's most common initial access method?
Social engineering: particularly via fake job offers on LinkedIn and professional networks: is Lazarus Group's most consistently documented initial access method against crypto targets. They create convincing fake recruiter personas, engage targets over weeks or months to build trust, and ultimately deliver malware through a "skills assessment" document or coding test. Developer environments make this particularly dangerous, as a compromised developer machine provides direct access to code repositories, deployment keys, and internal infrastructure.