Security teams should shift detection toward stable attacker mechanics rather than brittle infrastructure indicators. Focus on protocol abuse, user interaction patterns, clipboard manipulation, OAuth consent flows, and credential harvesting steps that remain consistent even when domains, page code, and hosting rotate daily. This reduces reliance on short lived indicators and improves resilience against AI assisted phishing campaigns.
Why Detection Has to Move Beyond Domain Reputation
When phishing infrastructure rotates quickly, domain reputation becomes a lagging signal rather than a dependable control. Security teams that over-weight newly registered domains, hosting history, or static blocklists often discover that the attacker has already moved on by the time the indicator is classified. The more durable detection problem is not the hostname itself, but the behaviours that make the phishing flow succeed, such as credential capture, token abuse, and the sequence of user interactions that turn a lure into access. The NIST Cybersecurity Framework 2.0 remains useful here because it pushes teams to think in terms of outcomes, visibility, and response quality rather than a single signal type. In practice, many security teams encounter this only after the infrastructure has already been rotated and the original indicators have gone stale.
How to Detect the Attack Chain, Not Just the Website
detection engineering works better when it models the attacker workflow end to end. A phishing campaign may start with a message, but the useful detection opportunities often appear later: a redirect chain that hides the final landing page, an unexpected authentication prompt, a fake SSO sequence, a consent grant, a clipboard change, or a burst of impossible user behaviour immediately after the lure is opened. These are more stable than individual domains because the attacker can swap hosting, templates, and certificates without changing the core abuse pattern.
- Instrument mail, web, identity, and endpoint telemetry so the same campaign can be seen across multiple control points.
- Write detections around sequence and timing, not just single events, because phishing success usually depends on a short chain of related actions.
- Use heuristics for lookalike login flows, suspicious redirects, and consent abuse when the final URL cannot be trusted for long.
- Correlate user interaction with downstream identity events such as new sessions, token issuance, MFA fatigue patterns, or unusual application approvals.
This approach also supports better triage: a short-lived domain may be dismissed as disposable, but a repeatable capture sequence is evidence of an active lure pattern that can be hunted across many campaigns. Where teams rely only on infrastructure reputation, the guidance breaks down once the attacker controls the cadence of rotation faster than the defender can classify each indicator.
Where Reputation Still Helps, and Where It Misleads
Tighter phishing blocking often increases false positives and operational overhead, so organisations have to balance speed of containment against the cost of over-blocking legitimate but new infrastructure. Reputation still has value as a coarse filter, especially for repeat offenders, but it should be treated as one input rather than the detection strategy itself. That distinction matters because many phishing kits now blend clean infrastructure with fast-moving registration, compromised hosts, or cloud services that are unlikely to remain blacklisted for long.
One common industry judgment is that domain reputation is best used for enrichment and prioritisation, while detections should key off attacker behaviour and post-click compromise signals. That is especially true when the phishing flow is designed to evade a single point of failure: even if the domain changes, the same login decoy, consent prompt, or token theft sequence often remains. Teams should also be cautious about assuming that AI-assisted phishing only changes volume; it often changes iteration speed and variation, which makes brittle infrastructure-based rules age out faster than expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-7 — Continuous Monitoring | Phishing detection needs continuous monitoring across changing indicators. |
| DE.AE-2 — Anomalous Events | Behavioural phishing signals are anomalous events, not static reputation hits. | |
| RS.AN-1 — Analysis | Teams must analyze attack chains when infrastructure indicators decay quickly. | |
| Recommendation — Monitor phishing-related telemetry continuously across mail, web, identity, and endpoint sources. Detect suspicious user and authentication anomalies that indicate phishing activity. Analyze event sequences to distinguish disposable infrastructure from active compromise. | ||
| CIS Controls v8 | 8.2 — Audit Log Management | Cross-telemetry correlation depends on collected and retained logs. |
| 13.1 — Network Monitoring and Defense | Network and web monitoring help spot redirect chains and phishing infrastructure. | |
| Recommendation — Centralize and retain logs needed to correlate click, auth, and token events. Monitor web and network traffic for redirect patterns and suspicious destination changes. | ||
| MITRE ATT&CK | T1566 — Phishing | The topic is the changing delivery infrastructure used for phishing campaigns. |
| T1078 — Valid Accounts | Credential harvesting and token abuse often lead to account misuse. | |
| Recommendation — Map observed phishing behaviours to T1566 and hunt for repeatable lure patterns. Hunt for account misuse after phishing because stolen credentials often become valid-account access. | ||
Practitioner Guidance
What to prioritise: Build detections around the earliest stable compromise steps you can observe, especially message-to-click-to-authentication sequences and any identity event that follows them. If the only alert trigger is a bad domain, the team is reacting to a symptom rather than the abuse path.
What to verify: Confirm that alerts can survive infrastructure churn by testing them against multiple lookalike campaigns, not one sample domain. If a rule only works while the exact URL is known, it is too brittle to trust as a primary detection.
What practitioners underestimate: The hardest part is often not identifying the lure, but preserving enough cross-telemetry context to prove that a click, redirect, consent, or token issuance belongs to the same attack chain. Without that linkage, investigation becomes fragmented and containment slows down.
Practitioner takeaway: The best phishing detections are resilient to attacker replacement of infrastructure, because they model the behaviour that produces compromise rather than the disposable assets used to deliver it.
Related resources from NHI Mgmt Group
- How should security teams govern AI and cloud infrastructure when misconfigurations emerge faster than manual reviews can keep up?
- How should security teams use AI to prioritize cloud exposure when threat data changes faster than manual review can keep up?
- How should security teams handle AI-powered phishing that changes faster than human review?
- How should security teams handle exposures that change faster than manual testing can keep up?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org