Half the Honeypot: One Toolkit Wearing Ten Names

The Toolkit — Part 3

Classification: HIGH · Confidence: HIGH (first-party corpus measurement)

The first two letters identified the toolkit and dissected its mining. This one measures it, and the measurement is the finding — a single number that reorganises what the honeypot's entire malware picture actually is. Scanning every retained sample in the corpus for the toolkit's build hash returns a result that is hard to overstate: forty-two of the estate's eighty-one retained malware samples — fifty-two percent — are this one toolkit. More than half of everything serious the honeypot has caught in four months is one operator's Go platform, and the classifier had scattered it across ten different family names.

The honeypot does not have a malware problem composed of dozens of distinct threats. It has, overwhelmingly, one threat, deduplicated by a build hash from the ten masks a content-classifier gave it, sitting beneath a short tail of everything else. This letter is that census — the true footprint of the dominant tenant, and what its dominance means for how anyone counts the adversaries in a body of malware.

Fifty-two percent, ten labels

The count is exact. Of eighty-one retained samples in the honeypot's corpus, forty-two carry the cgo package hash eba3282b571c — the build fingerprint established in Part 1 as this toolkit's unforgeable identity. Those forty-two were filed by the automated classifier under ten separate family labels:

Ten names, one codebase. A threat-intelligence report built on the classifier's labels would describe this honeypot as hosting a dominant XMRig mining problem plus a scattering of nine distinct PAM and SSH backdoor families — ten separate things to track, attribute, and defend against. The build hash collapses all ten into a single operator's toolkit, compiled with different capabilities foregrounded: thirty-two builds with the mining preset prominent (labelled XMRig), ten builds with the credential-and-persistence machinery prominent (labelled as one PAM or SSH backdoor variant or another). The apparent diversity was never real. It was the shadow one modular platform casts when a classifier reads it ten times and names each shadow separately.

Persistence, split by capability

The forty-two are not identical builds, and the way they differ reveals engineering discipline that a single-sample view could never show. Sort them by whether they carry the systemd-service persistence marker WantedBy=multi-user.target, and the split is perfectly clean along the capability line: all thirty-two mining builds carry it; none of the ten backdoor builds do.

That is not an accident; it is purpose-matched persistence. A miner must survive reboots to keep earning, so the mining builds install themselves as a systemd service — the durable, boot-persistent mechanism that restarts the miner every time the host comes up. A credential backdoor does not need its own service, because it persists by a different and quieter route: the PAM and SSH hooks of Part 1 embed the backdoor into the host's existing authentication stack, which already runs on every login, so a separate service would be redundant noise that only raises the backdoor's profile. The operator gave each capability the persistence appropriate to it — loud and durable for the miner that must always run, silent and embedded for the backdoor that must never be noticed. One codebase, two persistence strategies, each matched to what its foregrounded capability requires. This is the same tailoring the dual-miner presets of Part 2 showed at the mining layer, now visible at the persistence layer: a toolkit built by someone who thinks about each capability's operational needs separately and configures accordingly.

The software engineering of a criminal platform

Assemble the design decisions this series has documented and a portrait emerges that is worth naming directly: the toolkit is not a script, it is a software product, built with the discipline of a real engineering effort. Consider what the forty-two samples, read together, reveal about how it was made. It has a presets system (Part 2) — a configuration layer, current_preset_<capability>_*, that turns whole capabilities on and points them somewhere, which is how professional software separates configuration from code. It has hardware adaptation — the dual XMRig/NBMiner selection that mines each host the most profitable way its silicon allows. It has purpose-matched persistence — systemd for the miner, authentication-stack hooks for the backdoor, each capability given the persistence its operational needs require. It has externalised secrets — the pool and wallet held in server-side config, not baked into the binary, exactly as a well-architected system keeps credentials out of source. And under all forty-two builds, across four months and ten labels, runs one consistent build pipeline, stamping the same eba3282b571c package hash on every output — the signature of a maintained codebase compiled repeatedly from one tree.

Each of those is an ordinary practice in legitimate software development, and their presence together in a piece of malware is the tell of a resourced, maintained project rather than a one-off. Someone is treating this toolkit the way a company treats a product: a modular architecture, a configuration system, a build pipeline, a release cadence, capability modules added and refined over months. That implies an operator — possibly more than one person — with real development skill and the sustained investment to maintain a platform, not a downloader of someone else's kit. It is the opposite end of the craft spectrum from the bash worm, which inherited nine-year-old code and changed a password. And it matters for how seriously the threat is taken: a defender facing a maintained software platform is facing an adversary who can and will iterate — add capabilities, rotate infrastructure, fix what a defender catches — in a way a static, inherited script never can. The forty-two samples are not forty-two attacks. They are forty-two releases of one product, and the product is still shipping.

Four months, without a gap

The forty-two samples span 2026-03-24 to 2026-07-22 — the entire window of the honeypot's observation, from the earliest retained sample of this family to the day these letters were written — and they arrive throughout it, not in a burst. Reading the timeline, the toolkit's builds land in nearly every week of the four months: two backdoor droppers open the campaign on 24 March, the miners begin two days later, and from there a steady cadence of both build types continues through April, May, June, and into late July, the primary miner build alone redropping repeatedly across the whole span. This is not a campaign that happened; it is a campaign that is happening, continuously, the dominant persistent presence at this sensor for as long as the sensor has been watching.

Set that against the other half of the corpus and the estate's real threat structure resolves. The remaining thirty-nine samples — the other forty-eight percent — are the genuinely diverse tail: the crude bash Raspberry Worm and its handful of key-matched builds, the RedTail mining botnet, the Whisper and Nexus multi-architecture DDoS loaders, a scattering of unrelated droppers and utilities. Those are many operators, each with a modest footprint. And then there is the toolkit: one operator, fifty-two percent, four unbroken months. The honeypot's malware population is not a flat field of dozens of equal threats. It is one dominant operator and a long tail — the shape of a market with a single major player and many minor ones, which is a very different thing to defend against, and a very different thing to report, than "twelve families observed."

Two giants, opposite poles

The honeypot's two largest presences, set side by side, are almost a designed experiment in the range of what malware can be — because they are as different as two dominant operators could possibly be, and yet both thrive at the same door. The bash Raspberry Worm is the crude pole: a four-thousand-byte text script, a fork of a nine-year-old worm, single-purpose, spreading by guessing one default password, holding hosts with a loud password-lock, commanded in cleartext over a public IRC channel it does not own. This Go toolkit is the sophisticated pole: a thirty-megabyte compiled platform, original engineering, multi-purpose, spreading by stealing trust, holding hosts with quiet authentication hooks, commanded over encrypted HTTP with server-side config. On every axis — language, size, originality, propagation, persistence, C2 — they are opposites, and between them they account for a large fraction of everything the honeypot catches.

That both poles dominate at once says something about the market they share. It is not a market that selects for one kind of craft; it rewards the crude worm and the sophisticated platform simultaneously, because they are exploiting the same weakness — under-defended Linux hosts with weak credentials — by different strategies that both work. The worm wins by volume and simplicity: it is everywhere because it is trivial to run and the default password is everywhere. The toolkit wins by depth and flexibility: it extracts more from each host and reaches the valuable interior the worm cannot, at the cost of the engineering to build it. Neither strategy beats the other; they occupy different niches in the same ecosystem, the way a weed and a specialist predator both thrive in a neglected field. A defender who pictures "the threat to cheap Linux devices" as one kind of adversary — either the script-kiddie worm or the sophisticated actor — is wrong twice: the honeypot's evidence is that its two biggest tenants are both, the crudest and the most refined, working the same ground with opposite tools, and both succeeding because the ground itself never got harder to work.

The illusion the family label sells

The deepest consequence of this measurement is methodological, and it is worth stating plainly because it generalises far beyond this one honeypot. Family-label counts massively overcount operators. A corpus that a content-classifier describes as containing a dozen families — an XMRig campaign, several PAM backdoors, a handful of SSH implants — is, when deduplicated by build identity, one operator wearing most of those labels plus a few others wearing the rest. The number a defender's tooling reports as "distinct threats" is inflated, here by roughly a factor of ten on the toolkit alone, by the simple fact that a modular platform surfaces different strings in different builds and a classifier names each string-profile as its own family.

This is the same lesson every durable-correlator finding in this and the companion series has taught, now stated as a general warning about counting. The worm was one operator behind thirteen file hashes and six family labels (its fourth letter). This toolkit is one operator behind forty-two samples and ten family labels. In both cases the inflation runs the same direction — the label-count is far larger than the operator-count — and in both cases the correction comes from the same place: an artifact the operator could not externalise or vary, read across the whole corpus. A threat-intelligence practice that counts families and calls the number "adversaries" is counting masks and calling it faces. The honest count of serious operators at this honeypot is not twelve; it is a small handful, one of them responsible for half of everything, and the rest sharing the tail. The classifier's ten toolkit-labels are not ten adversaries. They are one adversary, photographed ten times, from angles that happened to catch different features of the same modular tool.

Deduplicate before you count

The methodological finding turns into a concrete practice, and it is the practical deliverable of this letter. Before a defender counts operators in a body of malware, prioritises which threats to chase, or reports how many adversaries a sensor sees, they should deduplicate the corpus by durable build artifact — and only then count. The family label is a starting hypothesis about a single sample, not a census of operators, and treating label-counts as adversary-counts inflates the threat picture by whatever factor the dominant operators' modularity happens to produce — here, tenfold on the toolkit alone.

The operation is not exotic. It is the same move that has recurred through every letter of this and the companion series, made routine: extract, from each sample, the one artifact its author could not cheaply vary — a cgo package hash for a Go toolkit, an RSA signing key for a bash worm, a TLS certificate or a code-signing identity or a distinctive mutex for other families — and cluster the corpus by that artifact before doing anything else with it. Samples that share the durable artifact are one operator's, whatever the classifier called them; the count of distinct durable artifacts is the honest floor on the count of operators. Applied to this honeypot, the practice turns "eighty-one samples across a dozen-plus families" into "one operator at fifty-two percent, a bash-worm operator with a handful of key-matched builds, a RedTail operation, a Whisper operation, a Nexus operation, and a scattering of singletons" — a threat picture with perhaps six or seven serious operators, not the dozen-plus the labels imply, and one of them overwhelmingly dominant.

That corrected picture changes what a defender does. It tells them where to spend effort — on the one operator that is half the problem, not spread evenly across ten phantom families. It tells them that blocking "XMRig" leaves the same operator's ten backdoor builds untouched, because they wear different labels and the label was never the thing to block. And it tells them, when they report to others, to report operators and not families — because a partner who hears "we see a dozen families" prepares for a dozen adversaries, while the truth they need is "we see one operator behind half of it, and here is the build hash that finds it." Deduplicate before you count is not an analytic nicety. It is the difference between defending against the threat that exists and defending against the tenfold-inflated shadow the labels cast.

What holds, and what is bounded

What holds, first-party: forty-two of the eighty-one retained corpus samples carry the eba3282b571c build hash, distributed across the ten classifier labels listed; all thirty-two mining-preset builds carry the WantedBy=multi-user.target systemd-persistence marker and none of the ten backdoor builds do; and the forty-two span 2026-03-24 to 2026-07-22 with drops across the whole window. All read directly from the honeypot's retained samples and the build-hash presence in each.

What is bounded: "fifty-two percent" is of this honeypot's retained corpus of eighty-one samples — a measure of dominance at one sensor, not a claim about the internet's malware population. The hash was confirmed by its presence in each sample's extracted strings; a sample that contained the toolkit's code but from which the string did not extract cleanly would be undercounted, so forty-two is a floor. And the systemd-versus-hooks persistence split is inferred from the presence or absence of the service marker, consistent across all forty-two, not from observing each build install.

What is not claimed: that the corpus is the operator's total output — it is what one honeypot retained — or that the ten labels are exhaustive of the toolkit's disguises. The measurement establishes dominance and unity at this sensor; the operator remains the pseudonymous Go author of Parts 1 and 2, correlated across all forty-two builds by the one hash and to nothing beyond them.

Core IOCs

• Toolkit footprint: 42 of 81 retained corpus samples (52%) carry cgo build hash eba3282b571c.
• Classifier masks (10 labels): XMRig (32), PAM session manipulator (2), SSH-PAM Backdoor, SSH-PAM session handler, PAM session handler, PAM session manipulation tool, PAM credential manipulator, PAM backdoor dropper, SSH-key backdoor dropper, SSHD backdoor dropper (1 each).
• Persistence split: mining builds → WantedBy=multi-user.target systemd service (32/32); backdoor builds → PAM/SSH-hook embedding, no service (0/10).
• Campaign span: 2026-03-24 → 2026-07-22 (entire observation window, continuous), 56 total drops.
• Method note: deduplicate a malware corpus by durable build artifact before counting operators — family labels overcount adversaries (here ~10×).

Cross-references

• TI-2026-090A / 090B — One Binary, Many Masks / Two Miners, No Wallet: the toolkit whose true corpus footprint this letter measures.
• TI-2026-087D — One Key, Six Names: the same label-overcounts-operators finding on the bash worm — one operator, thirteen hashes, six labels; here, one operator, forty-two samples, ten labels.
• TI-2026-087H — The Other Tenant: the PAM samples first catalogued separately, now counted as ten of the forty-two masks of one toolkit.

The investigation began by asking what the honeypot's biggest family was, and ends by finding that the question was wrong. The honeypot's biggest family is not a family at all; it is half the honeypot, and it is one operator, and it had been filed under ten different names by a system that reads what malware shows rather than what it is. The right question for any corpus turns out to be not "how many families are here" but "how many operators, once you dedupe the masks" — and the answer, at this sensor, is a small number with one giant at the front of it. The toolkit wore ten names. Under all of them was one hash, one author, and one four-month campaign that was, all along, the majority of everything the door had caught.