The Boring Explanations

Every reading in which none of this is about anyone in particular — steelmanned, then tested

TI-2026-103K · Series: The Loud Hour · Letter K of 15 Operates under the rules of evidence in Letter O — The Instrument. This letter is written against the rest of the series. Its job is to find the most mundane explanation for every finding and give it the strongest possible case. Several win.

Updated 2026-07-30. vmheaven.io, named here as the shortest unwalked path to the operator, is identified in Addendum P — and it turns out to be this letter's thesis in commercial form. Original text unaltered.

1. What this letter is for

Ten letters have accumulated a picture: offshore shells, named individuals at village addresses, a hundred-node fleet running a fixed job, beacons that have opened the same door twenty-two thousand times, a payload that checks whether it is in a honeypot, and a wallet thief on the same network.

That picture is seductive, and seduction is the failure mode. Every element of it has a boring counterpart — a version in which nothing is coordinated, nobody is targeted, and the infrastructure is bland commercial hosting doing bland commercial things badly.

This letter states each boring explanation in its strongest form and tests it. Five survive. Three are refuted, one is weakened. And one of the survivors turns out to be an explanation the series had already adopted without noticing it was the boring one.

The letter is deliberately structured to lose. If the mundane reading fits, it wins.

2. The strongest boring explanation

Claim: these are commercial internet-measurement services, and this series has spent ten letters describing Shodan.

This is by far the most serious challenge, and it deserves its full weight.

Internet-wide measurement is a legitimate, large, well-funded industry. Censys, Shodan, Shadowserver, BinaryEdge, LeakIX and a dozen others continuously connect to every routable address on the internet. They probe SSH. They fingerprint services. They maintain persistent schedules. They generate exactly the kind of traffic a honeypot records as "attacks", and honeypot operators routinely mistake them for adversaries.

Every behavioural finding in this series has a measurement-service reading:

[DOCUMENTED] That last row is the strongest point of all. A responsible scanner logs in and does nothing — exactly what the beacons do. The "silence" Letter F built a whole letter on is also the signature of a well-behaved research tool.

If this explanation holds, the series is a long description of ordinary commercial scanning.

The control exists in the corpus

The test is available because a real measurement service is present in this record.

[DOCUMENTED] Censys operates 42 addresses in this corpus. Their profile:

[DOCUMENTED] Every Censys address in this corpus connected once and never authenticated. Forty-two addresses, one hit each, zero successes total.

Now the same fields for the actors this series has followed:

[DOCUMENTED] The measurement-service explanation fails on four independent axes.

Identification. Censys registers autonomous systems under its own name and publishes per-address reverse DNS containing the word scanner and a domain that hosts an opt-out page. The beacons publish generic hosting boilerplate (hostedby.privatelayer.com), a reseller's customer-range label (dedi-kund-ips.vmheaven.io), or nothing at all.

Authentication. Censys connects and does not attempt credentials. Zero successes across 42 addresses. The beacons have authenticated 22,783 times. A measurement service that guesses passwords is not a measurement service — that is the line the industry draws, and it is drawn precisely there because crossing it is unlawful in most jurisdictions.

Volume per address. Censys: 1. Private Layer: 8,463.

Registration. Censys is a US corporation with an ARIN allocation in its own name. The beacons are a Panamanian shell with a Swiss phone, a Seychelles company at a Paradise Papers address, a bare forename at a Doncaster mailbox, and named private individuals in Kazakhstan (Letters C and G).

[DOCUMENTED] Verdict: REFUTED. Not narrowly — on every axis on which the comparison can be made, and against a reference sample sitting in the same dataset.

[INFERRED — confidence HIGH] The distinguishing property is not volume, persistence or technique. It is whether the operator wants to be identified. Censys makes itself maximally easy to attribute and to block. These actors make themselves maximally hard to. That difference is a choice, and it is the only one that reliably separates measurement from intrusion.

3. The vendor-crawler variant

Claim: the 762-job is a security vendor's asset-discovery crawler operating without consent but not criminally — the kind of thing an attack-surface-management company runs.

A narrower version of §2, and it needs a narrower answer because such companies do exist and some do behave badly.

[DOCUMENTED] The job authenticates. It presents 761 credentials, succeeds on twenty, and runs a command inside the resulting shell (Letter D). Authenticating with guessed credentials and executing a command on someone else's host is unauthorised access under the computer-misuse statutes of essentially every jurisdiction involved. No attack-surface-management vendor with a legal department does this, because the exposure is existential and the same inventory can be built from banners without touching authentication.

[DOCUMENTED] And the infrastructure argues against it independently. A vendor crawls from its own named allocation; this fleet runs from a Seychelles shell on a Spamhaus ASN-DROP listed ASN with three transit providers and no PeeringDB record (Letter H).

[DOCUMENTED] Verdict: REFUTED, on the authentication boundary. This is the same boundary that refutes §2, and it is worth stating as a general rule: the credential attempt is the line. Everything before it is measurement; everything after it is intrusion.

4. The explanations that survive

Now the ones that win, and they matter more than the ones that lose.

4.1 The bursts are software faults, not events

Claim: the excursions are retry storms, loops or restarts — not decisions.

[DOCUMENTED] SURVIVES, and is the leading explanation. The evidence favours it:

• The 2026-07-29 excursion used one credential, produced zero commands, and returned to exactly two attempts per hour afterwards.
• Its fleet siblings held their own cadence throughout — 178.16.54.226 beat at exactly 2/hour across the entire burst window (Letter A, Letter M).
• A different sibling burst independently five weeks earlier, on an unrelated date.
• Nothing about capability changed during any burst.

[INFERRED — confidence HIGH] Per-node runaway is a recurring, independent malfunction in this population. No coordination, no instruction, no intent is required to explain any burst in this record, and the original investigation that opened this series reached exactly that conclusion before ten letters of additional work confirmed it.

[DOCUMENTED] The one thing the fault reading does not explain is the underlying cadence — why a process runs every thirty minutes for four months at all. A fault explains the spike, not the metronome.

4.2 The credential overlap is coincidence

Claim: all these actors use admin/admin because everyone uses admin/admin.

[DOCUMENTED] SURVIVES, and Letter E already conceded it. admin/admin succeeds for 534 addresses across 152 ASNs and 46 countries, including 113 Google Cloud instances trying it once each. Convergence on the single most predictable credential in existence requires no coordination whatsoever.

[DOCUMENTED] What the coincidence reading does not explain is repetition without expansion: 4,574 attempts of one string over four months, never a third. That remains anomalous, and Letter E stated it as the residue after the boring explanation is subtracted.

4.3 This is one sensor's idiosyncratic view

Claim: the whole corpus describes one honeypot on one address, and generalises to nothing.

[DOCUMENTED] SURVIVES, entirely. Every number in this series is conditioned on a single Cowrie instance at a single address with a hand-enumerated credential accept-list (Letter E) and three distinct authentication regimes (Letter O). Letter I established that the sensor cannot observe exploitation at all, and Letter J that its clustering layers cannot represent groups larger than two.

[DOCUMENTED] The "20 successes per job" is a property of this honeypot's configuration file, not of the attacker. The 7.2% success rate describes nobody. The absence of CVE activity is a property of the sensor's shape.

[INFERRED — confidence HIGH] This is the most important surviving objection in the letter, and the series has repeatedly had to apply it to its own findings. It does not invalidate the behavioural results — a fixed 762-attempt job is a fact about the job regardless of what it hits — but it does bound every rate, ratio and success figure to this one instrument.

4.4 The metronome is an uptime monitor

Claim: a monitoring system checks this host every thirty minutes, exactly as monitoring systems do, and someone has simply pointed it at the wrong address.

This deserves testing because the cadence is precisely what monitoring looks like — a fixed interval, a trivial connection, a sub-second session, no payload, indefinite duration. Nagios, Zabbix, Uptime Kuma and a hundred others generate this shape continuously.

[DOCUMENTED] REFUTED, on three counts.

Monitors do not authenticate. Checking whether SSH is alive requires a TCP connect and a banner read. It does not require presenting admin/admin. The beacons authenticate on every single connection — 8,412 of 8,463 for the largest — which is not a liveness check but a credential validity check.

Monitors are pointed at owned assets. This address has never been under contract with a Panamanian hosting company, a Seychelles shell or a Kazakh individual. A misconfigured monitor aimed at a stranger's address would be corrected when the first alert fired; four months is not a misconfiguration.

Monitors notice when the target goes away. [DOCUMENTED] All five beacons have been blocked at the network edge since June and reach the sensor only via a deliberate honeypot exemption (Letter B). A monitoring system whose target became unreachable to everything except one deliberately open path would report an outage. These processes have never noticed anything.

[INFERRED — confidence HIGH] What survives from the monitoring reading is its shape, not its purpose. Whatever runs these beacons was built like a monitor — fixed interval, minimal payload, fire-and-forget — and that is a real observation about the software's design. It simply monitors a credential rather than a service.

4.5 The July step change was just the fleet arriving

Claim: the corpus's most dramatic feature has a completely dull cause.

[DOCUMENTED] SURVIVES — and is now the established explanation. Letter O declined to explain the twenty-five-fold July baseline rise and warned against merging it with the burst phenomenon. Letter H settled it: AS197170 contributed 130,565 attempts against an R3 total of 136,706 connections, its concurrent address count rising from 1 to 33 exactly across the dated inflection.

[DOCUMENTED] No campaign against this operator, no escalation, no response to anything published. One hosting customer scaled up a scanning job, and a sensor's graph changed shape.

5. The reseller layer nobody mentioned

[DOCUMENTED] Reverse DNS for the fleet's reference node returns dedi-kund-ips.vmheaven.io.

[INFERRED — confidence MEDIUM-HIGH] The label decomposes as dedicated customer IPs — kund from the German Kunde — under the domain vmheaven.io, a virtual-machine hosting brand that appears nowhere in the RDAP record, nowhere in the BGP data, and nowhere in ten previous letters.

[DOCUMENTED] The registration chain for a single fleet address is therefore at least four layers deep:

RIPE allocation      →  TechTies Inc. (Seychelles registered-agent address)
BGP announcement     →  AS197170, transit from ColocaTel + two unidentified ASNs
reverse DNS          →  vmheaven.io  ("dedicated customer IPs")
actual operator      →  a customer of vmheaven, unnamed

[INFERRED — confidence HIGH] This is the most deflationary finding in the letter. Letter H established that AS197170 is a landlord rather than an actor. The rDNS shows there is a sub-landlord below it. The entity actually running the 762-job is a customer of a reseller of a shell — and at that depth, "who operates this" stops being a question about the ASN entirely.

[DOCUMENTED] It also weakens, retroactively, every inference in this series that ran from network to operator. Letters A–F attributed behaviour to "the TechTies fleet"; Letter H narrowed that to "a tenant of AS197170"; this letter narrows it again to "a customer of a reseller within AS197170", whose identity appears in no record examined.

6. The scoreboard

[DOCUMENTED] Five of nine survive, three are refuted, one is weakened — and one survivor is strengthened by new evidence found in this letter.

[DOCUMENTED] The three refutations share a single test: all of them die on the credential attempt. Measurement services do not authenticate; vendor crawlers with counsel do not authenticate; monitors have no reason to authenticate. Everything that survives is an explanation that never needed the login in the first place.

[INFERRED — confidence HIGH] The residue — what no boring explanation accounts for — is smaller than the series' first nine letters implied, and it is precisely this:

1. A process that has verified one credential 22,783 times over four months without ever expanding its list or acting on the access, and continued after the source was blocked at the network edge.
2. A 761-entry wordlist curated for game servers, CI/CD runners and databases, paired with a payload that measures GPUs — a consistent interest in compute.
3. A payload that tests for honeypots and runs anyway for twenty-five days — careful tooling, careless operation.
4. One hand-authored RIPE maintainer linking two networks that every other source treats as unrelated.

Everything else in this series has a dull explanation, and most of them are correct.

7. What this letter establishes

1. [DOCUMENTED] Censys operates 42 addresses in this corpus at 1 hit and 0 successes each, with self-identifying RDAP, self-named ASNs and censys-scanner.com reverse DNS.
2. [DOCUMENTED] The beacons publish generic hosting rDNS or none, and have authenticated 22,783 times. The measurement-service explanation is refuted on four axes.
3. [INFERRED] The property distinguishing measurement from intrusion is whether the operator wants to be identified — not volume, persistence or technique.
4. [DOCUMENTED] The vendor-crawler variant is refuted on the authentication boundary: guessing credentials and executing is unauthorised access, and no vendor with counsel does it.
5. [DOCUMENTED] Four boring explanations survive: bursts as software faults, credential overlap as coincidence, single-sensor non-generalisability, and the July step as a fleet arrival.
6. [DOCUMENTED] dedi-kund-ips.vmheaven.io reveals a reseller layer beneath TechTies, putting the actual operator at least four layers below the RIPE allocation.
7. [DOCUMENTED] The unexplained residue reduces to four items, listed in §6.

8. What this letter could not establish

• What vmheaven.io is. A brand in a reverse-DNS label, absent from RDAP, BGP and every prior letter. Identifying it is now the shortest path to the operator, and it has not been attempted.

### ✅ CLOSED — Addendum P, and it is this letter's conclusion in commercial form. [DOCUMENTED] vmheaven.io is an offshore, DMCA-ignored VPS and dedicated-server provider that markets no KYC, anonymous cryptocurrency payment, Tor hosting, rDNS on request — and, verbatim, "ZMap & Port Scanning Allowed — Ideal for network research and security testing." Domain created 2024-12-12 via NameCheap behind "Withheld for Privacy ehf" (Iceland), nameservers and site protection on Cloudflare. It was the shortest path to the operator, and it is a dead end by construction. A no-KYC crypto signup means no customer record was ever created — so the narrowing from ASN to tenant to reseller customer does not stop for want of effort, it stops because there is nothing behind it. The operator is unidentifiable by design, and the design is the provider's. [INFERRED — confidence HIGH] This is the strongest single item of support for **this letter's** thesis, and it arrived after publication. §3 asked whether the fleet could be a legitimate research crawler and refuted it on the authentication boundary. The provider supplies the adjacent answer: **the fleet is there because scanning is explicitly advertised as permitted.** Not tolerated, not overlooked — sold as a feature. A tenant who picks a host for that reason is picking a capability, not a target. The rDNS-on-request policy also explains the artefact this letter found it through: dedi-kund-ips — dedicated customer IPs, kund from the German Kunde. **The one label that exposed the reseller layer exists because a customer asked for it.**

• Whether the beacon cadence has any boring explanation. §4.1 explains the spikes and explicitly fails to explain the metronome. No mundane reading yet accounts for a thirty-minute timer running for four months against one credential.
• Whether Censys is a fair reference. It is one measurement service, chosen because it is present in this corpus. A sloppier operator — one that does attempt credentials — would weaken the comparison, and no such example was found here.
• Whether the offshore registrations would look different for a lawful business. Letter G's archetypes describe form, not conduct; thousands of lawful companies use registered agents. The distinguishing evidence is the Spamhaus listing and the USTR docket, not the address.
• Whether any of this is aimed at this operator. Nothing in this letter addresses it, and Letter L is where it is tested. Every explanation examined here works equally well for any address on the internet, which is itself the strongest available argument that none of it is personal.

The last point is worth stating as this letter's real conclusion. The boring explanations that survive are not merely adequate — they are indifferent to the target. A fleet scaling up, a process looping, a credential everyone guesses, a sensor with idiosyncratic configuration: none of these requires that the address being hit is this address. That is what a null hypothesis looks like when it holds, and Letter L must beat it with evidence rather than with narrative.

Next: Letter L — What If. The evidence that would prove targeting, and why the record does not contain it.