The Graph

The corpus already knew, the clustering only counts to two, and the client was never libssh2

TI-2026-103J · Series: The Loud Hour · Letter J of 15 Operates under the rules of evidence in Letter O — The Instrument. This letter corrects Letter H, identifies a cohort Letter F could not name, and establishes that most of this series' principal findings were already published. All three are set out below.

1. What this letter is for, and a failure of method

The plan assigned this letter the relationship layer: entity links, campaign membership, actor clusters, and crosslinks to previously published work.

It should have been run first.

[DOCUMENTED] Querying the crosslink layer for the series' two principal actors returns 17 resolved edges into previously published dossiers and their evidence records. 179.43.139.58 — the beacon this series treated as a discovery from Letter B onward — is named in five published dossiers and carries evidence records describing its bursts, its shared SSH client and its HASSH cluster. 91.92.40.202 is named in a published dossier that documents the TechTies operation, its two-phase structure and its tooling.

Letters A through I re-derived, from primary data, findings that were already on the record.

That is not worthless — independent re-derivation from a different starting point is corroboration, and this series produced considerably more detail than the prior work. But it is a methodological failure worth naming precisely: the operator's own guidance specifies the entity graph as the authority for attribution, and this series consulted it in Letter J instead of Letter A. Nine letters of work proceeded without asking what was already known.

The remainder of this letter reconciles the two records, and in doing so overturns a claim made two letters ago.

2. What was already published

[DOCUMENTED] Crosslinks for 179.43.139.58:

[DOCUMENTED] Crosslinks for 91.92.40.202:

Two of these require detailed reconciliation.

3. TI-2026-043L — The Clock had the burst

[DOCUMENTED] A published dossier, TI-2026-043L The Clock (series The Liturgy of Control), documents 179.43.139.58 directly:

*"Daily distribution confirms: Monday = 2,954 sessions. All other days = 87–95 sessions. Source: Honeypot PostgreSQL, temporal API, IP 179.43.139.58 … Then, on **one specific day (Monday), at one specific hour (19:00 UTC / 21:00 CET), it fires 1,554 sessions in a single hour. Fifty-six times normal.* Then 1,363 the [next]…"

[DOCUMENTED] Letter A's census recorded event #5 as 2026-06-22 19:00, two hours, 1,528 + 1,336 = 2,864 connections, with a daily total of 2,947.

[DOCUMENTED] The Clock records the same hour (19:00), the same two-hour shape, a daily total of 2,954, and hourly figures of 1,554 + 1,363 = 2,917.

These are the same event. The largest burst in this series' census — the one Letter A ranked first at 255× local baseline and Letter O spent a section correcting the ratio of — was identified and published before this series began.

[INFERRED — confidence HIGH] The numeric differences (2,947 vs 2,954 daily; 1,528 vs 1,554 hourly) are consistent with connections versus credential attempts, the unit distinction Letter O's rule R6 exists to police. Neither figure is wrong; they count different things, and the ~1.7% gap is the probe-and-overhead margin.

A tension that must be flagged

[DOCUMENTED] The Clock describes the node's baseline as "a mathematically perfect baseline of 22–32 sessions per hour", connecting "approximately every 2 minutes, 24 hours a day."

[DOCUMENTED] This series measures 179.43.139.58 at 8,463 sessions across roughly 130 days — a lifetime average of 2.7 sessions per hour — and approximately 0.7 per hour over the final 30 days.

[DOCUMENTED] A sustained rate of 22–32 sessions per hour over 30 days would produce 16,000 to 23,000 sessions in that window alone, which exceeds the address's entire recorded lifetime. The two descriptions cannot both characterise the same window.

[INFERRED — confidence MEDIUM, flagged for reconciliation rather than asserted] The most likely explanation is the aggregation trap this series met in Letter O's D4: the per-IP temporal endpoint returns an hourly_distribution array whose values are sums per hour-of-day across the whole window, not sessions per hour. For this address those values run 16–34 — the same range The Clock reports as an hourly rate. This investigation nearly made the identical misreading and was caught only by cross-checking against the session total.

This is raised as a reconciliation item, not a correction. The Clock's full text has not been read here; only a retrieved excerpt. What is established is that a numeric tension exists between two published accounts of the same address, and that resolving it requires reading both against the session store. Letter O's rule R1 — chronology and volume from the session store, never from a derived aggregate — applies to this series' own back catalogue as much as to anything else.

4. TI-2026-050B — the operation has grown fifty-fold

[DOCUMENTED] TI-2026-050B The Validate-Then-Recon Pipeline: Go_SSH Two-Phase Operations (series The Toolmakers) documented the TechTies operation, and its reasoning is preserved in the evidence record:

*"Evidence against: The Go_SSH operator uses TechTies specifically for the command-execution role — the ONLY two IPs (of 320) that run post-auth commands. If TechTies were just another hosting provider, why wouldn't other TechTies IPs appear in the validation fleet?"*

[DOCUMENTED] At the time of that dossier: two TechTies addresses ran post-authentication commands, out of 320 addresses in the observed campaign.

[DOCUMENTED] This series measures, four months later: 125 active TechTies addresses, 130,565 attempts, 1,590 successful logins and 2,632 commands executed (Letter H).

[INFERRED — confidence HIGH] The command-execution role expanded from 2 addresses to approximately 45–50 — the number of distinct addresses observed running uname -s -v -n -r -m — and the surrounding fleet from a supporting role to 125 addresses carrying the majority of this sensor's traffic. TI-2026-050B caught the operation in its pilot phase; this series caught it at scale.

[DOCUMENTED] TI-2026-050B also framed the correct question and left it open, weighing "Hypothesis B: Same Organization, Different Tools — One organization operates both campaigns." Letter H answers it, and answers it against that hypothesis: AS197170 is multi-tenant, carrying an inventory fleet, a wallet-and-secrets thief and a marker-leaving third party simultaneously. The prior dossier's own counter-argument — "different operators frequently use the same bullet-proof hosts" — turns out to be the correct reading.

5. Correction — the client is Go, not libssh2

A claim in Letter H is corrected.

Letter H stated that the fleet is "comprehensively fingerprinted as libssh2_1.11.1", on the strength of the HASSH taxonomy's tool_name field for hash 0a07365cc01fa9fc82608ba4019af499.

[DOCUMENTED] The session records carry the actual client banner. Four fleet sessions retrieved independently:

45.156.87.204   hassh=0a07365cc01fa9fc82608ba4019af499   client=SSH-2.0-Go
45.156.87.253   hassh=0a07365cc01fa9fc82608ba4019af499   client=SSH-2.0-Go
45.153.34.167   hassh=0a07365cc01fa9fc82608ba4019af499   client=SSH-2.0-Go
45.153.34.165   hassh=0a07365cc01fa9fc82608ba4019af499   client=SSH-2.0-Go

[DOCUMENTED] The client is SSH-2.0-Go — the Go crypto/ssh library — not libssh2. The HASSH hash is correct and the population it identifies is correct; the tool_name label attached to that hash in the fingerprint taxonomy is wrong.

[DOCUMENTED] The prior published work had this right. TI-2026-050B is titled "The Validate-Then-Recon Pipeline: Go_SSH Two-Phase Operations", and Letter H's own ASN data listed a separate Go_SSH fingerprint on 18 addresses in the same ASN without the significance being noticed.

Rule R18. The SSH client banner recorded on the session is authoritative for client identification. A HASSH tool_name is a label applied by the taxonomy, not an observation, and must be verified against the banner before being cited.

[INFERRED — confidence MEDIUM] This also explains a loose end. Letter H reported three fingerprints on AS197170 — libssh2_1.11.1 (50 addresses), PuTTY (50), Go_SSH (18) — and treated them as three tools. If the largest is mislabelled, the ASN's tooling picture is simpler than it appeared, and the Go_SSH entry may be the same client correctly labelled on a different hash. That reconciliation is not attempted here.

This is the second time a derived label has misled this series, after Letter H's own correction of an inference drawn from an empty campaign_ids field. Both errors share a shape: a convenience field was read as an observation.

6. Letter F's fingerprinting cohort, identified

[DOCUMENTED] Letter F documented a 2,600-character payload — layered uname fallbacks, CPU and GPU profiling, and an explicit ===SHELL_BEHAVIOR=== honeypot-detection routine — executed 751 times by 27 unnamed addresses, and could not attribute it.

[DOCUMENTED] Session records retrieved here carry it, with attribution:

[DOCUMENTED] All three run the identical `export PATH=…; uname=$(uname -s -v -n -m 2>/dev/null

[DOCUMENTED] AS47890 UNMANAGED-DEDICATED-SERVERS (UNMANAGED LTD, GB) is the ASN Letter H independently profiled: Spamhaus ASN-DROP, flagged bulletproof, risk 87.26, taking transit from AS1299 Arelion, AS9002 RETN, AS9050 and AS12302.

[INFERRED — confidence HIGH] The honeypot-detection and GPU-profiling cohort is hosted on AS47890 under the RDAP organisation names DMZHOST and TECHOFF SRV LIMITED. Both names appear elsewhere in this corpus — 195.178.110.x addresses in Letter E's credential data carry DMZHOST TECHOFF SRV LIMITED as their AS48090 organisation — so the same operator identity spans at least two autonomous systems.

That is a genuine new link, and it is the kind the graph layer exists to produce.

7. The clustering layer counts to two

[DOCUMENTED] Against the groups this series has established, the corpus's own clustering:

[DOCUMENTED] honeypot_operator_clusters — described as grouping "IPs linked by shared identity evidence (shared SSH keys, shared malware)", approximating "distinct threat operators" — returns zero clusters of three or more members across the entire corpus.

[DOCUMENTED] The SSH key layer explains why it cannot do better. Of 284 keys classified actor_reuse across 568 IP associations, every single key has ip_count: 2 — 263 ssh-rsa keys covering 526 addresses, 19 ssh-ed25519 covering 38, 2 ssh-dss covering 4. The arithmetic is exact: 284 × 2 = 568. And with_campaign: 0 — not one of the 284 keys carries a campaign.

[INFERRED — confidence HIGH] The key-reuse layer records only pairs. A key observed on three or more addresses either does not occur or is not represented, and since the corpus demonstrably contains a key installed by 113 addresses, the second is true.

[DOCUMENTED] The reason is a category distinction the layer does not bridge. The 284 actor_reuse keys are client authentication keys offered during SSH handshake. The mdrfckr key is a public key written into authorized_keys by a shell command — recorded as a download artefact (sample a8460f44…), not as an SSH key. The two live in different tables, and no clustering crosses between them.

[INFERRED — confidence HIGH] This completes a pattern running through the series. The campaign linker clusters beacon pairs and misses a 118-address fleet (Letter H). The operator clusterer returns nothing at size ≥3. The key layer records only pairs. The CVE linkage is unpopulated (Letter I). Every derived relationship layer in this corpus either counts to two or does not count at all, while the largest real groups — 113, 118, 125 — pass through unrepresented.

That is Letter N's central engineering problem, and it is now specified rather than gestured at.

8. The web/SSH overlap — Letter I revisited

[DOCUMENTED] Letter I concluded, from two forward and two reverse tests, that the SSH and web attacker populations are disjoint, and flagged explicitly that "two forward and two reverse tests is not a census."

[DOCUMENTED] The crosslink collection documents a relationship type same_ip_web_and_ssh with 1,751 links — addresses present in both the web-threat and SSH corpora.

[DOCUMENTED] The disjointness does not hold corpus-wide. Letter I's extremes are genuinely disjoint — the largest web exploiter has no SSH sessions, and the largest SSH beacons throw no recognised web exploits — but across the full corpus, 1,751 addresses appear on both sensors.

[INFERRED — confidence MEDIUM] The likely structure is that specialists are disjoint and generalists overlap: an address running a 762-attempt SSH job or 26,806 PHPUnit requests is doing one thing at industrial scale, while the broad commodity population sprays both surfaces opportunistically. Letter I's caution was correct and its conclusion was over-generalised from its sample.

[DOCUMENTED] This letter has not enumerated the 1,751 links; the figure is the collection's documented size. Establishing which populations they belong to is unfinished work, and it belongs in the synthesis.

9. What this letter establishes

1. [DOCUMENTED] 179.43.139.58 appears in five published dossiers (TI-2026-038A, 038C, 023B, 042V, 056E) and findings in TI-2026-023A and 042V. 91.92.40.202 appears in TI-2026-050B.
2. [DOCUMENTED] TI-2026-043L The Clock published this series' largest burst — same address, same 19:00 hour, same two-hour shape, 2,954 vs 2,947 daily.
3. [DOCUMENTED] A numeric tension exists between The Clock's stated 22–32 sessions/hour baseline and this series' 8,463-session lifetime; both cannot describe the same window. Flagged for reconciliation.
4. [DOCUMENTED] TI-2026-050B observed 2 command-running TechTies addresses of 320. This series measures 125 active addresses and 2,632 commands — the operation scaled roughly fifty-fold, and the prior dossier's open hypothesis is now answered against by Letter H's multi-tenancy finding.
5. [DOCUMENTED] CORRECTION: the fleet client is SSH-2.0-Go, not libssh2. The HASSH hash and population are right; the taxonomy's tool_name label is wrong. R18 — the session banner is authoritative.
6. [DOCUMENTED] Letter F's 27-address honeypot-detection cohort is AS47890 UNMANAGED LTD, RDAP organisations DMZHOST and TECHOFF SRV LIMITED — names that also appear on AS48090, so one operator identity spans two ASNs.
7. [DOCUMENTED] Every derived relationship layer counts to two or not at all: operator clusters total: 0 at size ≥3; all 284 reuse keys at ip_count: 2 exactly; with_campaign: 0; CVE linkage unpopulated.
8. [DOCUMENTED] same_ip_web_and_ssh holds 1,751 links — Letter I's disjointness is true at the extremes and false corpus-wide.

10. What this letter could not establish

• The full content of TI-2026-043L and TI-2026-050B. Both were read as retrieved excerpts. The reconciliation in §3 and §4 should be redone against their full texts before either is treated as settled.
• Which of the 1,751 web/SSH overlapping addresses belong to which population. The count is documented; the membership is not enumerated.
• Whether the Go_SSH HASSH entry on 18 AS197170 addresses is the same client on a different hash. §5 raises it; the reconciliation is not attempted.
• Who operates the mdrfckr cohort. Still unexamined after three letters flagged it. The 113-address key group remains the largest uncharacterised object in the corpus, and the reason it keeps escaping is now understood: it lives in the download table, not the key table, so no clustering tool reaches it.
• Whether the prior dossiers' actor attributions agree with this series'. Crosslinks establish that the same addresses were studied; they do not establish that the same conclusions were reached.

The first point governs the rest. This letter compares two records through search snippets, and snippets are exactly the kind of partial evidence Letter O was written to distrust. The reconciliation is begun here, not finished, and anyone using it should read the source dossiers rather than this summary of them.

Next: Letter K — The Boring Explanations. Every reading in which none of this is about anyone in particular.