Why do adversary-in-the-middle phishing kits continue to succeed against cloud identities even when multifactor authentication is enabled?

These kits proxy the login flow in real time, capture credentials, and steal session cookies that can survive the MFA challenge. That means the attacker does not need to defeat the second factor directly. Success also rises when users trust branded login pages, reuse sessions, or accept authentication prompts without checking the origin and context of the sign in.

Why This Matters for Security Teams

Adversary-in-the-middle phishing kits remain effective because MFA is only one checkpoint in the sign-in chain, not a guarantee that the session is trustworthy after authentication. When a kit proxies the login flow, it can steal the authenticated session and reuse it before the user or defender notices. That turns a “successful MFA” event into a compromise, especially in cloud environments where session tokens often outlive the original prompt.

This is the same basic reason cloud identity incidents keep showing up in NHI research: attackers prefer the path of least resistance, and valid sessions are often easier to abuse than passwords. NHI Management Group has repeatedly highlighted how quickly exposed credentials are weaponised in the wild, including the LLMjacking research note and the broader 52 NHI breaches Report, which both reinforce how fast authenticated access is operationalised once it is obtained.

Current guidance from CISA cyber threat advisories and the MITRE ATLAS adversarial AI threat matrix points to the same operational reality: defenders must validate the origin, context, and binding of each sign-in, not just the presence of a second factor. In practice, many security teams discover session theft only after anomalous cloud actions have already started, rather than through a clean authentication alert.

How It Works in Practice

These kits succeed by sitting between the user and the legitimate identity provider. The victim enters credentials into a convincing lookalike page, completes MFA on the real service through the proxy, and receives a valid session cookie or token that the attacker can replay. For cloud identities, that is often enough to access email, admin consoles, SaaS tenants, and downstream APIs without needing to trigger another MFA challenge.

What makes this especially dangerous is that many cloud controls still treat MFA completion as a high-confidence signal. That assumption breaks when the adversary captures the whole authenticated context. A stronger model is to bind authentication to device posture, origin, and continuous risk checks, then re-evaluate access during the session. Techniques such as phishing-resistant authentication, token binding, conditional access, and short-lived sessions reduce the window for replay, but they do not eliminate it on their own.

• Use phishing-resistant factors where possible, especially for privileged cloud users.
• Reduce session lifetime and revoke tokens aggressively after suspicious sign-in behaviour.
• Require context-aware access decisions instead of trusting MFA alone.
• Monitor for impossible travel, new device fingerprints, and unusual token reuse.
• Constrain cloud admin actions with least privilege and just-in-time elevation.

NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now and Top 10 NHI Issues both underscore the same operational lesson: identity security fails when defenders rely on a single event instead of continuous trust evaluation. These controls tend to break down when legacy session lifetimes are long and users can approve prompts from unmanaged devices, because the attacker only needs one usable token to pivot.

Common Variations and Edge Cases

Tighter phishing resistance often increases user friction and rollout overhead, requiring organisations to balance stronger assurance against help desk load, application compatibility, and exception handling. There is no universal standard for this yet, especially across mixed cloud estates, partner access, and older authentication stacks.

Some environments still depend on push-based MFA, and those flows are particularly vulnerable to prompt fatigue, token replay, and real-time relay. Hardware-backed authenticators and passkeys materially improve resistance, but they do not fully solve post-authentication session abuse if token controls are weak. That is why current guidance suggests pairing MFA hardening with session controls, policy-as-code checks, and device-bound access where supported.

For high-risk cloud roles, the better question is not “Was MFA completed?” but “Should this session still be trusted right now?” That distinction matters most in admin workflows, contractor access, and federated SaaS where a stolen browser session can bypass the next several layers of control. NHI Management Group’s broader breach analysis, including the 52 NHI breaches Report, shows that attackers repeatedly convert one successful authentication into a wider compromise by chaining legitimate access paths.

Where organisations use shared devices, remote browser isolation, or aggressive session persistence, the guidance becomes less reliable because the defender loses visibility into whether the token is being replayed from the original context.

Related resources from NHI Mgmt Group

• Why do AiTM phishing kits still succeed against MFA?
• Why do adversary-in-the-middle phishing kits increase identity risk beyond ordinary credential theft?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?