Two-Handed: The Fleet That Scans With One Build and Breaks With Another

TI-2026-075C · Series: The Armory (Part C) · TLP:WHITE · 2026-07-10

Assessment (MEDIUM-HIGH confidence). Somewhere behind the honeypot's traffic is an operator that fights with two hands. One hand holds a scanner — 1,313 IPs across 84 countries, compiled against libssh_0.11.x, casting 44,341 login attempts to map what exists. The other holds a botnet — 421 IPs across 59 countries, compiled against the older libssh_0.9.6, the follow-on force that tries the handles the scanner found. The platform resolves both to one operator id; the honest, independent binding is that the two arms rent from the same networks. This letter is about what the Armory's build-string fingerprint makes legible that no single IP ever could: an operation's org chart, written in version numbers.

1. The thing an address cannot show you

Take any one of these 1,734 IP addresses on its own and it tells you nothing worth knowing. One of them is a single node in a fleet of 1,313. Another is one of 421. Each contributes a handful of login attempts to a pile of tens of thousands. Ban it and the operator does not notice; profile it and you have profiled a rented, disposable address that will not exist next week. At the packet level, at the address level — the level almost all defense operates at — there is no there there. Just noise, evenly spread across the map.

Lift to the fingerprint level and a structure snaps into focus that was invisible below it. Because the honeypot records HASSH — the hash of the exact ordered algorithm set an SSH client offers during key exchange, a property of the build rather than the address — the 1,313 scanner nodes collapse into one cluster, and the 421 botnet nodes collapse into another, and those two clusters turn out to be standing on the same ground. The operation was never hidden in the addresses. It was hidden by the addresses — smeared across 84 countries so that no single vantage could see it whole. The fingerprint un-smears it.

2. The two hands

Here are the two arms, side by side, because the contrast is the whole argument.

Two things about this table matter more than they first appear.

The first is that they run different libssh versions. That is not incidental. An SSH library's version determines its key-exchange fingerprint — 0.9.6 and 0.11.x ship different algorithm defaults and orderings, so they hash to different, stable HASSH values regardless of what IP runs them. An operator running both is maintaining two toolchains on purpose. Not one script reused; two builds, deliberately kept, for two different jobs. The version string is doing the work a leaked internal document would do in a corporate breach: it exposes the division of labour.

The second is the success columns, which look like failure and are not. Thirty-eight successful logins in forty-four thousand attempts reads, to the untrained eye, like a botnet that cannot break in. But the scanner arm is not trying to break in. Its job is to record which of a hundred thousand hosts answers — which ones present an SSH banner, which credentials draw a flicker of response, which addresses are worth a second visit. Near-zero success at enormous volume is not an inept intrusion; it is a competent reconnaissance. It is the map being drawn. The 24 successes on the botnet arm are the beginning of the map being used.

3. Why they are one operation

The platform assigns both clusters a single operator id — actor-6f199858ed7e. On its own, that is a clustering algorithm's opinion, and this program does not publish an algorithm's opinion as a fact. So the load-bearing question is: what independent evidence says these two fleets are one hand?

The answer is the ground they stand on. Look at the top networks feeding each arm and three ASNs appear in both:

• AS135377 — scanner arm 73 IPs, botnet arm 18.
• AS8075 (Microsoft) — scanner 56, botnet 17.
• AS14061 (DigitalOcean) — scanner 39, botnet 15.

The scanner and the botnet are provisioning from the same providers, in parallel. This is the disposable-infrastructure model of the previous letter — fresh, clean, rented IPs on mainstream clouds — but now run as two coordinated fleets from a shared account base. Two unrelated operators would not, by chance, both concentrate on precisely this trio of networks while running complementary roles. The shared ground is the fingerprint of a shared hand.

And note what it is not: it is not a shared SSH host key, and it is not an identical credential wordlist — the kinds of evidence that would make one operator certain. So the honest ceiling is here, and the letter stays at it: coordination is evidenced; a single hand is inferred. It could be one operator running two toolchains, or two collaborators sharing infrastructure. The disagreement between "clearly coordinated" and "provably one person" is not something the data resolves, so it is recorded rather than papered over. What can be said flatly is: this is one operation. How many hands are inside it is beyond what shared ASNs can prove.

4. Overlapping, not identical — the shape of real coordination

There is a subtlety in the infrastructure worth drawing out, because it is more convincing than perfect overlap would have been.

The two arms share their core networks (AS135377, AS8075, AS14061) but diverge at the very top. The botnet arm's single largest network is AS132203 (Tencent), 92 IPs — a concentration the scanner arm does not lead with. The scanner arm's largest is AS4811 (ChinaNet), 64 IPs — which the botnet arm does not. So the model is not "two identical fleets." It is a shared core plus role-specific extensions: common accounts and providers underpinning both, with each arm scaling out on whatever pool best suits its task — the noisy botnet on one, the wide scanner on another.

This is what genuine coordination looks like in infrastructure, and it is worth internalizing as a detection heuristic: real operations show partial overlap, not total. Total overlap is suspicious in the other direction — it suggests one fleet mislabeled as two. Partial overlap with a clean behavioral division — one arm scanning, one arm breaking — is the realistic signature of an operation that has organized itself into functions. Perfect symmetry is what a naive model expects; asymmetric overlap is what real logistics produce.

5. Steelman: is this just two botnets that happen to use libssh?

The counter-narrative deserves its strongest form. libssh and libssh2 are extremely common — vast numbers of unrelated scanners and bots compile against them, because they are the standard libraries for programmatic SSH. So perhaps these are simply two large, independent commodity botnets, and the shared ASNs are just the unremarkable fact that everyone rents from Microsoft, DigitalOcean, Tencent and ChinaNet. The operator id might be an artifact of over-eager clustering.

That objection is real, and it is why the confidence is medium-high and not high. But it does not fully survive three details. One: the version split is clean — the scanner behavior lives almost entirely on 0.11.x and the botnet behavior on 0.9.6, rather than both builds appearing in both roles, which is what independent commodity fleets would produce. Two: the shared trio of ASNs is specific and consistent across both arms' top networks, not just present somewhere in a long tail. Three: the behavioral complementarity — a wide low-success scanner and a narrower higher-intent brute-forcer — is exactly the functional pair an organized operation would field, and exactly not what two random botnets would be expected to form. None of these is proof. Together they move the reading from "coincidence" to "coordination" without pretending to reach "one named person" — which is precisely the calibrated place to leave it.

6. The seven questions

Who? One operation (operator id actor-6f199858ed7e), medium confidence; number of hands inside it unresolved.

What? A two-armed SSH campaign — a libssh_0.11.x scanner fleet and a libssh_0.9.6 botnet fleet — run in parallel.

When? Overlapping activity windows through 2026 (both clusters active into the May snapshot; the scanner is the larger, longer-running arm).

Where? 84 countries (scanner) and 59 (botnet), but concentrated on a shared core of AS135377, AS8075 (Microsoft), AS14061 (DigitalOcean), plus role-specific Tencent (botnet) and ChinaNet (scanner).

Why? Division of labour: map the internet's SSH surface with one build, exploit the mapped hosts with another.

How? Compile two libssh toolchains, deploy each across rented disposable IPs on shared mainstream networks, scan wide, then brute-force where the scan lands.

So what? The operation is invisible at the address layer and obvious at the fingerprint layer — proof that the build string, not the IP, is where an operator's structure is legible.

7. Read between the lines

The deepest thing this fleet says is about method, and it is the reason The Armory is built on HASSH rather than on IP reputation.

Everything an attacker can rent, they will rotate. The IP is disposable — that was the lesson of the cloud contractor. The country is chosen for spread, not meaning. The credential list is shared commodity. Every layer an operator can cheaply change, they change, precisely to defeat the reputation systems trained on those layers. But the one thing they do not casually change is the tool they compiled — because recompiling and re-testing a toolchain is real work, and an operation that has invested in two working builds keeps them. The build is the sticky layer. It is the part of the operation that persists while everything cheap around it rotates.

So the fingerprint of the build is the closest thing to a stable identity an internet-scale operator has. It survives the IP rotation, the country hop, the credential swap. It reunites a fleet across 84 countries. And when one operator maintains two of them for two roles, the pair of fingerprints exposes the internal structure the operator took such care to scatter. The addresses were the disguise. The version strings were the face under it.

8. Detection and defence

1. Cluster by build, not by address. The operation is only visible at the HASSH layer. If your telemetry throws away the SSH client fingerprint, you are discarding the one field where structure lives.
2. Read low-success/high-volume as reconnaissance, not incompetence. A wide fleet that almost never logs in is drawing a map. The intrusion is a different, quieter fleet arriving later — correlate the two by shared infrastructure, not by waiting for the scanner to succeed.
3. Use cross-cluster ASN overlap as a coordination test. When two behaviorally-distinct fleets share their top networks, treat coordination as evidenced even absent a shared key. Partial overlap plus behavioral division is the realistic signature of one operation.
4. Hold single-operator claims at their real confidence. "One operation" is defensible here; "one person" is not, on shared ASNs alone. State coordination as fact and single-handedness as inference — the calibration is the credibility.
5. Expect the build to persist while everything else rotates. Pin detections to the sticky layer (the compiled toolchain) rather than the disposable ones (IP, country, credentials) the operator changes precisely to evade you.

9. The Armory, placed

Letter A gave the method — fingerprint the weapon, not the address. Letter B applied it to the ground — the disposable cloud the weapons run from. Letter C applies it to an operator — and finds, in two version strings and a trio of shared networks, the shape of an organization: a hand that maps and a hand that breaks, working the same rented ground in parallel.

The series now turns to the heaviest weapons in the census — the command-and-control frameworks, Sliver and Havoc and AdaptixC2, where the tool is no longer an SSH library but a full remote-control platform, and the dual-use tension of the whole Armory reaches its sharpest point: software written, openly and by name, to help red teams practice the attacks it is used to commit.

10. Sources

• LSN honeypot HASSH campaigns — cluster 03a80b21… (libssh_0.11.x): 1,313 IPs / 84 countries / 44,341 attempts / 38 successes, top ASNs AS135377/AS4811/AS8075/AS136052/AS14061; cluster f555226d… (libssh_0.9.6): 421 IPs / 59 countries / 14,222 attempts, top ASNs AS132203/AS135377/AS8075/AS4766/AS14061; both linked to operator id actor-6f199858ed7e.
• LSN honeypot intelligence summary — actor clustering and HASSH tool distribution.
• Salesforce — HASSH (build-dependent SSH client fingerprinting).
• TI-2026-075A/B — the method and the infrastructure model this letter builds on.

Confidence: MEDIUM-HIGH. The two clusters, their sizes, geography, behavior, and shared top-ASN overlap are direct from honeypot telemetry (HIGH). The single-operator attribution is the platform's, held at MEDIUM and explicitly not inflated: coordination is well-evidenced by shared infrastructure and clean version-role split; a single hand is inferred, not proven, and the residual uncertainty (one operator vs. two collaborators) is recorded rather than resolved. TLP:WHITE — attacker fleets and tooling only.