TI-2026-008B — The Key to 81 Machines: The Outlaw Backdoor Key, Recounted

Classification: HIGH · Forensic threat intelligence · Honeypot-derived · Published 2026-07-07 · Series: Honeypot Field Reports

TI-2026-008 "The Backdoor-Key Harvester" and 049B "The Command Language" documented an Outlaw/Shellbot campaign that plants a single SSH backdoor key across compromised machines — 56 of them at the time of writing. This dossier is not a new discovery; it is a recount. At 15:15 UTC on 2026-07-07 the intelligence pipeline re-linked that cluster and the number had moved: the same backdoor key now sits in the authorized_keys of 81 machines across six continents. One public key, 81 doors, 0.90-confidence proof they are all the same lock. The story is a single fingerprint; the evidence is the fleet it unlocks.

1. One Key, Eighty-One Machines

The entity-resolution graph now records 81 IPs sharing the identical planted authorized_keys public key, tracked by its SHA-256:

a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2

The relationship is shared_authorized_key at confidence 0.90 — the strongest same-operator signal the platform assigns, because a planted authorized key is not a fingerprint an attacker leaks by accident; it is the literal backdoor. Every machine carrying it can be opened by whoever holds the matching private key.

Where the 81 are (from a 46-node sample of the current cluster):

The membership is deliberately indiscriminate — the key lands wherever a host falls, regardless of what kind of network it is:

That spread — a hyperscaler VM, a bulletproof VPS and a hijacked Nigerian mobile line all holding the same backdoor key — is the signature of an operation that does not buy infrastructure so much as collect it: every successful SSH compromise gets the same key, and joins the same fleet.

2. Why It Is the Same Operator, Not a Coincidence

Three independent signals converge on one campaign, and the first is decisive:

• The key itself (0.90). A shared host key can be a hosting-provider default; a shared authorized key cannot — it is planted, by the attacker, as persistence. Eighty-one machines do not independently receive the identical backdoor public key by chance.
• The Outlaw cleanup command (56 nodes). The anchor node and 55 others share a byte-identical command signature (command_hash a7aa36c3): rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh; pkill -9 auth.sh …. This is the Outlaw/Shellbot family's hallmark — killing rival cryptominers and cleaning prior implants before installing its own. It is the exact behaviour catalogued in 049B "The Command Language".
• The libssh-swarm toolkit (HASSH). The cluster's nodes present the libssh HASSH fingerprints 03a80b21 (libssh 0.11.1), af8223ac (libssh 0.12.0) and f555226d (libssh 0.9.6) — the same braided-version scanning organism dissected across the 049 "Swarm Protocol" series. The backdoor key is the persistence layer of the swarm whose scanning layer 049 already mapped.

Together these place the 81-node key cluster squarely inside the documented Outlaw/Shellbot cryptomining SSH botnet — the same family behind TI-2026-008 and TI-2026-012 "The mdrfckr Botnet". What is new is not the family. It is the count.

3. The Recount: 56 → 81

The value of a continuously-enriched intelligence store is exactly this — the story does not freeze when the article publishes. When 008/049B were written, the shared key sat on 56 "Family 1" machines. The intel-linker cronjob that ran today rebuilt the cluster from current honeypot data and the same key now spans 81 — a +45% expansion, most of it new members on networks that were not in the original census.

This is a live, growing backdoor fleet, not a historical artefact. The authorized_keys entry is the reason: unlike a running process (killed on reboot) or a /tmp dropper (wiped on cleanup), a planted SSH key survives reboots, patches and the removal of every other implant. It is the most durable thing the operator installs, which is why the count only goes up. Each new SSH compromise adds a door; almost none are ever removed, because almost no victim audits authorized_keys.

4. What a Shared Authorized Key Actually Means

A shared authorized_keys entry is the plainest form of botnet ownership there is. As TI-2026-026M put it for a smaller cluster: the private key that matches this public key is a master skeleton key — one credential that logs the operator into every machine on the list, no password, no exploit, silently. Eighty-one machines, one key, permanent access.

It is simultaneously the operator's greatest convenience and their greatest exposure:

• For the operator: frictionless re-entry to the entire fleet, resilient to everything short of an authorized_keys audit.
• For a defender: the single most valuable IOC in the whole campaign. You do not need to catch the attack in progress — you grep one file. Any host whose authorized_keys contains this key is compromised by this campaign, full stop, and the check is free.
• For law enforcement: possession of the matching private key (via a seized node) would instantly enumerate the entire fleet and could unlock every backdoor — the same skeleton key cuts both ways.

5. Alternative Interpretation

Steelman: "Outlaw/Shellbot is a widely-forked, off-the-shelf kit. A shared public backdoor key proves the same toolkit, not the same operator — the key may be a hardcoded default in a dropper that dozens of unrelated actors run. The 81 machines might be one operator's fleet, or many operators' machines all infected by the same commodity malware."

Why the evidence still lands — with calibrated confidence:

• Same toolkit is certain (HIGH). The composite — identical planted key + the Outlaw cleanup command signature + the libssh-swarm HASSH set — is conclusive that all 81 machines were compromised by the same Outlaw/Shellbot codebase.
• Same controller is the honest open question (MEDIUM). Whether one hand holds the matching private key depends on whether the key is a per-operator secret or a kit default. That is not resolvable from the public key alone. The concentration on one honeypot in one 30-day window, and the shared command hash, lean toward a single active operator — but a commodity-kit-with-default-key explanation cannot be excluded, and honesty requires saying so.
• The distinction does not change the defense. Whether it is one operator or several running the same kit, every host carrying the key is backdoored and the remediation is identical.

Confidence: HIGH that 81 machines across 20+ countries carry the same Outlaw/Shellbot backdoor key and were compromised by the same toolkit, and that the cluster grew from the documented 56 to 81 as of 2026-07-07. MEDIUM that a single operator actively controls all 81 (versus multiple operators sharing a kit-default key).

6. Defense Response

• Grep the key — it is a free, definitive IOC. Any Linux host whose ~/.ssh/authorized_keys (root and every user, plus /etc/ssh/) contains the key with SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 is compromised by this campaign. This is the cheapest high-confidence compromise check available; run it fleet-wide.
• Removing the key is necessary but not sufficient. Delete the entry, then rotate all credentials and find the entry vector — the libssh swarm brute-forces weak SSH logins, so the key got in because a password did. Enforce key-only SSH and kill the root/default logins the swarm relies on.
• Behavioural detection for hosts you can't audit at rest. The Outlaw cleanup command (rm -rf /tmp/secure.sh …; pkill -9 secure.sh …) and the libssh HASSH fingerprints (03a80b21 / af8223ac / f555226d) with a root login are network-side tells of an in-progress compromise from this fleet.
• Watch the count. Because the key persists and the cluster is live, this census (81) is a floor, not a ceiling — the same query re-run next week will likely be higher.

7. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence