TI-2026-100H — The Quiet Transit, Part H: The Brokers, a Layer That Never Attacks Anyone

Classification: TLP:WHITE · Confidence: MEDIUM · Series: The Quiet Transit, Part H Measured: 2026-07-26

CORRECTION — 2026-07-26. §9 of this dossier originally reported that lir-bg-telco-1-MNT "now returns zero objects" on inverse lookup and recorded it as an "open discrepancy — renamed, deleted, or migrated." That finding is withdrawn. It was wrong for two independent reasons, documented in Part J: the RIPE REST endpoint returns HTTP 429 with an errormessages block when rate-limited, and the parsing code read that as an empty result set — an error consumed as data. Separately, this corpus documents that handle as appearing in a mnt-ref cluster, while the query used inverse-attribute=mnt-by; those are different registry relationships, so the comparison was never valid for that handle regardless of the rate limit. No conclusion should be drawn about the status of lir-bg-telco-1-MNT from this dossier. Every other measurement in it was taken before the limit was reached and is unaffected.

1. Following the recommendation

Part G documented seven aged autonomous systems changing hands in five months, found that six of seven buyers presented a fresh vanity maintainer connecting to nothing, and concluded: track the broker, not the buyer.

Two intermediaries were visible in that wave — VIA-REGISTRY-MNT and lir-de-lain-1-MNT. This dossier does the obvious next thing and asks what they actually hold.

It also asks the question the whole series has been circling. If the supplier layer is where the persistence lives, why has a corpus of 777 dossiers never documented one?

The answer turns out to be structural, and it is the point of this dossier.

2. What one handle holds

A single RIPE inverse lookup on mnt-by=VIA-REGISTRY-MNT:

Organisation countries: GB 9 · CN 7 · FR 6 · ES 6 · US 5 · AE 3 · DE 3 · UA 3 · RU 2 · HK 2 — at least fifteen jurisdictions.

The maintainer object itself:

mntner:        VIA-REGISTRY-MNT
created:       2022-11-11
last-modified: 2026-01-14
admin-c:       VM7805-RIPE
auth:          SSO (filtered)
auth:          SSO (filtered)
mnt-by:        VIA-REGISTRY-MNT      ← self-maintained

Two SSO credentials. At least two RIPE accounts hold write access to all forty-six autonomous systems.

Part G saw this intermediary on exactly one acquisition. Enumerated, it sits above forty-six.

3. The central finding is a negative

Cross-reference those 46 autonomous systems against our entire threat corpus:

The two flagged are AS200730 ISAEV Igor (risk 70.3 — documented in TI-2026-020B and Part G) and AS205397 69HOST LLC (Spamhaus-listed, risk_score 0.0 because we have observed zero IPs from it).

The supplier layer is 91% invisible to the only instrument this corpus is built on.

And it is invisible for a structural reason, not a technical one:

Brokers do not attack anyone.

A honeypot is an instrument that waits to be attacked. An entity whose business is registration, sponsorship and transfer can never appear in it except by accident — when one of its customers happens to point a scanner at you.

We saw ISAEV because he attacked us. We did not see the other forty-two because there was nothing to see.

4. It was never hidden

Every fact above came from the public RIPE Database, via documented inverse-lookup endpoints, in a handful of queries, at no cost.

The broker layer employs no obfuscation whatsoever. No layered maintainer handles as in Part A. No inverted object kinds. No jurisdictional split between registration and operation. No anonymity of any kind.

It is simply a part of the registry that a telemetry-driven corpus has no reason to look at, because nothing in it ever generates an alert.

This is the deepest form of the blind spot this series opened with. TI-2026-030A hid an operator behind an em-dash. The broker layer needs no dash — it is in plain text, fully published, and still unread.

5. Where it touches work already done

Among the 60 organisations under VIA-REGISTRY-MNT:

• ORG-DSL56-RIPE — DEDIK SERVICES LIMITED (GB), holder of AS209413 at risk 84.25, an established subject of the published EMBNEX / Costume Catalog series. It shares an identical four-handle mnt-ref cluster with ORG-TI147-RIPE (TechTies Inc., AS197170) — itself a Part G 2026 reacquisition.
• ORG-II235-RIPE — ISAEV Igor (KZ), subject of TI-2026-020B and of the Part G wave.

Investigations this corpus ran separately, on different operators, at different times, converge on a single maintainer handle that none of them named.

6. The layer, to scale

Three orders of magnitude, from a two-ASN German sponsor to a thousand-organisation marketplace — the same structural role at wildly different sizes. (lir-bg-telco-1-MNT is shown as not measured: the query that produced its original row hit the rate limit — see the correction notice.)

Note that the largest holds no autonomous systems at all. Leasing address space and sponsoring ASNs are distinct businesses inside the same layer.

lir-de-lain-1-MNT, measured

303 objects: 2 aut-num — AS199428 (Alvaro Navas, ES, the Part G holder) and AS211507 (Aluy / Julian Achter, DE) — against 17 distinct organisations across DE, US, ES, GB, KR, VI, IS, IN and HR, plus 97 roles, 90 netblocks and 10 domains.

Two autonomous systems and seventeen customer organisations across nine countries is the profile of a registry sponsor, not a network operator.

7. The portfolio reads as a client list

The 60 organisations are unrelated companies and named natural persons across unconnected jurisdictions:

CFAI - LDA (FR) · Robotstxt S.L (ES) · Core Nextgen SL (ES) · DEDIK SERVICES LIMITED (GB) · LONNERBRO Anton (SE) · BASIUK Yanislav (RU) · CHAPMAN Adam (GB) · PAVLOV DMITRIY (LT)

The 46 aut-num names are equally heterogeneous:

ColdHosting · ZYLABS-2026 · GREAT-SCOTT-CONSULTING · SOLINTEX-INSULAR · NENASAL · NOVYRA-TECH-AS · SKULBYTE · DRUNK-GROUP · VAHIX-INFRASTRUCTURE · TOV-BITIORA · lawlietnet

No naming convention. No shared branding. No thematic coherence.

This is what a customer list looks like. It is not evidence that the maintainer directs any of them, and this dossier does not suggest that it does.

8. The objection, and it is a serious one

This dossier documents an ordinary commercial layer and risks implying that intermediation is itself suspicious. That objection is correct and is accepted.

• IP leasing and LIR sponsorship are substantial, legitimate industries. netutils-MNT with 1,005 organisations is a functioning marketplace, and it is included here precisely to establish that the shape documented is the normal shape.
• A handle holding many organisations means it sells a service to many customers. Nothing more.
• Two flagged ASNs out of forty-six is 4.3% — unremarkable, and quite possibly below the population baseline.
• A maintainer does not control what its customers route or do. mnt-by confers registry write access, not operational direction.

No claim is made that VIA-REGISTRY-MNT or lir-de-lain-1-MNT knew of, facilitated, or benefited from any customer's conduct.

What survives the objection is narrow and is about us, not them: an entire structural layer of the internet's address economy is absent from a 777-dossier threat corpus, because the corpus can only see things that attack it.

9. Two limits, stated

The operator behind VIA-REGISTRY-MNT is not identified. Resolving admin-c VM7805-RIPE — the single query most likely to name whoever runs it — returned:

ERROR:201: access denied
Queries from your IP address have passed the daily limit of controlled objects.

Person and role objects are RIPE's rate-limited controlled objects, a deliberate anti-harvesting protection. No attempt was made to circumvent it. The identification remains open to anyone querying from a fresh source on a later day.

WITHDRAWN 2026-07-26 — this paragraph was wrong. It originally read: "And one previously documented handle has gone quiet. lir-bg-telco-1-MNT — recorded in this corpus as part of the same substrate, identified via a shared telephone number to Telco power Ltd of Sofia — now returns zero objects, while four sibling handles returned between 187 and 3,445 in the same batch. Renamed, deleted, or migrated. Unexplained, and asserted as nothing."

The zero was not a registry fact. It was an HTTP 429 rate-limit response whose errormessages body the parsing code silently read as an empty object list — and lir-bg-telco-1-MNT was queried immediately after netutils-MNT, whose 3,445-object result had exhausted the daily budget. Independently, the handle is documented here as operating via mnt-ref, not mnt-by, so the inverse-mnt-by query used was the wrong relationship for it in the first place.

Nothing is known from this dossier about that handle's status. The failure is analysed in Part J.

10. What would actually work

If the durable entities are structurally incapable of appearing in attack telemetry, then a corpus built solely on attack telemetry can never document them — no matter how many dossiers it accumulates.

The proposal is a registry-side collection path independent of the honeypot: enumerate mnt-by inverse lookups for maintainer handles already touching known subjects, snapshot the resulting portfolios, and diff them over time, so that additions to a broker's client list become an event.

Under that model, the Part G wave would have been visible as it happened rather than reconstructed four months later.

[INFERRED — a design proposal, not a tested capability.]

It carries an obvious ethical constraint, which is not a footnote. Enumerating a lawful company's customer list is intrusive. RIPE's error-201 rate limiting exists precisely to prevent bulk harvesting of personal data. Any implementation must respect those limits rather than route around them — and the fact that this investigation stopped when it hit one is the standard it should be held to.

11. Metadata

Sources

• RIPE NCC REST DB — inverse mnt-by lookups on VIA-REGISTRY-MNT, lir-de-lain-1-MNT, netutils-MNT, mnt-bg-eurocrypt-1, MNT-ZEXOTEK, lir-bg-telco-1-MNT, all 2026-07-26
• RIPE NCC REST DB — mntner object VIA-REGISTRY-MNT
• LSN threat_intel — portfolio cross-reference
• Part A · Part G · TI-2026-020B · TI-2026-082

VIA-REGISTRY-MNT, lir-de-lain-1-MNT and netutils-MNT are named as public RIPE maintainer objects and their portfolios enumerated from public registry data. No allegation of wrongdoing is made against any of them, nor against any organisation in their client lists that is not already a published subject of prior work. Maintaining registry objects for customers is a lawful service. RIPE NCC is named as both the publisher of this data and the enforcer of the limit that stopped this investigation short.