TI-2026-100I — The Quiet Transit, Part I: The Ones the Filter Hid

Classification: TLP:WHITE · Confidence: HIGH · Series: The Quiet Transit, Part I Measured: 2026-07-26 · Subject: this series' own instrument

1. The question, and what it turned up instead

Part C found 149 ASNs cited across the corpus but never examined. Parts D, E and F took eight of them. This dossier was meant to answer a simple closing question: of the remaining 141, is anything left worth looking at?

Answering it required re-querying the backlog. And re-querying it found the error.

The Part C ranking query contained this:

WHERE a.asn IN (...) AND agg.ips > 0

Four characters of intent. ips > 0 restricts results to ASNs for which we hold at least one observed IP address.

It was added for a defensible reason — networks with no telemetry cannot be ranked by telemetry. Its effect was to delete from view every network that has never sent us a packet.

Which is to say: it deleted exactly the population Part H had just finished proving a honeypot cannot see.

2. Fourteen, not seven

Re-running the same gap without the clause returns seven additional Spamhaus-listed networks. Every one has zero observed IPs and zero honeypot hits — which is precisely why they were absent.

The Part C gap contains fourteen Spamhaus-listed ASNs, not seven.

Part C reported seven. Part F took Part C's list as its cohort and inherited the omission. Both understated it, and both did so because of the same clause.

Having documented the structural blind spot in Part H, the series discovered it had been applying that blind spot to itself since Part C.

3. What the filter was hiding

Four of the seven are Hong Kong. Three of them share one object.

APNIC RDAP returns the identical abuse entity IRT-CLOUDIE1-HK — admin@cloudie.hk, abuse@cloudie.hk — on three separate autonomous systems:

Three corporate names. Three distinct registrant organisation objects. Three different contact domains. Registration dates a decade apart.

One shared abuse object. All three Spamhaus-listed.

And one detail sharper than the rest: ANYUN's own administrative and technical contact — BJ469-AP, BingRong Jiang — publishes an admin@cloudie.hk address, on an ASN whose registrant publishes axytc.com.

Combined, the three announce roughly 9,216 addresses across 32 prefixes.

4. This changes something we published

Part F assessed AS133731 Cloudie Limited alone and rated it LOW risk, with this recorded reasoning:

"Rated LOW because one IP and four hits across a 4,352-address estate supports no characterisation on our evidence; the Spamhaus listing is the only adverse signal and it is not ours to interrogate."

That reasoning was correct and is not withdrawn. It was sound given what was in front of it.

What was in front of it was incomplete. Two sibling ASNs sharing the same abuse object had been removed from the cohort by the filter. The estate under a single abuse contact is 9,216 addresses across three autonomous systems, not 4,352 across one.

Cloudie is re-rated MEDIUM here — to reflect the cluster, not any new observed conduct. Our telemetry on it remains one IP and four hits, exactly as Part F said.

5. Two of them are not quiet. They are gone.

Zero prefixes. Zero neighbours. APNIC still records InfoMove's autnum status as active; its registry object was last changed in 2021.

Both still carry spamhaus_listed = true and is_bulletproof = true in our enrichment today.

A reputation flag describes a network's history. It does not expire when the network does. Any queue ranked by external flags should test liveness first, or it will spend attention on infrastructure that has not announced a route since 2009.

The remaining three: AS209274 Kraken Network (GB) is live — 1,280 addresses, single upstream, routed since 2019. AS214497 Whitelabel Solutions (IL) is present in the routing system with one neighbour while announcing no address space at all. AS400328 Intelligence Hosting (NL) returned no routing data, so its state is recorded here as unresolved rather than assumed.

6. And the honest closing measurement

Of the 141 gap ASNs still unexamined after Parts D, E and F:

Fewer than a third of the backlog has ever actually touched the sensor.

The remainder really is mostly inert. That was the expected answer — but it is only credible now, because the filter that made it look inert for the wrong reason has been corrected.

7. The counter-narrative on the cluster

Shared abuse handling is not shared ownership, and the objection deserves full weight.

An IRT object is the registry's designated abuse-handling contact. Sharing one is entirely consistent with a purchased service: small Hong Kong hosting companies routinely outsource abuse handling, and upstream providers frequently supply an IRT to downstream customers.

The evidence cuts both ways, and the parts that cut against a single owner are real:

• The three registrant contact domains genuinely differ — cloudie.hk, axytc.com, overcasts.net
• Registration dates span 2015 to 2025
• Each has its own distinct registrant organisation object

So this dossier claims what the record supports: one party handles abuse for all three. It does not claim common ownership, common control, or coordinated conduct.

The one detail that goes further than a vendor relationship comfortably explains is ANYUN's administrative and technical contact using a cloudie.hk address — an abuse vendor does not normally supply your admin-c.

8. The lesson, which generalises

The specific fix is trivial. The general one is not.

Never let telemetry define the population it is meant to assess.

Any query of the form "rank the unexamined by what we have observed" silently redefines unexamined as unexamined-but-already-seen. The two are not the same set, and the difference is exactly the entities that do not attack you.

The structural correction:

1. Build candidate populations from registry and reputation sources — they cover entities regardless of whether those entities have ever attacked anyone.
2. Use telemetry only to rank within that population, never to constitute it.
3. Add a liveness check from RIPEstat, so dormant ASNs are visibly separated from quiet ones rather than silently equated with them.
4. Treat shared abuse-object identity as a first-class clustering signal, alongside shared maintainer handles — it is what surfaced the Cloudie cluster.

[INFERRED — proposals, not implemented.]

9. Why this is the closing letter

The series began because an operator hid behind an em-dash in a table we published. It ends by finding that we had a second em-dash in our own SQL — a condition that made a whole class of entity unrepresentable, and then made the resulting gap look smaller than it was.

Nine dossiers, and the tally is worth stating plainly:

Three of the nine correct earlier work in this same series. That is not a defect in the method. It is the method — and a corpus that never publishes its own corrections is not being careful, it is being quiet.

10. Metadata

Sources

• APNIC RDAP — AS133731, AS134196, AS154206, AS38871, AS138687
• RIPE NCC RIPEstat routing-status — liveness, measured 2026-07-26
• LSN threat_intel / dossier_intel — gap re-query without the telemetry predicate
• Part C · Part F · Part H

All entities are named as registered holders per public APNIC and RIPE records, and as carrying Spamhaus listings per our own enrichment. No allegation of criminal conduct is made against any of them. The shared IRT-CLOUDIE1-HK object is documented as shared abuse handling and explicitly NOT as evidence of common ownership. InfoMove Solutions and Xdeer Limited are rated LOW because neither has announced address space for years. The defect documented in this dossier is the author's own.