One Key, Six Names: The Operator's Signature Across Four Months

The Raspberry Worm — Part 4

Classification: HIGH · Confidence: HIGH (first-party sample corpus analysis)

Part 3 ended with a claim and a promise. The claim was that the operator's 1024-bit RSA command-signing key — the public half of which every sample drops as /tmp/public.pem — is the strongest correlator this investigation holds, because unlike an IP or a domain it is durable and operator-bound: any sample anywhere bearing this key is commanded by the same hand. The promise, implicit, was that the claim was testable. This letter tests it, by running the key across the honeypot's entire retained-sample corpus and asking a simple question: how many of the captured samples carry it?

The answer is thirteen. And what those thirteen turn out to be — captured over four unbroken months, byte-for-byte carrying the same C2 configuration, and yet filed by the automated classifier under six different family names — is both a vindication of the key as a correlator and a small, sharp lesson in why the way we usually name malware fails.

Thirteen samples, one key

Searching every retained script and binary in the corpus for the operator's public key returns thirteen samples, and their consistency is total where it matters. Every one is 4,745 bytes. Every one connects to UnderNet via the same six-server round-robin array of Part 3. Every one joins #biret. Every one ships the identical RSA public key beginning MIGfMA0GCSqG…. Every one sinkholes the same parent-lineage domain, bins.deutschland-zahlung.eu. On every axis that defines who runs this and how it is controlled, the thirteen are one thing.

They are not, however, identical files — their SHA-256 hashes all differ. Same size, same configuration, same key, different hash: that combination has one ordinary explanation, and it matters for defence. The operator is rebuilding the worm between drops — regenerating the script so each delivered copy is a fresh file with a novel hash while its structure, its C2, and its key stay fixed. It is the malware equivalent of reprinting the same letter on different paper: the words are unchanged, but a system that files mail by the paper's fingerprint sees thirteen unrelated documents. This is precisely why hash-based blocklists — the reflexive first IOC of any malware report — are nearly worthless against this worm: thirteen captures produced thirteen hashes, and the fourteenth drop will produce a fourteenth. The hash identifies a file. The key identifies the operator, and the operator did not change.

The four-month campaign the hashes hid

Line the thirteen up by first capture and a campaign resolves that no single sample could show:

From late March to mid-July — and, counting the last redrop of the April sample, out to 2026-07-22 — the operator delivered a fresh build into this one honeypot's narrow window roughly once every one to two weeks, without a gap longer than about three, for four straight months. That cadence is the signature of a maintained operation, not a smash-and-grab: someone is tending this worm, rebuilding it on a schedule, keeping the brood fed with new copies. A single captured sample reads as an incident. Thirteen, spaced evenly across a third of a year and provably the same operator, read as a job — something run with the regularity of a cron entry, which for all we can tell it is.

None of that timeline is visible if you trust the labels. It only appears once the key collapses thirteen "different" samples into the one campaign they always were.

The builds do not retire

The cadence table shows when each build was first seen, but two of the thirteen carry a longer story in their last-seen dates, and it refines the picture of how the campaign runs. The build first captured on 2026-03-25 was still being dropped on 2026-05-26 — two months later. The build first captured on 2026-04-23 was still arriving on 2026-07-22 — three months on, the day these letters were written. So the operator does not replace the old worm when it ships a new one; old and new builds circulate simultaneously. At any given moment in the campaign, the brood in the field is a mix of generations — a March build still spreading itself while a June build spreads alongside it, both signed into the same #biret, both obeying the same key.

That overlap tells you something about the propagation model that the single-sample view of Part 1 could not. Because the worm is self-propagating — each victim scp-pushes its own copy onward (Part 2) — a build does not need the operator to keep dropping it to stay alive. Once released, it reproduces on its own, and keeps reproducing whatever version it happens to be, until the host is cleaned or re-infected by a newer copy. The operator's periodic fresh builds are not replacements; they are new seed stock injected into a population that is already self-sustaining. The result is a botnet that is heterogeneous in build and homogeneous in control: a dozen slightly-different scripts, all reporting to one channel, authenticated by one key. It is, once again, the key and the channel — not the file — that define the thing, because the files are a moving, overlapping, self-reproducing population and only the control plane holds still.

Six names for one worm

Now the labels themselves, because they are the lesson. The automated classifier — a competent, behaviour-and-string-based system — assigned these thirteen byte-consistent, same-key samples six different family names: IRC Botnet Loader, IRC Botnet Dropper, IRC Bot Backdoor, IRC botnet loader (it could not even hold its own casing steady), Bins, and — four times — XMRig.

The IRC-flavoured labels are forgivable disagreements about emphasis: loader, dropper, backdoor, and bot are all true of a worm that loads a bot, drops a backdoor, and takes commands. But XMRig is not a shade of emphasis. XMRig is a cryptocurrency miner — a specific, well-known one — and this worm is not a miner. It is, if anything, a miner's predator: Part 2 documented its killall block terminating minerd, cpuminer, and the ktx-* binaries, and its rm -rf of /tmp/cpuminer-multi. The classifier saw those mining-related strings — the names of miners the worm hunts — and concluded the sample was a miner. It mistook the predator for its prey, four times, because the predator carries its prey's name in order to find it.

This is the failure mode of content-based classification stated in one clean example: a system that names malware by the strings and behaviours it exhibits can be inverted by malware that exhibits the strings of the thing it opposes. The worm's competitor-killing — a hostile act against miners — is indistinguishable, to a string matcher, from a miner's own self-reference. And so the single most confidently-wrong label in the set is applied to the samples where the anti-mining behaviour is most prominent. The classifier is not incompetent; it is looking at the only thing surface analysis can look at — content — and content is exactly what this worm is happy to muddy.

The key looks at something else entirely. It does not care what strings the sample carries or what it claims to do. It asks one question — is this signed into the same botnet? — and the answer is cryptographic, binary, and un-gameable. Where the Recidivists series spent nine letters warning that a shared artifact is not a shared operator — a shared OTX pulse, a shared cloud ASN, a shared default password proving nothing about coordination — this is the artifact that inverts the warning. A shared command-signing key is not incidental co-location; it is the literal root of the botnet's authority, the one thing the operator cannot share without sharing control. It is the rarest kind of malware artifact: one that means exactly what it appears to mean.

Hiding among the things it kills

The mislabelling is not only a classifier quirk; it reflects the worm's real ecological position, and the honeypot's wider catch shows the ecosystem it hides in. The same corpus that holds these thirteen worm samples holds, by the classifier's count, thirty-seven XMRig samples and eleven RedTail samples — genuine cryptominers and mining botnets — alongside a thicket of PAM backdoors, SSH-key implants, and loaders. The honeypot is not watching one worm; it is watching a market, and mining is the market's dominant product. Most of what walks into a Linux honeypot and runs is there, ultimately, to mine.

The Raspberry Worm's whole competitive strategy is to enter that market as a spoiler: take the host, evict the miners already on it, and hold it — whether to mine itself later, to rent out, or simply to deny to rivals, the architecture of Part 3 leaves open. But the consequence for analysis is that the worm swims in a sea of miners, doing miner-adjacent things (killing them, referencing them, competing for the same hosts), and a classifier sorting that sea by content will inevitably wash some of the worm into the miner pile. The four XMRig-labelled samples are the worm caught mid-camouflage — not disguising itself deliberately, but naturally blending into the category it preys on, the way a wolf's stomach contents look a lot like a sheep's. The key is the DNA test that tells them apart.

The rest of that market is worth a moment, because it is the backdrop the whole series plays against. Beyond the miners, the honeypot's catch is dominated by a second theme: persistence implants — a dense cluster of PAM backdoors, SSH-PAM session handlers, credential manipulators, and SSH-key droppers, better than a dozen distinct samples whose entire purpose is to survive a reboot and keep a door open. Where the miners are there to spend a host's resources and the worm is there to hold the host, this third category is there to keep the host — the quiet layer of malware that does nothing dramatic and simply ensures the intruder can always come back. A Linux honeypot, seen through its retained samples, is therefore a three-cornered market: something to mine with (XMRig, RedTail), something to control with (the IRC worm), and something to persist with (the PAM and SSH-key backdoors), often layered on the same compromised host by different actors who each want it for a different reason. The Raspberry Worm's killall and password-lock are its attempt to win that three-way contest outright — to be the only one of the three left standing on any host it takes.

A ranking of correlators

Step back from this worm and the whole exercise suggests a general ordering — a ranking of the artifacts an analyst can correlate on, by the one property that matters: how expensive it is for the operator to change. The cheaper an artifact is to change, the weaker it is as a correlator, because the operator will change it the moment it becomes a liability. The thirteen samples map the ranking cleanly:

• Content and family label — weakest. Free to change, and worse than free: as the four XMRig verdicts show, an attacker can actively invert it by carrying the strings of something it opposes. A label is a hypothesis about a file, generated from exactly the surface the attacker controls.
• File hash — nearly as weak. Costs one rebuild to change, and this operator changes it every drop. A hash proves two captures are the same file, which for self-mutating malware is almost never the useful question.
• IP address — weak-to-moderate. Costs a new server or a rotated botnet node; the Recidivists series is a long study of how cheaply attackers rotate these, and how a per-address counter mistakes a rotating adversary for a crowd of strangers.
• Domain — moderate. Costs a registration and, if sinkholed, an abandonment — which is exactly why this worm's parent abandoned deutschland-zahlung.eu and this fork moved to a public network it need never register.
• Control channel — strong. The #biret/UnderNet rendezvous costs the operator its entire installed base to change, because every existing bot is hardcoded to it. Strong, but not maximal: a channel name is a string, and a sufficiently motivated operator could migrate the brood with a signed command.
• Signing key — strongest. The RSA keypair is the botnet's cryptographic root of authority. To change it, the operator must re-key every bot — and cannot do so without first commanding them with the old key, so the old key remains the correlator right up to the moment of migration. It is the one artifact the operator cannot cheaply change and cannot fake, because possession of the private half is the definition of control.

The practical instruction falls straight out of the ordering: correlate as high on that list as the evidence allows, and treat everything below it as perishable. Most malefactor-tracking effort, by habit and by tooling, clusters at the bottom — hashes and IPs and labels — precisely where the ground shifts fastest. This worm is a clean argument for inverting that habit: the same four months that produced thirteen useless hashes produced one durable key, and the key did all the work.

What this buys a defender

What this buys a defender

The practical yield of the correlator is a reordering of which IOCs are worth keeping, and it runs against instinct.

Demote the hashes. Thirteen captures, thirteen hashes, and a fourteenth coming: a hash blocklist against this worm is a treadmill that never catches up, because the operator reprints on fresh paper every drop. Publishing the thirteen hashes as the headline IOC — the default of most malware write-ups — would be publishing thirteen things already stale.

Promote the key and the channel. The RSA public key and the #biret/UnderNet channel are the IOCs that hold across the whole campaign, because changing them means re-deploying to every existing bot and abandoning the installed base. Detection and correlation should key on those: a sample dropping this public.pem, or a host connecting to UnderNet and joining #biret, is this operator with a confidence no hash can offer. This is the general lesson the specific worm teaches — correlate on what the operator cannot cheaply change, not on what they change every drop. The file is disposable; the botnet's cryptographic root is not.

Trust the label last. The four-times-wrong XMRig verdict is a standing reminder that an automated family name is a hypothesis, not a fact, and that the more a sample's behaviour resembles the thing it fights, the less the label can be trusted. Where a durable operator artifact exists — a key, a channel, a signing identity — it outranks the family label every time.

What holds, and what is bounded

What holds, first-party: the thirteen samples, their common 4,745-byte size, their shared RSA public key, their shared UnderNet/#biret C2, their shared parent-sinkhole, and their distinct hashes — all read directly from the retained corpus. The four-month cadence is a count of first-seen dates, not an inference. The six divergent family labels, including the four XMRig verdicts, are the classifier's own recorded output, reproduced here, not a characterisation.

What is bounded: this is one honeypot's window. Thirteen is the number of this operator's samples this sensor happened to retain; the true campaign is certainly larger, spread across countless perimeters this investigation cannot see. The key would correlate those too, if they were in hand — which is the point of publishing it — but their count is unknown and unclaimed. Equally, absence of the key in a sample proves only that that sample is not signed into this botnet, not that it is unrelated to the lineage; a relative that re-keyed would fall outside this correlator by design.

What is not claimed: the person. The key is the operator's cryptographic identity to the brood and the strongest thread this series holds, but it is pseudonymous. It says the same hand built and controls all thirteen; it does not say whose hand. That remains, as it has since Part 1, a thread for other perimeters holding this key and for the entity graph — not a name this letter can honestly write.

Core IOCs

• Durable operator correlator (the primary IOC): 1024-bit RSA command-signing public key, MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/ihTe2DLmG9huBi9DsCJ90MJs…WRq+Z8HYMvPlgSRA3wIDAQAB, dropped as /tmp/public.pem.
• C2 (durable): UnderNet public IRC, channel #biret, port 6667, six-server round-robin (Part 3).
• Campaign span: 2026-03-25 → 2026-07-22, thirteen retained builds, ~biweekly cadence.
• Build fingerprint: consistent 4,745-byte script; per-drop hash mutation (hash-based IOCs unreliable by design).
• Sample set (this sensor): 6d1fe6ab…, 1ece1d43…, 595a0565…, ef5c9406…, e0b2f2ee…, 9cbbeb3f…, 783565ad…, f88e93f1…, b3d1bcd1…, d946dbc5…, 603dd856…, e53619ba…, b4c8f6e4… (all carrying the key above).
• Classifier caveat: four of the thirteen are auto-labelled XMRig (a miner); this is a content-classification artifact — the worm hunts miners, it is not one.

Cross-references

• TI-2026-087C — The Channel: the operator RSA key and UnderNet #biret C2 this letter ran across the corpus.
• TI-2026-087B — The Self-Made Botnet: the competitor-killing behaviour that fooled the classifier into four XMRig verdicts.
• TI-2026-089C / 089I — The Familiar Faces / The Counterfeit Crawlers: the shared-artifact attribution discipline this letter inverts — the rare artifact (a signing key) that does prove a common operator.

The promise of Part 3 was that the key would prove testable. Tested, it did more than confirm a single worm's C2: it reassembled a four-month campaign that automated classification had scattered into six unrelated-looking families, and corrected the specific, confident error of calling a miner-killer a miner. The file the operator sends changes with every drop; the label a scanner assigns changes with the wind. The one thing that did not change in four months is the key — and in a discipline that spends most of its effort deciding which coincidences are meaningful, an artifact that means exactly what it says is worth more than any number of hashes.