MuddyWater Loader Skips DNS, Curls Straight to a Bare IP

Curl to a Bare IP: The C2 Pattern That Skips DNS Entirely

A Windows loader flagged as trojan.donut/dump by 57 of 75 engines is issuing outbound HTTP requests with a curl-style user agent straight to a numeric IP address rather than a resolved domain — a pattern four separate community intrusion-detection rules independently caught on the same sample. The same binary checks the CPU timer before running, a classic sandbox-timing test, and loads additional modules only after that check clears. Paired against a single piece of network infrastructure — a Dutch-hosted IP carrying a certificate valid for just 37 days with issuer and subject names that read like they came out of a string generator — the picture is of an operator who put more engineering into evading analysis than into building durable infrastructure.

The file in question (9b8d513298fdc3…) is a 7,109-kilobyte Win32 executable first seen in circulation in September 2020 and still being resubmitted as recently as May 2026, picked up under the aliases donut, dump, and marte — names that point directly at the open-source donut shellcode-conversion toolkit, which turns .NET assemblies or native PE payloads into position-independent shellcode for file-less, in-memory execution. That lineage matters for how the rest of the chain reads: a donut-style loader does not commit a full second-stage binary to disk. It pulls in what it needs at runtime and runs it in memory, which is precisely what the sample's own behavioural tag — "loads additional modules at runtime" — describes. Yomi Hunter's sandbox run calls the file outright malicious; a second sandbox, DAS-Security Orcas, returned a clean verdict on the same artifact, an evasion-consistent split rather than a contradiction, since a timing-aware loader is built to behave differently depending on whether it detects an analysis environment.

That CPU-timer check is the load-bearing piece of the defense-evasion layer here, and it maps to a specific technique class rather than generic "anti-analysis" — reading the processor clock directly to infer whether execution is being throttled or virtualized sits under time-based sandbox evasion [T1497.003]. Layered on top of the modular execution behaviour [T1129] and the process-injection posture implied by the donut label itself [T1055], the sample reads as shellcode tradecraft built for one purpose: survive the first thirty seconds inside a detonation sandbox long enough that automated triage waves it through, and only unpack its real behaviour once it believes it is on a live endpoint. From inside a SOC, that timing gate is exactly why this kind of loader tends to arrive at the analyst's desk with a shrug — the automated sandbox says "clean" or "low confidence," the file sits in a queue, and by the time a human opens it the CPU-timer check has already done its job of buying the operator a quiet window.

What a Curl User-Agent Buys — and What It Costs

The command-and-control layer is where the four IDS rule hits do the real talking: ET POLICY curl User-Agent Outbound, ET HUNTING curl User-Agent to Dotted Quad, TGI HUNT Curl to IP Address, and POLICY-OTHER HTTP request by IPv4 address attempt all fire on the same binary. Read together rather than individually, they describe one specific choice — the malware issues its HTTP callouts using a curl-style user agent, and it addresses those requests to a raw dotted-quad IP literal instead of a domain name. That is a deliberate trade. Skipping DNS resolution removes an entire telemetry layer that defenders lean on heavily: passive DNS logging, DNS sinkholing, domain-reputation blocklists, and DGA-detection tooling all become irrelevant if the malware never asks a resolver anything. The cost is durability. An IP-literal C2 channel is brittle — the operator cannot rotate infrastructure by simply repointing a DNS record, and if the hosting provider pulls the address, the entire channel dies with it, no fallback domain to fail over to.

That brittleness is consistent with what the connected infrastructure evidence shows, even though the catalog does not carry a direct resolution or connection log tying this specific file to this specific address — the link here is behavioural rather than confirmed, and should be read as such. The one IP indicator present in this record, 185.183.98.242, sits on AS60117, registered to Host Sailor Ltd out of the Netherlands under the 185.183.98.0/24 block, and currently returns 11 of 89 engines flagging it as malicious. Its most recent TLS certificate is valid from 2026-07-30 to 2026-09-05 — a 37-day window — with an issuer common name of www.5n5v5ydbvipc3vxbc6w.com and a subject common name of www.czkad4p2qeozglked.net. Neither string resembles a brand, a service, or anything a legitimate operator would register; both look machine-generated, and a certificate that short-lived paired with names that arbitrary is a signature of throwaway TLS infrastructure stood up specifically to be discarded, not of an ongoing hosted service. Whether or not this precise address is the loader's live callout point, it demonstrates the kind of node this operator is willing to burn through.

That single indicator also sets a hard limit on how far the infrastructure story can be pushed. AS60117 appears nowhere else in this record — no sibling IP, no shared certificate serial with another node, no registrar overlap to a domain, because no domains were populated for this record at all despite the underlying threat metadata declaring one URL indicator. That absence is itself informative rather than a gap to apologize for: a bare-IP C2 channel with no domain layer leaves no registration trail, no WHOIS history to mine, and no certificate-transparency log tying it to sibling infrastructure — which is structurally exactly what an operator wants if the goal is to frustrate the kind of infrastructure-pivoting that usually cracks a campaign open. The data here supports one throwaway node, not a hosting cluster, and treating it as anything more would overstate what a single ASN observation can carry.

A Companion PDF That Shares a Date but Not a Fingerprint

Sitting alongside the loader in this record is a 46-kilobyte PDF (39900c467e38…) that returned zero detections across 73 engines and a clean verdict from the Zenbox sandbox — on its face, an entirely unremarkable document. What makes it worth mentioning at all is that its behavioural tags describe a file that waits for user interaction before running and then enumerates network adapters once it does, and that it carries the identical first-seen date, September 2, 2020, as the donut loader. Coincidental co-submission on the same day is a weak signal on its own, and no shared hash, imphash, or other build-linkage indicator in this record ties the two files together directly — there is no confirmed delivery chain here. What the pairing is consistent with, without confirming it, is a document-based lure sitting in front of a loader: a PDF that behaves passively until a user opens it, then quietly checks what network interfaces are available, is a plausible reconnaissance step ahead of a payload drop, but the input does not establish that this specific PDF performed that role for this specific loader.

A third file listed in the same record, 564cd96eda91e0…, carries no dossier data at all — no detection ratio, no behavioural tags, nothing that would let an analyst characterize it one way or the other. It is worth naming only to be honest about what this record does and does not support: three files were catalogued, one of them (the loader) is well-evidenced, one (the PDF) is thinly evidenced but analytically suggestive, and one is functionally a blank. That distribution matters for how much weight the rest of this article can bear — this is a strong single artifact sitting inside an otherwise sparse record, not a fully-mapped campaign.

Signing, Packing, and What's Missing From the Build

Neither the loader nor the PDF carries any code-signing certificate — both come back unsigned, which forecloses the usual signer-cohort approach to linking this sample to sibling malware through a shared Authenticode identity. The loader's import-table hash is present (ea5930d320dcba3bcc8177d28420a4b8), but with no second signed or imphash-bearing peer in this record to compare it against, it functions here as a fingerprint for future matching rather than as proof of a build cohort today. Its .text section registers entropy at 5.96 — elevated, but well short of the 7.5-plus range typical of heavily packed or encrypted payloads, suggesting the bulk of the loader's logic sits closer to the surface than a maximally obfuscated dropper would allow. That is a small but real tell: an operator investing heavily in runtime evasion (the CPU-timer check, the DNS-skipping C2) did not correspondingly invest in defeating static analysis of the outer executable itself, which is the kind of asymmetric effort allocation that shows up when a team optimizes for automated triage evasion over a determined human reverse engineer.

For a defender building detection logic against this specific loader, the absence of any code-signing certificate means Authenticode-based allowlisting offers no protection here — this is a plain unsigned Win32 binary that has to be caught on behaviour or hash, not on a broken or stolen signing chain. The .text entropy reading of 5.96 also matters operationally: entropy-threshold heuristics tuned to flag packed payloads above roughly 7.0 will pass this file through untouched, so a detection strategy built solely around packer-entropy scoring would miss it entirely, leaving the CPU-timer check and the curl-to-IP traffic pattern as the more reliable detection surfaces this record actually supports.

MuddyWater's Alias Sprawl, in Brief

The record ties this activity to MuddyWater, listed here under the aliases TEMP.Zagros, Seedworm, Static Kitten, Mercury, and Mango Sandstorm — a five-name spread that is itself a familiar artifact of how differently multiple security vendors have independently tracked the same espionage-motivated cluster over time, rather than evidence of five distinct groups. The record's own motivation tag reads espionage, and the tradecraft on display here — in-memory loader execution, a sandbox-timing gate, and disposable C2 infrastructure with no persistent domain footprint — fits a covert, low-signature collection posture rather than a smash-and-grab financial operation. Beyond that alias list and motivation tag, this record does not carry the kind of historical campaign detail that would support a longer discussion of the actor's evolution, and stretching a five-name alias table into an attribution narrative would claim more than the evidence here actually gives.

The record's declared MITRE technique list runs past two dozen entries, including indicator-removal and defense-impairment techniques such as T1070 and T1562, yet only a handful of those are actually evidenced in this record's file-level telemetry — the CPU-timer check, the modular runtime loading, and the curl-to-IP callouts. One reading is that this gap reflects a generic actor-level technique profile attached to the MuddyWater label rather than campaign-specific behaviour observed in this particular sample, and that reading is preferable to treating the full technique list as confirmed tradecraft for this file: a single loader with no companion log-tampering or token-manipulation artifact in the dossier cannot itself demonstrate persistence or defense-impairment techniques that the broader actor profile carries in from unrelated campaigns.

Thin Data, Disciplined Tradecraft

It's worth being direct about how much this record can bear before drawing a conclusion from it: the overall confidence score attached to this indicator set sits at 25 out of 100, driven by the fact that neither file carries signing information and only one of the two carries an imphash, and by the single-IP, single-ASN infrastructure footprint that cannot be generalized into a hosting pattern. The declared targeting region — China — arrives with no accompanying industry tag, which leaves the who-gets-hit question here largely unanswered rather than narrowly documented; the technique combination itself — document-gated execution, in-memory module loading, DNS-bypassing C2 — is generic enough to work against essentially any Windows endpoint reachable by a lure, regardless of sector.

What the record does support, cautiously, is a read on operator priorities: this is a case where the tradecraft evidence is considerably stronger and more specific than the infrastructure evidence, and that imbalance is itself a finding. An operator who skips DNS to deny defenders a resolution trail, builds in a timing check specifically to stall automated detonation, and burns a certificate with algorithmically-generated common names inside a five-week validity window is not investing in infrastructure that survives scrutiny — it is investing in infrastructure that dies quietly and gets replaced. That is a lower-cost, higher-churn model than the persistent, multi-domain hosting clusters more heavily resourced operators tend to build, and it trades resilience for disposability on purpose. Whether the Host Sailor Ltd node examined here belongs to a larger rotation of similarly disposable addresses or really was used once and abandoned is not something this single record can settle — what it does establish is that whoever is running this loader has clearly decided that a callout point worth keeping is a callout point worth being traced, and has chosen not to keep one.