How should security teams detect phishing when domains rotate quickly?

Why This Matters for Security Teams

Phishing detection becomes unreliable when defenders treat domains as the primary signal. Attackers can rotate infrastructure faster than blocklists, disposable domains can appear and disappear within minutes, and the same campaign can present a different hostname to every victim. The stronger signal is the behaviour around the page: credential collection flow, redirect sequencing, token capture, browser-side scripting, and the way the lure adapts after a user interaction. That is why current guidance increasingly favours content and behaviour analysis over static domain reputation, as reflected in the OWASP Non-Human Identity Top 10 and NHIMG research on Top 10 NHI Issues.

For security teams, the practical risk is not only user compromise but also downstream misuse of stolen sessions, API tokens, and SaaS access that bypasses password resets entirely. Once those artefacts are harvested, rotating the phishing domain does nothing to stop replay. In practice, many security teams encounter the true scope of a campaign only after a valid session has already been abused, rather than through intentional domain blocking.

How It Works in Practice

Durable phishing detection starts with telemetry that can see beyond the domain. Browser visibility, secure web gateway inspection, endpoint event data, and identity logs should be correlated to detect the same campaign even when the hostnames differ. Teams should look for repeated page structures, suspicious form fields, abnormal JavaScript behaviour, lookalike login journeys, and redirect chains that terminate in credential submission or token theft. The NIST Cybersecurity Framework 2.0 is useful here because it encourages a detection strategy built around assets, events, and response rather than single indicators.

NHIMG’s Guide to the Secret Sprawl Challenge is a reminder that phishing often succeeds because credentials and tokens are overexposed after collection, not because the domain remained active for long. Teams should therefore tune detections for:

• Newly observed pages that mimic corporate or SaaS login flows
• Rapid redirect chains across unrelated infrastructure
• Form posts that send credentials to non-standard endpoints
• Post-login prompts that request MFA codes, tokens, or session validation
• Browser events showing clipboard access, hidden iframes, or script-driven navigation

The best practice is to score these signals together and trigger containment when multiple weak indicators align. This also supports faster hunting across campaigns that reuse the same lure logic while changing infrastructure. The Guide to NHI Rotation Challenges is relevant because attackers use the same rotation logic for domains that defenders must learn to treat as ephemeral. In practice, these controls tend to break down in highly distributed remote-browser environments where the security stack cannot inspect page behaviour consistently because the browser itself is outside the main telemetry path.

Common Variations and Edge Cases

Tighter browser inspection often increases latency and operational overhead, requiring organisations to balance detection depth against user experience and privacy constraints. That tradeoff is especially visible in environments with sanctioned third-party applications, heavy use of federated identity, or short-lived campaign infrastructure that disappears before enrichment completes. Current guidance suggests that there is no universal standard for domain reputation thresholds in these cases, so teams should rely on behaviour-based scoring and allowlist governance rather than static block decisions alone.

Edge cases matter. Some phishing pages are single-use and never host again, while others are multi-stage kits that shift domains after each interaction. The former are easiest to miss with feed-based blocking; the latter are best caught through consistent browser-side signals and identity correlation. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful for teams extending this thinking to session artefacts, because the valuable target is often the secret or token, not the site itself. A practical detection program should therefore measure behaviour persistence across domains, not domain persistence across time.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?