The Metronome

What the loud hours depart from

TI-2026-103B · Series: The Loud Hour · Letter B of 15 Operates under the rules of evidence in Letter O — The Instrument. Regimes per Letter A: R1 accept-all (03-21 → 05-20) · R2 transition (05-21 → 06-28) · R3 selective (06-29 → 07-30).

Updated 2026-07-30. Three open items in §9 are now closed by later letters, including point 5 — the pivot this letter said the series turns on. Letter E answered it a third way this letter did not consider. Original text unaltered.

1. The question this letter has to answer

Letter A closed with an open question it could not resolve from the census alone.

The three burst species sorted almost perfectly by regime. Every Species I event — the mute bursts, one machine, zero commands — occurred in R1 or R2. Every Species II event occurred in R3. Not one exception in twenty-five events.

Two explanations fit that. Either the population of attackers changed around 2026-06-29, or the sensor stopped being able to see one of them. The first would be a finding about the internet. The second would be a finding about a database. They are not close to the same thing, and Letter A had no way to choose.

This letter chooses. The answer is the second, and the evidence is unambiguous: the mute beacons never stopped. Three of the five are running right now. What changed on 2026-06-29 was not who was knocking but whether a corpus-level detector could hear them over the noise.

To show that, this letter first has to establish what the metronome actually is — because it turns out to be a much larger part of this record than the bursts are.

2. Five machines

[DOCUMENTED] Five addresses in the corpus share a signature that nothing else does: very high session counts, near-total authentication success, one or two credentials, and no commands. Session and success counts are taken from the session store per R2.

[DOCUMENTED] Three of the five were still transmitting at the time of writing. The most recent sessions in the record for 179.43.139.58 (08:41:54), 94.154.35.215 (09:04:21) and 185.246.128.133 (09:22:47) all fall on 2026-07-30, all admin, all successful, all with zero commands.

Now the number that reorganises the whole series.

[DOCUMENTED] The corpus contains 31,564 successful logins across all three regimes. These five machines account for 22,783 of them — 72.2%.

[DOCUMENTED] They do so using 13.7% of the corpus's connections.

Five machines own nearly three-quarters of every door that has ever opened on this sensor, and none of them has ever walked through one. Between them: 23,276 sessions, 22,783 successful authentications, and — across every one of the five — zero commands and zero downloads.

[DOCUMENTED] for 179.43.139.58, 94.154.35.215 and 80.66.66.10, whose full command and download tallies are confirmed at zero. [INFERRED — confidence HIGH] for 185.246.128.133 and 87.251.64.176, whose sampled sessions uniformly show zero commands but whose complete tallies were not enumerated; Letter F closes this.

The registrations

[DOCUMENTED] The five sit on five unrelated ASNs, and every one of them exhibits the geographic disagreement pattern R7 requires be reported as a finding rather than resolved:

[DOCUMENTED] Four of the five resolve to a named individual or a bare given name rather than a corporate entity. Three disagree three ways on country; 87.251.64.176 and 80.66.66.10 disagree three ways each. The one corporate registrant, Private Layer INC, is a Panamanian company answering a Swiss telephone number.

Letters C, G and H take the registrations. What matters here is that the metronome is not one operator's fleet: it is five separately-registered machines, on five ASNs, in five jurisdictional stories, doing the same thing.

3. The cadence

[DOCUMENTED] Each beacon keeps its own interval, and keeps it precisely.

94.154.35.215 is the cleanest. Since 2026-03-24 it has connected twice per hour — one session roughly every thirty minutes, 48–49 per day, every day, for four months. Sessions last 0.7–1.2 seconds. Sampling arbitrary hours from the drill record shows it present in every one: exactly 2 attempts and 2 successes at 2026-06-30 04:00, exactly 2 and 2 at 2026-06-30 19:00, exactly 2 and 2 at 2026-07-02 11:00.

185.246.128.133 runs at three per hour — 3 attempts, 3 successes, in each of the same three sampled hours.

179.43.139.58 is the irregular one. Over the most recent 30 days it averages roughly 0.7 sessions per hour, distributed across all 24 hours of the day with no diurnal preference and no day-of-week structure worth the name (Sunday 83, Monday 86, Tuesday 77, Wednesday 55, Thursday 54, Friday 63, Saturday 84). Its lifetime average is closer to 2.7 per hour, so it has slowed markedly — and it is the one beacon that has ever produced a corpus-level burst, three times.

[DOCUMENTED] The beacons do not coordinate. Their intervals — 30 minutes, 20 minutes, ~86 minutes — share no common factor, and Letter M shows that when one of them ran away on 2026-07-29 the others held their own cadence without deviation.

[INFERRED — confidence MEDIUM] Distinct intervals on distinct ASNs suggests five independently-configured processes rather than one system with five outputs. This is the strongest argument in the series against reading the beacon class as a single actor, and it is not conclusive: identical software with a per-host jitter setting would look the same.

The same two words, in different proportions

[DOCUMENTED] The beacons do not merely use few credentials. Across five unrelated ASNs in five jurisdictions, they use the same two: admin/admin and admin/123456. Nothing else. Not a third variant, not a rotation, not a fallback.

But the mixture differs sharply per machine:

[DOCUMENTED] 185.246.128.133 and 87.251.64.176 were sampled rather than enumerated; their most recent sessions carry admin/123456 and admin/admin respectively, so both credentials are in use across the class.

This cuts both ways, and the letter declines to resolve it.

Toward a shared origin: an identical two-element credential set, appearing on five separately-registered ASNs, is not what independent operators produce. admin/admin and admin/123456 are the two most predictable credentials in existence, so convergence by chance is entirely possible — but convergence on exactly these two and nothing else, with no third entry ever attempted across 23,276 sessions, is a narrower coincidence than it first appears. A machine guessing would eventually try root.

Toward independence: a 54/46 split, an 17/83 split and a 100/0 split are not one configuration. If a single controller dispatched these, the ratios would match. They do not.

[INFERRED — confidence LOW, stated as unresolved] The pattern is most consistent with common tooling under separate operation — the same small program, deployed by different hands, each instance carrying its own list ordering or retry weighting. It is also consistent with one operator who does not care about ratio consistency. The record does not choose, and Letter E takes the wordlist question properly; Letter J tests the shared-tooling reading against the entity graph.

What can be said without hedging is narrower and more useful: whatever these machines are doing, none of them is searching. A search expands its input when it fails. In four months across five machines, the input never changed by a single character.

4. The decisive test

Everything above could still be an artefact. R1 accepted every login for sixty-one days (Letter O, D8), so a "beacon" observed in R1 might simply be an ordinary scanner benefiting from an open door. If the beacons' success rate were an artefact of the sensor, it would collapse when the sensor started refusing logins.

[DOCUMENTED] In R3, the corpus authenticates 9,861 of 136,706 connections — a success rate of 7.2%. In the same regime:

[DOCUMENTED] And at scale: on 2026-07-29, 94.154.35.215 produced 1,042 attempts in one hour, all successful, deep inside R3, on a sensor rejecting more than nine connections in ten.

The beacons' success is not a property of the sensor. It is a property of the credential. When the door started checking, they kept walking straight through it, because they were never guessing. They already knew.

That is the difference between the two populations in this record, and it is total. The TechTies fleet arrives with 761 credentials and opens the door twenty times — a 2.6% hit rate. The beacons arrive with one or two credentials and open it every time.

5. The 7.2% is not a number about attackers

A consequence follows that matters for anyone reading honeypot statistics anywhere.

[INFERRED — confidence HIGH, arithmetic from documented rates] R3's headline success rate of 7.2% is a blend of two populations that share nothing. Taking the beacons' documented cadences across R3's 744 hours: 94.154.35.215 at 2/h contributes roughly 1,490 successes, 185.246.128.133 at 3/h roughly 2,230, 179.43.139.58 at ~0.7/h roughly 520 — on the order of 4,200 of R3's 9,861 successes, from approximately 3% of R3's connections.

The remainder is a very large population failing almost all the time.

[DOCUMENTED] The two populations are visible in the registry as cleanly as anywhere. Compare the beacons above against the TechTies fleet nodes, each of which shows 20 to 80 successes against three to six thousand attempts. Same corpus, same window, same sensor — success rates two orders of magnitude apart.

No actor in this record has a 7.2% success rate. It is an average over a bimodal distribution, and quoting it as a characteristic of "attackers" would describe nobody. This is the same error class as the capability collapse retracted in Letter O §10: a ratio computed across a mixture, mistaken for a property of the mixture's members.

6. Letter A's open question, answered

[DOCUMENTED] Species I did not disappear in R3. 94.154.35.215, 185.246.128.133 and 179.43.139.58 were all transmitting throughout R3 and were all still transmitting on the final day of the record.

What disappeared is the visibility of a Species I event to a corpus-level detector.

The mechanism is arithmetic. A mute burst is one machine accelerating. In R1, with a local baseline of 7 connections per hour, a machine reaching 543 registers at 54× and is unmissable. In R2, at a baseline of 6, 1,528 registers at 255×. In R3, the baseline climbs from 19 to 52 and beyond — so the same machine doing the same thing produces a ratio in the low tens at best, and never clears the threshold.

[DOCUMENTED] The proof is the event that caused this series to exist. On 2026-07-29 94.154.35.215 went to 348× its own baseline — a textbook Species I mute burst, 1,042 successful logins, zero commands — and it does not appear in Letter A's census at all.

The regime boundary did not change the attacker population. It changed the detector's sensitivity. Letter A's clean species-by-regime sort is, in its Species I half, an artefact of measurement — exactly the possibility Letter A flagged and could not test.

[DOCUMENTED] The Species II half of that sort is not an artefact. The TechTies fleet's earliest appearance in the corpus is genuinely late — 91.92.42.147 first connects 2026-06-15, 91.92.40.171 on 06-17, 91.92.42.227 on 06-20, 91.92.42.10 on 06-26, the rest in July. Those are session-store dates under R1, not registry fields. The fleet really did arrive during R2 and scale up in R3.

So the corrected statement is: one species was always there and became invisible; the other genuinely arrived. Letter A's sort was half real and half instrumental, and only this letter's test separates them.

7. D9 — the other end of the artefact

Status: RESOLVED. Severity: would have produced a false headline in this letter.

While assembling §2, the registry showed 80.66.66.10 and 87.251.64.176 both carrying last_seen = 2026-06-29T20:31:04.218171Z — identical to the microsecond, and falling precisely on the R2→R3 boundary.

Both are beacons. Both are in cluster actor_cluster_014. Both share campaign hassh-eff4c24daffc8532. A story assembled itself immediately: two members of one cluster ceasing operation at the exact moment the sensor changed its authentication policy.

It is false.

[DOCUMENTED] Queried against the session store:

They stopped 77 days apart. Neither stopped at the regime boundary. The shared timestamp is a sweep artefact — the same defect class as D1's first_seen, on the opposite end of the field pair.

Rule R12. Neither first_seen nor last_seen in the IP registry is an observation date. Both are sweep timestamps. All activity windows in this series are bounded by session-store queries, ascending and descending.

The near-miss is instructive beyond the correction. The false finding was more compelling than the true one — it had a mechanism, a shared cluster, a shared fingerprint and a suspiciously precise coincidence. The precision was the tell. Two independent machines do not stop within a microsecond of each other, and a coincidence that clean is almost always an artefact of the instrument rather than a fact about the world. D1 taught the same lesson with stamps 2.393 seconds apart; this one taught it with zero.

8. What a metronome is for

The census established what these machines do not do. This letter can bound what they might be doing, without choosing between the options — that is Letters K and L.

[DOCUMENTED] constraints any explanation must satisfy: a fixed one-or-two-credential set, never expanded; a stable interval per machine measured in tens of minutes; sub-2-second sessions; complete authentication success including under a selective policy; zero commands and zero downloads across 23,276 sessions and four months; and continuation long after the source addresses were blocked at the network edge.

That last constraint is worth stating precisely. [DOCUMENTED] All five carry mikrotik-ban and crowdsec-blacklist tags. They continue to reach the sensor only because the honeypot is deliberately exempted from those blocks. They are transmitting into a room that has been sealed off from everything else, and they have not noticed — because nothing in their behaviour ever checks whether the door leads anywhere.

The candidate readings — a liveness check confirming a credential still works; an inventory maintenance process; a keepalive against a list compiled elsewhere; a component whose downstream consumer no longer exists — are developed and tested in Letter K. What this letter establishes is that all of them must explain a process that has verified the same fact twenty-two thousand times and never once acted on it.

9. What this letter could not establish

1. Complete command tallies for 185.246.128.133 and 87.251.64.176. Sampled sessions are uniformly zero-command; the full enumeration is Letter F's.

✅ CLOSED — Letter F. The enumeration was done and the answer is zero. The beacon class has authenticated successfully 22,783 times and never issued a command. The sampled sessions were not a lucky sample. One caveat survives from Letter F's own open items: the record shows commands executed, so "zero commands" is strictly "zero commands recorded as executed".

1. Whether the five beacons are one operator or five. §3 argues for independence from distinct intervals, credentials and ASNs. Identical software with per-host jitter would produce the same observation. Letter J tests it against the entity graph, and 179.43.139.58 and 94.154.35.215 already share campaign hassh-a7a87fbe86774c2e, which cuts the other way.
2. Why 179.43.139.58 slowed from ~2.7 to ~0.7 sessions/hour, and why it alone among the five has ever produced a corpus-visible burst — three times.
3. Whether beacons exist below the detection floor. The five here were found by ranking on volume. A beacon at one session per day would have the same signature and would not appear. The beacon population is a lower bound, and nothing in this series claims it is complete.

✅ CLOSED — Letter E, and the floor was the method's. Approaching from the credential side rather than the volume side doubled the census from five to ten. 176.53.159.196 and 37.77.150.119 were missing because a machine beaconing on one credential ranks below one beaconing on two, and the census was ranked on total session volume. **The selection method, not the world, set the boundary at five.** The population is still a lower bound — that part of this item stands — but the specific suspicion was correct and cost one query from a different angle to confirm.

1. Whether the credentials were obtained or guessed. That they are never expanded is consistent with prior knowledge and equally consistent with a scanner that found them once in R1 — when everything worked — and cached the result. Letter E takes the wordlist; Letter L takes what would distinguish the two.

Point 5 deserves the last word, because it is the pivot the series turns on. If the credentials were cached from R1's accept-all period, the beacons are confirming something this sensor itself taught them, and their persistence is a comment on the honeypot's design rather than on any operator's intent. If they were obtained elsewhere, the same behaviour means something entirely different. The record as it stands does not distinguish these, and no letter in this series will claim it does without evidence that does.

### ✅ POINT 5 CLOSED — Letter E, and it closes a third way this letter did not consider. [DOCUMENTED] The credentials were neither obtained nor cached from this sensor. They are admin/admin — and it succeeds for **every one of the 534 addresses that has ever tried it here**, across 152 autonomous systems, 46 countries and 132 active days. 16,500 attempts, 16,500 successes, 100%. A pair that a third of the internet's scanning population already carries is not knowledge anyone had to acquire. This letter's framing of the pivot was wrong, and Letter E withdrew the claim it rested on. Both branches offered above — cached from R1, or obtained elsewhere — presuppose that knowing the credential required a source. It did not. **The beacons did not know anything about this host.** That is the finding, and it is one of the load-bearing reasons Letter L can conclude the activity was not targeted.

Next: Letter C — Who Goes Loud. Five registrations, four named individuals, and one Panamanian company with a Swiss telephone number.