AiTM reverse proxy — Microsoft endpoints rewritten into the attacker's path

YARA-only, and that is a limitation rather than a choice: SMQL has no filter for page HTML, response headers, cookies, form actions, script src URLs or redirect chains (verified against backend/smql/registry.py), so there is no way to express this as an SMQL anchor today. The registry gap is the same one docs/DEVICE_CODE_PHISHING_HUNTING_2026-06.md P2 proposed closing with a final_host filter and never did. Kept in its own hunt_family rather than under rcfh-aitm-storm2755 because the rule is not toolkit-specific and a sighting says 'something is proxying Entra ID', not 'Storm-2755'. FP posture, measured 2026-08-10 over 28,443,585 recorded subresource requests: the Microsoft-specific rewrite is 0 hits in every spelling tested (plain, percent-encoded, collapsed-slash), and 'SAS/BeginAuth' anywhere at all is 0. The generic technique is NOT clean — 38,657 requests contain '/https://' somewhere, overwhelmingly image optimisers and reader proxies — which is precisely why the rule names login.microsoftonline.com instead of matching path-embedded URLs in general, and additionally excludes web.archive.org, r.jina.ai, translate.goog, corsproxy.io, allorigins, 12ft.io, /cdn-cgi/image/, /_next/image and wsrv.nl. Caveat on reach: the toolkit fingerprints for webdriver, WebGL and hardwareConcurrency before it will serve the relayed page, so a datacenter-egress capture may only ever reach the fingerprinting stage and never the rewritten HTML. The fingerprint-path rule in the sibling family is what covers that case; consider a nodriver/residential re-capture on any host that hits it.