TI-2026-096D — Change of Hands: Reading the Ownership-Churn Feed Without Fooling Yourself

Classification: HIGH · Forensic threat intelligence · Entity-graph / lifecycle vector · Series: The Unannounced

The first three letters read the change-log's quiet streams — the 197 dark ASNs and the entities behind them. This one turns to the loud stream, and its whole job is restraint. The owner_changed feed has 9,239 events, roughly twenty-five times the other two change types combined. A naive analyst sees nine thousand "ownership changes" and imagines nine thousand corporate manoeuvres. That analyst would be almost entirely wrong. Most of these events are not the world changing; they are our own instrument re-labelling a world that stayed the same. This letter is about telling those two things apart — because the tiny remainder, the events that are real, are exactly where reputation laundering hides.

1. The Loudest Stream

The change-log has three streams and they are wildly unequal in size:

owner_changed is the elephant. If change-event volume were a proxy for real-world activity, you would conclude the internet's number space is a churning marketplace, hands swapping constantly. It is not. The number is an artifact of how the feed is built, not of how often control actually moves. Understanding why is the entire letter.

2. What Most of These Events Actually Are

Pull a sample of owner_changed rows and read the old_value → new_value pairs, and a pattern appears immediately. The changes are overwhelmingly the same underlying block being described differently as one data source's view supersedes another. A representative handful:

Not one of these is a transfer of control. Comcast did not sell anything to Comcast. Akamai did not acquire Prolexic on the day our feed noticed — it acquired it years ago; the graph simply caught up. "Not routed → UCLA" is not UCLA seizing a block; it is iptoasn finally attributing a range that was previously unmapped. These are provenance events: the pipeline's picture of reality sharpening, one relabel at a time. They are genuinely useful for keeping the graph accurate. They are worthless — worse, actively misleading — as signals of corporate activity.

3. The Two Discriminators

If most of the feed is noise, the value is a filter. Two fields do almost all the work.

Discriminator one — the source. owner_changed rows are stamped with the source that produced them, and the noisy ones cluster in two: iptoasn (which re-maps subnets to ASNs as its dataset refreshes) and rdap (which refreshes the org field from registry records). Both are, by construction, prone to relabel churn — every time their upstream data updates, entities that never changed hands emit an owner_changed event. A row whose entire story is "iptoasn re-mapped this subnet" is almost never a corporate event. Reading the source field first discards the majority of the noise for free.

Discriminator two — the direction. Among the events that do reflect a real holder change, direction carries the meaning:

• Toward a parent or a consolidation — Prolexic → Akamai, Tomsktelecom → Rostelecom, the Comcast internal folds. Benign. Big companies absorbing their own subsidiaries or regional units. Nothing to see.
• Toward an opaque or unfamiliar holder — a named, reputable hosting brand handing a block to a bland acronym or a shell. This is the direction that matters.

Neither field is exotic. Both are sitting in every owner_changed row. The reason the feed looks like nine thousand corporate events instead of the few dozen that matter is simply that nobody read them.

4. The Subset That Matters

Apply the filter and a small, high-value residue survives — blocks that genuinely changed corporate hands, in the direction that matters:

• HOLA TELECOMUNICACIONES COLOMBIA → TV AZTECA SUCURSAL COLOMBIA — a Colombian telecom block moving between corporate groups.
• ZETSERVERS (ZetServers.com) → "MES" — a named, marketed hosting brand handing space to a three-letter opacity.
• INFORMATICA BLUEHOSTING LIMITADA → ZAM LTDA. — a hosting company's space transferred to a bare LTDA.
• ODCLOUD-AS → PINKMARE-AS — one cloud/hosting handle replaced by another.
• NELLICUS-NETWORKS → DACSIX-NORTH — a networks brand's block moving to a different holder.

These are the events reputation-laundering is made of. TI-2026-021G (The Reputation Laundry) described the mechanism: address space accrues a bad reputation under one holder, so control moves to a fresh holder and the abuse history is, in effect, laundered — the block gets a clean slate while the operational reality underneath is unchanged. A real owner_changed event in the brand-to-opaque direction is the fingerprint of that laundering step. It is precisely what 021G had to reconstruct by hand, and precisely what the change-log surfaces automatically — if you filter the 9,000 relabels out first.

5. The Counter-Narrative

Steelman. "You've written a letter admitting your own headline feed is 98% noise, then pointed at five examples you can't prove are laundering. ZetServers changing hands could be an ordinary business sale. TV Azteca is a giant legitimate broadcaster. You're pattern-matching corporate transactions to crime because they look opaque to you."

Fair, and the letter is deliberately modest about it:

• "Your feed is mostly noise." Yes — that is the finding, stated as a strength. The point of the letter is that owner_changed must be filtered, hard, before it means anything, and it gives the two fields that do the filtering. A feed you know how to discount is more valuable than one you trust blindly.
• "You can't prove the five are laundering." Correct, and not claimed. The brand-to-opaque examples are presented as the direction that warrants a look, not as proven laundering. TV Azteca is explicitly a legitimate broadcaster — it is in the benign consolidation column, used as a control, not an accusation. The claim is about where to point the microscope, not what it will find.
• "Opaque ≠ criminal." Agreed. A three-letter holder name is a reason to check, not a verdict. The letter's actual product is a triage rule — source first, direction second — that shrinks 9,239 events to a reviewable handful. What the handful turns out to be is a separate, per-case question.

What is not claimed: that any named transfer is laundering (none is so alleged); that opaque new holders are criminal (they warrant review, nothing more); that the 9,239 count reflects real activity (it does not — it reflects source-refresh cadence). The claim is methodological: the biggest change stream is the least trustworthy per event, and here is how to read it anyway.

Confidence: HIGH that the majority of owner_changed events are provenance re-mapping rather than transfers of control, and that source + direction are the discriminators; MEDIUM that the filtered brand-to-opaque subset is the reputation-laundry signal.

6. Defence Response

• Never ingest owner_changed raw. A feed that is mostly iptoasn/rdap relabels will flood any watchlist with non-events. Filter on source first; drop the pure re-mapping rows before anything else looks at them.
• Alert on direction, not on the event. Wire the alert to fire only when a named, reputable holder is replaced by an opaque or shell holder. That single directional rule converts the loudest, least useful stream into a short, high-value reputation-laundering watchlist.
• Cross the residue with the dark census. The most interesting case is a block that changes to an opaque holder and whose new holder also appears in the dark reserve (Parts A–C). A transfer into held-dark inventory is the carousel loading its next wrapper — a signal no single stream shows, but the intersection of two change types does.

7. A Note on Method

Built entirely through the entity-graph MCP layer, no direct database access — entity_stats for the stream sizes and entity_changes(change_type=owner_changed) for the event sample, read for source, old_value, new_value, and direction. This is a feed-quality study: no honeypot data, no attack claim, no individual attribution. The deliverable is the discriminator that makes the noisiest change stream usable. No SQL touched the investigation.

8. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence