LSN โ€” Local Sovereign Network

The Same Hand: When the Web Mask and the SSH Scanner Share a Target

TI-2026-086J ยท Series: The Wardrobe ยท Case 10 ยท Classification: HIGH ยท Confidence: MEDIUM (convergence documented; single-operator attribution bounded)

Every case so far lived at the web edge โ€” costumes, kinematics, landlords, all in HTTP. But the honeypot has a second door, the SSH port, and it has been watching a different kind of attacker for a year: not masked crawlers but credential scanners, fingerprinted by the SSH client they carry. This case walks through the wall between the two. The reindexed crosslinks tie one Google Cloud node to both surfaces at once, and when you read what it does on each, the wall turns out to be thin. The web wardrobe and the SSH scanner are hunting the same thing.

Executive Summary

Node 35.188.112.111 (Google Cloud, AS396982, GreyNoise malicious, AbuseIPDB 100) is the bridge. On the SSH surface the honeypot has it dead to rights as a targeted credential-scanner: twenty-one sessions, averaging 1.9 seconds each, zero successful logins, zero commands, zero downloads. It guesses credentials and leaves. It carries the HASSH fingerprint f555226d (libssh_0.9.6) and is a member of three coordinated global SSH botnets โ€” libssh_0.9.6 (421 IPs / 59 countries), libssh_0.11.x (1,313 IPs / 84 countries โ€” the "1,313 Machines" of 026M), and libssh_0.12.0 (607 IPs / 71 countries).

And here is what makes the wall thin. Read its SSH wordlist:

deploy:admin@123   deploy:github    git:0000       dev:Dev23!
azureuser:azureuser@1234   ansadmin:admin   claude:Claude2026!
administrator:q1w2e3r4t5   david:david123!  admin:abc123

That is not a generic root:root botnet dictionary. It is a developer and deployment wordlist โ€” deploy, dev, git, azureuser, ansadmin, even claude โ€” and it targets the exact same prize the web wardrobe pursues. The web fleets sweep /.env files off the Gitea host (lsn-git) and the webmail server, hunting deploy keys, CI/CD tokens, and secrets committed to repositories. The SSH scanner guesses the login credentials of the same developer accounts. Two vectors, one target: the credentials of the people who deploy the software.

The convergence is HIGH-confidence at the level of tenancy and objective (AS396982 is flagged same_asn_web_and_ssh; the target surface is identical). That a single operator runs both halves is a bounded MEDIUM โ€” shared cloud is weak attribution, and the botnets are huge โ€” but the shared-credential cluster, the temporal correlation, and the target congruence push it well above coincidence.

Two Roads to One Prize

The clearest way to see the same hand is to notice that the two vectors are not doing different things; they are doing the same thing by different means.

A developer's secrets can be stolen two ways. You can read them โ€” if a .env file or a config was left web-accessible, or committed to a repo the server exposes, you fetch it and the secret is simply lying there. Or you can guess them โ€” if you know the account naming convention (deploy, git, ci, azureuser), you try likely passwords at the login until one works. The first is a web operation; the second is an SSH operation. But they are aimed at the identical asset: the credential that lets you deploy.

The web wardrobe is the reading operation. Cases 086Bโ€“D showed it firing 79-to-151-path .env sweeps at lsn-git and lsn-webmail โ€” the two hosts most likely to hold deploy keys and pipeline secrets โ€” under forged crawler identities so the sweep reads as indexing. 35.188.112.111 is the guessing operation, from the same cloud, running a wordlist built for the same accounts. Neither is a random scan. Both are a targeted hunt for the DevOps credential surface, and they are the two roads any operator after that surface would naturally take. Finding both roads running out of one Google Cloud tenancy, aimed at the same two hosts and the same account names, is the finding.

The claude:Claude2026! guess is a small, telling detail. That is not a legacy dictionary entry; it is a fresh, AI-era developer credential someone added on purpose โ€” the same currency of "recently-granted trust" the AI-crawler masks exploited in 086E, here on the SSH side. The wordlist is maintained, like the mask set is maintained; both are kept current with what developers actually name their accounts and their bots.

Why Only the Web Half Wears a Mask

If it is one hunt, why is there an elaborate wardrobe on the web and nothing but a bare libssh scanner on SSH? The answer is not two different operators; it is two different trust models, and it explains the entire existence of the wardrobe.

On the web, trust is granted by claimed identity. A request that says "Googlebot" is treated differently from one that says nothing, because the web has a population of allowlisted good bots whose names carry passage. That is a resource to steal โ€” so the operator steals it, and the wardrobe exists.

On SSH, there is no such resource. An SSH login is judged by one thing: does the credential work? There is no allowlisted "good bot" whose name grants entry, no User-Agent to forge, nothing an attacker can claim to be that improves its odds. So the SSH half has nothing to gain from a costume, and it wears none. It cannot even hide what tool it is โ€” the SSH handshake leaks a HASSH client fingerprint, which is exactly how the honeypot caught 35.188.112.111 and clustered it with 2,000+ siblings.

So the wardrobe is a web-specific adaptation of a cross-vector operation. The same operator, hunting the same credentials, wears a disguise on the surface where a disguise buys passage and goes bare on the surface where it buys nothing. The presence of the mask on the web and its absence on SSH is not evidence of two crews; it is evidence that a single crew is rational โ€” it invests in disguise exactly where disguise pays. This is the mirror image of 086I's population rule (masks blend, floods go bare): there the split was between blend-intents and flood-intents; here it is between the blend-surface and the no-blend-surface. Same logic, applied to where a mask is worth wearing.

The Node in Two Corpora

35.188.112.111 is not a fresh discovery; it is one of the most-documented nodes in the honeypot's history, and the reindexed crosslinks are what finally join that history to the web wardrobe. It appears, by name, in:

โ€” and now TI-2026-086A. For a year the SSH side documented this node as a persistent GCP credential-scanner; the web side documented AS396982 as a mask concentration; and until the indexer joined the graph, those were two separate stories. The crosslink same_ip_web_and_ssh โ€” one of 1,751 such edges โ€” is what makes them one. The node did not change; our ability to see both of its faces did.

That is the methodological payoff of the fresh vectors, and it generalises: the honeypot (SSH), the web edge (HTTP), and the router (L3 bans) are three sensors on one adversary population, and a node caught on any one can now be pre-blocked on the others. multi_layer_blocked โ€” the relationship for IPs confirmed hostile on MikroTik and CrowdSec and the honeypot and the web edge โ€” is that idea operationalised: cross-vector presence is itself a high-confidence hostile signal.

What the SSH Side Adds That the Web Side Cannot See

The two surfaces are not redundant; each sees something the other cannot, and together they read the operation's intent more precisely than either alone.

The SSH side reveals that this is a collection operation, not a smash-and-grab. 35.188.112.111 had twenty-one sessions and never once ran a command or downloaded a payload โ€” because it never successfully logged in, and, tellingly, it was not trying to persist. Its sessions averaged 1.9 seconds: connect, offer a credential, disconnect. That is the behaviour of a scanner mapping which credentials work, feeding a list, not an intruder exploiting a box. Pair that with the web .env harvest โ€” also a read-and-leave operation, no exploitation, just secret-gathering โ€” and the cross-vector picture is coherent: a reconnaissance-and-harvest operation building a store of DevOps credentials, presumably to be used or sold elsewhere. Neither surface alone shows that; the web harvest could be a prelude to anything, and the SSH scan could be mindless botnet noise. Seen together, both resolve into the same patient, collection-shaped intent.

Steelmanning: "Shared cloud proves nothing โ€” these are just two big botnets"

This is the strongest objection, and it is the one the series has been most careful about since 086A. Google Cloud has millions of tenants; the HASSH botnets span 84 countries and thousands of IPs that obviously include unrelated actors; a .env scanner and an SSH scanner both living on GCP could be pure coincidence of a popular cloud. So is "the same hand" over-reading shared tenancy โ€” the exact error the series keeps warning against?

The discipline holds if we are precise about what is claimed at what confidence:

So the objection is right that shared cloud alone proves nothing โ€” and the case does not rest on shared cloud. It rests on target congruence plus the bridge node's concrete cross-surface footprint. The honest headline is convergence, not conspiracy: two vectors demonstrably meet in tenancy and objective, and at least one node in operator-population. Full same-crew resolution is deferred to 086M, where the entity graph is turned on the operators directly.

What Holds, and What Is Bounded

Documented, HIGH confidence: the bridge node's SSH scanner behaviour (21 sessions, no login, DevOps wordlist) and HASSH botnet memberships; the target congruence between the SSH wordlist and the web .env sweeps; the same_asn_web_and_ssh cross-vector flag; the node's presence across both corpora.

Inferred, MEDIUM confidence: that the web fleets and the SSH scanners are run by the same operator population. Supported by target congruence, the shared-credential and temporal clusters, and the cross-corpus node identity; bounded by the weakness of shared-cloud attribution and the heterogeneity of the botnets. Held as "convergence in tenancy, objective, and โ€” at the bridge node โ€” operator-population," not "one crew." The collection-not-exploitation reading is a further inference from the zero-command SSH sessions plus the read-only web harvest.

Why It Matters

The Same Hand is the case that lifts the wardrobe out of the web logs and shows it is one face of a larger operation. The forged Googlebot at the front door and the deploy:github guess at the SSH port are not two problems; they are two reaches for the same set of keys โ€” the credentials that let someone push code to production. The mask is only on the web because the web is where a mask helps; the hunt underneath runs on every door.

For defenders this is the argument for a single graph across sensors. A web team that blocks a fake Googlebot and an SSH team that bans a libssh scanner, working separately, each see a fragment; joined, they see a credential-harvest operation working both surfaces of the same estate, and either team's detection becomes the other's early warning. The fresh crosslinks make that join automatic โ€” same_ip_web_and_ssh, same_asn_web_and_ssh, multi_layer_blocked โ€” and this case is what those edges look like when you follow one all the way through. The wardrobe was never only about the web. It was about who wants your deploy keys, and they knock on every door they can find.

Cross-references

Next in the series โ€” TI-2026-086K, The Mask That Convicts: the automated unmasking loop โ€” how the pipeline detects a spoofed fleet and turns the costume into a CrowdSec/MikroTik ban keyed to the fleet's own name.

TLP:WHITE. Attacker infrastructure only; family/host credentials shown are attacker-submitted guesses against the honeypot, not real accounts. No internal addresses or secrets disclosed. Single-operator attribution explicitly bounded.

โš  Personal capacity. Research published independently โ€” not reflecting employer views. Derived from passive observation of attacks against personal infrastructure. Full disclaimer โ†’
โ† Previous The Wardrobe โ€” 10 / 26 Next โ†’