The Fingerprint Without a Face: One Operator, Four Names, No Legible Function

The Long Tail — Part 2 of the honeypot census remainder

Classification: MEDIUM · Confidence: HIGH on attribution-to-one-operator, LOW on function (by the operator's design)

This letter is shorter on conclusions than the ones before it, and that is the point. It concerns four binaries that landed on the honeypot within hours of each other on the eighth of June, and about which the honest analytical position is: we know, with high confidence, that they are one operator's toolset, and we do not know what they do. The gap between those two statements — certain about the hand, blind to the work — is the finding. It is the census's second failure mode, the mirror image of the first, and it is worth a letter precisely because the discipline it demands is the discipline of saying less than the classifier did.

The first failure mode was established earlier in this investigation. The dominant Go toolkit was one operator that the content classifier read as ten different malware families, because it was verbose — it exposed enough strings, across enough capability variants, that the classifier named each string-profile separately. Ten labels, one build hash. Over-verbosity inflates the operator count.

The June eighth toolset is the opposite. It is one operator that the classifier could barely read at all, and so it did the only thing a classifier can do with a binary it cannot read: it guessed, confidently, and gave four binaries two different authoritative-sounding names. Under-legibility does not inflate the count the way verbosity does. It does something subtler and more dangerous: it produces confident labels backed by almost no evidence, and a family-label census cannot tell those apart from confident labels backed by a great deal.

What is actually known

Let me state the documented facts first, because they are firm, and then the wall they run into.

Four binaries arrived on 2026-06-08, each once, from one source. All four are Go binaries built with Go 1.24. All four carry, in their extractable strings, the same seven-character marker: $0f9C2u. All four exhibit the identical file entropy of 6.19 — not approximately, identically. Their sizes differ (6.49 MB, 2.19 MB, 1.97 MB, and 950 KB), so they are four distinct binaries, not copies. But the shared marker, the shared Go toolchain version, the shared same-day delivery, and the byte-identical entropy signature are four independent reasons to conclude they came off one build pipeline. This is the durable-artifact method again, and its verdict is unambiguous: $0f9C2u is to this operator what the build hash eba3282b571c is to the toolkit — a fingerprint that clusters the set. One operator. Four tools.

The largest binary was UPX-packed: it arrived compressed to 2.6 MB on disk and unpacked to its full 6.49 MB. It also carries a reference to libssh — the SSH protocol library — which is the single genuine capability signal in the entire set. A Go binary statically linking libssh does something with SSH: connects, authenticates, manipulates keys, or serves. That is real, and it is consistent with the classifier's label for that binary, "SSH-key backdoor dropper."

And there the firm ground ends.

The wall

Here is what the four binaries do not contain, in their strings, even after the packed one was unpacked to its full size: no command-and-control address. No IP, no domain, no URL, no onion. No mining pool, no wallet, no stratum endpoint. No persistence string — no cron line, no systemd unit, no authorized_keys path. No scanning or brute-forcing vocabulary. No credential dictionary. Nothing that names a target, a beacon, a channel, or a purpose. What the extractor surfaces is Go runtime internals — sync.Pool, runtime.tgkill, the standard-library source paths, the embedded timezone abbreviations that every Go binary carries — the marker $0f9C2u, and, in one of the four, libssh. That is the whole legible surface of a 6.49-megabyte program.

This is what stripped Go looks like when the operator has taken the trouble. Go binaries are normally garrulous — they embed function names, package paths, and error strings in quantities that make them among the easiest malware to read. To reduce one to a few hundred runtime strings and a single capability library is to work against the grain of the language. Whether that was achieved by aggressive symbol stripping, by an obfuscation pass, or by the UPX layer on the flagship, the result is a set of binaries whose function is not recoverable from their strings. Determining what they actually do would require unpacking, disassembly, and dynamic execution in an instrumented sandbox — analysis this honeypot does not perform and this letter does not claim to have performed.

So the honest characterization of the June eighth toolset is: one operator; four Go tools; at least one with SSH capability; all deliberately, or at least effectively, illegible. Everything past that is the classifier's guess.

The one thing that survived stripping

It is worth dwelling on $0f9C2u, because in a set of binaries engineered to say nothing, the one thing that persisted is analytically the most valuable, and understanding why it persisted is understanding how to track this operator.

A marker that survives when function strings do not is, almost always, not a leftover — it is load-bearing. Aggressive stripping and obfuscation remove what the program does not need at runtime: symbol names, source paths, debug information. What they cannot remove is what the program reads at runtime. A string that the code itself references — a build salt used to derive a key, an embedded campaign or version tag, a mutex name used to avoid double-infection, a magic value checked against a configuration blob — has to remain in the binary in usable form, because the program will dereference it while running. When everything decorative is gone and one seven-character token remains across four binaries, the odds are strong that the token is functional: something the code touches, which is exactly why it could not be stripped.

That has two consequences. First, it makes $0f9C2u a robust hunting signature — more robust than a family name, because it is tied to the program's operation rather than to a classifier's reading, and it survived precisely the stripping that erased everything else. A retro-hunt across a wider corpus for that token would cluster this operator's binaries regardless of what labels they attracted or whether they were packed. Second, it is a small warning to the operator's own operational security: the discipline that stripped four binaries down to their runtime skeletons left the one thread that ties them together, because that thread was the one thing the code could not do without. Opacity that is total everywhere except the load-bearing marker is opacity that still has a handle. This operator built four faceless tools and stamped the same rivet into all of them.

The confabulated names

The classifier labelled the four as two families: two "SSH-key backdoor dropper" and two "Runtime monitoring tool." Look at what those names assert against what the evidence supports.

"SSH-key backdoor dropper" is a defensible reading for the libssh binary — libssh plus the honeypot's SSH-brute-force delivery context makes an SSH-key backdoor a reasonable hypothesis. It is still a hypothesis, but it is an evidenced one.

"Runtime monitoring tool" is not. There is no string in those binaries that supports it — no monitoring vocabulary, no metrics, no observability library. Worse, the label describes a benign system utility, which is an actively misleading thing to call a stripped Go binary delivered by an SSH brute-force attempt onto a honeypot alongside a libssh backdoor. No one sweeps the internet for shells in order to install a monitoring tool. The name is almost certainly an artifact of the classifier pattern-matching a Go runtime profile — the runtime.* and sync.Pool strings that are present precisely because nothing else is — and reaching for a plausible-sounding name that happens to be exactly wrong about the binary's nature.

That is the mechanism to watch. A classifier's naming confidence is not calibrated to its evidence. "Runtime monitoring tool" reads as specific and authoritative and sits in the corpus next to "SSH-key backdoor dropper," which reads equally specific and authoritative — and one is a reasonable inference from libssh while the other is a confabulation from the absence of anything to read. A family-label census weights them the same. It has no column for how much the classifier actually knew when it wrote the name down.

And notice the count. Four binaries, one operator, two family names. It is the toolkit's error in miniature: the labels imply more diversity than exists. Where the toolkit's verbosity split one operator across ten names, this operator's opacity split it across two — smaller, but the same direction and the same root cause, which is trusting the name over the fingerprint. The marker $0f9C2u says one operator, flatly. Only by reading it, and disbelieving the four confident names stacked on top of it, does the toolset resolve correctly.

Selective opacity is a professionalism signal

There is one inference the evidence does support beyond the clustering, and it is about the operator's judgment.

Of the four binaries, exactly one was UPX-packed: the largest, the one that links libssh, the one most plausibly the actual backdoor. The other three shipped stripped but unpacked. An operator who packs one tool and not the others is not packing reflexively — a reflexive packer packs everything. This one spent the concealment effort on the tool that mattered most and left the utilities in the clear. That is a small, deliberate allocation of opacity: protect the crown, economize on the rest. It rhymes with a pattern this investigation has seen repeatedly — the toolkit externalizing only its wallet, RedTail carrying only its miner — operators who are precise about which single thing is worth the cost of protecting. The June eighth operator protected the SSH tool.

It is a modest inference, and I flag it as an inference. But it is the kind of thing that is legible even when function is not: you cannot always read what a binary does, but you can sometimes read what its author was careful about, and care is aimed at what matters.

Two ways to defeat a census

Set this operator beside the staged sweeps of the previous letter and the pair define the two ways a sample can be in the honeypot's corpus and still refuse to be counted honestly.

Whisper and Nexus defeated the census by absence: they dropped a legible loader and kept the payload off-box, so what the sensor held was readable but incomplete — the address was there, the weapon was elsewhere. The June eighth operator defeated it by opacity: it dropped the payload directly on the sensor, complete, and made it illegible — the weapon was there, but unreadable. Absence and opacity. One hides the thing and shows you the pointer; the other shows you the thing and hides its meaning. A drop-weight census misses the first because the weight is elsewhere; a family-label census misses the second because it names what it cannot read. Both live in the tail, and both are invisible to exactly the summary that would file them there.

The defensive takeaway is narrow and firm. When four binaries share a build marker, treat them as one operator regardless of how many family names they wear — the marker is evidence, the names may not be. And when a family label describes a benign utility ("monitoring tool," "system info," "test binary") on a sample that arrived by attack, distrust the label specifically, because that is the shape a confabulation takes: a plausible, benign, specific-sounding name generated from the absence of anything real to read. The label most worth doubting is not the alarming one. It is the reassuring one attached to a binary no one could actually read.

A census robust to both failure modes

The two failure modes together make a constructive case for how a corpus census should be built, because they are not two separate problems — they are one problem, seen twice.

A family-label census fails on verbosity because it counts names, and a verbose operator generates many names. It fails on opacity because it counts names, and an opaque operator forces the classifier to invent names from too little. In both cases the fault is the same: the unit of counting is the label, and the label is a function of how legible the operator chose to be, not of who the operator is. Legibility is under the operator's control, which means a census keyed on legibility is a census the operator can skew at will — pad it by being verbose, confabulate it by being opaque.

A durable-artifact census inverts that. It counts fingerprints the operator embedded for their own purposes — a build hash the toolchain stamps, a marker the code dereferences, a key the payload needs. These are not chosen for the analyst's benefit and mostly cannot be shed without breaking the operator's own tooling. eba3282b571c clustered ten labels into one operator by being the toolkit's build hash; $0f9C2u clusters four labels into one operator by being this toolset's runtime marker. The same method resolved both failure modes because both failure modes were label-artifacts and the method does not use labels. The honest operator count for this corpus was never readable from the family names — not because the names were careless, but because names measure the wrong thing, and they measure it in a direction the operator gets to choose.

The rule that falls out is simple to state and was earned twice over in this investigation: cluster on what the operator could not help emitting, count the clusters, and treat every family name as a hypothesis to be checked against the fingerprint rather than a fact to be tallied. A verbose operator will hand you too many names and one hash; an opaque one will hand you too few readable strings and one marker. Follow the hash and the marker. The names are downstream of a choice that was never yours to trust.

The discipline of the empty finding

There is a temptation, at the end of an analysis like this, to close the gap — to let "one operator, at least one SSH backdoor, function otherwise unknown" round up to a confident sentence about a cryptominer or a proxy botnet, because a confident sentence reads better and the reader expects a verdict. That temptation is exactly what produced "Runtime monitoring tool," and it should be resisted for the same reason.

A finding that ends in a stated unknown is not a failed finding. "We know who, with high confidence, and we do not know what, by the operator's design" is a complete result — it reports precisely what the evidence supports and marks precisely where it stops, which is more useful to a defender than a guess wearing the costume of a conclusion. The value of a corpus analysis is not that every sample gets a verdict; it is that every verdict can be trusted at the confidence it is stated with. One confabulated label in a feed does not just mislead about its own sample — it corrodes the reader's ability to trust every other label beside it, because there is no visible mark distinguishing the guess from the evidenced call. The remedy is to state uncertainty as precisely as certainty, so that "SSH-key backdoor, moderate confidence, from libssh" and "function unknown, static analysis defeated" carry their own calibration on their face.

That is why this letter is short on conclusions and long on the boundary. The boundary is the deliverable. Four binaries came off one pipeline on one day, one of them an SSH backdoor, all of them made deliberately hard to read, tied together by a single rivet the code could not shed — and everything past that line is unknown, stated as unknown, and left that way on purpose.

Bounds and limits

DOCUMENTED: four Go 1.24 binaries dropped 2026-06-08, sizes 6.49 / 2.19 / 1.97 / 0.95 MB, identical entropy 6.19, all four sharing the string marker $0f9C2u; the largest was UPX-packed (2.6 MB on disk, 6.49 MB unpacked) and references libssh; the classifier assigned them two "SSH-key backdoor dropper" and two "Runtime monitoring tool" labels.

INFERRED, high confidence: the four are one operator's toolset from one build pipeline (shared marker plus shared toolchain version plus shared delivery date plus identical entropy — four independent corroborations). INFERRED, moderate confidence: the libssh binary performs SSH operations consistent with an SSH-key backdoor; the selective packing of only the flagship reflects deliberate, economical concealment.

BOUNDED — and this bound is the letter's subject, not a footnote to it: the function of these binaries is not established. Stripped Go defeats static string analysis, and no command-and-control, persistence, mining, scanning, or targeting strings were recovered even from the unpacked flagship. Whether these are backdoors, proxies, miners, spreaders, or something else is unknown from this analysis and would require dynamic execution not performed here. The "Runtime monitoring tool" label in particular is assessed as a low-evidence classifier confabulation and should not be read as a description. And the 04-04 "SSH-related implant" that superficially resembled this set is excluded from it: its entropy (2.74) and absence of the $0f9C2u marker place it outside the cluster — a separate opacity, not part of this operator's June eighth toolset.

The result, stated at the confidence it deserves: one operator put four illegible Go tools on the sensor on a single day, one of them an SSH backdoor, and the honest report ends there. The classifier wrote four confident names over that gap. The fingerprint $0f9C2u is the only thing in this entry that earns the certainty it is stated with — and all it certifies is who, never what.

This is Part Two of The Long Tail. Part One found operators who hid by staging their payloads off the sensor; this part found one who hid by making the payload unreadable on it. Part Three turns to the opposite of concealment — the reconnaissance layer, where attackers profile the honeypot with off-the-shelf tools, and where one of them fired a Windows binary at a Linux machine that could never run it.