TI-2026-096E — Putting On a Face: What the Rename Feed Reveals About Identity

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

Part D read the loudest, least trustworthy change stream. This letter reads the smallest and cleanest. The renamed feed has just 187 events — but every one of them is real in a way the others are not. Where taken_down records a number we only ever saw dark, and owner_changed is mostly our pipeline relabelling itself, renamed records something an operator actually did: they changed what their network is called. It is the inverse of going dark. Where the census watched identities dissolve into un-announced silence, this watches them form — a bare integer putting on a face.

1. The One Stream You Can Trust Per Event

A quick recap of the change-log's reliability, because it is the whole reason this stream is worth its own letter:

Every renamed row has a real old_value and a real new_value, and — this is the key fact — every one is sourced from peeringdb, the operator-maintained directory of networks. That means a rename is not the pipeline guessing; it is a human at the network editing their own record to change what it says. The events are all dated 2026-07-21 and 2026-07-23, a tight self-report refresh window. When this stream says a name changed, a name changed, on purpose, by the person who owns it. That makes it the change-log's ground truth about identity.

2. Type 1 — A Ghost Integer Gains a Face

The most interesting renames are the ones where the old name was not a name at all. It was a number.

Before the rename, these entities existed in the graph as bare integers — 274974, ASN264967 — allocated numbers with no declared identity, ghosts in the registry. The rename is the moment the ghost puts on a face: the operator opens their peeringdb record and writes in who they are. This is the exact inverse of the census in Parts A–C. There, we watched identities dissolve — allocated numbers going un-announced, fading to dark. Here we watch them crystallise — allocated numbers acquiring a declared self. The two feeds bracket the lifecycle: renamed at the birth of an identity, taken_down at its dimming.

And there is a sub-type worth isolating.

Type 1b — the handle becomes a person. Some renames replace a technical handle not with a company but with a human being:

• BO-AS → Bilotserkovets Oleksandr
• YUKI-AS → Yuki Haigner
• CLNexus → Conor Lewis

This is the registry-naming companion to Part C (The Retail Floor). There we found autonomous systems held in one person's name and asked what that meant. Here we catch the act — the human behind a terse handle self-declaring, in peeringdb, that the network is them. CLNexus sounds like a company; Conor Lewis is a person deciding to drop the corporate veneer and sign their own name. That decision, captured as a transition, is a small piece of attribution the operator handed us for free.

3. Type 2 — The Ordinary Rebrand

The benign majority of meaningful renames are exactly what you would expect: businesses changing their market identity.

• CDN Squared Limited → DCNet Limited
• Arrow Group → Arrow Datacenters Inc
• GAMGROUP-INET → GAMGROUP-IT
• TBONET SERVICOS DE INFORMATICA → INFIX TELECOM

Companies rebrand. A CDN outfit repositions as a datacenter business; a group formalises into an Inc; a -INET handle modernises to -IT. None of this is suspicious, and that is the point of documenting it: the rebrand type is the baseline. It is the large, boring population against which a genuinely suspicious rename — a clean brand suddenly renaming to a throwaway, or a name jumping to match a known-bad entity — would stand out. You cannot spot the anomalous rename without first knowing what the normal one looks like, and the normal one looks like Arrow Group → Arrow Datacenters Inc.

4. Type 3 — Cosmetics, and the Human Hand

The smallest type is pure housekeeping, and it is quietly the most revealing about who is doing this:

• Shamal Telecome → Shamal Telecom — a typo, fixed.
• KUMARNET-AS-IN → Kumar Cable Digital Network — a handle expanded to a real name.
• OTETE-RU-ASN → OTT — a contraction.
• 121-AND-ONTO → 121&0n2 — an operator having fun.

That last one matters more than it looks. 121&0n2 is a leetspeak rendering of "one-two-one and onto" — a joke, chosen by a human, typed into a global routing directory. You do not get whimsy from an automated pipeline. Every rename in this feed carries a fingerprint of intent, and the cosmetic type makes that impossible to miss: these are people naming their networks, with all the typos, expansions, contractions, and jokes that implies. The renamed stream is, uniquely in the change-log, a record of self-chosen identity.

5. Why This Closes the Change-Log Triad

With this letter the series has read all three streams the change-log offers, and they turn out to occupy three different positions on a single spectrum of trust and meaning:

• taken_down (Parts A–C) — a first-census snapshot of the dark. Population-level truth, no per-event transition. Reveals the reserve, the accumulator, the retail floor.
• owner_changed (Part D) — the pipeline's own churn. Loud, mostly noise, occasionally hiding a reputation-laundry transfer. Trust nothing until you filter source and direction.
• renamed (this letter) — the operator's own voice. Small, clean, self-authored. Trust per event; use for attribution, not threat-hunting.

Reading lifecycle as a vector, then, is not one technique but three, and knowing which stream you are in is half the analysis. The same word — "change" — means a census artifact, a data refresh, and a human decision, depending on the column. That is the methodological spine the whole series was built to expose.

6. The Counter-Narrative

Steelman. "This is the softest letter yet — you've admitted the rename feed is basically benign, mostly rebrands and typos, no attacks, no threat. Why is it threat intelligence at all?"

Conceded, and reframed:

• "It's benign." Mostly yes — deliberately. Not every letter in a lifecycle series is an accusation. Establishing that the renamed stream is operator-authored and largely benign is itself the finding, because it tells a defender exactly how to weight it: as attribution ground-truth, not as an alert source. Knowing which of your feeds is trustworthy-but-quiet is as valuable as knowing which is loud-but-noisy.
• "Why threat intel?" Because attribution is threat intel. The number-to-person renames are self-declared identity that survives ASN churn — the durable seam you follow when everything else about a network changes. A rename feed is where you learn that CLNexus is Conor Lewis, and that mapping is exactly what you need the day one of those handles reappears behind different infrastructure.

What is not claimed: that any rename is malicious (none is so alleged); that renaming is suspicious (it is normal operator behaviour); that the named individuals are anything but public peeringdb self-reports. The claim is structural: renamed is the change-log's clean, self-authored identity stream, and it closes the triad.

Confidence: HIGH that every renamed event is a real operator-authored transition, that the three types (number-to-name, rebrand, cosmetic) partition the stream, and that it is the change-log's most per-event-trustworthy feed; MEDIUM on the framing of number-to-personal-name as the retail floor's registry companion.

7. Defence Response

• Use renamed as an attribution ledger, not an alert feed. Its value is durable, self-declared identity. Store the old→new maps (especially handle→person) so that when a handle reappears elsewhere you can resolve it to the human who once claimed it.
• Watch for the one rename that breaks type. Because the normal renames are rebrands and typos, the anomaly to alert on is a rename that jumps category — a clean corporate name suddenly becoming a throwaway, or a name mutating to impersonate a known entity. The benign baseline is what makes that anomaly visible.
• Join renames to the other two streams. A rename that immediately precedes a taken_down, or a holder that renames and changes owner in the noisy feed, is a lifecycle sequence worth a closer look. No single stream shows a carousel turning; the ordered join of all three can.

8. A Note on Method

Built entirely through the entity-graph MCP layer, no direct database access — entity_changes(change_type=renamed) for the 187 operator-authored transitions and their old_value/new_value/source fields, with entity_stats for the cross-stream comparison. All names are public peeringdb self-reports. No honeypot data, no attack claim, no accusation. This is an identity-formation study — the naming layer the rest of the series reads on top of. No SQL touched the investigation.

9. Investigation Metadata

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