The Sponsor
Two handles resolved after publication, and the correction one of them forces
TI-2026-103P ยท Series: The Loud Hour ยท Addendum Operates under the rules of evidence in Letter O โ The Instrument. This addendum corrects a claim in Letter C and closes the question Letter N left open.
1. Why this exists
The Loud Hour closed with two unwalked paths. Letter G established that the RIPE maintainer ru-avm-1-mnt โ the object on which the series' only claimed operator link rested โ appears in no public reporting whatsoever. Letter K found vmheaven.io in a reverse-DNS label and noted that it appears in no RDAP record, no BGP data and no prior letter. Letter N named both as "the two shortest paths to an operator, and neither was walked."
They have now been walked. Each took a handful of queries.
One of them corrects a published finding, and the correction runs in the direction the series should have preferred from the start: a claim of coordination turns out to be a claim about paperwork. The other resolves an open question into a better-formed answer than the one that was sought.
Both are set out below with the same standard applied to everything else in this series.
2. ru-avm-1-mnt, resolved
[DOCUMENTED] Querying the RIPE RDAP entity endpoint for the maintainer handle returns an administrative contact and a registration history:
| field | value |
|---|---|
| handle | ru-avm-1-mnt |
| registered | 2018-08-01T12:22:40Z |
| last changed | 2025-07-09T10:40:30Z |
| administrative contact | AB16907-RIPE โ Aleksei Balalaev |
| address | 630032 Russian Federation, Novosibirsk, st. Startovaya 7A, LLC "STK" |
| telephone | +7 383 3351222 |
[DOCUMENTED] A RIPE REST inverse lookup on mnt-by returns the objects it maintains, and one of them carries an organisation reference. Resolving that organisation:
| field | value |
|---|---|
| organisation | ORG-PMAV1-RIPE |
| org-name | Aleksandr Valerevich Mokhonko |
| org-type | LIR |
| reg-nr | "Not Applicable" |
| country | RU |
| address | Dmitrieva st. 2/4 ft. 45, 644123, Omsk, Russian Federation |
| telephone | +79628282620 |
| admin-c / tech-c | AB38031-RIPE |
| mnt-by | RIPE-NCC-HM-MNT, ru-avm-1-mnt |
| created | 2018-08-01 ยท last modified 2026-05-13 |
[DOCUMENTED] And the referenced person object:
| field | value |
|---|---|
| nic-hdl | AB38031-RIPE |
| person | Aleksei Balalaev |
| address | Galushaka st. 9 fl. 24, 630049, Novosibirsk, Russian Federation |
| telephone | +79628282620 โ identical to the organisation's |
[DOCUMENTED] The handle decodes exactly. ru-avm-1-mnt โ Aleksandr Valerevich Mokhonko, with the ru country prefix RIPE handles conventionally carry. The organisation's allocations follow a matching netname convention: RU-AVM-19880518, RU-AVM-20050912, RU-AVM-20180802, RU-AVM-20180912.
[DOCUMENTED] Two distinct person objects carry the name Aleksei Balalaev โ AB16907-RIPE (Startovaya 7A, c/o LLC "STK", +7 383 3351222) and AB38031-RIPE (Galushaka st. 9, +79628282620) โ both in Novosibirsk, both maintained by ru-avm-1-mnt, created within one second of each other on 2018-08-01.
What it holds
[DOCUMENTED] Inverse lookup on the organisation returns its allocations:
| range | netname | status | created |
|---|---|---|---|
130.49.214.0 โ 130.49.215.255 | RU-AVM-19880518 | ALLOCATED PA | 2025-12-02 |
193.37.68.0 โ 193.37.71.255 | RU-AVM-20180912 | ALLOCATED PA | 2020-09-16 |
194.113.232.0 โ 194.113.235.255 | RU-AVM-20180802 | ALLOCATED PA | โ |
87.251.84.0 โ 87.251.89.255 | RU-AVM-20050912 | ALLOCATED PA | โ |
80.66.83.0/24 | โ | โ | โ |
[DOCUMENTED] Every one is co-maintained by RIPE-NCC-HM-MNT, the RIPE hostmaster maintainer โ the marker of a direct allocation to a registry member.
Now look at the last two rows.
[DOCUMENTED] Letter C's linked pair sits at 87.251.64.0/24 (Isaev) and 80.66.66.0/24 (Soldatov). Mokhonko's LIR holds 87.251.84.0/22-scale space and 80.66.83.0/24 โ the same two /16s.
3. The correction to Letter C
A central claim of Letter C is withdrawn.
Letter C wrote that ru-avm-1-mnt on both networks means "one party holds modification rights over both", called it "the only hard operator link in the series", and concluded that the two operations "are not separate." Letter E reinforced it with a fourth signal, and Letter G called it "the highest-value open pivot."
[DOCUMENTED] ru-avm-1-mnt is the maintainer object of a RIPE Local Internet Registry. An LIR maintains the RIPE objects of every resource it sponsors, as a matter of routine administration. That is what the object is for.
[DOCUMENTED] Combined with the address holdings above, the structure is unambiguous: Isaev and Soldatov hold sub-allocations from ranges the same LIR sponsors. They share a sponsor, not demonstrably an operator.
[DOCUMENTED] The corrected statement: 87.251.64.176 and 80.66.66.10 are customers of the same Russian LIR. That is a real and useful relationship โ it is why their registry objects look alike, why they share a maintainer, and why their allocations sit where they do. It is not evidence that one party runs both machines.
[DOCUMENTED] What survives independently: the two addresses still share HASSH campaign hassh-eff4c24daffc8532, still share actor_cluster_014, and still share a one-credential configuration where every other beacon runs two (Letter E). Those are behavioural and remain untouched. What falls is the registry evidence that was treated as the strongest of the four.
Letter G was right and this series did not test it
[DOCUMENTED] Letter G set out both readings explicitly:
*"either maintainer objects are low-salience metadata that most reporting ignores โฆ or the handles are unremarkable. A shared maintainer can indicate a shared LIR, a shared consultant, or one person who set up both allocations years ago and moved on."*
and concluded that "this letter cannot distinguish them."
[DOCUMENTED] It could have. Distinguishing them required one RDAP call on the handle and one REST inverse lookup โ the two queries that produced ยง2. Letter G ran neither, searched the public literature instead, found nothing, and reported the absence as the finding.
[INFERRED โ confidence HIGH] The failure is the same shape as the series' other corrections: an absence in one source was reported without querying the source that would actually answer. Letter I's rule R16 โ run a saturation control before reporting any absence โ was written for enrichment linkages. It applies to literature searches identically. No public reporting names this handle was true and irrelevant; the registry names it.
Rule R20. Resolve every maintainer handle to its organisation before inferring operator identity, and run an inverse lookup to size what it controls. If it maintains an LIR organisation object or unrelated ranges, it is a sponsor โ shared maintainer means shared sponsor until an LIR relationship is excluded.
4. What the correction does not dissolve
The finding is weaker than Letter C claimed and more structurally interesting than a retraction implies.
[DOCUMENTED] The series established a descending accountability chain (Letter G): a real company, then registered-agent shells, then named private individuals โ with the observation that "a private individual at a village house in North Kazakhstan is where a subpoena stops."
[DOCUMENTED] It does not stop there. It continues one level up and terminates at another natural person. The sponsor of those Kazakh allocations is an LIR whose org-name is a person's name, whose org-type is LIR, and whose company registration number is recorded as the string "Not Applicable".
[INFERRED โ confidence HIGH] A Local Internet Registry is a contracting party to the RIPE NCC with a membership agreement, a fee, and obligations. reg-nr: "Not Applicable" on an LIR means a natural person holds that contract, not a company. Every layer of this chain โ the ASN holders, and now their sponsor โ is an individual.
The Transnistria sub-assignment
[DOCUMENTED] The same maintainer sub-assigns two halves of its newest allocation:
| range | netname | descr | country |
|---|---|---|---|
130.49.214.0 โ 130.49.214.127 | HYPER-HOSTING-NET | HyperHosting, MD-4304, str. Manoilova 25, or. Tiraspol, Republica Moldova | IT |
130.49.214.128 โ 130.49.214.255 | HYPER-HOSTING-NET | (same) | IT |
[DOCUMENTED] The registered premises are in Tiraspol โ the administrative centre of Transnistria, a breakaway region of Moldova outside effective Moldovan jurisdiction. The country attribute on both objects reads IT, for Italy.
[DOCUMENTED] Per R7, the disagreement is the finding, and this one is not a disagreement between independent sources โ the address and the country code are in the same object, written by the same hand. A Moldovan street address filed under an Italian country code is not two sources measuring differently. It is one record contradicting itself.
[DOCUMENTED] No inference of criminality is drawn against any named individual in this addendum. Sponsoring customers who later misbehave implies nothing about a sponsor; RIR registration data records what a registrant typed; and the series' standing position on named private persons (Letter C) applies here without modification. The finding is about the shape of the accountability structure, not about the conduct of anyone named in it.
5. Does the correction change the series' answer?
No, and it is worth showing why rather than asserting it.
[DOCUMENTED] The series was built to answer one question: was the 348ร hour of 2026-07-24 retaliation for the operator's published dossiers? Letter L put that hypothesis against seven criteria and six failed โ the beacons predate the publishing system by three months, the tightest temporal correlation runs backwards, no named actor has ever made a web request naming the site, the credential set is a global commodity, the command set is generic, and the burst shape matches the corpus rather than standing apart from it.
[INFERRED โ confidence HIGH] Letter C's shared-maintainer claim appears in none of those seven tests. It was a coordination finding between two beacons, not a targeting finding. Reclassifying it from operator link to sponsor link subtracts nothing from the refutation, because the refutation never drew on it.
[DOCUMENTED] Where it does propagate is narrower and worth stating precisely:
| letter | claim resting on the maintainer | status after this correction |
|---|---|---|
| C | "the two operations are not separate" | withdrawn โ sponsor, not operator |
| C | "the only hard operator link in the series" | withdrawn โ the series has no hard operator link |
| E | maintainer as fourth signal linking the pair | downgraded โ three behavioural signals remain |
| G | "highest-value open pivot" | resolved โ and it resolved against the reading Letter C took |
| M | fleet coordination test | untouched โ the fleet test never used registry data |
| N | operator unidentified | strengthened โ see ยง6 |
[DOCUMENTED] The number of demonstrated hard operator links across fifteen letters is therefore zero. Every remaining inter-node relationship in this series is behavioural โ a shared HASSH campaign, a shared actor cluster, a shared credential configuration, a shared job structure โ and behavioural evidence is exactly what a shared toolkit or a shared commodity script produces without any shared operator at all.
[INFERRED โ confidence MEDIUM-HIGH] That is a stronger position than the one the series published, not a weaker one. A claim that rested on paperwork has been replaced by an accurate description of paperwork, and the conclusions that survive rest on the sensor's own record โ which is the only instrument in this investigation whose provenance Letter O was able to audit end to end.
The methodological point
[DOCUMENTED] Letter C reached for registry data because registry data feels harder than behaviour. It is written down, it has dates, it can be quoted verbatim. But an RIR object records who administers a record, and administering a record is a clerical relationship. A HASSH hash records what software opened a connection, which is a fact about the machine that connected.
[INFERRED โ confidence HIGH] The apparently softer evidence was the load-bearing evidence all along. Documents describe custody; telemetry describes conduct. When an investigation wants to know who did something, the second is closer to the question โ and a series that spent fifteen letters distrusting derived fields should have distrusted a maintainer handle first.
6. vmheaven.io, resolved
[DOCUMENTED] Letter K found the fleet's reference node 91.92.40.202 resolving to dedi-kund-ips.vmheaven.io and could not identify the brand.
[DOCUMENTED] The provider publishes its own answer. Its marketed feature set includes:
- offshore, privacy-first, DMCA-ignored VPS and dedicated servers
- no KYC required
- anonymous / crypto payments
- Tor hosting
- rDNS configuration and IPv6 assignment on request via support ticket
- and, verbatim: "ZMap & Port Scanning Allowed โ Ideal for network research and security testing"
[DOCUMENTED] Domain registration: created 2024-12-12, expiring 2027-12-12, registrar NameCheap, registrant organisation "Privacy service provided by Withheld for Privacy ehf" (Iceland), nameservers on Cloudflare, with a Cloudflare interstitial protecting the site itself. A third-party profile lists the operation as Russia.
[INFERRED โ confidence HIGH] This answers two of the series' open questions at once.
Why the fleet is there. Letter K asked whether the 762-attempt job could be a legitimate research crawler and refuted it on the authentication boundary. The provider resolves the adjacent question: the fleet hosts here because the provider explicitly advertises that port scanning is permitted. Not tolerated, not overlooked โ advertised, as a feature, in the marketing copy.
Why the operator cannot be found. Letter N closed by naming the operator as unresolved after narrowing from ASN to tenant to reseller customer. [INFERRED โ confidence HIGH] The narrowing terminates because no-KYC crypto signup means no customer record exists to obtain. The operator is not hidden behind a shell that could be pierced; there is nothing behind the reseller but a payment nobody was asked to identify.
[DOCUMENTED] The correction to Letter N's closing is therefore that the question is answered, not open โ and answered in a stronger form. "Who operates the fleet" is unanswerable by design rather than by omission, and the design belongs to the provider, not the operator.
[DOCUMENTED] One detail also closes a small loop. The Trustpilot listing records that the provider "provide[s] rDNS configuration โฆ upon request through a support ticket", which explains why a customer range carries a PTR reading dedi-kund-ips โ dedicated customer IPs, kund from the German Kunde. The single artefact that revealed the reseller layer exists because a customer asked for it.
7. The reckoning
[DOCUMENTED] This addendum makes the series' tenth correction. The full list, for anyone auditing it:
| # | claim | corrected to |
|---|---|---|
| 1 | capability collapse | capability concentration (4.4ร rise) |
| 2 | 382ร burst ratio | 255ร under regime-local baselining |
| 3 | fleet has no fingerprint | libssh2 hash present โ the linker failed |
| 4 | wordlist lexicographically ordered | an API sort artefact; order unrecoverable |
| 5 | beacons "already knew" credentials | a common password, 534 addresses succeed |
| 6 | HASSH tool is libssh2 | SSH-2.0-Go per session banner |
| 7 | pacing 5.4 s/attempt, 68 min | 6.47 s/attempt, 82 min across 22 jobs |
| 8 | SSH and web populations disjoint | true at extremes; 1,751 overlap corpus-wide |
| 9 | ips_total: 1 suspected artefact | real; the suspicion was the analyst's |
| 10 | ru-avm-1-mnt = operator link | = sponsoring LIR |
[INFERRED โ confidence HIGH] Nine of the ten were caught before or shortly after publication by cross-checking one instrument against another. The tenth was caught only because the series published its open questions explicitly enough that they could be picked up and closed.
That is the argument for writing the what this could not establish section into every letter. Letter G named the exact alternative that turned out to be correct and marked it untested; Letter N put the handle on a list of two things worth walking. The correction was pre-loaded into the series by its own admissions, and it took two queries to collect.
8. What this addendum establishes
[DOCUMENTED]ru-avm-1-mntbelongs toORG-PMAV1-RIPE, org-name Aleksandr Valerevich Mokhonko,org-type: LIR,reg-nr: "Not Applicable", Omsk, Russian Federation. The handle decodes to the org-name's initials and its allocations useRU-AVM-<date>netnames.[DOCUMENTED]Its administrative and technical contact is Aleksei Balalaev, Novosibirsk, appearing as two person objects, one c/o LLC "STK", sharing the organisation's telephone.[DOCUMENTED]The LIR holds at least five allocations โ including space in both87.251.xand80.66.x, the /16s containing Letter C's linked pair.[DOCUMENTED]CORRECTION: the shared maintainer is a shared SPONSOR, not a demonstrated shared operator. The behavioural links (HASSH campaign, actor cluster, one-credential configuration) survive; the registry link is reclassified.[DOCUMENTED]The same maintainer sub-assigns to HyperHosting, Tiraspol, Transnistria, under acountryattribute readingITโ a single object contradicting itself.[DOCUMENTED]vmheaven.ioadvertises "ZMap & Port Scanning Allowed", no KYC and crypto payment, behind Namecheap, an Icelandic privacy proxy and Cloudflare.[DOCUMENTED]CORRECTION to Letter N's closing: the operator is unidentifiable by design, not by omission โ there is no customer record because none was ever collected.[DOCUMENTED]Rule R20 issued.
9. What this addendum could not establish
- Whether Mokhonko's LIR sponsors the Kazakh ASNs directly, or whether the sub-allocation path runs through an intermediary. The address-range overlap and shared maintainer establish sponsorship; the contractual chain has not been retrieved from RIPE membership records.
- Why two person objects exist for the same name with different addresses and telephones, created one second apart. Ordinary registry duplication is the likeliest explanation and it has not been tested.
- Who operates HyperHosting, or whether it is related to any similarly-named business. The name is common in hosting and no link is claimed beyond the sub-assignment itself.
- Whether
vmheaven.iois the fleet's provider or an upstream of it. A PTR record establishes who controls the reverse zone for that range, not who sold the server. - A report, dated approximately 2026-07-28, associating "GHOSTYNETWORKS and OMEGATECH" with a global JavaScript malware operation. OmegaTech is AS202412 โ the operator of the address that began this series. The article could not be retrieved; the fetch timed out, and only a search snippet was seen. It is recorded here as an unverified lead requiring a primary read, and nothing in this series rests on it.
The last item is deliberately left in this state. Per the standard the series has applied throughout, a snippet is not a source โ and the temptation to close fifteen letters with an external corroboration that was never actually read is exactly the kind this addendum exists to resist.
The Loud Hour: fifteen letters and one addendum. The corrections are the record.