A common sign is reliance on known-bad site lists that only track domains or other easy-to-change indicators. If malicious tools keep appearing under new domains, or if attackers can run reverse proxy phishing sites without triggering alerts, the control is too shallow. Effective detection should see the application behavior itself, including script activity and storage patterns, before the page is used.
What AitM-aware browser detection is actually trying to catch
Browser-based phishing detection fails when it only asks whether a page looks suspicious from the outside. AitM attacks are designed to look ordinary at the domain layer while stealing the session during the interaction itself. The detection problem is therefore not just “is this site bad?”, but “does this page behave like a credential-intercepting proxy once it loads and the user starts typing?”
That is why the strongest signals are often behavioural: unexpected script execution, token or storage access, form interception, and page logic that proxies the login flow rather than hosting it directly. Browser-level controls have to observe what the page does in the session, not only what the domain is called. For broader identity-oriented guidance on the credentials and tokens that AitM tooling targets, see Ultimate Guide to NHIs, what are Non-Human Identities and the key challenges and risks section.
A useful way to think about the gap is that AitM tooling thrives on speed and reuse. If detection depends on reputation feeds that lag behind attacker infrastructure changes, or on indicators that can be swapped quickly, the control will miss the proxy stage even when the page is actively collecting credentials, MFA responses, or session material. That is the same failure pattern highlighted in Top 10 NHI Issues: weak visibility and shallow detection leave high-value access material exposed.
Signs the control is too shallow
The clearest sign is repeated alerting gaps when the attacker rotates domains, hosts, or URLs faster than the browser control can classify them. If each new lure lands cleanly because the detector only knows previously seen bad sites, the control is only screening reputation, not phishing behaviour. Another sign is that the page can proxy a real login without being blocked, even though the browser is clearly interacting with a deceptive intermediary.
Look for evidence that the detector misses the session mechanics that matter most: form submission redirection, clipboard or storage access, injected scripts, cross-origin oddities, and abnormal use of cookies, local storage, or tokens during the login sequence. When those behaviours are invisible, the product may still catch low-effort phishing pages, but it will not reliably catch live reverse-proxy campaigns. The browser has to inspect the page’s runtime actions, not just the destination.
For the broader control pattern behind this failure, the best comparison is with a system that sees only static indicators while the attack lives in the execution layer. MITRE D3FEND is useful here because it frames detection around countermeasures that map to adversary technique rather than only list-based blocking, and browser inspection guidance from W3C helps anchor what a browser can actually observe at page runtime.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 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 |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | AitM phishing is a phishing delivery pattern with credential-intercept goals. |
| T1185 — Browser Session Hijacking | AitM attacks often hijack the browser session during authentication. | |
| Recommendation — Map observed login interception to T1566 and hunt for proxy-based credential theft. Monitor for session hijack indicators and block suspicious browser-mediated access paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | AitM campaigns target credential, token, and session material. |
| NHI-05 — Identity Lifecycle and Visibility | Missing visibility into active access material weakens AitM detection and response. | |
| Recommendation — Prioritise controls that detect credential and token exposure during interactive login flows. Improve visibility into access material and revoke suspicious sessions quickly. | ||
| NIST CSF 2.0 | DE.AE — Anomalies and Events are Detected | AitM detection depends on recognising abnormal browser and session behaviour. |
| PR.AC — Access Control | AitM exploits weak control over interactive authentication and session access. | |
| DE.CM — Security Continuous Monitoring | Continuous monitoring is needed to catch changing phishing infrastructure and runtime abuse. | |
| Recommendation — Tune detection for anomalous browser activity and authentication session events. Strengthen access controls around interactive authentication and session use. Continuously monitor browser and authentication telemetry for live phishing behaviour. | ||
| CIS Controls v8 | 8 — Audit Log Management | Browser and authentication events must be logged to expose AitM runtime abuse. |
| 6 — Access Control Management | AitM succeeds when attackers obtain usable access; access control limits blast radius. | |
| 16 — Application Software Security | Runtime page behavior and script abuse sit inside application-layer security concerns. | |
| Recommendation — Log browser, authentication, and session events that reveal proxy-style phishing. Restrict session and account access so stolen credentials yield less usable privilege. Validate browser-facing application behavior that could enable login interception. | ||
Practitioner Guidance
What to verify: Test the detector against live AitM-style flows, not just known phishing domains. If a page can relays credentials, session values, or MFA completion through a proxy while still loading normally, the control needs deeper runtime inspection.
Common mistake: Treating URL reputation and blocklists as sufficient browser protection. That approach is useful for commodity phishing, but it is too late and too shallow for reverse-proxy attacks that preserve a believable user experience.
What good looks like: The browser or security layer flags suspicious script behaviour, proxy-like login handling, and abnormal storage or token activity before the user completes the session. That gives defenders a chance to interrupt the attack at the point where stolen access is being assembled, not after it is already usable.
Practitioner takeaway: If your control only knows the site is bad after the domain is identified, it is not really detecting AitM, it is only reacting to reputation.
Related resources from NHI Mgmt Group
- What are the signs that browser-based phishing detection is failing?
- What breaks when security teams rely on indicator-based detection for modern browser attacks?
- How can organisations improve detection and response for browser-based phishing and identity abuse?
- What are the signs that a remote administration platform is failing to contain browser-based attacks?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
