The Recipe

Seven hundred and sixty-two attempts, twenty doors, one question asked of each

TI-2026-103D · Series: The Loud Hour · Letter D of 15 Operates under the rules of evidence in Letter O — The Instrument. Units per R6: connection = one session record · attempt = one credential presentation · node-connection = connections from a single source address.

Updated 2026-07-30. Two open items in §9 are resolved. One is a straight correction: “why the fleet presents no SSH client fingerprint” was a malformed question — the fleet is fingerprinted, and this letter read an empty index field as an absent observation (R8, applied backwards). Original text unaltered.

1. What this letter is for

Letter A found that twenty of twenty-five burst events in a four-month record belong to a single operator's fleet, and that each of those events is one machine running what appeared to be a fixed-size job: 762 connections, 20 successes, one command per success. The number recurred too exactly to be a coincidence and was confirmed by an hour-boundary straddle test.

This letter takes the job apart.

What it finds is not a brute-force campaign. It is a batch program — one whose input never changes, whose pacing is metronomic, whose output is a single string per opened door, and whose accounting is so rigid that the session totals of a hundred separate machines are arithmetic multiples of the same number.

It also finds that the most mechanically coordinated group in the entire corpus has no campaign assigned to it, for a reason that says more about how coordination is usually detected than about this fleet.

2. The anatomy of one job

[DOCUMENTED] The first job observed from 91.92.40.202 began 2026-06-30T03:12:08.923Z. Its opening sessions, in timestamp order:

[DOCUMENTED] Three properties are immediately visible.

The first connection is different. It lasts 8.0 seconds against 1.3–2.4 for everything that follows, and it is separated from the second by 41 seconds where the subsequent spacing is uniform. A long opening connection followed by a pause and then a regular cadence is the signature of a probe — establish the service exists and characterise it, then begin.

The pacing is fixed. From session 2 to session 28 spans 142 seconds across 26 intervals — approximately 5.4 seconds per connection, with no observed jitter beyond the sub-second variation of the connections themselves.

[INFERRED — confidence HIGH] At 5.4 seconds per connection, 762 connections require roughly 68 minutes. This independently explains the straddle documented in Letter A: a job beginning at 03:12 completes around 04:20, distributing 514 connections into the 03:00 bucket and 248 into the 04:00 bucket. The job size and the pacing predict the split without being fitted to it.

Nothing is in a hurry. 5.4 seconds between attempts is not an attack rate. A brute-force tool aiming at throughput opens parallel connections and pushes hundreds per second; this one walks.

The arithmetic of the input

[DOCUMENTED] 91.92.40.202 presented 761 distinct credential pairs, and in the credentials record each pair carries a count of 2. Its lifetime total is 1,524 connections and 40 successes — exactly two jobs.

Two jobs × 761 distinct pairs, each attempted once per job, gives 1,522 credential attempts. Add the one probe connection per job and the total is 1,524. The accounting closes exactly.

[DOCUMENTED] The job is one probe plus 761 credential attempts. 1 + 761 = 762. Each credential is attempted exactly once per job. Nothing is retried.

[INFERRED — confidence HIGH] A tool that never retries a failed credential is not searching a space; it is walking a list to completion. Retry logic exists in brute-force tooling because network failures produce false negatives. Its absence here means either the operator does not care about false negatives, or the operator already knows which entries will work and the other 741 are padding.

3. Twenty doors, and the same question at each

[DOCUMENTED] A complete job yields exactly 20 successes, confirmed on three independent occasions: 91.92.40.202 assembled across two hour buckets as 13 + 7, and 45.153.34.165 twice at 20 in a single hour. Registry success totals corroborate: 91.92.40.202 at 40 for two jobs, and fleet peers at 60 for three and 80 for four.

[DOCUMENTED] In every one of the twenty R3 burst events, success_count equals command_count exactly. Twenty events, twenty exact equalities.

[DOCUMENTED] The command is always the same. 91.92.40.202's complete command record across its entire lifetime is a single entry:

uname -s -v -n -r -m        × 40

Forty successful logins, forty invocations, one distinct command. Kernel name, version, node name, release, machine architecture. Then the session ends.

[DOCUMENTED] No wget. No curl. No chmod. No file written, no persistence attempted, no second command issued, zero downloads across the fleet.

[INFERRED — confidence HIGH] uname -s -v -n -r -m with those five flags is not a human keystroke; it is a fingerprinting call assembled by a program to populate a record. The job opens a door, asks what kind of machine is behind it, writes that down, and leaves. It is inventory, not intrusion — and it is the maintenance counterpart to the architecture census documented in TI-2026-102A.

[DOCUMENTED] Among the 40 successful sessions the sensor recorded 5 distinct usernames and 16 distinct passwords. So the twenty doors that open are not twenty different accounts — they are a small set of accounts reachable by a slightly larger set of passwords, and the remaining 741 list entries never open anything.

4. One hundred and five machines doing the same arithmetic

This is where the job stops looking like a tool and starts looking like a service.

[DOCUMENTED] 91.92.40.202 has 105 peer addresses within AS197170 present in the same corpus. The ten largest, with their connection and success totals:

[DOCUMENTED] Every success count in the table is an exact multiple of 20 — 80, 80, 60, 60, 60, 60, 40, 40 — with a single off-by-one at 41. Every connection count sits within two of an exact multiple of 762. Three separate machines report precisely 2,286, which is 762 × 3.

[DOCUMENTED] command_count equals success_count for every peer without exception.

[INFERRED — confidence HIGH] A hundred machines whose independent lifetime totals are multiples of the same job size are not a hundred operators using similar tooling. They are a dispatch pool: one job definition, one wordlist, one command, handed out to whichever host is free. Letter A's finding that the dispatch interval is regular in rate (14-hour median) but irregular in timing (4–35 hours) is what a work queue looks like from the receiving end, and this table is the same conclusion from the supply side.

The off-by-one and off-by-two counts are worth stating rather than smoothing. [INFERRED — confidence MEDIUM] A job interrupted mid-run, a connection the sensor dropped, or a duplicate probe would each produce exactly this kind of ±1–2 drift on an otherwise exact multiple. The signal is that the drift is small and bounded, which is itself evidence of a fixed process rather than a variable one.

The outlier that reveals the mechanism

[DOCUMENTED] 91.92.47.123 recorded 1,765 connections and zero successes. Not a reduced number — zero. It ran the job and no door opened.

[DOCUMENTED] It is also the only peer in the table on 91.92.47.0/24 rather than the four /24s that carry every burst event in Letter A's census.

[INFERRED — confidence MEDIUM] If the wordlist were identical and the sensor's accept rule deterministic, an identical job should yield an identical 20. Zero means one of the two differed — a different list version, or a run that fell outside the window in which the sensor's selective-authentication policy accepted those particular credentials. Either way the outlier confirms the general point: the "20" is a property of the pair — this list against this door — and not a capability of the attacker. Letter O made that argument from arithmetic; this machine makes it by failing.

5. D10 — the sessions table cannot tell you what was tried

Status: RESOLVED. Rule issued. Affects any reconstruction of attempt sequences.

Section 2's table records "none recorded" in the credential column for the first 28 sessions of a job. That is not because no credential was presented.

[DOCUMENTED] For 91.92.40.202 the two records disagree by two orders of magnitude:

[DOCUMENTED] The node has 1,524 connections and 40 successes. Five usernames and sixteen passwords describe the 40 successful sessions. The 1,484 failures carry null credential fields, while the credentials record holds all 761 pairs with a count of 2 each.

[INFERRED — confidence HIGH] The session record's username and password columns are populated on successful authentication and left null on failure. This is consistent across the corpus: beacon sessions, which almost always succeed, always show their credential; swarm-event sessions, which never succeed, show null or empty.

Rule R13. Credential attempts are read from the credentials record, never from session rows. Any per-session credential field is evidence about successes only. unique_usernames and unique_passwords in session-derived statistics describe the successful subset and must not be quoted as wordlist size.

[DOCUMENTED] The practical consequence for this letter is that the order in which the 761 credentials were attempted cannot be reconstructed from the record. An earlier reading of this investigation noted that the credentials record appears in lexicographic order — a/a, aaa/123456, aaa/chris, admin/!QAZ2wsx, admin/051178, admin/1 — and considered whether that indicated a sort -u-generated list rather than a likelihood-ordered one. That inference is withdrawn. The ordering is the API's own sort over the credentials table, not the attacker's attempt sequence, and the two cannot be distinguished with the fields available. Letter E takes the wordlist's composition, which is recoverable; its ordering is not.

6. The fleet has no campaign

[DOCUMENTED] 91.92.40.202 carries an empty campaign_ids array. So do 45.153.34.235, 45.156.87.204, 45.153.34.165, 45.153.34.167, 45.156.87.253, 91.92.40.217, 91.92.47.123 and every other fleet node examined.

[DOCUMENTED] Meanwhile every beacon in Letter B carries one: 179.43.139.58 and 94.154.35.215 on hassh-a7a87fbe86774c2e, 87.251.64.176 and 80.66.66.10 on hassh-eff4c24daffc8532, 185.246.128.133 on hassh-57e4cc8ee36c3d78.

The corpus's campaign clustering is built on HASSH, the SSH client-library fingerprint. The fingerprint taxonomy holds 132 distinct HASSH values with named tooling — libssh 0.9.6 at 1,798 addresses, libssh 0.11.x at 1,383, Go crypto/ssh at 506, AsyncSSH, Paramiko, Ncrack, Hydra, PuTTY. The single largest entry in that taxonomy is hassh: null — 2,983 addresses and 14,278 sessions with no fingerprint recorded at all.

[INFERRED — confidence HIGH] The fleet is in the null bucket. It has no HASSH, therefore no HASSH-derived campaign, therefore no coordination label — despite being, by every behavioural measure in this series, the most rigidly coordinated group in the record. A hundred and five machines running a byte-identical 762-attempt job with an identical single command are invisible to the clustering that successfully groups pairs of beacons.

Per R8, the linker's silence is evidence about the linker. Here it is a precise statement about a detection strategy: HASSH clustering identifies shared toolchains, and a fleet that presents no fingerprint has no toolchain to share. Letter J tests whether the entity graph recovers the fleet by another route; Letter N takes the detection consequence, which is that job-arithmetic — connection counts that are multiples of a common divisor — would have found this fleet immediately and no deployed signal did.

7. What kind of program this is

The constraints are now tight enough to describe the software without seeing it.

[DOCUMENTED] It opens one long characterising connection, pauses, then walks a fixed list of 761 credentials at one attempt every ~5.4 seconds, single-threaded, never retrying. On each success it issues exactly one command — uname -s -v -n -r -m — records the answer, and disconnects. It downloads nothing, writes nothing, and attempts no persistence. It runs to completion in about 68 minutes and exits. Its job definition is shared across at least 105 hosts on four /24s of one autonomous system, dispatched at a 14-hour median interval with no diurnal pattern, and it presents no SSH client fingerprint the sensor can identify.

[INFERRED — confidence MEDIUM-HIGH] This is an asset-discovery worker, not an attack tool. Every design decision points the same way: the slow pacing avoids rate-based blocking, the absence of retries accepts false negatives as the cost of throughput across many targets, the single uname populates a database field, and the absence of any payload means the operator's product is the record rather than the access.

[INFERRED — confidence LOW, stated as unresolved] Whether the operator sells that record, uses it to target later, or is a commercial scanning service with a thin legal fiction is not established. Letter K tests the boring readings — including the possibility that this is a security vendor's inventory crawler operating without consent — against the cost structure. Nothing in the mechanism distinguishes a criminal inventory from a commercial one; what distinguishes them is authorisation, and authorisation is not visible in a packet.

8. What this letter establishes

1. [DOCUMENTED] The job is one probe connection plus 761 credential attempts, each attempted exactly once, never retried.
2. [DOCUMENTED] Pacing is ~5.4 seconds per connection, predicting a ~68-minute runtime that independently explains the observed hour-boundary straddle.
3. [DOCUMENTED] A complete job yields 20 successes, and command_count equals success_count for every node and every event without exception.
4. [DOCUMENTED] The only command ever issued is uname -s -v -n -r -m — 40 invocations from 40 successes on the reference node, one distinct command in its entire lifetime.
5. [DOCUMENTED] 105 fleet peers report connection totals within ±2 of exact multiples of 762 and success totals at exact multiples of 20; three separate machines report precisely 2,286.
6. [DOCUMENTED] One peer ran the job to zero successes, confirming the "20" is a property of this list against this door rather than an attacker capability.
7. [DOCUMENTED] D10 — session credential fields are populated only on success; session-derived username and password counts describe successes, not the wordlist.
8. [DOCUMENTED] The entire fleet has no HASSH and no campaign, while looser behavioural pairings do.

9. What this letter could not establish

• The order of the 761 credentials. Withdrawn as unrecoverable (§5). The apparent lexicographic ordering is an API sort artefact.
• Whether all 105 peers run the identical list. Their success totals are consistent with it and one peer's zero contradicts it. The list itself is compared across nodes in Letter E.
• Why the fleet presents no SSH client fingerprint. A custom client, a proxy layer, or a gap in the sensor's fingerprint capture would each produce a null HASSH, and the record does not distinguish them. This is the most important open mechanism question, because the answer determines whether the null is the attacker's choice or the instrument's limit.

⚠ CLOSED — and the question was malformed. The fleet is fingerprinted. Letter H found libssh2_1.11.1 across **118 addresses and 67,660 sessions — the largest fingerprint population in the corpus.** None of the three candidates above applies. The error was mine and it is a straight inversion of R8: I reasoned from an empty campaign_ids field to an absent fingerprint. A derived index's silence is evidence about the index, not the world — **the linker had not clustered the fleet; the sensor had captured it perfectly.** Letter H documents why the linker skipped a 118-address group. Letter J then corrected the fingerprint's label: the session banner reads SSH-2.0-Go, not libssh2, and the banner is authoritative over a HASSH tool_name (R18). So the fleet runs a Go client that hashes to a libssh2-labelled HASSH entry — which is the answer to "custom client?", arrived at from the opposite direction.

• What the operator does with the uname results. Nothing in the corpus observes the downstream consumer.
• Whether this fleet's arrival explains the July volume step. The fleet's scale is large enough to be relevant, and its first appearance (2026-06-15) precedes the step (2026-07-13/15) by a month. Letter O declined to merge the volume step with the burst phenomenon on the grounds that two signals sharing a month is not evidence of shared cause. That caution stands here. The fleet is now a named candidate rather than an established explanation, and Letter K tests it against the alternatives instead of assuming it.

The last point is the one to resist hardest. Having found a hundred-node fleet running a metronomic job through exactly the period when the corpus baseline rose twenty-five-fold, the pull toward declaring the cause found is considerable. A candidate with the right timing and the right scale is still a candidate. The test is whether the fleet's measured connection volume accounts for the measured rise, and that arithmetic has not been done.

### ✅ CLOSED — Letter H did the arithmetic, and the candidate holds. [DOCUMENTED] **AS197170 accounts for 130,565 attempts against an R3 total of 136,706 connections** — of the same order as the entire regime. Because a fleet job generates approximately one credential attempt per connection (§4 of this letter), attempts and connections are near-equivalent for this population. Against R2+R3 combined (158,185 connections) the fleet is ~83%. The R6 unit caveat is real and stated: total_attempts and connections are different counters. The mechanism is the fleet's own growth curve: **1 concurrent address on 06-30, 9 on 07-14, 14 on 07-15, 33 on 07-21**, contracting to 3 by 07-30 — sitting exactly on the 2026-07-13/15 inflection Letter O dated. **Either framing gives the same answer: the step change is the fleet arriving.** The caution in this paragraph was correct and cost nothing. It held the claim for four letters until the arithmetic existed, and the arithmetic then confirmed it — which is the outcome that makes the discipline worth keeping when it does not confirm.

Next: Letter E — Two Words. Seven hundred and sixty-one credentials that open nothing, and two that open everything.