One Maintainer, Thirty Netblocks: Mapping an Iranian VPS Resale Cluster

Disclosure. AI (Claude) was used to help draft this write-up from my notes. The underlying research, the findings, and every verified claim are my own, drawn from manual registry work against RIPE, Boarnet data, and publicly accessible sources.

Honeypots catch a lot of noise. Most of it is forgettable. But every so often a cluster of scanning traffic turns out to be the visible edge of a much larger structure — one that, with patience and primary-source discipline, is possible to map in full. This is the story of one of those clusters: a group of IP ranges hitting my sensors with VNC probes that resolved into a tightly-structured Iranian commercial reselling operation hiding under European and Gulf country attribution. This writeup catalogues the operation as INFRA-01-RTCS, the first entry in the Infrastructure Actor tracking schema I introduce in a companion piece.

The findings here are built entirely from public RIPE records, open abuse telemetry, and published threat-intelligence IOC sets. No private data, no paid WHOIS-history services, and no identification work on natural persons beyond what the operator has self-published in RIPE's own abuse-contact fields. The point of the piece is to show both what the registry evidence actually supports — which turns out to be a lot — and where it stops, which matters just as much.

The honeypot thread

The initial signal was unglamorous: Boarnet sensor data showed seven source IPs in 213.177.179.x repeatedly scanning VNC and RDP against my honeypots. The activity was malicious scanning of the kind Boarnet is designed to catch — repeated unsolicited probes against exposed remote-desktop services, from the same narrow address range, sustained over time. Geolocation put the sources in AS208137, operated by Feo Prest SRL, a company registered in Romania.

The scanning itself is commodity. What makes it worth following is the question underneath: who is using this infrastructure to do it? An IP is the end of a chain of commercial relationships — a tenant renting from a reseller, a reseller sitting on a sponsored allocation, a sponsorship brokered through an LIR, an LIR operating under RIPE policy. The scanning is observable; the chain behind it usually isn't. Mapping the chain is where structural attribution does its real work, and in this case the chain turned out to run back to something much larger than a single Romanian hoster.

The RIPE record for AS208137 had two details worth pulling on. The maintainer object was wcd, and the netname was simply wcd as well on an inetnum sub-partitioned out of the Feo Prest allocation. The country code on that same partition was AE, despite Feo Prest being Romanian and the sponsoring LIR being in Belize.

The maintainer field in RIPE isn't a free-text label. It's a cryptographically-controlled attribute that controls write access to an object. Two different ASNs sharing a maintainer means one entity has registry-level control of both, and that's a far harder thing to fake or coincidentally share than a company name on an inetnum. So the question became: what else does wcd touch?

The structural picture

What wcd touches is a lot. Across the netblocks I traced, wcd appears as the maintainer on 30 separate /24 or /25 inetnum objects, invariant across the entire set. Two of those blocks carry a second co-maintainer (Almasnet-MNT and lir-ir-ariajahangiri1-1-MNT), but there is no block in the cluster where wcd drops out. That invariance is the strongest single finding in the whole investigation — it's the registry equivalent of a fingerprint on every object.

The portfolio has visible layers. On top sits a set of customer-facing hosting brands: LordVPS, Almasnet, AMWAJ/Tawsie, Lexahosting, with supporting domains like soshiant.net, btcloud.ro, feoprest.life, and amnet.ae. Below that, a registrant layer of corporate shells that varies block by block:

Atis Omran Sevin PSJ (an Iranian corporate entity in Tehran) — twelve blocks, one per LIR membership ORG-AOSP1-RIPE through ORG-AOSP12-RIPE, all carrying the same Iranian tax number
AMWAJ ALKHYR Commercial Brokers Co. (a UAE-registered trading company in Bur Dubai) — ten blocks
Feo Prest SRL (a Romanian limited-liability company registered as a retail pharmacy in Constanța county) — two blocks
Limited Network LTD (a UK company registered at a Manchester address) — single block attached to AMWAJ routing
An individual Iranian LIR member — single block (213.177.179.0/24)
A single-block LIR registered to the operator himself under his own name

Under that, two Iranian corporate entities — Pardazeshgaran Almas Pasargad Co. PJS (which operates AS8604 under the striking name "DWCI-CORE-BACKBONE-NL" and AS47554 as ALMASNET-AS) and Blue Diamond Network — appear to be either the same operator or closely related, sharing the "Almas" / Diamond branding. The AlmaseAbi ("Blue Diamond") Building in Robat Karim, Tehran, is listed as Blue Diamond Network's registered premises.

The operator at the centre of this maintainer, as self-published on sixteen of the blocks via the mohammad@khatibi.org abuse contact, is Mohammad Khatibi — a founder of IRNOG, the Iran Network Operators Group, and the person behind the LordVPS and Almasnet brands that front much of the portfolio's commercial activity.

The abuse contacts rotate: mohammad@khatibi.org on sixteen blocks, abuse@lordvps.net on four, abuse@almasnet.ir on the AS8604 backbone, and single or paired assignments to half a dozen other mailboxes including two anomalous Gmails that sit on otherwise-uniform blocks and probably mark sub-resold space. One of the anomalous mailboxes is the abuse contact for AS215930 (CIPHER OPERATIONS DOO BEOGRAD, a Serbian company) with a role-object address claiming Kyiv, Ukraine — a Serbian company administered by an Iranian maintainer with a Ukrainian address on file is a four-jurisdiction stack.

The country attribution on these objects is set, prefix by prefix, to whatever fits the fronting target. The same operator's blocks appear with country codes for the UAE, Netherlands, UK, Germany, Romania, Iraq, Azerbaijan, and the US. The underlying operation is Iranian. The country-attribution shell game is architectural, not accidental, and it exists specifically to defeat geographic-origin filtering by payment processors, SaaS gatekeepers, and defensive filtering systems.

The LordVPS acquisition cadence

One slice of this portfolio tells the story particularly cleanly. Twelve of the netblocks are registered as sequential netnames — IR-LORDVPS1 through IR-LORDVPS12 — with date suffixes that run through 2024 in near-perfect order. Each one maps to a separate RIPE organisation handle (ORG-AOSP1-RIPE through ORG-AOSP12-RIPE), but every one of those organisations carries the same Iranian tax number, the same Tehran address, and the same contact phone. Roughly one /24 per month, over roughly a year, acquired by the same registrant under the same maintainer (wcd), with abuse alternating between abuse@lordvps.net and the Khatibi mailbox. That cadence is itself a finding. It's not opportunistic acquisition; it's a deliberate buildout.

The use of a single Iranian tax ID as the basis for twelve separate RIPE LIR memberships is also a RIPE-governance question in its own right, independent of anything the infrastructure is used for. RIPE policy generally contemplates one LIR per organization. Whether twelve LIRs under one Iranian tax number comply with current policy is a question RIPE NCC can be asked about on the record.

Cross-ASN linkage, confirmed from registry data

The thing that elevates this from "an interesting hand-drawn graph" to "a documented operation" is that the maintainer linkage shows up in RIPE's own records across ASN boundaries. At minimum:

AS8604 (Pardazeshgaran Almas Pasargad, the Iranian backbone object named "DWCI-CORE-BACKBONE-NL") — mnt-by: wcd, abuse abuse@almasnet.ir
AS47554 (ALMASNET-AS, same organisation) — mnt-by: wcd
AS44947 (AMWAJ, UAE-fronted) — mnt-by: wcd
AS52209 (LORDVPSNLNETWORKNL) — mnt-by: wcd
AS58192 (DDOS-PROTECTION-GAJNET) — mnt-by: wcd
AS213456 (TT-UAE, Tawsie Technology) — mnt-by: wcd
AS215193 (LI-TX, operator's own LIR) — mnt-by: wcd
AS199983 (Hooshmand Shabake Dez Net, Dezful) — mnt-by: wcd
AS215930 (Cipher Operations, Belgrade) — mnt-by: wcd
AS208137 (Feo Prest, Belize-sponsored through IPv4 Mall) — wcd maintains the inetnum partitions sub-allocated under it

Same maintainer, authoritative registry data, multiple fronting jurisdictions. The declared as-set: as-wcd object itself names at least sixteen AS numbers as part of this routing family, published by the operator as the explicit administrative perimeter of the operation. The "Iranian operation behind a European front" thesis isn't inference from a graph someone drew by hand; it's visible in the primary source, declared by the operator.

A note on the Feo Prest leg specifically: the ASN was sponsored at RIPE through IPv4 Mall Ltd. (ORG-IML22-RIPE), a Belize-registered LIR that commercially sells RIPE sponsorship as a product via ipv4mall.com. The Feo Prest end-user side carries a RIPE person record in the name of the pharmacy's registered managing director, listed at the pharmacy's registered address, with a non-Romanian mobile number as the contact. These person-field contents are editable by the holder on request, GDPR-filtered on anonymous queries, and spoofable at registration; they are what the records say, not necessarily who is operationally behind the keyboard. The maintainer linkage is the stronger evidence. The person-field detail is included only to note that an unusual mismatch exists — a small-town pharmacy owner's name sitting on a RIPE maintainer object controlling an abuse-prevalent ASN — and that mismatch is a question for RIPE audit, not an identification.

The abuse footprint is real — and generic

If you want to know what this infrastructure does, the public abuse data is the first place to look. AS208137 appears in FraudGuard's honeypot telemetry as an actively malicious ASN. Sampled Feo Prest IPs carry tens of thousands of abuse reports on AbuseIPDB, with a single address having drawn over 300,000 reports from more than a thousand distinct reporters, with notes consistent with brute-forcing, SSH/RDP scanning, and proxy abuse. The honeypot activity I observed matches that profile — VNC and RDP scanning, the same pattern the third-party telemetry already reflects.

But — and this is the important part — the characterization is generic. Brute-force scanning, credential-stuffing, proxy laundering: this is bulletproof / abuse-tolerant hosting being used opportunistically for commodity criminal purposes. It is not, on this evidence, a named APT campaign.

The state-nexus question

The most tempting move at this point is to escalate the framing. "Iranian commercial VPS cluster used for scanning" becomes "Iranian state cyber infrastructure" by implication. I want to be direct that the evidence does not support that step.

To test it rigorously, I correlated the full 16-distinct-/24 cluster against the published IOC sets from several current Iranian APT reports — SafeBreach's Prince of Persia / Infy writeup, Hunt.io's tracking of MuddyWater, APT42, and Dark Scepter / APT34. The result was unambiguous: zero direct overlap, and no shared /16. None of the publicly-documented Iranian state-aligned infrastructure sits on these ranges, and the ranges don't even border it.

One further tempting detail that I'll flag explicitly and then set aside: the wcd maintainer is co-listed on the RIPE org object for Tehran Regional Electric Company (ORG-TREC1-RIPE), an Iranian state-owned utility, alongside MNT-RSPN. That linkage dates to 2010 and almost certainly reflects legacy IT-services work from well before the LordVPS buildout. On its own it is not evidence of a current operational tie between the commercial reseller business and the state sector, and I'm not going to treat it as such. It is a fact worth noting and a question worth putting to the parties involved; it is not a conclusion.

So the honest statement of the finding is this: INFRA-01 fits the structural category of operations like Cloudzy/abrNOC that have been documented as hosting Iranian state activity, but the elevating evidence — multiple independently-attributed APT C2 nodes actually living on the specific ranges — is not present in current open reporting. The cluster is a commercial abuse-tolerant Iranian VPS reseller. Whether any of its tenants are state actors is an open question that only behavioral analysis of what the infrastructure hosts could answer, and that analysis has not been publicly done.

The caveats on the negative result are real: I'm checking against a subset of public IOCs; APTs rotate infrastructure fast and historical use could have aged out of current reporting; and — most importantly — bulletproof resellers are specifically where quiet state tenancy would not flag at the provider level, because actors who want deniability deliberately blend into commodity criminal traffic. The MuddyWater reporting makes exactly this point: the group uses commodity tooling "to blend in with cybercriminals."

Cataloguing: INFRA-01-RTCS

The operation described in this piece is INFRA-01 under the Infrastructure Actor schema I introduce in a companion piece. Its full classification is INFRA-01-RTCS: a reseller (R), whose infrastructure is abuse-tolerant (T), operated with concealment-forward structures (C), with state-adjacent credentialled ties (S). The schema piece explains the suffix system; the evidence for each letter is in the body of this writeup.

For other researchers to confirm sightings — a new RIPE object that may belong to INFRA-01 — the structural signatures to check are:

mnt-by: wcd on an inetnum, inet6num, aut-num, route, or route6 object
Membership in the declared as-set: as-wcd
mohammad@khatibi.org as abuse-contact mailbox
Admin-c / tech-c handle MK17520-RIPE (which the operator maintains as a business-handle person object)
Netnames of the form IR-LORDVPS<N>, IR-<NAME>-<DATE> (the individual LIR member's block), AMWAJ-ALKHEYR, or IR-KHATIBI<N>
Country-attribution mismatches between the registrant organisation's country and the inetnum's country code

Any object matching three or more of those signatures is almost certainly a new INFRA-01 asset.

What's genuinely newsworthy, and what isn't

Three threads from this investigation are legitimately in the public interest:

The first is the architectural pattern itself. This is a clean, primary-sourced example of how modern abuse-tolerant hosting actually works: single-maintainer control, rotating corporate shells, country-attribution set to defeat origin filtering, parallel direct-LIR and brokered-sponsorship customer relationships, with the Feo Prest / IPv4 Mall leg showing the brokered pattern and the Atis Omran Sevin twelve-LIR stack showing the direct pattern on the same operator's books. The literature describes this pattern in the abstract constantly. Here it is in full, in RIPE's own records.

The second is the governance question for RIPE NCC. Twelve LIR memberships under a single Iranian tax ID, administered by a single maintainer that also sits on an Iranian state utility's RIPE objects, and simultaneously accepting a Belize-brokered sponsorship whose named end-user is a two-employee Romanian pharmacy — that is a stress test of whether RIPE's "know your customer" controls are functioning. It's a question that deserves to be put to RIPE directly, on the record.

The third is the sanctions-policy angle. The whole architectural purpose of the country-attribution shell game is to make Iranian-origin space appear non-Iranian to Western filtering systems — including the ones that implement sanctions compliance. Whether that constitutes evasion in a legal sense varies by case, but the structural fact that the operation deliberately defeats origin attribution is policy-relevant on its own.

What is not a story — not from this evidence — is "named Iranian individuals running state cyber operations." The infrastructure attribution is strong; the person-level identification is weak and spoofable; the state-nexus claim is unsupported. Reaching for any of those three framings on the current evidence would be the kind of overreach that gets real people harmed, including people who may well have nothing to do with whatever is actually happening on the ranges. The structural story is enough.

Methodology notes

Everything above is built from primary sources: RIPE REST API records (rest.db.ripe.net) and the RIPE WHOIS CLI (whois -h whois.ripe.net -- -i mnt-by wcd enumerates the full maintainer-level inventory in one query), third-party RIPE mirrors (bgp.tools, ipgeolocation.io), FraudGuard and AbuseIPDB public telemetry, Scamalytics fraud-risk scoring, and published Iranian APT IOC lists from SafeBreach and Hunt.io. The IOC overlap check was run programmatically against the full /24 set and verified not to produce any direct or /16-adjacent matches. The maintainer-invariance finding was verified across all 30 cluster blocks in the source data.

Where contact-level identifiers are referenced — a shared phone number appearing on multiple person objects maintained by wcd, or an abuse-contact mailbox repeating across the portfolio — those are included as what the RIPE records display, not as identification work on natural persons. RIPE person-object content is editable by the holder, GDPR-filtered on anonymous queries, and has historically been both corrected and scrubbed in place. The identifying weight is on the maintainer and organisation linkage, not the person fields. Specific phone numbers, home addresses, and natural-person names from RIPE records are omitted from this writeup even when technically public; the structural case does not require them.

Nothing in this piece required accessing private data, paid WHOIS-history services, personal contact information, or any identification work on named individuals.

What's next

The analytic step that would legitimately escalate this story is passive DNS and certificate-transparency analysis against the cluster's prefixes and the operator-controlled domains. If pDNS surfaces phishing-kit landing pages, malware C2 panels, or impersonation infrastructure for Western banks and services, that's the behavioral evidence that moves "grey hosting" into campaign-attribution territory. If it surfaces legitimate Iranian SaaS, it reinforces the sanctions-evasion-without-malware reading. If it surfaces residential proxy panels, it's a proxy-laundering story. All three are publishable; which one is true is a question of what the records show.

Monitoring the cluster for registry-level change — new netblocks acquired, country attribution shifting, maintainer edits — is also straightforward with RIPE's APIs, and tracking that over time is how you see the operation grow or restructure. INFRA-NN assignments will continue as further clusters are mapped.

For now: the infrastructure is well-mapped, the governance questions are on the table, the defensive block list is ready, and the state-nexus question is correctly left open rather than overreached.

If you work in trust & safety, network abuse response, or infrastructure journalism and want the full technical dossier — including the 16-/24 defensive block list, the RIPE object inventory, and the IOC-overlap methodology — reach out via jacobonintelligence.com.