GigaWiper Infrastructure: From Two IPs to an Iranian APT Attribution Chain

We took two C2 IP addresses from a malware news article and pivoted through Shodan, DNS, reverse MX lookups, certificate transparency, WHOIS, and MITRE ATT&CK to reconstruct the GigaWiper backdoor's hosting infrastructure: a six-server cluster on WorldStream NL behind a front domain, three co-located aged domains sharing a Dynadot registrar and a common mail relay, and a probable attribution chain to CyberAv3ngers — an IRGC-affiliated Iranian APT group.

TL;DR: GigaWiper is a modular Golang-based Windows backdoor disclosed by Microsoft Threat Intelligence on 9 July 2026. It combines three previously separate malware families — Crucio ransomware, FlockWiper, and a standalone disk wiper — into a single implant with approximately 20 commands across destruction, remote access, and system management categories. The article we started from mentioned two C2 IP addresses. From those two IPs, we pivoted through Shodan, DNS reverse lookups, certificate transparency, WHOIS, and Wayback Machine snapshots to reconstruct a six-server cluster on WorldStream AS49981 (Netherlands) behind a front domain called snaptobook.com. A reverse MX pivot on the cluster IPs then surfaced three co-located aged domains — a Spanish B&B (casahondon.com, since 2016), a Chinese medical centre (wf-breast-center.com, since 2003), and a VPN infrastructure domain (zeal-strap.com, since 2005) — all registered at Dynadot and sharing a common mail relay on 1pda.com. Cross-referencing the malware's code overlap with Crucio ransomware through CISA advisory AA23-335A, FortiGuard, and MITRE ATT&CK produced a probable attribution chain to CyberAv3ngers (G1027) — an IRGC-affiliated Iranian APT group. Microsoft has not confirmed the attribution. We assess it as PROBABLE.

1. The source

On 10 July 2026, our f4n6 security feed aggregated a Malwarebytes report on GigaWiper, a destructive Windows backdoor disclosed by Microsoft Threat Intelligence the day before. The Microsoft blog post is a code-level analysis worth reading in full, but the key facts for our purposes were:

• Two C2 server IPs: 185.182.193[.]21 and 212.8.248[.]104
• C2 protocol stack: RabbitMQ over AMQP for command delivery, Redis for status/output reporting
• C2 ports (from the hard-coded AES-encrypted config): 185.182.193[.]21:5544 (RabbitMQ) and 185.182.193[.]21:7542 (Redis) — non-standard ports, not the default 5672/6379
• Persistence: Scheduled task named "OneDrive Update" running every minute and at startup
• Code overlap: Command 3 (RanMain/BigBangExtortMain) is derived from Crucio ransomware. Command 12 (WipeCMain) is a Golang reimplementation of FlockWiper.
• Eight SHA-256 hashes published by Microsoft across GigaWiper backdoor, standalone wiper, Crucio, and FlockWiper samples
• Tracked by Google Threat Intelligence Group and Binary Defense as BLUERABBIT

Two IPs. That was the starting point. The question was not "is this malware dangerous?" — Microsoft answered that. The question was: what sits behind those IPs, who controls them, and can we build an attribution chain from public data alone?

2. Phase 1 — Automated pipeline (and its limitations)

We ran the IPs through our phishing-tracker MCP pipeline, which is designed for phishing kit infrastructure but works for any IP-based IOC pivot. The pipeline ingested the article, extracted the two IPs as high-confidence markers, and ran six queries across URLScan, urlquery.net, and direct IP pivots.

The result: zero candidates. No URLScan scans for either IP. No urlquery verdicts. No phishing infrastructure. This is the expected result — GigaWiper is a post-compromise backdoor, not a phishing kit, and its C2 runs RabbitMQ and Redis on non-standard ports rather than serving web content that URLScan would crawl.

URLScan did return one scan for 212.8.248[.]104 — a bare HTTP root access on 9 July 2026, the disclosure date. Someone else had the same idea we did. No page title, no server header, no content.

The automated pipeline had done its job: it extracted the IOCs and confirmed there was no web-facing infrastructure to score. The next phase was manual pivoting.

3. Phase 2 — Shodan and the snaptobook.com discovery

The first pivot that produced results was Shodan's InternetDB API. A single curl call:

curl -s "https://internetdb.shodan.io/185.182.193.21" | jq .

Returned:

{
  "cpes": ["cpe:/a:apache:http_server:2.4.52"],
  "hostnames": ["snaptobook.com"],
  "ip": "185.182.193.21",
  "ports": [80],
  "tags": [],
  "vulns": ["CVE-2026-33857", "CVE-2024-24795", ... 76 total]
}

A hostname. snaptobook.com. The C2 IP has a PTR record pointing to a domain that presents itself as a web application. The secondary C2 (212.8.248.104) returned nothing from Shodan — "No information available." Dark host, no indexed services.

This is the moment the investigation shifted from IOC enrichment to infrastructure reconstruction.

4. Phase 3 — DNS enumeration and the six-server cluster

A DNS A record query confirmed snaptobook.com resolves to 185.182.193.21. The MX record points to mail.snaptobook.com — same IP. The nameservers are GoDaddy (ns15/16.domaincontrol.com). The SPF record is where it got interesting:

v=spf1 a mx ip4:185.182.193.21 ip4:185.182.193.0/24 ~all

The SPF record authorises the entire /24 subnet. That is either a lazy admin or a deliberate authorisation for a multi-server deployment. A reverse DNS sweep of the full /24 confirmed the latter.

The snaptobook.com cluster

Six servers, all on 185.182.193.0/24, all running the same Apache 2.4.52 on Ubuntu, all with PTR records linking them to snaptobook.com. The C2 IP (.21) sits in the middle of the cluster. snap5 (.62) is the only host with SSH exposed — the likely management entry point.

Certificate transparency logs on crt.sh added more subdomains:

*.snaptobook.com
d1-manager.snaptobook.com
docker.snaptobook.com
habits-blog.snaptobook.com
habits-blog-r2.snaptobook.com
habits-r2.snaptobook.com
habits-wonder.snaptobook.com
habitswonder.snaptobook.com
test.snaptobook.com
www.snaptobook.com

docker.snaptobook.com and d1-manager.snaptobook.com are infrastructure management interfaces. The habits-* subdomains suggest a second product ("Habits Wonder") on the same domain. None of these subdomains resolve now — they existed historically and were captured by CT logs.

5. Phase 4 — WHOIS and the Wayback Machine: what is snaptobook.com?

WHOIS for snaptobook.com:

Privacy-protected, GoDaddy, created March 2024 — seven months before GigaWiper was first observed in the wild (October 2025). The update in April 2026 is recent.

The Wayback Machine told us what the domain presents to the world. The snapshot from December 2025 shows:

SnaptoBook | Personal accounting software — Conduct Worthy Business — Invoice and Receipt Management software for Reimbursement & Tax Filing & Bill Splitting & Project Tracking

A receipt-scanning and expense management app. QR code download. Referral traffic from AI tool directories (proaitools.com, creati.ai, taaft, workwithai, topaitools). Copyright "© 2024 Leeta." Contact email at snaptobook.com.

Front domain or compromised host?

Two hypotheses:

1. Front domain. snaptobook.com was registered in March 2024 as a legitimate-looking SaaS shell to camouflage C2 traffic. The receipt management app is thin cover — a single landing page with no functional backend, no app store presence, no user reviews. The C2 runs on the same IP behind non-standard ports that would not be visible to typical internet scans. The six-server cluster is over-provisioned for a receipt-scanning app with no app store listing.
2. Compromised host. snaptobook.com is a real (small) SaaS product and the attacker compromised the server to deploy GigaWiper C2 alongside it. The domain has been operational since 2024 with referral traffic from AI tool directories.

We assess hypothesis 1 (front domain) as more likely. The domain was created seven months before GigaWiper's first observed activity. The Wayback content is a single landing page — no user dashboard, no API documentation, no pricing page, no help center. The docker and d1-manager CT log subdomains suggest infrastructure management rather than product deployment. A real SaaS product would have a functional backend, user registration, and app store presence. We found none of those.

But we cannot rule out hypothesis 2. The referral traffic from AI tool directories suggests someone marketed the domain. If it is a compromised host, the operator should be notified via GoDaddy abuse.

6. Phase 5 — The /24 neighbourhood and WorldStream's abuse problem

Both C2 IPs — 185.182.193.21 and 212.8.248.104 — are on WorldStream B.V. (AS49981), a Dutch hosting provider based in Naaldwijk. RIPE WHOIS confirms both /24 ranges are ASSIGNED PA to WorldStream.

The reverse DNS sweep of 185.182.193.0/24 revealed the standard WorldStream pattern — most IPs have generic 185-182-193-X.hosted-by-worldstream.net PTR records, with a few customer-specific hostnames sprinkled in:

.82  SRV001PVE001.serverbeheer.com    (Proxmox VE — Dutch hosting reseller)
.84  SRV001RTR001.serverbeheer.com    (Proxmox router)
.86  VPSRV08.serverbeheer.com         (VPS)
.135 mail.nether-realm.com            (unrelated mail server)
.145 mx3.mailplatform.eu              (email platform)
.183 mx1.mgadmin.info                 (mail admin)
.220 widget0.servitubes.com           (web widgets)
.234 rpgland.org                      (unrelated)

The /24 is shared infrastructure. The snaptobook cluster occupies IPs .21, .40, .42, .54, .59, .62 — a contiguous block suggesting a single VPS deployment.

The secondary C2's /24 (212.8.248.0/24) is similarly WorldStream shared hosting, with supremehosting.nl as a co-tenant and the neighbour 212.8.248.103 running nginx + OpenSSH 8.0.

WorldStream's abuse profile

MalwareURL.com lists 50+ malicious entries on AS49981 from the last 45 days alone:

CleanTalk also lists multiple spam reports across WorldStream ranges. WorldStream is a consistent enabler of malicious infrastructure. The abuse volume suggests minimal takedown response. GigaWiper C2 on this provider is consistent with the pattern.

7. Phase 5b — Reverse MX pivot: co-located domains on the cluster IPs

The snaptobook.com SPF record authorised ip4:185.182.193.0/24 for mail sending. The MX record pointed to mail.snaptobook.com at .21. This raised a question: if the cluster runs mail services, are there other domains using this infrastructure? A reverse IP lookup on each cluster IP produced results that expanded the investigation significantly.

The pivot

HackerTarget's hostsearch API and URLScan's page.ip search were run against all six cluster IPs. Three of the six returned domains that were not snaptobook.com subdomains:

Three co-located domains

All three domains are registered at Dynadot Inc with the same nameservers (ns1/ns2.dyna-ns.net). All three share the same SPF-authorised mail server IPs: 45.138.37.98 and 46.105.47.219. The shared registrar, nameservers, and mail infrastructure link them to the same operator.

casahondon.com — A Spanish bed and breakfast in Hondón de las Nieves, Alicante. Facebook page shows "Casa Hondon, Bed and Breakfast en vakantiehuis verhuur." Created 2016-10-17 at Dynadot. The Wayback Machine shows the domain's content has shifted over time: 2017 snapshots show Japanese-language content about driver's license training camps (免許合宿), unrelated to a Spanish B&B. The domain currently has 20+ subdomains (login, admin, api, app, staging, dev, mail, demo, testing, m, sitemaps) all resolving to 185.182.193.54. The content mismatch between the B&B identity and the Japanese content suggests the domain has changed hands at least once, but we cannot determine whether that was a legitimate sale or unauthorised takeover.

wf-breast-center.com — Created 2003-11-19 at Dynadot. Wayback snapshots from 2020 show Chinese-language medical content about a breast center — case studies, product pages, company introduction, contact page. URLScan shows cloud.wf-breast-center.com and mta-sts.wf-breast-center.com subdomains. The SPF record authorises a large fleet of IPs: OVH (France and Canada), Viettel (Vietnam), and Velcom. The domain currently has no A record. The SPF breadth (13 IPs across 4 providers in 3 countries) is unusual for a medical clinic website and is consistent with a mail relay operation, but we cannot confirm whether the current operator is the original registrant.

zeal-strap.com — Created 2005-12-08 at Dynadot. URLScan captured 10 subdomains: remote1, terminal1, terminal2, web1, web2, app2, vpn-portal, vpn2, sign, auth. The subdomain names are consistent with VPN/remote access infrastructure. None of these subdomains resolve now. SPF authorises the same two mail server IPs as casahondon.com. We do not know what the domain hosted before the URLScan captures.

The shared mail relay: 1pda.com

The SPF records for all three co-located domains authorise 45.138.37.98 for mail sending. Shodan identifies this IP as 1pda.com — running nginx and PHP 7.4.33 (end-of-life) on 3W Infra B.V. (another Dutch hosting provider). The domain 1pda.com was registered 2026-01-24 at Gname (a Singapore-based registrar) via Afternic nameservers — a recently purchased domain, likely from the aftermarket. URLScan also found pathwaysdirectory.com on the same IP, with an mta-sts subdomain certificate. The second SPF-authorised IP, 46.105.47.219, is on OVH SAS (France) — no Shodan data.

What this means

The GigaWiper C2 is not just two IPs. It is a multi-layered infrastructure:

1. C2 layer: 185.182.193.21 and 212.8.248.104 on WorldStream NL — RabbitMQ/Redis on non-standard ports, behind a front domain (snaptobook.com)
2. Hosting layer: Six-server cluster on 185.182.193.0/24 (WorldStream NL) — Apache 2.4.52, Postfix, SSH management on snap5
3. Co-located domain layer: Three aged domains (casahondon.com since 2016, wf-breast-center.com since 2003, zeal-strap.com since 2005) registered at Dynadot, hosting subdomains consistent with VPN portals, admin panels, and API endpoints on the cluster IPs
4. Mail relay layer: 1pda.com on 3W Infra NL (45.138.37.98) and OVH FR (46.105.47.219) — shared outbound mail infrastructure for the co-located domains

What we know versus what we are inferring

We need to be precise about the distinction between facts and interpretation here, because this is where investigations go wrong.

Facts (directly evidenced):

• All three domains resolve (or recently resolved) to IP addresses within the snaptobook.com cluster
• All three are registered at Dynadot with the same ns1/ns2.dyna-ns.net nameservers
• All three share SPF-authorised mail server IPs (45.138.37.98, 46.105.47.219)
• casahondon.com's Wayback history shows content that does not match its B&B identity
• wf-breast-center.com's SPF record authorises 13 IPs across 4 providers in 3 countries
• zeal-strap.com's URLScan subdomains are named like VPN/remote access infrastructure

What we are inferring (not directly evidenced):

• We are inferring that the domains are "compromised" — we have no evidence of unauthorised takeover. The content mismatch on casahondon.com could be explained by legitimate resale. Domains change hands. Aged domains are bought and sold on aftermarket platforms daily.
• We are inferring that the same operator controls all three domains. The shared Dynadot registrar and ns1/ns2.dyna-ns.net nameservers are Dynadot's default — any Dynadot customer gets them. The shared SPF mail servers are more compelling, but a hosting provider could configure the same SPF for multiple customers as a default mail relay.
• We are inferring that the co-located domains are part of the GigaWiper infrastructure rather than unrelated customers who happen to be on the same WorldStream /24. WorldStream is shared hosting — multiple unrelated customers share the same subnet. The snaptobook cluster occupies a contiguous block (.21, .40, .42, .54, .59, .62), but casahondon.com and zeal-strap.com both resolve to .54 — they could be different virtual hosts on the same server, owned by different people.

What would resolve the uncertainty:

• Fetching the current content of casahondon.com to see if it still serves the B&B website or something else
• Checking Dynadot's WHOIS for historical registrant data (if available) to see if the registrant changed
• Querying passive DNS (e.g., SecurityTrails, DNSDB) to see when each domain first started resolving to the cluster IPs — if the resolution predates the snaptobook.com registration (March 2024), it weakens the "same operator" hypothesis
• Contacting the original B&B owner (via the Facebook page) to ask if they still control casahondon.com
• Checking whether 1pda.com (the shared mail relay) is a Dynadot default mail relay or a custom configuration

The shared SPF mail servers are the strongest linking factor. But "strongest" does not mean "definitive." We should flag these as co-located and linked by infrastructure pattern, not as confirmed compromised domains.

8. Phase 6 — The attribution chain: Crucio → CyberAv3ngers → IRGC

This is where the investigation moved from infrastructure to actor.

Microsoft's blog establishes that GigaWiper command 3 (RanMain/BigBangExtortMain) is "heavily based on Crucio's code" and that "the same threat actor developed both malware families." The shared function name BigBangExtortMain appears in both Crucio and GigaWiper. Microsoft also links GigaWiper command 12 (WipeCMain) to FlockWiper, with PDB paths referencing a "GRAT" framework:

A:\GRAT\CWipeNew\Release\CWipeNew.pdb
E:\files\new\GRAT\CWipe\Release\CWipe.pdb

The question: who operated Crucio?

CISA Advisory AA23-335A

A SearXNG query for "Crucio" ransomware CISA advisory Iran destructive returned a direct hit: CISA Advisory AA23-335A, published December 2023. The advisory states:

"The group claimed to use a ransomware named 'Crucio' against servers where the webcams camera software operated"

The advisory attributes the activity to IRGC-affiliated cyber actors exploiting PLCs in water, wastewater, food and beverage, and healthcare sectors.

FortiGuard Labs threat actor profile

FortiGuard maintains a threat actor profile for CyberAv3ngers that is more specific:

"The CyberAv3ngers is an arm of the Iranian government's Islamic Revolutionary Guard Corps (IRGC). The modus operandi for this group is exploiting programmable logic controllers (PLC) commonly used in wastewater and irrigation, especially those made in Israel."

Known tools used: Crucio Ransomware, Custom wipers (unnamed), Brute force tools, Custom ladder logic files (Unitronics PLC), ChatGPT (recon/debugging)

Aliases: Sons of Solomon, Bauxite, CyberAv3ngers_supp

Associated threat actors: Handala Hack Team, Fox Kitten, Oilrig, MuddyWater

MITRE ATT&CK

MITRE tracks CyberAv3ngers as G1027 in the ICS-ATT&CK domain:

"The CyberAv3ngers are a suspected Iranian Government Islamic Revolutionary Guard Corps (IRGC)-affiliated APT group. The CyberAv3ngers have been known to be active since at least 2020, with disputed and false claims of critical infrastructure compromises in Israel."

The chain

GigaWiper (October 2025, first observed in-the-wild)
  │
  ├─ Command 3 = Crucio ransomware code (confirmed by Microsoft)
  │    └─ Crucio → attributed to CyberAv3ngers (G1027)
  │         └─ CyberAv3ngers = IRGC-affiliated Iranian APT group
  │            (CISA AA23-335A, FortiGuard, MITRE ATT&CK, Rewards for Justice)
  │
  ├─ Command 12 = FlockWiper reimplemented in Golang (confirmed by Microsoft)
  │    └─ FlockWiper PDB paths reference "GRAT" framework
  │    └─ FlockWiper first uploaded to VirusTotal: June 2025
  │
  └─ Same hashes tracked by Binary Defense as BLUERABBIT (June 2026)
       └─ Binary Defense: "likely targeting of organisations in Israel"

Virtual Routes / Pharos report names the actor behind Crucio as "Soldiers of Solomon" — which FortiGuard lists as an alias of CyberAv3ngers. The Ignition Technology Global Threat Report 2024 explicitly states "IRGC-AFFILIATED SoldiersOfSolomon's Crucio RANSOMWARE ATTACKS ISRAELI IT INFRASTRUCTURE."

Confidence assessment

Microsoft has not named a threat actor for GigaWiper. The Iran-nexus assessment is ours, built from public sources. TechTimes reported "Iran-nexus implant" without citing a source — we treat this as corroborating but not independent.

9. The full IOC set

Network indicators

File hashes (SHA-256)

Behavioural indicators

MITRE ATT&CK mapping

10. Detection and mitigation

Network-level

Block the C2 infrastructure at perimeter firewall, proxy, and DNS sinkhole:

185.182.193.21
212.8.248.104
snaptobook.com
*.snaptobook.com
casahondon.com
*.casahondon.com
zeal-strap.com
*.zeal-strap.com
wf-breast-center.com
*.wf-breast-center.com
1pda.com
45.138.37.98
46.105.47.219

Block AMQP egress on non-standard ports. GigaWiper uses port 5544 for RabbitMQ and 7542 for Redis — not the standard 5672/6379. Block outbound AMQP and Redis protocol traffic from workstations and servers to external addresses unless explicitly required. If you run RabbitMQ or Redis internally, restrict egress to known internal IPs only.

Alert on AMQP protocol signatures on non-standard ports. A network IDS rule for AMQP 0-9-1 protocol frames on ports other than 5671/5672 would catch this C2 channel regardless of which IP the operator moves to.

Host-level

Hunt for the persistence indicator:

Get-ScheduledTask -TaskName "OneDrive Update" | Select-Object TaskName, State, Author, Actions

Legitimate OneDrive tasks use names like OneDrive* Standalone Update Task*. The exact string OneDrive Update with per-minute triggers is the indicator. Verify the executable path in the task action — a legitimate OneDrive task points to the OneDrive executable; GigaWiper points to its own binary.

Deploy EDR detections for:

• Raw disk access via DeviceIoControl with IOCTL_DISK_CREATE_DISK from non-standard processes
• Processes writing directly to \\.\PHYSICALDRIVE* device paths
• Creation of Windows Firewall rules by non-standard processes (GigaWiper creates its own exceptions for the VNC-like remote control TCP server)
• Execution of mc.exe (MinIO Client) from unexpected locations
• Bulk event log clearing via wevtutil cl or direct deletion of C:\Windows\System32\winevt\Logs\Security.evtx
• Creation of files with .candy extension
• Creation of image_danger.jpg

Sigma coverage

SigmaHQ has 22 rules mapped to T1490 (Inhibit System Recovery) and 50 rules mapped to T1053.005 (Scheduled Task). The highest-value rules for GigaWiper detection:

• Boot Configuration Tampering Via Bcdedit.EXE (high) — GigaWiper's BSOD command disables recovery via bcdedit
• All Backups Deleted Via Wbadmin.EXE (high) — backup destruction
• Scheduled Task Creation Masquerading as System Processes (high) — the "OneDrive Update" task
• Schtasks Creation Or Modification With SYSTEM Privileges (high) — per-minute trigger as SYSTEM
• Suspicious Scheduled Task Creation Involving Temp Folder (high) — if the backdoor binary is in a temp path

Response procedure

If GigaWiper is detected on an endpoint:

1. Isolate immediately. Disconnect from wired, wireless, VPN, and shared-storage access. Do NOT attempt remediation while the host is network-connected — the operator can trigger wiping remotely at any time.
2. Do not reboot. If the destructive command has not yet been executed, the data on disk is still recoverable. Rebooting may trigger the scheduled task.
3. Preserve evidence. Record the scheduled-task action, executable path, hashes, logged-on user, active network connections, and alert timeline before any cleanup.
4. Block C2 at the perimeter. Block both IPs and the snaptobook.com domain at the firewall and DNS layer.
5. Verify offline/immutable backup integrity. GigaWiper's destruction is irreversible. Recovery depends entirely on backup availability. Confirm backups are isolated from the production network.
6. Hunt laterally. Search firewall, proxy, EDR, RabbitMQ, Redis, and MinIO logs for the two C2 IPs and for unusual client activity from workstations.
7. Rebuild. If GigaWiper execution or destructive commands are confirmed, reimage from known-good media and rotate exposed credentials from a separate clean device.

11. What this investigation did not find

• No confirmed attribution from Microsoft. The Iran-nexus assessment is ours, built from the Crucio code overlap chain. Microsoft has not named a threat actor for GigaWiper.
• No live RabbitMQ or Redis services confirmed on the C2 IPs. Shodan only sees port 80 on the primary C2. The C2 ports (5544, 7542) are likely firewalled to specific source IPs or require authentication. We did not attempt to connect to them — that would be active probing, not OSINT.
• No Binary Defense BLUERABBIT report retrieved. The URL we tried returned 404. The report (June 2026) likely contains additional IOCs and the Israel targeting detail. We are attempting to obtain it directly from Binary Defense ARC Labs.
• No VirusTotal data for the hashes. No VT API key was available in our environment. VT lookups would reveal first-submission dates, submission geographies, and AV detection ratios — all useful for the attribution timeline.
• No direct link between snaptobook.com and the threat actor. The domain is privacy-protected via GoDaddy/Domains By Proxy. Subpoena or GoDaddy cooperation would be required to identify the registrant.
• No direct registrant identity for any domain. snaptobook.com is privacy-protected via GoDaddy/Domains By Proxy. casahondon.com, zeal-strap.com, and wf-breast-center.com are at Dynadot (privacy status not checked via their WHOIS API). 1pda.com is at Gname (Singapore). Subpoena or registrar cooperation would be required to identify the registrants.
• No confirmation that the three co-located domains are compromised. We have evidence of co-location on the cluster IPs and shared infrastructure patterns (Dynadot, SPF mail servers). We do not have evidence of unauthorised takeover. The domains could have been legitimately purchased on the aftermarket, or could be unrelated WorldStream customers on shared hosting. The 'compromised' characterisation is an inference, not a fact.

12. The durable outputs

IOC lists go stale. The IPs will be abandoned, the hashes will be rotated, the domain will be let to expire. What endures is the methodology and the attribution chain.

1. The attribution chain: GigaWiper → Crucio code overlap → CyberAv3ngers (G1027) → IRGC. This chain will remain valid even if the actor rebrands or deploys new tooling. Any future malware sharing Crucio's BigBangExtortMain function or FlockWiper's WipeCMain logic connects to the same actor.
2. The infrastructure fingerprint: WorldStream AS49981 + non-standard AMQP/Redis ports + Apache 2.4.52 front + privacy-protected GoDaddy domain + six-server cluster + co-located aged domains at Dynadot + shared mail relay on 3W Infra NL. This is the actor's deployment pattern. If they deploy new C2, it will likely match some subset of these characteristics.
3. The co-located domain pattern: Three aged domains (2003-2016) registered at Dynadot, sharing nameservers (ns1/ns2.dyna-ns.net) and SPF-authorised mail servers (45.138.37.98, 46.105.47.219). These domains are co-located on the same cluster IPs as the GigaWiper C2. Whether they are operated by the same actor, are compromised, or were legitimately purchased is not confirmed — but the infrastructure overlap is a detection signal. Any future domain at Dynadot with these SPF records and resolving to WorldStream AS49981 warrants investigation.
4. The "GRAT" framework reference: The PDB paths in FlockWiper (A:\GRAT\CWipeNew\Release\CWipeNew.pdb, E:\files\new\GRAT\CWipe\Release\CWipe.pdb) and the prevalence of "GRAT" in GigaWiper function names suggest a parent framework that has not been recovered. Any future malware with "GRAT" in PDB paths or function names connects to this actor.
5. The monitoring queries: Shodan searches for AMQP on non-standard ports within WorldStream AS49981. CT log monitoring for *.snaptobook.com, *.casahondon.com, *.zeal-strap.com, and *.wf-breast-center.com. Reverse DNS monitoring on 185.182.193.0/24 and 212.8.248.0/24 for new customer-specific PTR records. HackerTarget hostsearch monitoring on all cluster IPs for new domains appearing on the same hosts.

Investigation conducted using the phishing-tracker MCP pipeline for initial IOC extraction, followed by manual pivoting through Shodan InternetDB, DNS reverse lookups across two /24 subnets, certificate transparency logs via crt.sh, WHOIS (RIPE + GoDaddy), Wayback Machine CDX API, SearXNG metasearch, MITRE ATT&CK (via local DFIR intel database), IntelStore for observable correlation, and MalwareURL for ASN abuse profiling. All 20 observables (2 C2 IPs, 7 cluster IPs, 2 mail relay IPs, 6 domains, 8 SHA-256 hashes) recorded in IntelStore under case gigawiper-c2-infra with full context and relationship edges. The graph includes resolves-to, related-to, uses, and communicates-with edges linking the C2 IPs to the front domain, the co-located domains to the cluster IPs, and the co-located domains to the shared mail relay.

Adverse Trace — sovereign by default.