The Census

Twenty-five events, three regimes, two detectors

TI-2026-103A · Series: The Loud Hour · Letter A of 15 Operates under the rules of evidence established 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 §10 are now closed by later letters — the 762-entry wordlist (Letter H) and whether any burst was directed at this host (Letter L) — and a third is half-closed. Original text unaltered.

1. The question a census has to answer first

"How many attacks were there" is not a question the record can answer. "How many hours departed sharply from what surrounded them" is — and even that requires deciding what surrounded them means, because the thing being departed from moved by more than an order of magnitude across the window.

This letter publishes two counts. Neither is "the number of bursts." One is the number of hours in which the sensor as a whole was overwhelmed relative to its local context. The other is the number of times an individual machine departed from its own habit. They overlap only partially, and the second cannot be derived from the first.

That is not a hedge. It is the finding that organises everything after it.

2. Three regimes, not four months

Letter O established that the sensor ran three distinct authentication configurations. The record must be read through them, because a "success" means something different in each:

[DOCUMENTED] R1's success rate was exactly 100.0% on every one of sixty-one consecutive days. R2 contains a zero-success day (2026-05-22: 1,697 connections, no successes) and 59 of the corpus's 104 missing hourly buckets. R3 is stable in configuration but not stationary in volume: its local baseline climbs from ~19 conns/h on 2026-07-01 to ~52 by 2026-07-12 and beyond.

Per R10, every ratio below is computed against a centred 7-day rolling median drawn only from hours in the same regime on days with ≥95% coverage.

3. The corpus census — 25 events

[DOCUMENTED] Detector: hourly connections ≥10× local regime baseline and ≥150 absolute. Result: 41 burst hours, merged at a ≤2-hour join gap into 25 distinct events.

[DOCUMENTED] 41 burst hours — 1.35% of the corpus's 3,040 recorded hours — carry 25,791 connections, 15.2% of all traffic.

[DOCUMENTED] Twenty-two of twenty-five events carry zero downloads. The three exceptions carry one each. In 25,791 connections across four months of the loudest hours in the record, five files were fetched.

A correction carried forward

An earlier draft of this series scored event #5 at 382×, using a rolling median that drew on hours from a 61.1%-coverage window. An interim sensitivity estimate against a month-wide healthy mean gave 122×. The R10-compliant figure — same regime, ≥95% coverage only — is 255×. All three describe the same 1,528 connections; they differ only in what those connections are compared against. 255× is the published figure, and the range is stated because a single number with no visible sensitivity is a number asking to be trusted rather than checked.

The direction of the original error is worth naming: the degraded window depressed the baseline and inflated the ratio. Collection failure does not make events look smaller. It makes them look bigger.

Sensitivity of the count

A census that picks a threshold owes the reader the shape of the curve behind it. Twenty-five is not a fact about the world; it is what this detector returns at this setting.

[DOCUMENTED] The count degrades gracefully. Roughly nineteen to twenty-two events survive even at 15–20×, so the census has a hard core that is not an artefact of the cutoff; the number only begins to inflate below 8×, where ordinary busy hours start qualifying.

[DOCUMENTED] One detail matters more than the table. At ratio ≥10, the absolute floor of 100 and of 150 both yield exactly 41 hours — the second criterion is inert at the published setting. Every hour reaching ten times its local regime baseline already carries well over 150 connections. The census is therefore, in practice, a pure ratio test; the absolute floor exists only to prevent a quiet regime from manufacturing bursts out of single digits, and in this record it never has to.

4. Who was in the room

[DOCUMENTED] Each event's peak hour was drilled to its dominant source. Share = node-connections ÷ bucket connections.

[DOCUMENTED] Twenty-three of twenty-five events are single-node dominated. Nineteen exceed 90% share. Only events #2 and #4 — at 4.5% and 9.0% — are genuinely distributed.

This is the census's central structural result. A burst in this record is almost never a crowd. It is one machine. The intuition that a traffic spike means "an attack" — many adversaries converging — is contradicted 23 times out of 25.

5. Three species

[DOCUMENTED] The events sort cleanly, and the regimes sort them almost perfectly:

Species I is 179.43.139.58 — AS51852 Private Layer INC — three times, on 2026-03-29, 05-23 and 06-22. Each time it takes essentially the whole hour, authenticates on every attempt, and types nothing. Letter O voids "100% success" as evidence in R1; the zero-command trait survives everywhere, because command capture was never suppressed by any regime.

Species III appears only in R2 and only twice: 61 sources on 2026-05-21 and 25 on 05-27, with the busiest contributing 20 and 17 connections respectively, near-zero successes, and null or empty usernames. These are protocol-level probes, not credential attacks — the only events in the record that look like what people picture when they say "distributed attack."

Species II accounts for 20 of 25 events and every single R3 event. It is examined next, because it is not a species so much as a machine.

6. R3 is a monoculture

[DOCUMENTED] Every one of the twenty R3 burst events is dominated by a node in one of four /24s:

45.153.34.0/24    45.156.87.0/24    91.92.40.0/24    91.92.42.0/24

[DOCUMENTED] Sixteen distinct addresses across twenty events, all presenting as Netherlands. Those confirmed by registry lookup — 91.92.40.202, 45.153.34.165, 45.153.34.167 — all resolve to AS197170 TECHTIES-AS, TechTies Inc., registered at 306 Victoria House, Victoria Mahé, Seychelles, with RIPE maintainer mnt-bg-eurocrypt-1 and an entity-resolution verdict of rebrand.

[INFERRED — confidence HIGH] The remaining thirteen addresses belong to the same operator, on prefix adjacency and identical behavioural signature. Letter C establishes the attribution formally; Letter H runs the institutional-anchor pass.

Three addresses recur: 45.153.34.165 in events #7, #9 and #23; 45.153.34.235 in #16 and

#21; 45.156.87.147 in #11 and #24. The other thirteen appear once each. The fleet rotates addresses between jobs but reuses them freely — this is not burn-after-use infrastructure, and Letter K takes up what that implies about cost and intent.

[DOCUMENTED] In every R3 event, success_count equals command_count exactly. Twenty events, twenty exact equalities. Every successful login runs precisely one command and then stops.

7. The 762-job

The most mechanical finding in the census, and it was found by chasing what looked like a bug.

[DOCUMENTED] 45.153.34.165 recorded 762 connections and 20 successes in the hour 2026-06-30 19:00, and 762 connections and 20 successes again in 2026-07-02 11:00 — two different hours, two days apart, identical triples. Two independent endpoints agree, and in both hours the per-source counts sum exactly to the bucket total (776 and 870).

[DOCUMENTED] The suspicion that this was an endpoint returning lifetime totals is refuted: that address's lifetime total is 2,286 = 762 × 3.

[DOCUMENTED] 45.153.34.167 also totals 2,286. 91.92.40.202 totals 1,524 = 762 × 2, and its registry success count is 40 = 20 × 2.

[DOCUMENTED] The straddle test confirms the unit. 91.92.40.202 shows 514 connections and 13 successes in 2026-06-30 03:00, and 248 connections and 7 successes in 04:00. 514 + 248 = 762. 13 + 7 = 20.

[DOCUMENTED — with n=3] The job is 762 attempts. A complete job yields 20 successes. Where an event shows fewer than 762, the job straddled an hour boundary or the bucket caught part of it; where it shows fewer than 20 successes, the same. Complete-job observations are 91.92.40.202 (assembled from two buckets) and 45.153.34.165 twice.

[DOCUMENTED] 91.92.40.202 presented 761 distinct credentials. A 762-attempt job containing 761 distinct credentials is a fixed wordlist of 761 entries with exactly one repeat.

[INFERRED — confidence HIGH] The identical success count across complete jobs implies both a fixed wordlist and a deterministic accept rule on the sensor side. The same list run twice against the same door opens the same twenty times. This is a property of the pair, not of either alone — and it means the "20" measures the honeypot as much as the attacker. Letter D develops the mechanism; Letter E takes the wordlist itself.

The 762-job is why Species II should not be called a brute-force campaign. Nothing about it adapts. It is a batch process with a fixed input, dispatched to a rotating set of hosts, whose only output is a uname string per opened door.

How often the job runs

[DOCUMENTED] The twenty R3 events span 2026-06-30 03:00 to 2026-07-12 22:00 — 307 hours containing 20 dispatches, one per 16.2 hours on average. Interval between consecutive peaks:

[DOCUMENTED] Of nineteen intervals, five fall under 12 hours, eleven between 12 and 24, and three exceed 24. The dispatch is regular in rate but irregular in timing — this is not a cron entry firing on a fixed schedule, or the intervals would cluster tightly around a single value instead of spreading from 4 to 35 hours.

[DOCUMENTED] The peaks land in 14 of 24 possible hours of the day, spread across the whole clock — 01, 03, 04, 05, 07, 08, 09, 11, 16, 18, 19, 21, 22, 23 UTC. There is no diurnal preference and therefore no working-day signature. Whatever schedules these jobs does not keep office hours in any timezone.

[INFERRED — confidence MEDIUM] A rate that is stable in aggregate but jittered in individual timing is what a work-queue produces: jobs dispatched when a worker frees up rather than when a clock strikes. That is consistent with the rotating-address behaviour in §6 — a pool of hosts drawing tasks — but the record cannot distinguish a queue from a randomised scheduler, and Letter D takes the question up properly.

8. The second census — what the corpus detector cannot see

[DOCUMENTED] The corpus detector returns no events after 2026-07-12.

Bursting did not stop on 2026-07-12. R3's baseline climbs from ~19 conns/h at the start of July to ~52 by the 12th and higher after, so no single node can clear ten times it. The detector is not broken; it is measuring the wrong thing for the second half of the record.

The clearest demonstration is the event that caused this series to exist.

[DOCUMENTED] 94.154.35.215 — AS202412 Omegatech LTD — has connected to the sensor since 2026-03-24 at a rate of two attempts per hour, one roughly every thirty minutes, 48–49 per day, for four months. On 2026-07-29 23:00 it produced 1,042 attempts in one hour, then 202 in the next, then returned to two per hour. That is 348× its own baseline, and the only two anomalous hours in its entire four-month record.

[DOCUMENTED] Against the corpus, that same hour reaches roughly 2–13× depending on unit. It does not appear anywhere in the table in §3.

[DOCUMENTED] The same address is visible in the drill output of ordinary hours, ticking steadily: exactly 2 attempts in 2026-06-30 19:00, exactly 2 in 2026-06-30 04:00, exactly 2 in 2026-07-02 11:00. The metronome is in the record continuously, underneath everything else in this letter.

A node census and a corpus census answer different questions. The corpus detector finds hours when the sensor was overwhelmed. A node detector finds machines departing from their own habit. Event #5 — one address taking 100% of an hour — is the only case in this record where both would fire on the same event.

Scope of the node census

[DOCUMENTED — stated as a limitation, not a result] A complete node census requires per-address hourly series across the full window for every address in the corpus. The per-address temporal endpoint clamps to 30 days (Letter O, D4), so this cannot be built from it. The node-level findings published in this series are therefore targeted, not exhaustive: they cover 94.154.35.215, 179.43.139.58, 80.66.66.10, 178.16.54.226 and the sixteen R3 fleet addresses named in §6.

There may be node bursts in this record that nobody has counted. That is a statement about what has been examined, not about what exists, and no claim in this series depends on the node census being complete. Letter N specifies the detector that would close the gap prospectively.

9. What the census establishes

1. [DOCUMENTED] 25 events, 41 burst hours, 15.2% of all traffic in 1.35% of hours.
2. [DOCUMENTED] 23 of 25 are one machine, not a crowd. Nineteen exceed 90% share.
3. [DOCUMENTED] 22 of 25 carry zero downloads; five files across all of them.
4. [DOCUMENTED] All 20 R3 events belong to one operator's fleet across four /24s.
5. [DOCUMENTED] success == command in all 20 R3 events, without exception.
6. [DOCUMENTED] The job is 762 attempts, 20 successes, one command per success.
7. [DOCUMENTED] The largest event by local ratio is #5 at 255× — one address, one hour, 1,528 successful logins, zero commands.
8. [DOCUMENTED] The event that prompted this series is not in the census at all.

10. What the census cannot say

• Whether the three regimes changed attacker behaviour or only its measurement. R3 has every Species II event and no Species I event; R1 and R2 have every Species I event and no Species II. Whether that is a real change in who was attacking, or an artefact of a sensor that started refusing logins, is not resolved here. It is the single most important open question in the series and Letters B and K both attack it.

◐ HALF-CLOSED 2026-07-30. The **Species II side is settled and the answer is a real change in who was attacking.** Letter H recovered the fleet's own growth curve — 1 concurrent address on 06-30, 9 on 07-14, 14 on 07-15, 33 on 07-21 — against a first appearance of 2026-06-15 (Letter D). The fleet therefore existed for the last fortnight of R2 at roughly one node and scaled twenty-fold inside R3. **That curve is a property of the fleet, dated independently of the sensor**, so Species II's absence before R3 is the fleet not yet being there at scale — not the auth policy hiding it. [INFERRED — confidence HIGH] The Species I side remains open. Species I is one address, 179.43.139.58, which produced three mute bursts in R1/R2 and none in R3 — and Letter B separately documents that same address slowing from ~2.7 to ~0.7 sessions/hour without explanation. Until that slowdown is accounted for, its silence in R3 cannot be assigned to the attacker or the instrument. **Letter B's open item 3 is the same question wearing different clothes.**

• Whether events #2 and #4 are the same phenomenon as each other. Two swarms, both R2, five days apart, is too few to characterise.
• Why the fleet rotates addresses but reuses them. Observed; unexplained.
• What the 762-entry wordlist contains. Letter E.

✅ CLOSED — Letter H, §6. Letter E could not enumerate it per address; **querying the fingerprint instead of the addresses recovered it** — 8,699 distinct pairs across the 118-address libssh2_1.11.1 population, each appearing at ~46–50 nodes, consistent with each node walking the list once. Service accounts (jenkins, mysql, ftp, openvpn), game servers (minecraft, ark), single-board devices (pi/raspberry, the list's most-used entry at 364 uses), a root password sweep — and one non-English entry, potok/potok, Russian поток, "flow". Its order remains unrecoverable (R13).

• Whether any burst was directed at this host rather than at an address range containing it. Nothing in the census speaks to intent. Letter L sets out what evidence would, and why the record does not currently contain it.

✅ CLOSED — Letter L. Seven criteria were specified and six fail. The beacons predate the publishing system by three months; the tightest temporal coupling runs backwards in time; the address named in eight published dossiers has never once fetched a page from the site that names it; the credentials are a global commodity; the commands are generic; the burst shape matches the corpus. The seventh (C4, comparative attention) is untestable without a control sensor. No burst in this record was directed at this host.

One temptation deserves explicit refusal. The R3 monoculture is a striking result — twenty consecutive events from one operator — and it would be easy to write it as an escalating campaign against this sensor. The census does not support that. It supports a batch process with a fixed wordlist, dispatched from a rotating pool at a median interval of fourteen hours with no diurnal pattern, which has never once done anything with the doors it opened beyond asking what kind of machine was behind them.

An escalating campaign accelerates, adapts its wordlist, or eventually uses an open door. In 307 hours and twenty dispatches, this one did none of the three.

Next: Letter B — The Metronome. What the normal is, that these events depart from.