CaptiveCrunch — Midnight Blizzard (Storm-2945) traveler-targeting infrastructure

Created 2026-08-02 from MS blog IoCs + infrawatch DNS pivot (statistic-g.com resolves to ChocoShell C2 107.189.26.194). All campaign domains share NS ns1-4.1domainregistry.com, but that NS is multi-tenant (15,507 domains in zone data incl. unrelated typosquats) — deliberately NOT anchored, to avoid mis-attribution. SMQL tier = verdict-inert tracking. 0 matches at creation (validated via live SMQL API). Delivery vector is captive-portal traffic manipulation, so sightings are expected only if the infrastructure is submitted directly. UPDATE 2026-08-02: added two indicators surfaced from internal CT-DNS pivots — o365bd3417a777636.com (cert 2026-07-09, resolved to blog-listed DNS-resolver IP 38.146.28.132 then AND now; mail./www. subdomains; in no public feed) and IP 104.145.210.184 (AS398256 UltaHost; co-resolved with ms365-live.com since 2026-07-17 and its SOLE A record as of 2026-08-02 — actor moved off the blog-listed IP). CT corroborates blog first-seen dates (certs 06-03/07-09/07-17/07-20/07-23/07-27). No rDNS PTR data for any campaign IP. UPDATE 2026-08-02 (anchor v3): domain terms changed from exact to LEADING-WILDCARD (domain:*X) — SMQL domain: matches the EXACT host only, so mail.o365bd3417a777636.com was rostered solely via its ip: term and any subdomain moved to a new IP would have been missed; *X covers apex+subdomains+sibling registrations in one term. Added the two payload SHA-256s as ioc: terms (CornFlake 918fa52a, ChocoShell be998574; both in malwarebazaar) so a scan that SERVES the fake-update binary is caught — the campaign delivery vector. NOT anchored: actor /24s (the ip: filter cannot do subnet matching, see the CIDR bug) and title:"Acuity Systems" (FruitStone alias, but plausibly a real company = attribution FP risk). ms365-device.com + m365-owa.com stopped resolving 2026-08-02; kept for historical tracking. UPDATE 2026-08-02 (anchor v4): DROPPED the two ioc: payload-hash terms. Measured cost: they took the anchor from 208ms to 8.4s (18s with title) because OR-ing an EXISTS subquery over ioc_matches defeats index use on the 517k-row scans table, forcing a seq scan with a per-row subquery — ioc_matches itself is only 10k rows, so the table is not the problem, the OR shape is. Detection value was ~zero anyway: both hashes are in malwarebazaar, so a scan serving either binary is flagged by the ioc-matcher independently of this hunt; the term only added grouping. Domain wildcards KEPT — backend v1.0.65 made them indexed (45s timeout -> 335ms). UPDATE 2026-08-04 (anchor v5): added ip:192.142.52.31 — FruitStone C2 operator panel (CloudSync Console), AS214036 ZA/AFRINIC, VT-linked CornFlake sample; Hunt.io OSINT pivot, not in MS blog. 15 leaf terms, under 20-node cap.