The Accept List

The cohort was already published, the regime was never what it was called, and a column stopped moving

TI-2026-103Q · Series: The Loud Hour · Addendum II Operates under the rules of evidence in Letter O — The Instrument. This addendum corrects the regime characterisation in Letter O and the "unexamined" claim in Letters F, I and J.

1. Why this exists

Addendum P closed the two handles the series left unwalked. One open item remained, flagged by three letters and closed by none: the mdrfckr cohort — 113 machines that installed a persistent SSH key. Letter F called it "the largest unexamined cluster in the corpus." Letter J called it "the largest uncharacterised object," noted it had been "still unexamined after three letters flagged it," and offered an explanation for why it kept escaping: it lives in the download table rather than the key table, so no clustering tool reaches it.

That explanation was correct about the tooling and wrong about the conclusion. The object was not uncharacterised. It is the most thoroughly documented single actor in this operator's entire archive — five published dossiers, one of them a full anatomy with a YARA rule, published two months before the letter that called it unexamined.

Walking it took an afternoon and produced four things: the identification (which was already published), a reconciliation between two of the archive's own numbers, a correction to the series' regime spine, and a second frozen-timestamp defect that had already written a false finding into my notes before a control caught it.

2. The cohort, identified

[DOCUMENTED] The command that defines the cohort, executed 123 times by 113 addresses, first 2026-03-31T13:49:31Z, last 2026-07-29T23:43:10Z:

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4…
  …KQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys
  && chmod -R go= ~/.ssh && cd ~

[DOCUMENTED] It is preceded, 0.8 seconds earlier and by exactly the same 123 executions from the same 113 addresses, by:

cd ~; chattr -ia .ssh; lockr -ia .ssh

[DOCUMENTED] chattr -ia clears the immutable and append-only attributes. lockr is not a standard Linux utility — it is a non-standard chattr equivalent carried by this toolkit, and its presence in a command line is a family marker in its own right.

[DOCUMENTED] The full chain runs in about twenty seconds — 13:49:30 to 13:49:50 on the first observed instance — and after the key install it profiles the host: `cat /proc/cpuinfo | grep name

awk '{print $4,$5,$6,$7,$8,$9;}', lscpu | grep Model, free -m, df -h, crontab -l, w, top, uname, uname -m, whoami, and ls -lh $(which ls).

[DOCUMENTED] One command in the chain is not reconnaissance. 82 executions from 77 addresses:

rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh; pkill -9 auth.sh;
  echo > /etc/hosts.deny; pkill -9 sleep;

[DOCUMENTED] That removes other actors' hardening scripts, kills their processes, and empties /etc/hosts.deny — disabling TCP-wrapper blocking on the host it has just taken. It is competitor eviction and defence removal in one line.

[DOCUMENTED] The installed key's SHA-256 is a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2. The corpus classifies it family_name: "SSH-key backdoor", severity: 0, no tactics, no technique IDs.

[INFERRED — confidence HIGH] This is Outlaw, also tracked as Dota, Haiduc and Shellbot — a Perl-based cryptomining botnet first documented by Trend Micro in 2018, described by Kaspersky's Securelist and by The Hacker News (April 2025) as "auto-propagating." The name derives from Haiduc, Romanian for a brigand or social outlaw, after the group's SSH brute-force tool.

3. The correction to Letters F, I and J

The claim that this cohort was unexamined is withdrawn.

[DOCUMENTED] The operator's published archive contains, at minimum:

[DOCUMENTED] TI-2026-012 was published 2026-05-12 — before Letters F, I and J were written. It carries a YARA rule, Outlaw_mdrfckr_2026, whose string set is mdrfckr, 345gs5662d34, lockr -ia .ssh, echo > /etc/hosts.deny, chattr -ia .ssh, .mountfs/.rsync/ and .satan.

Every marker I "found" this afternoon is a literal in a rule this operator wrote in May.

[DOCUMENTED] And it documents the toolkit rotation in full, which no letter in this series knew about:

[DOCUMENTED] The rotation happened 2026-04-21, and the dossier's point is the operationally important one: "any detection system tracking only the old fingerprint would see a dying campaign while the botnet was actually growing." The key blob and comment, the 345gs5662d34 marker, the hardware-profile chain and the rival-cleanup routine are identical across both waves. Only the library version changed.

[DOCUMENTED] One further detail from that dossier is a better forensic marker than anything in this addendum: the key's RSA exponent is 0x25 (37). ssh-keygen defaults to 65537. The key was not generated by the standard tool, and it has been in continuous use for six years.

Why three letters missed it

[INFERRED — confidence HIGH] Letter J diagnosed the mechanism correctly — the artefact sits in the download table, outside every key-clustering tool's reach — and then drew the wrong conclusion from its own diagnosis. That the automated tooling cannot see an object is not evidence that nobody has looked at it. The archive is not a clustering tool; it is a set of documents, and it is searchable.

[DOCUMENTED] This is the second occurrence of the same failure in this series. Letter J's own closing recorded the first: "nine letters re-derived already-published findings" because dossier_crosslinks was not run in Letter A. The lesson was written down, published, and then not applied to the very object the same letter was flagging.

Rule R23. Before describing any object as unexamined, unattributed or uncharacterised, search the published corpus for it. An absence in the tooling is a fact about the tooling (R8); an absence in the archive requires querying the archive.

4. One hundred and thirteen is not the botnet

[DOCUMENTED] Letter F reported 113 machines. TI-2026-012 reported 1,639. Both are correct and they count different things.

[INFERRED — confidence MEDIUM-HIGH, unit caveat per R6] 113 of 1,639 is a ~6.9% brute-force-to-execution conversion — the fraction of a spraying botnet's nodes that got far enough to do anything. The caveat is real: the windows are not identical, and the 1,639 is bounded by TI-2026-012's 2026-03-28→05-12 collection while the 113 spans the full four months.

[DOCUMENTED] The distinction matters for how Letter F's finding should be read. Letter F set the cohort against the beacons — "113 machines, a population larger than the beacon class by an order of magnitude" — and that comparison holds. But 113 is not the size of the adversary. It is the size of the adversary's success against this sensor, which is a fact about the accept list as much as about the botnet.

The dispersion, which is the honest local finding

[DOCUMENTED] The 113 addresses sit across 72 autonomous systems in 35 countries, mean threat score 77.9, with only 17 carrying any GreyNoise record at all. 1.57 nodes per ASN.

[DOCUMENTED] Below that: a long tail of one and two nodes each across Oracle, Google Cloud, OVH, Hetzner, Liquid Web, Network Solutions, China Telecom, China Unicom, Viettel, Bharti Airtel, and telcos in Brazil, Bolivia, Paraguay, Venezuela, Colombia, the Dominican Republic, Nigeria, Morocco, Pakistan, Thailand, Indonesia, Turkey, Macau and Moldova.

[DOCUMENTED] 106 of the 113 addresses appear exactly once. Six appear twice; one appears three times.

[INFERRED — confidence HIGH] This is a victim population, not a rented one. Azure being the largest single contributor is not a finding about Microsoft; it is what a self-propagating worm looks like when the internet's compromised-host population is sampled. Set it against the other two populations this series measured:

The fleet and the cohort are almost the same size and are opposite objects. One is a network someone paid for; the other is a census of machines someone else lost.

5. D14 — R1 was never "accept-all"

This is the correction that matters, and it is to the series' own spine.

[DOCUMENTED] Letter O's §9 established three sensor regimes and named the first "accept-all", on the evidence that R1 (2026-03-21 → 05-20) recorded 11,781 connections and 11,781 successes — exactly 100.0% for sixty-one consecutive days. That figure is correct. I re-ran it:

sessions 11,781 · successes 11,781 · 100.00%

[DOCUMENTED] The credential store, over the same window, does not agree with the name:

[DOCUMENTED] 82,921 credential attempts with a non-empty password were refused inside the "accept-all" regime. Among them, the Outlaw marker credential: 345gs5662d34/345gs5662d34, 67 attempts from 66 addresses in R1, every one rejected — and across the full corpus, 120 attempts from 110 addresses, plus five variants under root, admin, ubuntu, pi and test. Two hundred and forty-three marker attempts. Zero successes.

Both numbers are true

[INFERRED — confidence HIGH] There is no contradiction. A session is recorded successful if any attempt within it succeeds. In R1 every attacker's wordlist eventually intersected the sensor's accept list, so no session was ultimately refused — while nine attempts in ten still failed.

[DOCUMENTED] "Accept-all" is a statement about outcomes. It was used as a statement about the accept list. Those are different claims, and only the first is supported. The correct name for R1 is no-refusal: not one session was turned away, because every wordlist that reached the sensor contained at least one accepted pair.

[DOCUMENTED] Letter E established independently, and from a different direction, what the accept list actually was: admin/password opens the door while admin/admin123 does not; root/1234 works while admin/1234 does not. Letter E's conclusion — "the accept set was enumerated by hand" — is now shown to hold in R1 as well, not only after the regime changed. The sensor's behaviour did not become selective on 2026-05-21. Its list was always a list. What changed was how much of it the arriving wordlists happened to cover.

[INFERRED — confidence HIGH] The error is R6 — connection versus attempt — committed inside the letter that issued R6. Letter O measured a session-level rate, and named a regime with an attempt-level word.

Rule R21. A regime is named for what the sensor's accept list does, never for an aggregate success rate. Before labelling any collection period, compute the rate at both units in the same window; where they disagree, the label describes neither and must be stated as the measured outcome instead.

6. What the correction costs, and what it does not

[DOCUMENTED] The arithmetic of D8 is untouched. The three regimes are real, dated by two independent boundaries; the R1/R2/R3 session-success figures of 100.0% / 46.2% / 7.2% stand; the regime-local baselining that R10 requires stands; the 255× sensitivity figure stands. Nothing that was computed changes. One thing that was named changes.

[DOCUMENTED] What does move:

[INFERRED — confidence HIGH] The most useful consequence is for the cohort in §2. Outlaw ran its marker credential against this sensor 243 times and was refused every time, including 67 times during the period the series described as accepting everything. Whatever that credential is for — and §8 addresses what it is for — the sensor answered it correctly for four months, and the series had published a name for the sensor that predicted otherwise.

7. D15 — the column that stopped moving

[DOCUMENTED] honeypot_fingerprints holds 261,863 rows across 9,435 addresses. Its timestamps:

min(first_seen)  2026-03-21T08:03:31Z
max(first_seen)  2026-07-30T16:28:45Z     ← live
max(last_seen)   2026-05-21T12:00:06Z     ← frozen, all 261,863 rows

[DOCUMENTED] first_seen advances to the present. last_seen stops dead at 2026-05-21T12:00, within half an hour of the registry backfill sweep at 2026-05-21T11:32:48 that produced D1 and R12.

[DOCUMENTED] Row creation continues normally across the freeze — 15,522 rows in March, 55,512 in April, 42,593 in May, 13,871 in June, and 134,365 in July, the largest month in the table. The table is healthy. One column in it is not.

The false finding this produced

[DOCUMENTED] Grouping the table by client_version and reading max(last_seen) returns, for every SSH client family without exception, an end date on or before 2026-05-21. I had written down "the Outlaw libssh waves cease 2026-05-21" — a clean, plausible, publishable claim that would have contradicted TI-2026-012's "still running", contradicted the cohort's own installs through 2026-07-29, and been entirely an artefact of a stalled column.

[DOCUMENTED] What caught it was the control: a column that reports the same end date for libssh, libssh2, Go, PUTTY and every other client is not describing the world. R15 and R16 — verify a non-empty control, run a saturation control — generalise here to a third form.

Rule R22. Before deriving any ended, ceased or last active claim from a timestamp column, verify the column advances: compare its maximum against the corpus end date. If the maximum is constant across unrelated groups, it is a write artefact and carries no temporal information.

[INFERRED — confidence HIGH] This is the third distinct date-field defect in one corpus — honeypot_ips.first_seen (D1/R1), honeypot_ips.last_seen (D9/R12), and now honeypot_fingerprints.last_seen. The pattern is no longer a series of accidents. Any timestamp column in this corpus is presumed non-observational until demonstrated otherwise, and that presumption is cheaper than the three retractions it would have prevented.

8. Two things the archive got right and I did not

[DOCUMENTED] The marker credential. I read 345gs5662d34/345gs5662d34 as a honeypot canary — a pair that cannot exist on a real host, so success proves the target accepts everything and the bot should leave. TI-2026-012 reads it as a propagation marker: Outlaw sets that credential on machines it takes, and other nodes use it to recognise an already-owned host and skip it. The dossier records the wider behaviour as bot-on-bot poaching, quoting a researcher: "The bots have become self-referential. They are brute-forcing the passwords that other bots set."

[DOCUMENTED] My data cannot distinguish the two readings. Both predict exactly what was observed — the credential fails, and the bot proceeds. A canary reading predicts fail → not a honeypot → proceed; a marker reading predicts fail → not yet owned → take it. The observation is identical under both. The published reading has independent corroboration across four honeypots; mine had a plausible story. Per this series' own standard, the disagreement is resolved by evidence and not by which of us wrote it.

[DOCUMENTED] R18, confirmed from a direction Letter J did not use. Letter J corrected the fleet's client from libssh2 to SSH-2.0-Go on the strength of session banners, and issued R18 — the banner is authoritative over a HASSH tool_name. The raw client_version column for AS197170 agrees, and by a wide margin:

[DOCUMENTED] 65,037 of 65,386 fingerprinted fleet sessions — 99.5% — announce themselves as Go. Letter J reached the right answer from a banner sample; the full column carries it independently. The eleven fleet nodes presenting libssh_0.12.0 are the more interesting residue: that is the Outlaw second-wave client, on the fleet's network, which §12 declines to interpret.

9. What this addendum establishes

1. [DOCUMENTED] The mdrfckr cohort is Outlaw/Dota/Haiduc/Shellbot, identified by a two-command install pair (123 executions, 113 addresses), a non-standard lockr binary, a fifteen-command hardware profile, and key SHA-256 a8460f44….
2. [DOCUMENTED] CORRECTION: it was never unexamined. Five published dossiers cover it; TI-2026-012 predates the letters that called it uncharacterised and documents the 2026-04-21 HASSH rotation those letters did not know about. Rule R23 issued.
3. [DOCUMENTED] 113 addresses across 72 ASNs in 35 countries, 106 of them one-shot — a compromised, dispersed population, opposite in shape to the 118-address single-ASN fleet.
4. [DOCUMENTED] 113 is not 1,639. It is the subset that reached execution: a ~6.9% brute-force-to-shell conversion, stated with its unit caveat.
5. [DOCUMENTED] D14 / CORRECTION: R1 was never "accept-all." Sessions 11,781/11,781 = 100.00%; credential attempts in the same window 8.21–21.07%, with 82,921 non-empty-password refusals including 67 rejected Outlaw markers. The regime is renamed no-refusal. Rule R21 issued.
6. [DOCUMENTED] D15: honeypot_fingerprints.last_seen is frozen at 2026-05-21T12:00:06 across all 261,863 rows while first_seen runs live to 2026-07-30. Rule R22 issued.
7. [DOCUMENTED] R18 independently confirmed: SSH-2.0-Go on 83 AS197170 nodes and 65,037 sessions — 99.5% of the fleet's fingerprinted traffic.
8. [DOCUMENTED] My canary reading of 345gs5662d34 is withdrawn in favour of the published propagation-marker reading, on the ground that the observation does not discriminate and the published reading has multi-sensor corroboration.

Twenty-three rules. Twelve corrections. Fifteen letters and two addenda.

10. What this addendum could not establish

• Whether the eleven AS197170 nodes running libssh_0.12.0 are Outlaw on the fleet's network, or an unrelated tenant. Letter H established AS197170 is multi-tenant and that ASN co-tenancy is not evidence of common control. The observation is recorded; no link is claimed.
• Whether the R2 dip in cohort activity is real. Installs per regime run 66 nodes in R1, 16 in R2, 33 in R3 — roughly 1.3, 0.4 and 1.0 nodes per day. R2 is also the regime containing the backfill sweep and the degraded-recording cluster from Letter O §9, so the dip may be collection. Per R10 the comparison is inside one detector but across three regimes, and it is not made.
• Why the cohort is regime-insensitive when the burst species are not. It installs across all three regimes at comparable daily rates while Species I and II sort almost perfectly by regime. That is a real asymmetry and this addendum does not explain it.
• What the 15-command hardware profile is scored for. TI-2026-012 reports XMRig Monero mining as the payload. No miner was ever delivered to this sensor — the cohort profiles and leaves. Whether the results are consumed, and by what, is not observable from inside a honeypot.
• Whether severity: 0 on the key hash has caused mis-ranking elsewhere. A persistence artefact scored zero will sink below noise in any severity-ordered view. The classification is reported here as found; its downstream effects are not audited.

The instrument was named for what it did, not for what it was. That took eleven letters, two addenda and a botnet's rejected password to notice.