Hunting Lazarus Part IV: Real Blood on the Wire

The full investigation is consolidated in the Inside the Machine research article.

Executive Summary

In the days following Part III's publication, continued investigation of the Contagious Interview campaign produced findings that fundamentally change the picture. Red Asgard's threat research team:

• Confirmed the C2 infrastructure is operationally real—not a honeypot—by recovering 241,764 stolen credentials belonging to 857 victims across 90 countries
• Discovered credentials for banking platforms (HDFC, Bank of America, Charles Schwab, Revolut), payment processors (PayPal, Payoneer, Stripe), and 4,280 Google accounts—all in plaintext on unauthenticated endpoints
• Identified the victim profile: software developers and freelancers, primarily in South Asia, recruited through fake job interviews on Upwork and Fiverr
• Discovered a fourth malware family: an AnyDesk RAT that installs persistent remote desktop backdoors with hardcoded attacker credentials
• Identified 6 operator accounts through endpoint enumeration, and exploited an IDOR vulnerability to dump victim data without authentication
• Decrypted the binary protocol on ports 22411-22413, revealing active operator beacons and automated C2 scheduling
• Filed reports with FBI IC3 and CISA before the deepest findings—then continued the investigation
• Produced 16 YARA rules and 88 Snort rules for community detection

This is the article that answers the question from Part III. The answer is worse than either possibility we considered.

---

The Question We Left Open

Part III ended at an impasse. We had mapped approximately 20 standardized servers, attempted 11 attack classes, found zero exploitable vulnerabilities, and identified six indicators suggesting the infrastructure was a honeypot or counter-intelligence operation. We assigned a 70/30 probability favoring honeypot.

We recommended caution. We said: do not trust data obtained from these servers.

Then we found the data.

---

Act 1: The Answer

Wave 5—Querying the Victim Endpoints

While we debated honeypot probabilities, we kept probing. The C2 infrastructure exposes unauthenticated HTTP endpoints defined in the malware's own source code. These are not hidden admin panels. They are not authenticated APIs we bypassed. The malware instructs victims to POST stolen data to these endpoints, and the endpoints serve that data back to anyone who sends a request with a valid campaign identifier.

No exploitation. No authentication bypass. The malware's own protocol told us exactly where to look.

What came back was not test data.

Wave 6—The Scale Reveals Itself

The first campaign we queried returned structured victim records: hostnames, internal IP addresses, geolocations, ISP names, operating system details. Real machines. Real people. The hostnames were not synthetic—they followed the messy, inconsistent patterns of actual developer workstations: DESKTOP-A7B3K9F, 77_e30028tech, MacBook-Pro-de-Juan.local.

Additional campaigns returned hundreds more victims.

The honeypot theory began dying under the weight of the data. Test infrastructure does not contain credentials for HDFC Bank and PayPal from 90 different countries. Counter-intelligence operations do not fabricate 241,764 credential records with internally consistent timestamps spanning weeks of real-time collection.

Final Consolidated Numbers

After full extraction across waves 10-11:

Campaign	Victims	Stolen Credentials
5346	121	31,473
15	287	72,493
99	449	137,798
TOTAL	857	241,764

Eight hundred fifty-seven compromised developer workstations. Nearly a quarter-million credentials. Ninety countries.

---

Act 2: What Was Stolen

The Credential Structure

Each stolen credential record follows this format:

{
  "url": "https://www.paypal.com/signin",
  "username": "[REDACTED]",
  "userpwd": "[REDACTED]",
  "pc_name": "[REDACTED]",
  "created_time": "2026-01-27 09:57:22",
  "last_time": "2026-01-28 06:25:14",
  "ip": "[REDACTED]",
  "country": "India"
}

Plaintext passwords. Not hashes. Not encrypted blobs. The actual passwords people use for their banking, their email, their cryptocurrency wallets—sitting on a server that responds to unauthenticated HTTP requests.

The records also include paths to downloadable archives of each victim's full browser data—every credential, every saved form, every autofill entry. We are withholding the URL structure and endpoint details to prevent secondary exploitation of the victim data.

Banking and Financial Services

The credential set includes logins for financial institutions across five continents:

Category	Platforms
Traditional Banking	HDFC Bank (India), Bank of America, Charles Schwab, OTP Bank (Hungary), Bankinter (Spain), Scotia (Costa Rica), DBS Bank (Singapore)
Digital Banking	Revolut, Wise, CapitExPay
Payment Processors	PayPal, Payoneer, Stripe
Cryptocurrency	MetaMask, Phantom, Coinbase, Trust Wallet + 23 additional wallet extensions

Developer Platforms

Platform	Credentials Stolen
github.com	2,647
upwork.com	969
localhost:3000	2,808
localhost:5173	665
Google accounts	4,280

The localhost credentials are the forensic detail that matters most. localhost:3000 is the default port for React development servers. localhost:5173 is the default for Vite. These are not web users who clicked a bad link. These are software developers who were running local development environments when their credentials were stolen. The malware captured their browser-saved passwords while they had dev servers running—a fingerprint that only exists on active developer workstations.

The Upwork and GitHub numbers confirm the attack vector documented in Parts I-III: developers recruited through freelancing platforms, given malicious repositories to review, compromised the moment they open the project.

Lure Domains

Two domains appeared repeatedly in the credential dataset, not as targets but as origins—URLs where victims had created accounts as part of the social engineering:

Domain	Credentials
elvengold.com	573
email.tokenloopz.com	189

These are lure domains. The attackers create fake project websites—in this case, what appear to be blockchain gaming and token platforms—where victims sign up during the "interview" process. The credentials victims use for these fake platforms often match their credentials elsewhere. Password reuse turns a fake signup form into a skeleton key.

Geographic Distribution

Country	Credentials	% of Total
India	6,863	2.8%
Bangladesh	4,979	2.1%
Vietnam	3,301	1.4%
Pakistan	2,933	1.2%
United States	2,396	1.0%
Russia	1,859	0.8%
Nigeria	1,685	0.7%
Sri Lanka	1,475	0.6%
Croatia	1,233	0.5%
France	1,125	0.5%

The remaining credentials span 80 additional countries. The geographic concentration in South Asia aligns precisely with the Upwork/Fiverr freelancer ecosystem—these are the regions where a disproportionate share of remote software development talent is sourced.

The victim profile is unambiguous: software developers and freelancers, recruited through fake job interviews, with their entire digital lives extracted and served on unauthenticated endpoints.

---

Act 3: We Called the FBI

At wave 8, we had documented 121 victims with banking credentials exposed on unauthenticated servers. That was enough.

We filed a report with FBI IC3.

The decision was not complicated. Real people's banking credentials were sitting on unauthenticated endpoints. Every hour those servers stayed up was another hour those credentials could be harvested—not just by Lazarus, but by any opportunistic actor who stumbled onto the same infrastructure we found. The victim data was not encrypted. It was not rate-limited. It was not behind authentication.

We reported what we had. Then we kept digging.

As the investigation progressed and the numbers grew from 121 victims to 857 victims, from 31,473 credentials to 241,764 credentials, we filed a supplementary report with CISA. The scale warranted it.

Everything documented in Acts 4 through 7 below was discovered after the initial FBI report. We continued the investigation because the initial filing covered only what we knew at wave 8—and what we found afterward was significantly more extensive.

---

Act 4: The AnyDesk RAT

Discovery

While enumerating endpoints on the C2 infrastructure, we discovered a previously undocumented endpoint that returned a Python script—a fourth malware family we had not previously encountered in the Contagious Interview campaign.

This is not BeaverTail. It is not InvisibleFerret. It is not OtterCookie. It is a purpose-built AnyDesk deployment and backdoor tool that gives the operators persistent remote desktop access to victim machines.

The Attack Chain

The script executes the following sequence:

1. Downloads AnyDesk from the C2
2. Installs and launches AnyDesk silently
3. Waits for AnyDesk to generate its configuration files
4. Steals AnyDesk credentials from service.conf
5. Exfiltrates the stolen credentials to the C2 over plaintext HTTP
6. Injects hardcoded attacker credentials into the victim's AnyDesk configuration
7. Restarts AnyDesk with the backdoor credentials active

After step 7, the operators have persistent remote desktop access to the victim's machine. This access survives password changes on other services because the AnyDesk credentials are embedded in the local configuration file—the victim would need to specifically audit their AnyDesk installation to detect the compromise.

C2 Infrastructure

The AnyDesk RAT component communicates with a different C2 server than the credential stealer:

C2: 95.164.17.24:1224

The IP is obfuscated in the script using base64 with an 8-character rotation:

host = "LjE3LjI0OTUuMTY0"
decoded = base64.b64decode(host[8:] + host[:8]).decode()
# Result: "95.164.17.24"

The obfuscation is minimal—split the string at position 8, swap the halves, base64 decode. It defeats grep-based IOC scanning but nothing more sophisticated.

Three Campaign Variants

We recovered three variants of the AnyDesk RAT script, each identical except for the campaign identifier:

Campaign ID	Variant
5346	Primary
hkMrMq7	Secondary
team15	Tertiary

All three share the same C2 infrastructure and the same hardcoded attacker credentials. The campaign IDs match those documented across Parts I-IV, confirming this malware family is part of the same Contagious Interview operation.

Hardcoded Attacker Credentials

The script contains a PowerShell payload that injects the following credentials into the victim's AnyDesk configuration:

pwd_hash:   967adedce518105664c46e21fd4edb02270506a307ea7242fa78c1cf80baec9d
pwd_salt:   351535afd2d98b9a3a0e14905a60a345
token_salt: e43673a2a77ed68fa6e8074167350f8f

These values are written directly into the AnyDesk service.conf file, replacing whatever credentials the victim had configured. The pwd_hash and pwd_salt correspond to a password known only to the operators. The token_salt enables session token generation.

Once injected, the operators can connect to the victim's machine via AnyDesk using their known password, at any time, without the victim's knowledge. This persists across reboots, across network changes, and across credential rotations on other services. The only remediation is removing the injected credentials from the AnyDesk configuration or uninstalling AnyDesk entirely.

Implications

The AnyDesk RAT answers a question we raised in Part I: what happens after credential theft? The answer is persistent remote access. The credential stealer extracts the victim's passwords. The AnyDesk RAT ensures the operators can return to the machine whenever they want—to install additional tools, to steal new credentials as they're created, or to use the victim's machine as a proxy for further operations.

This is a complete attack chain: initial access via fake job interview, credential theft via browser stealer, persistent access via AnyDesk backdoor.

---

Act 5: Breaking Into the Operator Panel

Wave 12: CVE-2024-4577

The C2 at 146.70.253.107 runs XAMPP with Apache 2.4.58 and PHP 8.1.25 on Windows Server 2022. We identified CVE-2024-4577—a PHP-CGI argument injection vulnerability that allows remote code execution on Windows when PHP runs in CGI mode.

We tested over 100 payloads against the server.

Every one returned HTTP 500. PHP on this server runs as mod_php, not as CGI. The vulnerability does not apply to this configuration.

But the error responses were informative. The server leaked:

Detail	Value
Service account	VM-98203$ (machine account, SYSTEM context)
Backend path	C:\Users\Administrator\Documents\server2\Backend\

The server runs under a machine account in SYSTEM context and the backend application lives in the Administrator's Documents folder. These details would prove useful later.

Wave 15: Endpoint Role Mapping

A critical discovery emerged during systematic endpoint enumeration: the operator-facing endpoints exist on only one server.

The secondary servers (147.124.x.x, 66.235.x.x, and others) are victim-facing only—they accept stolen data but do not expose any management functionality. Operator endpoints for campaign management, victim data queries, and database exports exist exclusively on a single backend server.

This is strict role separation. The victim-facing servers collect data. The operator server manages campaigns, queries victim data, and exports databases. The infrastructure is layered—the hardened front-end servers documented in Part III sit in front of a fully operational backend that we had not yet reached.

Wave 21: The IDOR Breakthrough

We identified an Insecure Direct Object Reference (IDOR) vulnerability in the operator panel. An endpoint that returns victim records by campaign does not validate who is requesting the data—no session token, no API key, no authentication header, no IP allowlist.

We are withholding the specific endpoint path, parameter format, and query methodology. The vulnerability has been reported to law enforcement. Reproducing it would grant access to the personal credentials of 857 victims.

The three primary campaigns yielded over 130 MB of structured victim records. This is where the investigation shifted from statistics to individual people. A developer in Colombo, Sri Lanka—their GitHub credentials, their Google account, their Microsoft account, all in plaintext. Not an aggregate count. Not a statistical summary. A specific person whose digital identity was exposed.

We stopped extracting individual records at that point. We had enough to characterize the operation. We did not need to catalog every victim's personal details.

Waves 9 and 23: Operator Account Discovery

The operator accounts were not found through a single exploit—they emerged across two phases of the investigation.

Wave 9 (during AnyDesk RAT analysis): We discovered that certain C2 endpoints accept arbitrary identifiers—not just campaign IDs. By enumerating common values, six identifiers returned valid responses indicating active accounts. Some corresponded to campaigns with victim data. Others returned zero victim records but served malware payloads—these are operator accounts, not campaigns.

Wave 23 (confirmation): A database export endpoint further distinguished operator accounts from campaigns through differentiated error responses—valid accounts received permission denials while unknown identifiers triggered application errors that leaked the authorization model (a boolean is_admin field).

The non-numeric identifiers (yjs, Eric) suggest personal handles rather than system-generated accounts. These are the operational team managing this C2 cluster.

Six operators. 857 victims. 241,764 credentials.

---

Act 6: Decrypting the Operator's Comms

Wave 24: Breaking the Binary Protocol

The binary protocol on ports 22411-22413 had been opaque since Part I. We documented the message format, identified the XOR key 0xcb, and mapped command codes—but never recovered meaningful content. The protocol remained a black box.

In wave 24, we cracked it.

Server 66.235.168.238:22411 returns 916-byte encrypted streams on connection. The encryption is not complex, but it is layered:

Encoding: UTF-16LE (wide characters, 2 bytes per character)

Cipher: XOR with key 0x47

The key 0x47 is not arbitrary. It is the ASCII value of G—the first byte of G01d*8@(, the XOR key we recovered from BeaverTail in Part I. The operators use derivatives of the same key family across their entire infrastructure. This is the kind of operational shortcut that APT groups make when they prioritize convenience over compartmentalization.

What the Decryption Revealed

The decrypted output from 66.235.168.238:22411 contained 6,208 lines of operator beacon data spanning January 29 through February 3, 2026.

The beacons show two processes alternating in a steady rhythm:

Process	PID	Function
WINSTART.exe	9999	Session initialization
WINEXIT.exe	8888	Session teardown

The two processes alternate every approximately 10 minutes. The PIDs are hardcoded—9999 and 8888—not dynamically assigned by the OS. This is automated C2 beacon scheduling: a watchdog process that starts sessions, runs for a fixed interval, tears them down, and repeats.

The beacons also reference Z:\ drive paths—a mapped or virtual drive letter that does not correspond to standard Windows drive assignments. This is consistent with a network-mounted resource or a virtual drive used for operational data storage.

The 6-day span of continuous beacon data confirms this infrastructure is actively managed. These are not abandoned servers. Someone—or something automated—is maintaining persistent sessions on this C2 cluster as recently as three days before the publication of this article.

Key Rotation

A second key was discovered on port 22413: XOR 0x8c.

The value 0x8c is derived from the same G01d*8@( key family. Specifically, 0x47 XOR 0xcb = 0x8c—the first-byte key XORed with the binary protocol key from Part I produces the port 22413 key. The operators are generating per-port keys through deterministic derivation from a master key, not independent key selection.

This key derivation pattern means that recovering any single key from the family potentially compromises the others. We now have confirmed XOR keys for:

Key	Value	Derivation	Used On
0xcb	203	Original binary protocol key	Port 22412
0x47	71	First byte of G01d*8@(	Port 22411
0x8c	140	0x47 XOR 0xcb	Port 22413
0x5A	90	OtterCookie screenshot key	Screenshot encryption

---

Act 7: What We Built for Defenders

We converted every finding from Parts I-IV into deployable detection content.

YARA Rules: 16 Rules

Rule	Target
lazarus_tsunami_backdoor	Tsunami/XMRig payload indicators
lazarus_rat_payload	RAT module artifacts
lazarus_metamask_injector	MetaMask wallet stealer
lazarus_z238_protocol	Custom binary protocol magic bytes
lazarus_campaign_tokens	Campaign identifier patterns
lazarus_npm_package_payload	Malicious npm package patterns
lazarus_python_obfuscator	Python obfuscation layer
lazarus_fake_runtime_broker	Fake RuntimeBroker persistence
lazarus_vscode_payload_dropper	VSCode folderOpen auto-execution
lazarus_function_constructor_rce	Function constructor RCE chain
lazarus_contagious_interview_generic	Generic campaign indicators
lazarus_xor_key_0x8c_rotation	XOR key 0x8c rotation (Wave 25)
lazarus_beavertail_operator_panel_stream	916-byte operator panel telemetry
lazarus_c2_endpoint_vulnerability	C2 endpoint vulnerability exploitation
lazarus_c2_ip_146_70_253_107	Primary operator C2 indicators
lazarus_port_22413_z238_protocol	Port 22413 Z238 protocol

Snort Rules: 88 Rules

Covering:

• C2 beacon traffic on ports 1224, 1244, 5918, 5934, 5961, 5974
• Binary protocol handshakes on ports 22411-22413
• Credential exfiltration POST patterns
• AnyDesk configuration theft patterns
• AnyDesk binary download patterns
• Operator panel access patterns
• Lure domain DNS resolution
• Known C2 IP address connections
• XOR-encrypted data patterns in HTTP body
• Campaign token patterns in URL parameters

Detection Availability

The full rule packages are available to law enforcement and vetted threat intelligence partners. Contact [email protected] with your organizational affiliation for access.

---

The Honeypot Question, Resolved

Part III assigned a 70/30 probability favoring honeypot. That assessment was based on the information available at the time—the standardized servers with their perfect security posture. That assessment applied to those servers, and it still holds.

But Part III was looking at the wrong layer.

The approximately 20 standardized servers documented in Part III are the front-end infrastructure—the victim-facing data collection nodes. Their security hardening is real. Their anomalous characteristics are real. Whether they represent counter-intelligence, sophisticated operational security, or something else, we cannot say with certainty.

The operational C2—the server running the operator panel and managing campaign data—is a different story entirely. This server has an IDOR vulnerability that exposes all victim data to any unauthenticated requester. It has operator accounts discoverable through endpoint enumeration. It runs under a machine account in SYSTEM context and leaks its filesystem path in error messages.

This is the gap between the front-end and the back-end. The victim-facing infrastructure is hardened to a degree we have never seen from an APT. The operator infrastructure behind it has the kind of vulnerabilities we see in every engagement.

Two possible explanations:

1. Different teams, different standards. The infrastructure deployment team and the application development team are separate groups. The infrastructure team uses templates and automation—Infrastructure-as-Code that produces consistent, hardened servers. The application team writes the C2 backend and operator panel with less rigor. This is common in large organizations, including state-sponsored operations.

2. Deliberate prioritization. The operators hardened everything victim-facing because that is what researchers probe first. The operator panel was considered internal-only and received less attention. They did not anticipate someone enumerating campaign IDs on an endpoint they considered operational rather than public.

Either way, the data is real. You do not fabricate 241,764 credential records with internally consistent timestamps, geolocation data matching ISP assignments, localhost development server credentials that only exist on active developer workstations, and banking URLs spanning institutions across 90 countries. The effort required to generate convincing fake data at this scale exceeds the effort required to simply steal real data.

The honeypot theory is dead. The credentials are real. The victims are real.

---

Operational Timeline

Wave	Date	Activity	Key Finding
1-4	Jan 9-25	Initial discovery, malware analysis	BeaverTail, InvisibleFerret, OtterCookie
5	Jan 26	Query victim data endpoints	121 victims, first real credential data
6	Jan 27	Query additional campaigns	Scale grows to 857 victims
7	Jan 28	Credential analysis	Banking, crypto, developer platform creds
8	Jan 29	FBI IC3 filing	Reported 121 victims with banking credentials
8	Jan 29	AnyDesk RAT discovery	Fourth malware family
9	Jan 30	AnyDesk variants + operator enumeration	3 campaign variants, 6 operator accounts discovered
10-11	Jan 31	Full extraction	241,764 credentials consolidated
12	Jan 31	CVE-2024-4577 testing	Failed—mod_php, not CGI
13-14	Feb 1	Infrastructure analysis	Machine account (VM-98203$) in SYSTEM context, backend path leaked
15	Feb 1	Endpoint role mapping	Operator vs. victim server separation
16-20	Feb 1	Systematic enumeration	Campaign ID and endpoint discovery
21	Feb 1	IDOR exploitation	6 campaigns dumped, over 130 MB
22	Feb 2	Victim analysis	Individual victim records examined
23	Feb 2	Database endpoint probing	Account 15 confirmed as valid operator (vs error for unknown identifiers)
24	Feb 2	Binary protocol decryption	6,208 lines of operator beacon data
25	Feb 2	Detection content	16 YARA rules, 88 Snort rules
--	Feb 2	CISA filing	Reported full scope: 857 victims, 241,764 creds

---

MITRE ATT&CK Mapping

New Techniques (Part IV)

ID	Technique	Evidence
T1219	Remote Access Software	AnyDesk RAT deployment and backdoor
T1098	Account Manipulation	Injecting attacker credentials into AnyDesk config
T1005	Data from Local System	Full browser credential extraction
T1560	Archive Collected Data	Victim data packaged and served via C2 endpoint
T1114	Email Collection	Google account credentials (4,280)
T1530	Data from Cloud Storage	Operator panel data accessible without auth
T1552.001	Unsecured Credentials	Plaintext passwords on unauthenticated endpoints
T1087	Account Discovery	Operator account enumeration via C2 endpoints
T1071.001	Application Layer Protocol: Web	HTTP-based C2 on port 1224

Campaign-Wide (All Parts)

ID	Technique	First Observed
T1566.003	Phishing via Service	Part I (Upwork, Fiverr)
T1204.002	Malicious File	Part I (VSCode tasks)
T1027.002	Software Packing	Part I (64-layer obfuscation)
T1102.001	Dead Drop Resolver	Part I (Pastebin), Part II (Polygon), Part III (Vercel)
T1573.001	Symmetric Encryption	Part I (XOR keys)
T1573.002	Asymmetric Encryption	Part I (RSA-PSS)
T1496	Resource Hijacking	Part I (XMRig)
T1497.001	Sandbox Evasion	Part II (MAC detection), Part III (full VM detection)
T1056.001	Input Capture: Keylogging	Part III (OtterCookie)
T1113	Screen Capture	Part III (OtterCookie)
T1547.001	Registry Run Keys	Part III (OtterCookie persistence)
T1053.005	Scheduled Task	Part I (Tsunami), Part III (OtterCookie)
T1555.003	Credentials from Web Browsers	Part I (Chrome stealer), Part III (27 extensions)

---

IOC Summary

IP Addresses

IP	Port(s)	Role	Status
146.70.253.107	1224	Primary operator C2	Active
95.164.17.24	1224	AnyDesk RAT C2	Active
147.124.213.232	1244	BeaverTail victim C2	Active
147.124.212.125	1244	BeaverTail victim C2	Active
147.124.214.129	1244	BeaverTail victim C2	Active
66.235.168.238	1244, 22411-22413	BeaverTail + binary protocol	Active
45.59.163.55	1244	BeaverTail victim C2	Active
216.250.251.87	1247	BeaverTail backup	Active
172.86.105.40	5918	OtterCookie victim C2	Active
172.86.116.178	5918	OtterCookie victim C2	Active
86.106.85.234	4558	OtterCookie victim C2	Active
144.172.104.117	5918	OtterCookie victim C2	Active
144.172.101.45	1224	OtterCookie victim C2	Active
87.236.177.9	3000	BeaverTail C2 (env08539)	Active

Domains

Domain	Role	Status
elvengold.com	Lure domain	Active
email.tokenloopz.com	Lure domain	Active
tetrismic.vercel.app	OtterCookie delivery	Active
codeviewer-three.vercel.app	BeaverTail delivery	Active

Campaign Identifiers

ID	Family	Context
5346	Multi-family	Primary campaign (121 victims)
15 / team15 / dGVhbTE1	Multi-family	Secondary campaign (287 victims)
99	Credential stealer	Largest campaign (449 victims)
hkMrMq7	BeaverTail + AnyDesk	Majestic Hosting campaign
kmHgMq7	BeaverTail	Secondary token
env08539	BeaverTail	EuroHoster campaign
31df390f0305	BeaverTail	Vercel campaign

Operator Accounts

Identifier	Discovery Method
55	C2 endpoint enumeration
98	C2 endpoint enumeration
15	C2 endpoint enumeration + database confirmation
16	C2 endpoint enumeration
yjs	C2 endpoint enumeration
Eric	C2 endpoint enumeration

AnyDesk Backdoor Credentials

pwd_hash:   967adedce518105664c46e21fd4edb02270506a307ea7242fa78c1cf80baec9d
pwd_salt:   351535afd2d98b9a3a0e14905a60a345
token_salt: e43673a2a77ed68fa6e8074167350f8f

XOR Key Family (Complete)

Key	Hex	Used For
G01d*8@(	--	File encryption (BeaverTail)
0x47	0x47	Binary protocol, port 22411
0xcb	0xcb	Binary protocol, port 22412
0x8c	0x8c	Binary protocol, port 22413
0x5A	0x5A	OtterCookie screenshot encryption
Vw1aGYoP	--	Base85 layer decryption
Xt3rqfmL	--	Payl module encryption
Ze4pq4iT	--	MetaMask injector encryption

YARA Rule Names

lazarus_tsunami_backdoor
lazarus_rat_payload
lazarus_metamask_injector
lazarus_z238_protocol
lazarus_campaign_tokens
lazarus_npm_package_payload
lazarus_python_obfuscator
lazarus_fake_runtime_broker
lazarus_vscode_payload_dropper
lazarus_function_constructor_rce
lazarus_contagious_interview_generic
lazarus_xor_key_0x8c_rotation
lazarus_beavertail_operator_panel_stream
lazarus_c2_endpoint_vulnerability
lazarus_c2_ip_146_70_253_107
lazarus_port_22413_z238_protocol

---

Defensive Recommendations

Immediate Actions

If you are a developer who has participated in a coding interview involving a GitHub repository from an unknown party in the last 18 months:

1. Check your browser saved passwords. If you see entries for elvengold.com, tokenloopz.com, or any domain you do not recognize from a "job interview," assume compromise.
2. Rotate ALL saved browser passwords immediately. Start with banking and cryptocurrency.
3. Check for AnyDesk installed on your system. If present and you did not install it, remove it and audit service.conf for the credential hashes listed in this report.
4. Search for the OtterCookie persistence artifacts documented in Part III: registry key NodeHelper, scheduled task NodeUpdate.
5. Enable 2FA on every account that supports it. SMS-based 2FA is better than nothing. Hardware keys are better than SMS.

Network-Level Detection

# Block all confirmed C2 IPs
146.70.253.107
95.164.17.24
147.124.213.232
147.124.212.125
147.124.214.129
66.235.168.238
45.59.163.55
216.250.251.87
172.86.105.40
172.86.116.178
86.106.85.234
144.172.104.117
144.172.101.45
87.236.177.9

# Alert on connections to port 1224 (non-standard HTTP)
# Alert on connections to ports 22411-22413 (binary protocol)
# Alert on the 13-port configuration signature from Part III

Host-Level Detection

# AnyDesk backdoor detection
$adConfig = Get-Content "$env:ProgramData\AnyDesk\service.conf" -ErrorAction SilentlyContinue
if ($adConfig -match "967adedce518105664c46e21fd4edb02270506a307ea7242fa78c1cf80baec9d") {
    Write-Warning "COMPROMISED: AnyDesk config contains Lazarus backdoor credentials"
}

# OtterCookie persistence (from Part III)
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" |
  Where-Object { $_.NodeHelper -like "*node*" }

Get-ScheduledTask | Where-Object {
  $_.TaskName -like "*NodeUpdate*" -or
  $_.Actions.Execute -like "*node*"
}

---

A Practitioner's Perspective

We spent four articles and 25 investigation waves documenting this campaign. The technical findings matter—the malware families, the infrastructure architecture, the protocol analysis, the detection rules. But the number that will stay with us is 857.

Eight hundred fifty-seven developers opened a repository from someone they thought was offering them a job. They ran npm install or opened it in VSCode and their entire digital lives were extracted. Their banking credentials, their cryptocurrency wallets, their GitHub accounts, their Google accounts—all of it packaged and served on an unauthenticated HTTP endpoint for anyone to download.

The geographic distribution tells the human story. India, Bangladesh, Vietnam, Pakistan, Sri Lanka, Nigeria—these are developers competing for freelance work on global platforms, often in economies where a compromised bank account represents months of income. The attackers target them because they are the most likely to accept a coding test from a stranger. They are the most vulnerable, and they are the least likely to have organizational security teams watching their backs.

Part III asked whether we were hunting Lazarus or walking into a trap. The answer turned out to be: both, but it does not matter. While we were asking that question, while we were debating honeypot probabilities and counter-intelligence theories, 857 developers were losing their credentials, their banking access, and their cryptocurrency. The infrastructure we spent weeks analyzing was actively stealing from real people.

That is why we reported to the FBI and CISA before we had the complete picture. That is why we published IOCs before we finished the analysis. And that is why this article exists: because the detection rules in this series can prevent the 858th victim.

For organizations hiring remote developers: the Contagious Interview campaign has been running for at least 18 months. It targets the same freelancing platforms you use to source talent. Implement repository vetting. Disable VSCode auto-execution. Review package.json scripts. These are not theoretical recommendations—they are the specific mitigations that would have prevented 857 compromises.

For the threat intelligence community: the 16 YARA rules and 88 Snort rules are available. The IOCs are in this report. The MITRE ATT&CK mappings are complete. Use them.

For the 857: we are sorry we did not find this sooner.

---

How Red Asgard Can Help

Red Asgard Security provides offensive security services, threat intelligence, and AI security assessments to organizations that operate in high-threat environments. Our expertise spans penetration testing, malware analysis, APT investigation, and security research.

Services:

• Offensive Security & Penetration Testing
• Threat Intelligence & APT Tracking
• AI/ML Security Assessment
• Contractor Code Review & Supply Chain Security
• Incident Response Support

This investigation originated from our freelancer code vetting practice—a service we offer to organizations that outsource development work. If you're outsourcing development work—especially in crypto or Web3—we'd welcome the opportunity to discuss your security posture.

Contact: [email protected]

---

References

1. Part I: Hunting Lazarus—Inside the Contagious Interview C2 Infrastructure
2. Part II: When the Dead Drop Moved to the Blockchain
3. Part III: The Infrastructure That Was Too Perfect
4. SentinelOne: Contagious Interview: North Korean Threat Actors Scout Cyber Intel Platforms
5. Sekoia: ClickFake Interview Campaign by Lazarus
6. MITRE ATT&CK: Contagious Interview (G1052)
7. Unit42: Two Campaigns by North Korea-Linked Bad Actors
8. Rewterz: Lazarus Group OtterCookie Advisory (May 2024)
9. FBI IC3: Internet Crime Complaint Center
10. CISA: Cybersecurity and Infrastructure Security Agency

---

TLP: WHITE—Disclosure is not limited. Information may be distributed freely.