From public IOCs to pre-attack context - BYOIOC and the Hunt.io DinDoor / Tsundere C2 case

Malanta Research Team

THINK

29 Apr 2026

From public IOCs to pre-attack context - BYOIOC and the Hunt.io DinDoor / Tsundere C2 case

Contents

Example H2

This is a div block with a Webflow interaction that will be triggered when the heading is in the view.

Example H3

Bring Your Own IOC (BYOIOC) - you supply indicators you already trust (a vendor report, ISAC feed, or your own detections). Malanta enriches, clusters, and expands them into Indicators of Pre-Attack (IoPAs) and graph context, so CTI and SecOps teams can prioritize blocking, hunts, and abuse reporting without replacing the source analysis.

This run: 37 BYOIOC seeds taken from Hunt.io's "DinDoor's Caddy Problem: How One HTTP Header Exposed 20 Active C2 Servers" (April 21, 2026) expanded to 31 IoPAs, 4 newly-discovered malicious domains, and up to 173 days of lead time on Malanta-graded malicious infrastructure that the Hunt.io HuntSQL pivot had not yet surfaced.

What Hunt.io reported (and the IOCs they published)

On April 21, 2026, Hunt.io's research team published "DinDoor's Caddy Problem: How One HTTP Header Exposed 20 Active C2 Servers", breaking down two MSI samples (migcredit.pdf.msi and Installer_v1.21.66.msi) that abuse the Deno runtime to execute obfuscated JavaScript backdoors and beacon to a tiered Caddy-fronted C2. DinDoor is tracked as a variant of the Tsundere botnet, with code- and tradecraft-level overlap to CastleLoader / TAG-150 and to Seedworm / MuddyWater (per Broadcom).

The Hunt.io IOC set covers the operator-controlled delivery and C2 layer they observed, including:

20 active DinDoor C2 IPs surfaced via a HuntSQL pivot on the Via: 1.1 Caddy, 1.1 Caddy + X-Request-Id response signature on port 80.
~17 phishing / staging domains resolving to that infrastructure (e.g. serialmenot[.]com, justtalken[.]com, annaionovna[.]com, weaplink[.]com, ilspaeysoff[.]site, ineracaspsl[.]site, generalnewlong[.]com, healthydefinitetrunk[.]com).
2 file hashes for the MSI samples + a JWT campaign token decoded from the /mv2/<JWT>/<victim_hash> URL pattern.

Malanta expansion (this run)

From 37 BYOIOC seeds aligned with Hunt.io's DinDoor write-up, the BYOIOC export contains:

31 Expansion IoPAs
8 Cluster-sourced indicators
4 High-risk Malanta clusters
2 APT names attributed
7 Malicious-labelled IoPAs
8 Attack-infra flagged
9 Seeds in URLhaus / code repos
173 days max lead time vs publication
‍

Lead time is the delta between Malanta's first graded conviction on an indicator and the point where it would typically appear only as a headline IOC. In this case, bubuklaysdertolitodas.com, surfaced through a /24 + cluster pivot off the seed 178.16.52[.]191, carries 173 days of lead time against Hunt.io's April 21, 2026 publication. coinbase.com[.]lv (115 days), verification-stokr[.]io (97 days), and geralnewlong[.]com (11 days) round out the new malicious convictions - plus three of Hunt.io's primary seed domains (serialmenot[.]com, justtalken[.]com, annaionovna[.]com) were already in Malanta's graph as malicious 7–40 days ahead of publication.

Proximity in the BYOIOC HTML ranks how tightly each expansion ties back to the nearest seed (the same column shows distance band and hop depth). Closer rows are usually cheaper to operationalize first - shorter chains mean faster decisions on blocks, SIEM correlation, and scope for takedowns.

APT attribution — TEMP.Zagros (Iran) & Shuckworm (Russia)

Malanta's attribution engine cross-checks Malanta APT labels on domain and IP seeds against GPT-5.5 reasoning over the expansion graph. For this seed set it returns a Medium-confidence attribution (62%) to TEMP.Zagros (a.k.a. MuddyWater / Seedworm / StaticKitten) - consistent with Broadcom's prior linking of DinDoor to Iran-aligned activity - alongside a parallel signal for Shuckworm (Gamaredon / Armageddon). The two attributions reflect DinDoor's documented multi-tenant C2 (serialmenot[.]com serving multiple operators) and the cluster-level overlap with both MuddyWater tradecraft and CIS-criminal CastleLoader / ChainShell ecosystems.

Selected indicators (BYOIOC export)

The spaeysoff phishing family - one operator, four lookalike apexes

Hunt.io listed ilspaeysoff.site and myspaeysoff.site among the domains resolving to 193.24.123.25 (PROSPERO OOO, RU) - the IP fronting one of the Installer_v1.21.66.msi C2 paths. From those two seeds Malanta surfaced two additional lookalike apexes:

All four *spaeysoff[.]site apexes - the two seeds plus the two newly-discovered ones - were registered on the same day, 2025-09-30, behind the same nameservers (ns1.eranet-dns.com, ns2.eranet-dns.com) and resolve to the same IP 193.24.123.25.
This is textbook pre-attack staging: the operator built the lookalike fleet in one batch, and only two of the four (ilspaeysoff[.]site and myspaeysoff[.]site) had been observed in the wild by the time Hunt.io published. The other two - aespaeysoff[.]site and inspaeysoff[.]site - share IP, nameservers, ASN, and the same registration day with their already-burned siblings. That is the IoPA value proposition: blockable context derived from shared operator infrastructure, not from waiting for a detonation.

The same registration-batch pattern repeats one row down in the *eracaspsl[.]site family (aeeracaspsl[.]site, ineracaspsl[.]site as seeds; ileracaspsl[.]site, myeracaspsl[.]site as discovered IoPAs - all four registered 2025-09-25, same NS, same IP).

The /24 + code-repo bridges - DinDoor neighbours surfacing in malicious GitHub feeds

Two of Hunt.io's published C2 IPs sit in /24 ranges that already appear inside malicious / threat-intel code repositories. Malanta's repo-pivot stage walks from the seed IP, into the repo where its sibling is indexed, then through the fork network to a malicious cluster - and lands on a graded apex domain.

The full provenance chains, as rendered in the BYOIOC HTML report:

178.16.52[.]191 (seed; matched via 178.16.52[.]64)
→ SecWiki/linux-kernel-exploits (flagged by urlhaus)
→ Gandalf-ocinzento/C2-Tracker (pivot via fork_network)
→ 178.16.52[.]64 (/24 subnet match)
→ Cluster 38F86DE0-6FC
→ bubuklaysdertolitodas[.]com (Malicious p=1.0, lead 173d)

193.24.123[.]25 (seed; matched via 193.24.123[.]84)
→ pr0xylife/DarkGate (flagged by urlhaus)
→ MikhailKasimov/validin-phish-feed (pivot via fork_network)
→ 193.24.123[.]84 (/24 subnet match)
→ Cluster E8120272-B5B
→ verification-stokr.io (Malicious p=0.99, lead 97d)

In plain English: 178.16.52[.]64 and 193.24.123[.]84 are /24 neighbours of two of the seed C2 IPs Hunt.io published, both already indexed inside Malanta's attack-infra cluster graph and inside existing malicious GitHub feeds (DarkGate, kernel-exploit lists, phishing feeds). They are not just hypothetical lookalikes - they are the bridge that lets us pivot from "20 hosts" into the cluster where the operator is also staging brand-impersonation phishing (verification-stokr[.]io for the Stokr brand, bubuklaysdertolitodas[.]com as a parked-then-weaponized apex).

Selected indicators - see the full report and STIX 2.1 bundle for the complete 31-IoPA list and per-indicator provenance chains.

Why this matters

Hunt.io's HuntSQL pivot is exactly the right move at the post-detonation layer: a unique Caddy/X-Request-Id signature gave them 20 active DinDoor C2s in a single query. Malanta layers IoPAs, lead time, and graph-scale pivots on the same seeds - surfacing 2 lookalike phishing apexes that share day-of-registration with their already-burned siblings, and 2 /24 neighbours already indexed inside attack-infra clusters and malicious GitHub feeds that bridge to Malanta-convicted apexes (bubuklaysdertolitodas[.]com at 173 days lead time, verification-stokr[.]io at 97 days).

For CTI analysts and SecOps teams: block the lookalike apexes now, hunt for resolutions of the /24 neighbours in your DNS / proxy logs, and use the cluster IDs to scope the attached brand-impersonation infrastructure long before it's public.