Why do modern credential phishing attacks create risk even in organisations with strong email filtering and MFA?

Why This Matters for Security Teams

Modern credential phishing is dangerous because it no longer depends on tricking a mailbox filter into missing a malicious attachment. Attackers increasingly use adversary-in-the-middle kits to proxy a user’s real login flow, capture the password, intercept the MFA challenge, and steal the session token after authentication succeeds. That means the control gap is not just “did the user click,” but “did the attacker become part of the session.” Strong email filtering still helps reduce volume, but it does not stop a convincing live relay page or a stolen browser session. NHI Management Group’s research on The 52 NHI breaches Report shows how often identity compromise turns into broader operational exposure once tokens and secrets are in play.

Security teams often overestimate MFA as a final barrier, when in practice it is only one control in a wider chain of trust. If the attacker can observe the authenticated browser session, the user’s second factor may be irrelevant. In practice, many security teams encounter session hijack only after an account has already been used for lateral movement or data access, rather than through intentional detection of the phishing event.

How It Works in Practice

Adversary-in-the-middle phishing works by standing between the victim and the legitimate service. The victim still sees the real application experience, but the attacker relays credentials and MFA exchanges in real time, then preserves the resulting session cookie or token for reuse. This is why modern guidance treats session security as part of authentication, not a separate afterthought. The issue is documented in broader identity standards such as NIST SP 800-63 Digital Identity Guidelines, which emphasise stronger authenticator and session protections beyond passwords alone.

Practically, defenders should focus on reducing the value and lifetime of what attackers can steal:

• Use phishing-resistant authentication methods where possible, especially hardware-backed or origin-bound approaches.
• Shorten session lifetimes and require reauthentication for sensitive actions.
• Bind sessions to device, context, or token characteristics so a stolen cookie is less reusable.
• Monitor for impossible travel, unusual token reuse, and abnormal post-authentication behaviour.
• Treat browser session theft as a detection priority, not just a help desk event.

For identity-driven threat patterns, the MITRE ATT&CK Enterprise Matrix and CISA cyber threat advisories help teams map how initial access, credential theft, and follow-on abuse typically unfold. NHIMG’s Top 10 NHI Issues is also useful for understanding how stolen secrets and tokens become durable access paths once an attacker is inside. These controls tend to break down in legacy apps that rely on long-lived bearer sessions and cannot enforce device binding or real-time risk checks.

Common Variations and Edge Cases

Tighter authentication often increases user friction and operational overhead, so organisations must balance stronger session protection against help desk load and login disruption. That tradeoff matters because not every application can move to phishing-resistant methods at the same pace, and there is no universal standard for this yet across every business system.

Some attacks do not need to defeat MFA at all. If the victim is already authenticated in a browser, an attacker may abuse a stolen session cookie, malicious OAuth consent flow, or device enrolment gap instead. In these cases, the weak point is the post-login trust model, not the second factor itself. Current guidance suggests prioritising sensitive applications, administrative accounts, and high-risk workflows for stronger controls first, because that is where token theft causes the most harm.

For organisations with mature email filtering, the more important question is whether users can still be sent to a live relay page through chat, search, QR codes, or compromised infrastructure. Email controls reduce noise, but they do not eliminate the core risk of session hijacking. A useful next step is to review how MFA, session management, and conditional access behave when the attacker is already present in the browser, not just in the inbox.

Related resources from NHI Mgmt Group

• Why do verification phishing attacks create risk even when organisations use phishing-resistant MFA for their main IdP?
• Why do highly personalized phishing emails create more risk for organisations with strong email filters?
• Why do phishing attacks against cloud apps succeed even when email security is in place?
• Why do phishing attacks on GitHub accounts create such a broad risk to engineering teams?