What breaks when organisations only rely on static phishing detection?

Why This Matters for Security Teams

Static phishing detection assumes the page itself is the signal. That works only when the attacker reuses a known lure, template, or brand kit. Live proxy attacks break that assumption by relaying the real site in real time, so the victim sees correct logos, flows, and content while the attacker sits in the middle capturing session state. This is why content-based inspection alone misses the failure mode that matters most: a legitimate-looking login path with malicious session handling behind it. Guidance from the NIST Cybersecurity Framework 2.0 and NHIMG research such as the Ultimate Guide to NHIs — Key Challenges and Risks both point to the same operational lesson: identity and session protection matter as much as URL filtering. In practice, many security teams encounter proxy-based compromise only after token replay, mailbox access, or downstream fraud has already started, rather than through intentional detection of the phish page itself.

How It Works in Practice

The defensive shift is from static page matching to behavioural and session-aware controls. A proxy phish can clone the visible website perfectly, so detection needs to look at how the session is established, what device or token properties change mid-flight, and whether authentication is being relayed through an intermediary. That means combining email and web controls with identity telemetry, conditional access, and token validation rather than relying on page similarity scores alone.

• Inspect authentication context, not just content: device posture, IP reputation, impossible travel, and fresh token issuance all matter.
• Use phishing-resistant authentication where possible, because strong user verification reduces the value of a relayed page.
• Monitor for session anomalies after login, including token reuse, unexpected MFA bypass patterns, and unusual OAuth consent activity.
• Correlate URL, DNS, and identity logs so a benign-looking page can still be flagged when the session path is inconsistent.

NHIMG guidance on NHI Lifecycle Management Guide is relevant here because the same principle applies to credentials and tokens used by service accounts and automated workflows: issue, use, rotate, and revoke based on state, not just on static policy. That aligns with broader identity governance expectations in the NIST Cybersecurity Framework 2.0, which emphasises detection and response across the full identity lifecycle. These controls tend to break down in environments with legacy SSO, long-lived refresh tokens, and weak session telemetry because the attacker can preserve a valid-looking authentication flow even when the page content is completely benign.

Common Variations and Edge Cases

Tighter session validation often increases operational friction, requiring organisations to balance user convenience against stronger signal quality. That tradeoff is especially visible in high-volume environments such as customer support portals, SaaS admin consoles, and hybrid workforces where legitimate IP shifts and device changes are common. Current guidance suggests that there is no universal standard for this yet, but the best practice is to treat static phishing detection as a first layer, not a decision point. Some edge cases are particularly hard:

• Real-time reverse proxies that terminate and reissue authentication cookies can evade simple blocklists completely.
• Brand-new domains used only briefly may never accumulate enough reputation data to trigger traditional filtering.
• Legitimate third-party login pages can look identical to phishing pages, so content similarity alone creates both false negatives and false positives.

NHIMG’s Top 10 NHI Issues is also useful context because compromised identities often become the downstream impact of a missed proxy attack. The practical takeaway is to verify what the session is doing after the page loads, not merely whether the page resembles a known phish. In hybrid identity stacks, those controls are strongest when paired with continuous risk evaluation, but they can still struggle when telemetry is fragmented across browsers, IdPs, and downstream applications.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on static vendor lists for fraud prevention?
• What breaks when organisations rely only on native Microsoft protections?
• What breaks when organisations rely only on posture checks for NHI security?
• How can organisations use one confirmed phishing attack to improve broader detection?