Prince of Persia: Detecting the Next C2

All infrastructure data in this post is current as of 13 August 2026. Both attachments carry the same date.

Prince of Persia is an Iranian espionage group that has been active for well over a decade. It is also tracked as Infy, after the malware family that first exposed it. Palo Alto Networks' Unit 42 documented it in detail in 2016, describing a campaign reaching back to around 2007 that focused on Iranian dissidents, journalists, and opposition figures, alongside some government and telecommunications targets (Unit 42, "Prince of Persia: Infy Malware Active in a Decade of Targeted Attacks"). Its more recent tooling centres on two malware families, Foudre and Tonnerre — French for "lightning" and "thunder" — that work as a pair: a first-stage implant that profiles a victim, and a second stage delivered only to targets the operators judge worth the effort.

SafeBreach has followed the group since 2019. In December 2025 and February 2026 it published two detailed reports covering the actor's return after a quiet period, its command-and-control servers, its domain-generation algorithm, and its move to Telegram for tasking (Part I, Part II). Those reports are the starting point for this post. We took the indicators SafeBreach published and ran them through a large internet infrastructure graph — first to expand the picture of the actor's hosting, then to understand how the backend is put together, and finally, using the naming rules SafeBreach documented, to identify a set of domains the group has prepared but not yet switched on.

How we expanded

SafeBreach's reports list the group's command servers, and they cluster tightly: nearly all of the recent ones sit in a single address range, with a couple of older servers elsewhere. That list is the obvious place to start, but an address list is a snapshot. It tells you where the actor was, not where the actor keeps its things.

Running those indicators outward through the graph — from each address to the block it belongs to, the network that announces it, and the domains that resolve to it — filled in more of the picture. The hosting resolves to a small Romanian reseller (AS204641, HOSTGW), and the group's servers are spread across several of that network's blocks rather than the single range the reports name. One of those blocks holds a server worth stating plainly: 185.244.129.70 carries the group's DGA domains, sits in a block that appears in neither SafeBreach report, and is listed in no threat-intelligence feed we checked. It is a working command server that reputation-based tools are blind to, and it is the clearest sign that expanding past the published list was worth doing.

Two caveats belong here. This is more of the picture, not all of it; the graph's coverage is uneven and there are almost certainly boxes it does not show. And "live" in this context means DNS-active — the domains are registered and point at the server — which is not the same as confirming the server is answering victims. That takes a direct connection to it, which is a separate step.

What we found mapping the backend

The more useful question is not which servers exist but how they are wired together. Every domain has to be looked up before anyone can reach it, and that lookup — turning a name into an address — is handled by a nameserver. Following the nameserver records for the group's domains showed a consistent arrangement.

The live command servers are self-authoritative. Each one runs the nameservers for its own domains. dmxqdlcuiryu.site resolves to 45.80.148.195, and the nameservers for that domain (ns1.dmxqdlcuiryu.site) also sit on 45.80.148.195. The .space domains on 45.80.149.3 do the same. The domain, the address it points to, and the machine that answers "where is this name" are all one box.

Alongside the command servers are machines that do something different. They answer no malware and host no command service; they exist only to hold nameserver records. And the domains delegated to them share one property: they are registered, their nameservers are set on the actor's own machines, and they resolve nowhere. They have no address record at all. A large pool of the group's domains sits in this prepared-but-inactive state — staged on the group's own DNS, pointing at nothing.

Their backend structure, and the method

Put together, the backend is more organised than an address list suggests. There are two kinds of machine: command servers that are self-contained units of C2 plus their own DNS, and a separate tier of nameserver boxes holding a reserve of prepared domains. The published reporting listed the addresses; the DNS layer shows the shape.

None of this appears in any single lookup. It shows up only when you join two things that are usually looked at apart: which name is delegated to which nameserver, and which name resolves to which address. A domain delegated to the actor's own nameserver but resolving to nothing is invisible to a blocklist, because it has done nothing to be listed for, and absent from a C2 list, because it is not a C2 yet. Seeing it means holding both layers at once.

The repeatable part is the algorithm. A command address is true only until the actor rotates it; the generator that produces the group's domains keeps minting valid names on a schedule. SafeBreach reverse-engineered that generator and published how it works, so the names can be produced ahead of time and checked against the graph to see which are delegated, which are live, and where they point. We did not decode the algorithm ourselves for this work — we used the naming rules SafeBreach documented as a test and applied them to what the graph already held.

One difference stands out. The newest server, 185.244.129.70, does not follow the self-hosted nameserver pattern as cleanly as the older boxes; at least one of its domains uses a commercial DNS provider instead. It is a small thing and we would not read too much into it, but it may point to a change in handling on the group's most recent infrastructure.

What to look out for

The reserve is the part defenders should care about. It is a set of 58 domains, registered and delegated to the group's own nameservers, none of which currently points at any server. The full list is attached below (Attachment A).

They are confirmed as the group's by the rules SafeBreach documented, not by where they sit. Of the 58, 51 follow the eight-letter form the reports describe, using only letters from the second half of the alphabet, j to z, and the remaining seven follow the older hexadecimal form. None breaks either rule. The backend work is what surfaced these domains; the published naming rules are what confirm they belong to this actor and not a neighbour.

Three signs point to an operation still growing rather than winding down. When we began this work, the live server at 185.244.129.70 answered for 17 domains; at the time of writing (13 August 2026) it answers for 18. The reserve itself has been restocked while we watched: it held 56 names in late July, and two more hexadecimal names had been staged on the group's nameserver boxes by 13 August, delegated and dormant like the rest. And two of the reserve domains use top-level domains — .top and .website — that appear in neither report, so the generator's range of endings is wider than what has been documented. The names have not changed; the shelves they are placed on have.

The registration data adds a practical handle. Nearly all of the registered domains were bought through a single registrar (Spaceship) and hidden behind a single privacy service (Withheld for Privacy). The buyer is masked, so this names no person, but the consistency is the point: it reads as one operator registering in bulk, and it gives a single registrar to approach for abuse or takedown. Registration dates are not carried in the graph; a standard WHOIS lookup on any of these domains returns them.

One honest limit sits under all of this. A domain that is delegated but resolves nowhere can be one of two things: a name prepared ahead of use, or a name that was used and has since been pointed away — a removed address record and a never-set one look identical from outside. Both readings lead to the same place. This is a managed reserve on the actor's own DNS, and the moment any of these 58 domains gains an address record, a new command server has gone live. That is the event to watch for, and it is visible before the server does anything at all.

The part that lasts

The 58 names will age. The generator keeps minting valid names on a schedule, and the reserve will be restocked as it is spent — indeed it grew by two while we were writing. Attachment A is a snapshot with a shelf life, not a durable blocklist.

What does not age is the method. Every finding in this post came from joining two records that are usually read apart: which name is delegated to which nameserver, and which name resolves to which address. A domain parked on an actor's own DNS with no address record has done nothing to be listed for, so no reputation feed carries it, yet it is the clearest available signal of infrastructure prepared ahead of use. Nothing about that join is specific to this group. Any actor that stages domains before switching them on leaves the same seam in the DNS, and the same query finds it.

So watch the 58 while they last, and watch for the address records that turn them live. But the instrument worth keeping is the join itself. It can be run today, against any actor, on infrastructure that has not yet done anything at all.

Indicators (attached)

Attachment A — the 58 dormant reserve domains (with DNS-holder box, TLD, pattern, registrar, registrant, and per-field verification dates). Data as of 13 August 2026:

Attachment_A_reserve_domains.csv

Attachment B — the live server 185.244.129.70 and its current 18 domains. Data as of 13 August 2026:

Attachment_B_live_server.csv