The Fleet Test

Twenty-two jobs, two hundred and thirty-one chances to act together, and one overlap

TI-2026-103M · Series: The Loud Hour · Letter M of 15 Operates under the rules of evidence in Letter O — The Instrument. This letter measures coordination directly and refines a pacing figure from Letter D.

1. What coordination would look like

Every letter so far has used the word "fleet" — 118 addresses sharing a fingerprint, 125 active in one ASN, four beacons on four continents running the same two credentials. The word carries an implication that has never been tested: that these machines act together.

They might not. A hundred machines running identical software from one hosting provider is not the same thing as a hundred machines receiving an instruction. The distinction matters because it separates a botnet — synchronised, commandable, with an operator at a console — from a work queue, where jobs are handed out as workers free up and nobody is watching.

Coordination leaves specific, measurable traces:

This letter tests all six. Five show no coordination at all. One shows a single instance in 231 opportunities — and it is the same event that produces the only short dispatch gap.

2. Test 1 — when one machine went to 348×, did anything else move?

[DOCUMENTED] The 2026-07-29 excursion: 94.154.35.215 produced 1,042 attempts in one hour against its own two-per-hour baseline.

[DOCUMENTED] Its closest relative — 178.16.54.226, same ASN 202412, same operator, same credential pair, same beacon behaviour — through the identical window:

20:00   2 attempts
22:00   2 attempts
23:00   2 attempts   ← the 348× hour
00:00   2 attempts
01:00   2 attempts
02:00   2 attempts

[DOCUMENTED] It did not move. Not by one connection. Through the largest single-hour excursion in that operator's entire record, its sibling on the same autonomous system held exactly two attempts per hour, before, during and after.

[INFERRED — confidence HIGH] A command moves more than one node. An instruction issued to an operator's fleet — "hit this harder" — would be received by every machine configured to listen. This one was received by nothing. The excursion was local to one process.

[DOCUMENTED] Corpus-wide corroboration: during that hour the sensor saw 1,180 attempts from 28 distinct addresses, of which 1,042 came from the one address. Distinct-source count moved from 23 to 28 — within ordinary variation. Nobody joined in.

3. Test 2 — the hour when nobody else was there at all

[DOCUMENTED] The largest event in the census: 179.43.139.58, 2026-06-22 19:00, 1,528 connections, ips_total: 1.

[DOCUMENTED] Letter O closed this as a real observation confirmed by three independent code paths, against a discriminating control showing that comparable-volume hours elsewhere report 11, 26, 28 and 32 distinct sources.

[DOCUMENTED] So the single most violent hour in a four-month record — 255× its regime baseline — was produced by one machine, with no other address on the sensor at all.

[INFERRED — confidence HIGH] This is the strongest available evidence against the burst phenomenon being campaign activity. A campaign is plural by definition. This was singular.

[DOCUMENTED] And its sibling behaviour matches Test 1: 179.43.133.154, the other Private Layer beacon, contributed nothing to that hour.

4. Test 3 — the overlap test

The fleet offers a cleaner measurement than the beacons, because its work is discrete. A job is 761 attempts with a beginning and an end, so job windows can be compared directly.

[DOCUMENTED] Twenty-two fleet addresses in the corpus recorded exactly 761 fingerprints — one complete job each, nothing before or after. Their job windows, drawn from the fingerprint record:

[DOCUMENTED] Twenty-two jobs across twenty-five days give 231 possible pairs. Testing every pair for temporal overlap:

One overlapping pair of 231.

[DOCUMENTED] The single exception is 2026-07-22, where 91.92.42.64 (20:07–23:01) fully contains 77.239.124.237 (20:42–22:07) — 85 minutes of concurrency, and the only instance in the sample.

[INFERRED — confidence HIGH] The fleet does not run concurrently. Jobs are dispatched one at a time. Twenty-one of twenty-two single-job nodes had the fleet's attention to themselves for their entire run, and the exception involves the slowest node in the sample (see §5), which is consistent with a job overrunning its slot rather than a second job being launched deliberately alongside it.

[DOCUMENTED] This is the same conclusion Letter A reached from the opposite direction — that 23 of 25 burst events are single-node dominated — measured here by a method that does not depend on the burst detector at all.

A two-tier fleet: a reused core and a disposable periphery

[DOCUMENTED] Selecting the 22 nodes at exactly 761 fingerprints reveals something the job-size arithmetic alone did not. For every one of them, the fingerprint record's first and last observations are the start and end of a single job — 46 to 174 minutes apart. These addresses appear once, work for roughly an hour, and are never seen again.

[DOCUMENTED] Against the multi-job nodes from the same fingerprint population:

[INFERRED — confidence HIGH] The fleet is two-tier. A small core of addresses is used repeatedly over two to three weeks, while a much larger periphery is used exactly once each and discarded. Letter A observed that three addresses recurred and concluded the fleet "rotates but reuses"; that is true of the core and false of the periphery, and the distinction was invisible until job boundaries could be measured.

[INFERRED — confidence MEDIUM] Two readings, not separated here. Either the operator burns addresses deliberately to limit each one's exposure — in which case the core is a configuration error or a cost compromise — or the periphery is simply newer, and those addresses would have been reused had the record continued past 2026-07-30. The corpus ends before the question can be answered, and a node last seen on 07-28 has had two days to reappear, which is less than the median 24.5-hour dispatch gap allows to be meaningful.

5. Test 4 — fixed size, variable speed

The job windows carry a second result that was not anticipated, and it corrects a figure from Letter D.

[DOCUMENTED] Job durations across the 22 complete runs:

[DOCUMENTED] CORRECTION to Letter D. That letter measured ~5.4 seconds per connection and predicted a ~68-minute runtime, from the first 28 connections of one job. Across 22 complete jobs the median is 6.47 seconds per attempt and 82 minutes per job. The earlier figure was correct for the sample it was drawn from and unrepresentative of the population — an opening burst that settles.

[DOCUMENTED] The pacing spread is 3.8-fold, from 3.60 to 13.71 seconds per attempt. But the job size does not vary at all — every one of these nodes delivered exactly 761 attempts.

[INFERRED — confidence HIGH] The input is fixed and the execution rate is not. That is the signature of a work definition distributed to heterogeneous workers, each running as fast as its own host, network path and load allow. Central rate control would produce uniform pacing; these nodes vary by a factor of nearly four while delivering byte-identical workloads.

[DOCUMENTED] This also resolves Letter D's straddle arithmetic honestly. The 514 + 248 split across the 03:00/04:00 boundary implies that particular job ran approximately 68 minutes — near the fast end of the observed distribution, not the median. The straddle prediction survives as an explanation of that specific job; it does not generalise to a fleet-wide runtime, and Letter D's presentation of ~68 minutes as the job's duration is narrowed accordingly.

6. Test 5 — the dispatch is memoryless

The job windows also give the start times, and the intervals between consecutive starts test whether anything schedules this work.

[DOCUMENTED] Twenty-one intervals between consecutive job starts across the 22 single-job nodes:

[DOCUMENTED] Distribution: 4 gaps under 6 hours, 6 between 6 and 24 hours, 11 over 24 hours. Exactly one gap falls under an hour.

[DOCUMENTED] Job starts land in 16 of 24 possible hours of the day — 01, 02, 05, 09, 10, 11, 13, 14, 16, 17, 18, 19, 20, 21, 22, 23 UTC.

[INFERRED — confidence HIGH] A coefficient of variation of 0.83 is the signature of a memoryless process. For exponentially distributed inter-arrival times — the mathematical signature of events occurring randomly at a constant average rate — the coefficient of variation is exactly 1.0. For a scheduled process it approaches 0, because every interval is the same. 0.83 sits close to random and nowhere near scheduled.

[DOCUMENTED] The comparison is worth making concrete. A cron entry firing every 24 hours would produce twenty-one intervals of 24.0 hours and a coefficient of variation near zero. What the record shows instead is intervals of 0.6, 3.8, 4.2, 4.9, 16.2, 16.8, 17.3, 18.2, 19.1, 21.9, 24.5, 26.7, 26.7, 29.2, 32.5, 32.7, 33.8, 40.0, 45.2, 59.2 and 110.2 hours.

[INFERRED — confidence MEDIUM-HIGH] This is what work arriving in a queue looks like from the receiving end. If this sensor's address sits in a large target list that the fleet works through, each visit is a re-arrival at one position in a rotation whose period depends on list size, worker count and per-job duration — none of which is constant. The result at any single target looks random, because from that target's perspective it effectively is.

[DOCUMENTED] The absence of diurnal structure reinforces it. Sixteen of twenty-four hours, including 01:00, 02:00 and 05:00 UTC, is what a process that never sleeps produces. Nobody is starting these jobs by hand.

The one exception, now doubly exceptional

[DOCUMENTED] The single sub-hour gap and the single overlapping pair are the same event: 91.92.42.64 starting 2026-07-22 at 20:07 and 77.239.124.237 starting 35 minutes later at 20:42, running concurrently for 85 minutes.

[DOCUMENTED] That evening is the only moment in 22 jobs, 21 intervals and 231 pairs at which this fleet did anything that resembles acting together — and one of the two nodes involved is the slowest in the entire sample, taking 174 minutes for a workload the fastest node completed in 46.

[INFERRED — confidence MEDIUM] The most economical reading is that 91.92.42.64 stalled, its slot expired, and the next job was dispatched to a different worker while the first was still grinding. That is a queue overrunning, not a fleet coordinating — and it is the shape a queue produces precisely when it is not being supervised.

7. The beacons: always together, never synchronised

The beacons show the opposite pattern to the fleet, and it is equally uncoordinated.

[DOCUMENTED] Three arbitrary hours drilled from the record, showing every beacon present:

[DOCUMENTED] Every beacon is present in essentially every hour. They are permanently co-active. But each runs its own fixed rate — two per hour, three per hour, roughly 0.7 per hour for 179.43.139.58 — and Letter B established that their intervals share no common factor: 30 minutes, 20 minutes, ~86 minutes.

[INFERRED — confidence HIGH] Co-presence is not coordination. Four processes that run continuously will always be observed together; that says nothing about whether they talk. The test is whether they share phase or respond to each other, and they do neither — no common interval, no synchronised start, and Test 1 shows no response when one of them goes to 348×.

[DOCUMENTED] The one genuine linkage in the beacon population is not behavioural at all. It is the hand-authored RIPE maintainer ru-avm-1-mnt shared by 87.251.64.176 and 80.66.66.10 (Letter C), corroborated by a shared campaign, a shared cluster and a shared one-credential configuration (Letter E). Those two are linked by registry and configuration evidence, not by anything they did in concert.

⚠ CORRECTED — 2026-07-30, and the correction inverts this paragraph. ru-avm-1-mnt is the maintainer object of a sponsoring LIR (ORG-PMAV1-RIPE) holding space in both 87.251.x and 80.66.x; the two addresses are customers of one registry, not machines under one operator. So the linkage is behavioural after all — the shared campaign, the shared cluster and the shared one-credential configuration are all that remain, and all three are things the machines did. **Read: the one genuine linkage in the beacon population is behavioural, and the registry evidence contributed nothing.** The conclusion of this letter is unaffected — co-presence is still not coordination, the tests in §§1–7 used no registry data, and the CV of 0.83 stands. See TI-2026-103P — The Sponsor.

8. What the tests establish

[DOCUMENTED] Six signatures of coordination sought. None present. The single exception — one overlapping pair, one sub-hour gap — is the same event, and involves the slowest node in the sample.

[INFERRED — confidence HIGH] The infrastructure in this record is a queue, not a command structure. Work is defined centrally — the 761-entry list is identical everywhere — and executed independently, one node at a time, at whatever rate each host manages, with no synchronisation and no response to any other node's behaviour.

[DOCUMENTED] This is consistent with every other structural finding in the series: a 14-hour median dispatch interval that is irregular from 4 to 35 hours (Letter A), address rotation without burn-after-use (Letter A), multi-tenancy on the carrying ASN (Letter H), and a reseller layer beneath that (Letter K). Nothing about this operation requires anyone to be at a console.

[INFERRED — confidence MEDIUM-HIGH] It also bears on the burst question one final time. If the fleet cannot be commanded to act in concert — and five tests say it cannot — then no burst in this record can have been ordered, because there is no mechanism visible by which an order would propagate. Per-node runaway remains the only mechanism the evidence supports.

9. What this letter could not establish

• Whether the 22-job sample is representative. These are nodes that ran exactly one job and are therefore the cleanest to measure. Nodes running three or four jobs were excluded because their windows cannot be separated from the fingerprint record, and it is possible that multi-job nodes behave differently.
• Whether concurrency exists outside the sample. One overlap in 231 pairs is a rate, not an absence. With 118 fleet addresses and only 22 measured, concurrent execution elsewhere in the population is not excluded — it is shown to be uncommon among the nodes that can be measured.
• Why 91.92.42.64 took 174 minutes. Nearly four times the fastest node for an identical 761-attempt workload, and the only node involved in the sample's single overlap. Host load, a throttled network path and a partially-stalled job would all produce it.
• Whether the beacons' independence is designed or incidental. Intervals sharing no common factor is consistent with independent configuration and equally consistent with deliberate jitter. Letter B raised this; nothing here settles it.
• What dispatches the jobs. The queue is inferred from the shape of what arrives, and its controller has never been observed. Nothing in the corpus shows where the work definition comes from or who receives the results.

The second point deserves emphasis, because this letter's headline is a ratio and ratios invite overreading. One overlap in 231 pairs means concurrency is rare among measurable nodes. It does not mean the fleet is incapable of running jobs in parallel — only that, in this record, it almost never did.

Next: Letter N — Detection. What would have caught any of this, and why nothing did.