Introducing Infrastructure Actors: A Tracking Schema for the Layer Beneath Threat Actors

Disclosure. AI (Claude) was used to help draft this piece from my notes. The underlying research, framing, and schema design are my own.

Threat intelligence has spent two decades perfecting the vocabulary for naming attackers. APT28, UNC2452, Mint Sandstorm, Charming Kitten, FIN7 — every major vendor runs its own naming convention, and defenders routinely translate between them. The conventions have different flavours (CrowdStrike's animals, Microsoft's weather, Mandiant's numbers), but they share a purpose: they let different researchers write about the same actor using a stable label that survives the actor rotating infrastructure, tooling, and operational patterns.

The layer underneath those actors has nothing comparable.

The hosting operators whose infrastructure is observably used, at material scale, for malicious activity — the Cloudzys and abrNOCs of the world, the small Iranian and Russian and Southeast Asian VPS resellers whose address space threat actors rent, the brokers who lease RIPE sponsorship as a product, the operators who tolerate abuse either by cultivation or by sustained non-enforcement — are tracked, when they're tracked at all, by their own commercial names. "Cloudzy" and "abrNOC" are the hoster's names, published because specific research disclosed them. There's no systematic way to label the ones that haven't been written up yet, no shared vocabulary for the pattern, and no convention for distinguishing an operator from the brands they run.

The category is deliberately not for mainstream hosters whose networks happen to carry occasional abusive customers. Legitimate commercial hosting companies — the AWSes, Cloudflares, DigitalOceans, Hetzners of the world — host abusive customers constantly, because the scale of their customer base guarantees it, but they enforce acceptable-use policy, respond to abuse reports, and terminate repeat offenders. They are not in this category and should not be labelled as if they were. The category is for operators where the abuse is a sustained property of the infrastructure, not an outlier on it.

That's a real gap, and it has real operational consequences. This piece proposes filling it with Infrastructure Actor as a tracked category, numbered INFRA-NN in order of first public mapping, with the operator's own structural signatures published alongside each number so the designation survives paperwork rotation.

Why the gap matters

Infrastructure actors sit at a different point in the attack chain than threat actors, and they have different properties that make them worth tracking separately.

They persist longer. APT groups rotate C2 domains in weeks and C2 IPs in days. The hoster underneath them changes paperwork much more slowly — monthly at the operational layer, sometimes years at the organisational layer. When an APT burns a C2 node, it moves to a new one; when the hoster underneath it burns, dozens of APTs and criminal operations have to move at once. The hoster is often the more durable attribution target, and almost always the more actionable one.

One infrastructure actor serves many threat actors. The hosting business model is multi-tenant by design. A single abuse-tolerant hoster can simultaneously carry commodity botnet C2, credential-stuffing SaaS, phishing-kit landing pages, residential-proxy exit nodes, and — occasionally, quietly — state-aligned APT infrastructure that is deliberately blending in with the criminal traffic. Attribution to any one tenant campaign leaves the hoster's other customers running. Attribution to the hoster blocks all of them at once.

They are legally and politically distinct. Threat actors are usually anonymous individuals or small teams operating outside their jurisdiction's law. Infrastructure actors are commercial entities operating, in most jurisdictions, within some reading of local law. They have corporate registrations. Their maintainers sign RIPE's terms of service. Their abuse contacts are usually self-published. Naming them does not carry the same identification risks as naming individual hackers, because the operators themselves have chosen to attach their names and brands to a commercial operation. The structural attribution is strong exactly where person-level threat-actor attribution is weak.

They are observable in registry data. Threat-actor attribution usually depends on behavioural evidence — malware fingerprints, TTPs, infrastructure overlap with historically-attributed campaigns. Infrastructure-actor attribution can be done from RIPE records alone: shared maintainer fields, declared as-set memberships, repeated abuse-contact strings, consistent registrant tax IDs. The evidence is public, primary-source, and stable in a way that behavioural attribution often isn't.

What a tracking schema needs

The successful threat-actor conventions share four properties, and an infrastructure-actor convention should copy all four:

1. A category marker. APT = state-aligned persistent, FIN = financially motivated, UNC = uncategorised cluster. The prefix tells you what kind of entity you're looking at and keeps the namespace separate from existing conventions. INFRA does the same for infrastructure.

2. A unique identifier. A memorable, non-sensational name. Numbers work (APT28, UNC2452). Two-word codes work (Fancy Bear, Mint Sandstorm). Sequential numbering has the advantage of being obviously inexhaustible and doesn't require inventing a theme. INFRA-NN, numbered in order of first public mapping.

3. Internal consistency. The same researcher's names follow the same rules, so a reader can scan a list of actors and know what each one is at a glance.

4. Attribution hedging built in. "UNC" exists because Mandiant needed a way to track clusters they hadn't attributed yet without implying attribution they couldn't support. Infrastructure actors need the same escape valve, because the structural evidence often doesn't extend to specific operator identification. INFRA-NN by default implies only that a cluster has been structurally mapped, not that the operator has been named.

The one property an infrastructure-actor schema needs that the threat-actor conventions don't is durable structural signatures published alongside each designation. Threat actors are named by their behaviour; the behaviour is the signature. Infrastructure actors are named by their registry footprint, and that footprint changes paperwork regularly — shell company names rotate, country attribution gets edited, abuse contacts get reassigned. The signature that identifies an infrastructure actor as still being the same actor across paperwork changes has to be published explicitly, so other researchers can confirm sightings against it.

For INFRA-NN, the published signature set should at minimum include:

• The RIPE maintainer (or equivalent at ARIN, APNIC, LACNIC, AFRINIC) — the cryptographically-controlled attribute that is hardest to coincidentally share
• The declared as-set, if the operator maintains one — these are self-published administrative perimeters
• The repeated abuse-contact string across the portfolio — operators rarely rotate these because customers depend on them
• The registrant tax ID or company registration, if a single corporate identity recurs
• The admin-c / tech-c handle pattern — person-object NIC handles reused across many objects
• Characteristic metadata quirks — specific transliteration errors, placeholder strings used as address labels, phonetic misspellings of landmark addresses, anything that would be a fingerprint in a textual sense

Any new RIPE object matching three or more of those signatures is almost certainly a new asset of the same actor. That's what makes the designation durable.

Scope: what counts as an Infrastructure Actor

The category is deliberately narrow. INFRA-NN is for malicious infrastructure actors — operators whose infrastructure is being used, at material scale, for the kinds of activity that abuse telemetry, honeypot sensors, and threat-intel reporting flag as malicious: scanning, brute-forcing, credential-stuffing, phishing-kit hosting, botnet C2, residential-proxy abuse, and the like. The "whether they know it or not" qualifier matters: some operators in this category actively cultivate the business, some simply fail to enforce acceptable-use policy at scale, and distinguishing those two states requires evidence the structural record often doesn't provide. The schema does not require proof of intent. It requires evidence that the infrastructure is observably being used this way and that the operator's conduct — through action, inaction, or deliberate obscurity — enables it.

What this excludes is just as important as what it includes. Mainstream commercial hosters are not infrastructure actors, even when some of their customers are abusive. Cloudflare, DigitalOcean, AWS, Hetzner, OVH, and the hundreds of other legitimate hosting companies in that tier host abusive customers constantly — the sheer scale of their customer base guarantees it — but they publish and enforce acceptable-use policies, respond to abuse reports, maintain abuse-response teams with real authority, and terminate repeat offenders. Their business is hosting; the abuse is a cost they manage. For an infrastructure actor, the abuse is not a cost being managed; it is a feature of the service, whether that's by design or by neglect.

The three properties that distinguish a tracked INFRA-NN cluster from a mainstream hoster:

1. Observable abuse at material scale, as a sustained property of the infrastructure. Not a few bad customers on a large network — a measurable concentration of abuse reports, honeypot-caught scanning, residential-proxy activity, or C2 traffic sustained across the operator's address space over time. Public abuse telemetry (AbuseIPDB, FraudGuard, Spamhaus, Shadowserver), honeypot sensor data, and threat-intel vendor reporting are the evidence sources for this property. The scale threshold is whatever makes the pattern unambiguously a property of the network rather than a property of a few outlier IPs.

2. Non-response to abuse — through action, inaction, or structural obscurity. The operator does not meaningfully enforce acceptable-use provisions. Depending on the specific actor this may look like: deliberately opaque corporate structures that defeat abuse-reporting attempts, published abuse mailboxes that go unanswered, abuse-contact addresses that route to the operators of the abusive activity themselves, country-attribution mismatches that defeat jurisdictional reporting, or simply ignoring reports when they arrive. Note that mainstream hosters sometimes miss abuse reports — the distinguishing property is systematic non-response at scale, not any single missed complaint.

3. Scale that justifies a tracked designation. A one-prefix operation is noise. The suggested threshold is roughly ten /24-equivalent prefixes or three distinct ASNs, administered under a single maintainer or equivalent control structure. Below that, informal names and brief writeups serve defenders better than a numbered schema entry; above it, the operator is operationally significant enough that defenders benefit from a stable label.

A fourth property — structural concealment — is common across most infrastructure actors but not strictly required. Rotating shell registrants, brokered sponsorships through third-country LIRs, country-attribution shell games, and placeholder person-object content are the diagnostic patterns of operators who are deliberately obscuring themselves. Some infrastructure actors do all of this; some are simply lax commercial operators who tolerate abuse without actively concealing anything. Both qualify. The concealment, when present, is useful for distinguishing the actively-cultivated subset from the merely-negligent subset, which the suffix system (below) handles.

Operators meeting the three required properties get INFRA-NN designations. Operators that meet one or two go onto an informal watch list until further research resolves whether they qualify. Operators who meet none — mainstream hosters whose networks have the usual trickle of abusive customers but whose business and enforcement posture are legitimate — do not belong in the schema at all, and including them would dilute the category to meaninglessness.

Classification suffixes

For operators where more than the structural map is known, optional suffixes carry additional information:

• -R for reseller — the operator's business model is leasing IP space or sponsorship to third parties
• -T for abuse-tolerant — demonstrable pattern of customers performing scanning, brute-forcing, phishing, C2, or other malicious activity without enforcement response. Whether the operator cultivates this pattern or merely fails to police it is often indeterminable from registry data, which is the point: the suffix flags observable non-enforcement, not inferred intent.
• -C for concealment-forward — the operator uses the structural-concealment patterns (rotating shell registrants, brokered sponsorships, country-attribution mismatches) that distinguish actively-cultivated malicious infrastructure from merely-negligent operations. Operators with -T but not -C are typically lax commercial hosters; operators with both -T and -C are operating in a mode that implies cultivation.
• -S for state-adjacent — the operator has documented credentialled relationships with state entities in its jurisdiction (with appropriate hedging; this does not imply state-directed activity)
• -U for under investigation — structural map is incomplete; full attribution set still pending

Suffixes stack when multiple apply, written in alphabetical order (so -RTCS, not -STCR). The U suffix always appears last when present, since it modifies the certainty of the whole entry rather than describing an operator property. Operators that don't warrant any suffix are just INFRA-NN.

Worked example. INFRA-01, the first operation mapped under this schema, carries all four descriptive suffixes and is written as INFRA-01-RTCS. Parsed letter by letter: it is a reseller (openly leases IP space and brand identities such as LordVPS and Almasnet to third parties); its infrastructure is abuse-tolerant (hundreds of thousands of abuse reports and sustained honeypot-caught scanning across the prefix, with no enforcement response); it is concealment-forward (twelve LIR memberships under one Iranian tax number, country attribution scattered across eight codes, a Belize-sponsored Romanian pharmacy shell for one leg); and it is state-adjacent (the operator's RIPE maintainer is co-listed on an Iranian state utility's RIPE object, and the operator himself is a founder of the Iran Network Operators Group). Four properties, four letters, one classification string that encodes the full operational character of the actor.

Reading other combinations. Different operators carry different combinations, and the combination itself tells defenders what kind of actor they're dealing with:

Suffix combo	Reads as
-RTCS	Full-stack malicious actor: reseller, abuse-tolerant, concealment-forward, state-adjacent. The hardest-attribution case; INFRA-01 is one.
-RTC	Classic bulletproof hoster: concealed commercial reseller for abusive customers, no visible state tie.
-RT	Lax commercial reseller: open operation, poor AUP enforcement, no concealment. Defenders should block the ranges; it's probably not an active adversary.
-TC	Concealed single-tenant operation: operator runs their own abusive service through their own concealed infrastructure, not reselling to third parties.
-RTS	Open state-adjacent reseller: visible operation whose abuse profile reflects political constraints on enforcement rather than active concealment.
-RTCU	Classifiable but incomplete: structural map is in place, operator identification pending.
-T	Borderline inclusion: barely qualifies for the category — no concealment, no resale, no state ties, just an operator who fails to police their customers at scale.

The combination system is deliberately coarse-grained. Four descriptive letters plus one certainty letter is enough to characterise an operator's operational mode without forcing the schema to encode every nuance of every actor. Nuance belongs in the writeup; the suffix string belongs on the schema entry.

Sub-brands and customer clusters

Infrastructure actors frequently operate under multiple customer-facing brand names and serve distinct customer clusters that are worth tracking separately. The schema should accommodate parent-child relationships:

• INFRA-NN/BRAND:<name> for a specific hosting brand the parent actor operates
• INFRA-NN/CUSTOMER:<label> for a notable customer cluster — a specific sub-reseller, a repeat tenant, a visibly-separated routing partition

So an operator running three brands might appear as INFRA-01, INFRA-01/BRAND:LordVPS, INFRA-01/BRAND:Almasnet, INFRA-01/BRAND:AMWAJ. A notable customer cluster under them might be INFRA-01/CUSTOMER:FEOPREST. The parent designation covers the operator; the sub-labels let different researchers write about different sub-components without re-attributing the whole thing each time.

INFRA-01: the first entry

I've mapped the first entry in parallel with this schema announcement. INFRA-01 is a Tehran-centred commercial VPS reseller operation; the full cluster mapping is in a companion piece. Short-form entry for the schema registry:

INFRA-01 (WCD) — Mohammad Khatibi aka LordVPS, Almasnet, AMWAJ, Tawsie Technology, DWCI, GAJNET Classification: INFRA-01-RTCS (reseller, abuse-tolerant, concealment-forward, state-adjacent) First mapped: October 2026

Structural signatures:

• RIPE maintainer: wcd
• Declared routing perimeter: as-set: as-wcd
• Admin/tech contact handle pattern: MK17520-RIPE across most inetnums; AA40101-RIPE, CA108xx-RIPE, CA109xx-RIPE across the Atis Omran Sevin twelve-LIR stack
• Abuse-contact pattern: mohammad@khatibi.org on sixteen blocks; abuse@lordvps.net on four; abuse@almasnet.ir on the AS8604 backbone
• Repeat registrant: Iranian corporate entity Atis Omran Sevin PSJ, same tax ID across all twelve LIR memberships ORG-AOSP1-RIPE through ORG-AOSP12-RIPE
• Characteristic metadata fingerprint: the physically-impossible address string "808 burj khalife businessbay uae" on ORG-MK219-RIPE (the Burj Khalifa is in Downtown Dubai, not Business Bay — that specific error is itself a textual fingerprint)
• Country-attribution pattern: UAE, Netherlands, UK, Germany, Romania, Iraq, Azerbaijan, and US codes appearing on allocations whose underlying operator is Iranian

Known operator identification: Mohammad Khatibi, a founder of IRNOG (the Iran Network Operators Group), who personally operates the LordVPS and Almasnet brands and is self-published as the abuse contact across most of the portfolio.

Scale at first mapping: 30 inetnum objects, 16+ autonomous systems declared in the as-set, 11+ distinct corporate shells across six fronting jurisdictions.

Any RIPE object showing three or more of the above structural signatures should be considered a new INFRA-01 asset. The parent operator may rotate corporate shells, country attribution, and sub-reseller mailboxes; the maintainer field, the as-set membership, and the admin-c handle pattern are the durable identifiers.

What INFRA-NN is not

A few explicit scope boundaries to prevent the schema from being misread:

• INFRA-NN is not an attribution to specific criminal activity. It designates the hosting operation, not any particular tenant's conduct. Writing "the C2 was hosted on INFRA-01 infrastructure" is accurate; writing "INFRA-01 operated the C2" is not, unless specific evidence supports that stronger claim.
• INFRA-NN is not an accusation of state tasking. The -S suffix flags credentialled relationships with state entities, which is a structural observation. Any specific state-tasking claim requires its own evidence.
• INFRA-NN is not a sanctions designation. Sanctions are a legal determination made by competent authorities. The schema is a research-community tracking vocabulary.
• INFRA-NN does not identify individual operators by default. Where the operator is self-published (as with Khatibi for INFRA-01), the designation can carry that name; where the operator is structurally mapped but not individually identified, the designation stands on its own without a name attached.

Call for adoption

I'd like to see this used. Infrastructure actors are a real category of operator with real operational significance to defenders, and the lack of shared vocabulary is a problem I can only fix for my own research in isolation. For the schema to be useful, other researchers need to be able to assign new INFRA-NN numbers to clusters they map and publish them against the same signature-set standard.

A few concrete things I'd suggest for anyone who wants to adopt this:

1. Number sequentially from your own work. INFRA-01 is my first. If you map one before this piece reaches you, number it INFRA-02 and publish your structural signatures; if we collide, we'll reconcile.
2. Publish the full signature set. The schema works only if other researchers can confirm sightings. A name without signatures is just a brand.
3. Hedge appropriately. Use the -U suffix freely when structural mapping is incomplete. Avoid -S without a specific documented state linkage. The vocabulary works only if the hedges are honest.
4. Separate operators from brands. A hoster running three brands is one INFRA-NN with three BRAND sub-labels, not three INFRA-NN entries. Keeping the parent-child relationship explicit prevents the schema from double-counting.
5. Treat it as community vocabulary, not a proprietary taxonomy. I'm proposing it; I'm not claiming it. If adoption produces refinements, those are improvements, not forks.

The infrastructure-actor layer is tractable to map, structurally durable, and operationally more significant than the threat-actor-of-the-week framing usually allows. A shared vocabulary for naming it is the first step toward making the research in this layer cumulative rather than one-off.

---

The full WCD cluster mapping behind INFRA-01 is published separately. Comments, corrections, or proposed INFRA-NN entries from other researchers welcome.