The Ledger

Three upstreams, no peers, an ASN younger than its own campaign — and the wordlist, recovered

TI-2026-103H · Series: The Loud Hour · Letter H of 15 Operates under the rules of evidence in Letter O — The Instrument. This letter corrects a substantive error in Letter D and recovers material Letter E reported as unrecoverable. Both are set out in full, in §4 and §6.

1. What this letter is for

Letter G established what the documentary record says about these operators. It found one entity with a real paper trail and several with none, and it left the obvious question standing: if the accountability chain terminates at a village house in Kazakhstan, who is actually carrying the traffic?

An autonomous system cannot route by itself. It needs transit, bought from someone, who bills it, and who can stop. That relationship is a contract between two companies, and unlike a Seychelles mailbox it is a real commercial arrangement with a real counterparty.

This letter follows the money and the packets rather than the paperwork. What it finds is that the fleet's entire global reachability rests on three transit relationships and nothing else — no peering, no internet exchanges, no public presence at all — and that the autonomous system carrying 130,565 attack attempts against this sensor was allocated seven weeks before the campaign against it started.

Along the way it corrects a claim in Letter D that was simply wrong, and recovers the 761-entry wordlist that Letter E had to leave unopened.

2. The transit chain

[DOCUMENTED] AS197170 TechTies Inc., operator of every R3 burst event, has the following routing posture:

[DOCUMENTED] The three upstreams:

[DOCUMENTED] AS213438 is ColocaTel Inc. — and it appears independently in Letter E's data as itself a source of admin/123456 attempts against this sensor (45.129.231.10, threat 70, abuse 100). The fleet's largest transit provider is also, separately, an attacker.

[DOCUMENTED] The PeeringDB record for AS197170 is entirely empty — every field null. Its apparent PeeringDB entry is sourced from ripestat, meaning the routing data came from RIPE's own measurement rather than from any self-published profile. TechTies has no PeeringDB presence, no peering policy, no listed facilities, no looking glass and no route server.

[INFERRED — confidence HIGH] This is a pure transit customer with no interest in being reachable as a network. A hosting company that wants business publishes a PeeringDB profile, joins an exchange, and peers — it is cheaper and faster. An operation that expects to be disconnected buys transit from three providers and lists nothing, because peering requires counterparties who will ask questions and exchanges have membership committees.

The accountability that exists is here. Three companies bill AS197170 monthly. Any one of them could stop, and no committee, regulator or registry needs to be consulted. Nobody has.

[DOCUMENTED] The corresponding structure for entities examined elsewhere in the risk data shows the same shape at larger scale: AS47890 UNMANAGED LTD — Spamhaus ASN-DROP, flagged bulletproof, and present in Letter E's credential data with 12 addresses — takes transit from AS1299 (Arelion), AS9002 (RETN), AS9050 and AS12302. AS1299 is a tier-1 carrier. AS9002 RETN is the same autonomous system named alongside Private Layer in the RIPE 77 Anti-Abuse presentation cited in Letter G.

[INFERRED — confidence MEDIUM-HIGH] The bulletproof layer is not disconnected from the mainstream internet; it is retail-attached to it through ordinary transit contracts with carriers that have abuse desks, legal departments and reputations. That is the ledger, and it is the only page in this investigation where a name with an address could act unilaterally.

3. The autonomous system is younger than the campaign

[DOCUMENTED] The enrichment store records AS197170's allocation as allocated_at: 2026-05-29, RIR ripencc.

[DOCUMENTED] The fleet's earliest observed contact with this sensor, from fingerprint records that are not subject to the registry's sweep artefacts, is 2026-06-11 (91.92.42.19), with 91.92.42.147 on 2026-06-15 and 91.92.40.171 on 2026-06-17.

[DOCUMENTED — flagged for RIR confirmation] If allocated_at is the RIR allocation date, the autonomous system was thirteen days old when it began attacking this address, and seven weeks old at the peak of its campaign.

The caveat is necessary and this series has earned it. Two date fields in this corpus have already proved to be pipeline artefacts (Letter O's D1, Letter B's D9), and 2026-05-29 falls eight days after the registry backfill sweep of 2026-05-21. This date is reported as an enrichment-store value requiring confirmation against the RIR, not as an established fact. It is included because if true it is one of the most consequential facts in the series, and because Letter C independently established that the prefix 91.92.40.0/24 was allocated 2025-07-17 — eleven months before use.

[INFERRED — confidence MEDIUM] A prefix aged eleven months paired with an ASN aged weeks is the signature of address space acquired and parked, then activated behind a freshly registered autonomous system. The expensive, scarce component is held in advance; the disposable component is created on demand.

4. Correction — the fleet is fingerprinted, and the linker failed

A substantive claim in Letter D is withdrawn.

Letter D stated that the fleet "presents no recordable SSH client fingerprint", that it "falls into the null bucket" of the HASSH taxonomy, and concluded that "a fleet that presents no fingerprint has no toolchain to share." That was an inference from the fleet's empty campaign_ids arrays, and it is wrong.

[DOCUMENTED] The fleet is comprehensively fingerprinted. HASSH 0a07365cc01fa9fc82608ba4019af499 — classified scanner, tool libssh2_1.11.1 — covers 118 addresses and 67,660 sessions, first seen 2026-05-19, last seen 2026-07-30T12:51:46Z.

[DOCUMENTED] Its membership is the fleet, by name:

[DOCUMENTED] Every session of the reference node 91.92.40.202 carries this fingerprint — 1,522 fingerprints against 1,522 sessions in the fingerprint record.

The corrected statement: the fleet's fingerprint is not merely present, it is the highest-volume SSH client fingerprint in the entire corpus. What is absent is a campaign assignment. The failure is in the campaign linker, not in fingerprint capture.

[DOCUMENTED] This makes the underlying detection finding sharper, not weaker. The corpus holds a single fingerprint shared by 118 addresses across 67,660 sessions, and generated no campaign for it — while generating campaigns for beacon pairs sharing a fingerprint at a fraction of that volume. A linker that clusters two machines and misses a hundred and eighteen is not failing for want of data.

[INFERRED — confidence MEDIUM] The most likely mechanism is a threshold or diversity rule — a cluster this large, this homogeneous, or this concentrated in one ASN may be excluded as "infrastructure" rather than campaign. That is a design choice, not a bug, and Letter N takes it.

The error's origin is worth stating: I reasoned from an empty campaign_ids field to an absent fingerprint, without querying the fingerprint directly. An empty derived field is evidence about the deriving process — which is exactly what rule R8 says, applied in the wrong direction by the person who wrote it.

An independent confirmation of the 762-job

[DOCUMENTED] The correction delivers an unexpected dividend. Fingerprint counts land on multiples of 761, while Letter D's session counts land on multiples of 762:

91.92.40.202    1,522 fingerprints = 2 × 761      1,524 sessions = 2 × 762
45.153.34.165   2,283 fingerprints = 3 × 761      2,286 sessions = 3 × 762
twenty nodes      761 fingerprints = 1 × 761        762 sessions = 1 × 762

[DOCUMENTED] The difference is exactly one per job.

A HASSH is recorded when a client negotiates key exchange and offers authentication. Letter D inferred, from an 8.0-second opening connection with no credential followed by a 41-second pause, that each job begins with a probe that does not authenticate. The fingerprint counter, an entirely independent instrument, confirms it: the probe connection produces a session but no authentication fingerprint.

Two counters, derived from different tables, agreeing on a one-per-job offset is the strongest corroboration in the series of any structural claim.

5. Scale — and the July step change, finally settled

[DOCUMENTED] AS197170's total activity against this sensor:

[DOCUMENTED] For comparison, the whole corpus holds 170,038 connections, of which the R3 regime (2026-06-29 to 07-30) holds 136,706.

Letter O declined to explain the July volume step, warning that "two signals sharing a month is not evidence of shared cause." Letter D named the fleet as a candidate and stated explicitly that "the test is whether the fleet's measured connection volume accounts for the measured rise, and that arithmetic has not been done."

It can now be done. [INFERRED — confidence HIGH, with a unit caveat] One autonomous system accounts for 130,565 attempts against an R3 total of 136,706 connections — of the same order as the entire regime. Since Letter D established that fleet jobs generate approximately one credential attempt per connection, attempts and connections are near-equivalent for this population, and AS197170 alone is sufficient to account for the July step change.

The unit caveat is real and per R6 must be stated: total_attempts from the ASN record and connections from the hourly timeline are different counters, and part of the fleet's traffic falls in R2. Against R2+R3 combined (158,185 connections) the fleet is ~83%. Either framing gives the same answer: the step change is the fleet arriving.

[DOCUMENTED] The fleet's own growth curve shows the mechanism. Concurrent active addresses per day: 1 on 06-30, 4 by 07-03, 9 on 07-14, 14 on 07-15, 19 on 07-18, 33 on 07-21, 30 on 07-23 — then contracting to 8, 9, 6, 9, 7, 7 and 3 by 07-30.

[DOCUMENTED] The scale-up coincides precisely with the 2026-07-13/15 inflection that Letter O dated as the step change, and the contraction after 07-23 is visible in the corpus tail. Letter O's caution was correct as a matter of method and is now discharged as a matter of fact.

6. The wordlist, recovered

Letter E stated that the fleet's 761-entry wordlist was "recoverable only by enumerating the credentials record per address, which has not been done." Querying the fingerprint rather than the addresses recovers it.

[DOCUMENTED] Credentials shared across the libssh2_1.11.1 population — 8,699 distinct pairs across 118 addresses, each appearing at ~46–50 addresses, consistent with ~46–50 nodes each walking the same list once:

Service and application accounts: jenkins/jenkins · node/node · mysql/mysql · ftp/ftp · openvpn/12345678 · server/server · debian/debian · ubuntu/ubuntu · administrator/administrator · support/support · testuser/test · labuser/p@ssw0rd

Game servers: minecraft/minecraft · ark/ark

Single-board and IoT: pi/raspberry (364 uses — the highest in the list) · pi/pi

Root password sweep: root/toor · changeme · admin · password · root · 1234 · 12345 · 111 · 000000 · 00000000 · 123123 · 123123123 · 1234567890 · qwerty123 · Qwerty123 · 1q2w3e4r · 1Q2w3e4r · 1q2w3e4r5t6y · passw0rd · Admin123! · admin1234 · Ab123456 · Test1234 · test1234 · linux · redhat

And one that is not English: potok/potok — Russian поток, "flow" or "stream".

[INFERRED — confidence MEDIUM-HIGH] This is not a generic credential list. minecraft, ark, jenkins, node, mysql and openvpn are application-specific service accounts, and their presence tells you what the operator is looking for: game servers, CI/CD runners, database hosts and VPN appliances. Every one of those is a machine with more CPU, more memory or more network than an average host.

[DOCUMENTED] That reading is corroborated from a completely different direction. Letter F documented a payload from 27 addresses profiling CPU model, core count, uptime and NVIDIA GPU presence via lspci. A wordlist hunting game servers and a payload measuring GPUs are the same question asked twice: how much compute is behind this door?

[DOCUMENTED] The mixed capitalisation and symbol patterns — Admin123!, 1Q2w3e4r, Qwerty123, p@ssw0rd — indicate a list assembled from breach corpora or policy-compliant password generators, not from a simple dictionary. Someone curated this.

7. The bulletproof ASN is multi-tenant

The most consequential structural finding in this letter is that AS197170 is not one operation.

[DOCUMENTED] Alongside the mute 762-job fleet, the same autonomous system carries commands that no fleet node has ever issued. Each of the following was executed by one address:

A different SSH backdoor, with a PuTTYgen-style key comment:

chmod +x setup.sh; sh setup.sh; rm -rf setup.sh; mkdir -p ~/.ssh;
chattr -ia ~/.ssh/authorized_keys;
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9…rsa-key-20230629"
  > ~/.ssh/authorized_keys; chattr +ai ~/.ssh/authorized_keys; uname -a

[DOCUMENTED] This is not the mdrfckr key from Letter F. It is a second, distinct backdoor key, and the comment rsa-key-20230629 is PuTTYgen's default naming convention — which explains the otherwise baffling PuTTY HASSH on 50 addresses in this ASN, classified manual.

A systematic host survey, run as discrete labelled stages:

===OSRELEASE===   ===ROOTHOME===   ===PHILHOME===   ===ETC===   ===VAR===
===PROCESSSES===  ===LISTENING===  ===CRONTAB===    ===SUDO_CRON===  ===CRONFILES===
===SYSTEMCTL===   ===ENABLED===    ===DOCKER===     ===DOCKER_COMPOSE===
===ENV===         ===SUDO_ENV===   ===PROFILES===

And a theft sweep:

===WALLETS===  find /home /root /var -name "wallet.dat" -o -name "keystore" -type d
               -o -name "*.keystore" -o -name "wallet.json" -o -name "mnemonic*"
               -o -name "seed*" -o -name "private.key" -o -name "private_key*" -o -name "*.pem"
===SSHKEYS===  find /home /root -name "id_rsa" -o -name "id_ed25519" -o -name "authorized_keys"
===DOTENV===   find … -name ".env" -o -name "secrets.json" -o -name "secrets.yml"

[DOCUMENTED] Cryptocurrency wallet files, mnemonic seeds, private keys, PEM certificates, SSH private keys, .env files and secret stores. This actor is stealing credentials and crypto, and it is hands-on: the survey is staged, labelled for human reading, and includes ls -la /home/phil/ — a specific named home directory.

[DOCUMENTED] Also present: echo BMOK (278 executions, one address) — the marker string Letter F could not place — and echo SSH_OK; whoami; hostname; uptime.

[INFERRED — confidence HIGH] AS197170 is a platform, not an actor. It carries at minimum: a 118-node automated inventory fleet running libssh2 and taking nothing; a hands-on operator harvesting wallets and secrets over PuTTY; and whatever left the BMOK marker. They share a network and nothing else.

[DOCUMENTED] This is what "bulletproof hosting" means, and it explains a difficulty running through the whole series. ASN-level attribution cannot work here. Letters A–F characterised "the fleet" as though AS197170 were an actor; it is a landlord. The fleet is one tenant, and Letter F's "division of labour between populations" is, at least in part, a division between customers of the same provider.

[INFERRED — confidence MEDIUM] This also supplies the missing explanation for the 2,632 commands against 1,590 successes in §5. The fleet issues one command per success; the excess belongs to the other tenants.

8. Who could act

[DOCUMENTED] Consolidating the ledger for AS197170:

[DOCUMENTED] Spamhaus has listed the entire autonomous system under ASN-DROP — the strongest signal that organisation issues. The fleet has continued to operate at 1,045 attempts per address regardless, and was transmitting at 12:51 on the final day of the record.

[INFERRED — confidence HIGH] The enforcement gap is not informational. Every fact needed to disconnect this network is public: a Spamhaus ASN-DROP listing, a bulletproof flag, an average threat score of 87, 83 of 106 addresses rated critical, and three identifiable transit providers. Nothing is hidden. What is missing is any party with both the ability and the incentive to act, and the transit providers — the only ones who could do it in an afternoon — are the ones being paid.

9. What this letter establishes

1. [DOCUMENTED] AS197170 has 3 upstreams, 0 peers, 0 IXPs, 0 downstreams and an entirely empty PeeringDB record. Its transit providers are AS213438 (ColocaTel), AS51396, AS58212; ColocaTel is separately an attacker against this sensor.
2. [DOCUMENTED — pending RIR confirmation] The ASN's recorded allocation date is 2026-05-29, thirteen days before the fleet's first observed contact, against a prefix allocated 2025-07-17.
3. [DOCUMENTED] CORRECTION: the fleet is fingerprinted — libssh2_1.11.1, 118 addresses, 67,660 sessions, the largest fingerprint in the corpus. Letter D's "no fingerprint" claim is withdrawn; the failure is in the campaign linker.
4. [DOCUMENTED] Fingerprint counts are multiples of 761 where session counts are multiples of 762 — independent confirmation of the probe-plus-761 job decomposition.
5. [DOCUMENTED] 130,565 attempts from 125 addresses, 1,590 successes, 2,632 commands, zero downloads, 1,045 attempts per address — sufficient to account for the July step change.
6. [DOCUMENTED] The wordlist is recovered: 8,699 shared pairs including minecraft, ark, jenkins, node, mysql, openvpn — game servers, CI/CD, databases, VPN appliances — plus potok, and breach-corpus password patterns.
7. [DOCUMENTED] AS197170 is multi-tenant. A second actor on the same ASN installs a different SSH backdoor (rsa-key-20230629, PuTTYgen naming — explaining the PuTTY HASSH on 50 addresses) and runs a staged wallet, SSH-key and .env theft sweep including ls -la /home/phil/.
8. [DOCUMENTED] Spamhaus has ASN-DROP'd the network; it operates unaffected. Three transit providers could stop it unilaterally and none has.

10. What this letter could not establish

• Whether allocated_at: 2026-05-29 is the true RIR allocation date. Flagged, not asserted. Requires a direct RIR query. Given two prior date-field artefacts in this corpus, the caveat is not a formality.
• The identities of AS51396 and AS58212. Named as upstreams; not resolved to companies. Together with ColocaTel they are the three parties who could act, which makes identifying them the highest-value follow-up in this letter.
• Whether the wallet-hunting actor and the fleet share an operator. They share an ASN and nothing else demonstrated. Given §7, ASN co-tenancy is now explicitly not evidence of common control — a conclusion that constrains this series' own earlier reasoning.
• Who "phil" is. A specific home directory was enumerated. Whether from a name list or prior knowledge is not established, and the distinction matters.
• Why the campaign linker excluded a 118-address cluster. §4 offers a threshold hypothesis at MEDIUM confidence; the linker's rules have not been read.
• Whether the fleet's contraction after 2026-07-23 reflects a campaign ending, address rotation, or the record simply closing. Three days of decline is not a trend.

The constraint in the third point deserves emphasis, because it cuts against work already published in this series. Letters A through F treated AS197170's behaviour as a single actor's behaviour. §7 shows the network is shared. The 762-job findings survive intact — they were derived from per-node arithmetic, not from ASN aggregates — but any statement of the form "the TechTies fleet did X" must now mean "one tenant of AS197170 did X." The distinction is not pedantic: it is the difference between attributing a campaign to a network and attributing it to whoever rented part of it.

Next: Letter I — Nothing to Exploit. A CVE tied to one autonomous system, and a corpus in which nobody used it.