What are the signs that an AITM phishing campaign is targeting identity sessions?

Look for cloned login pages, suspicious redirects from sponsored results, repeated MFA prompts, and authentication flows that end in session theft rather than password-only capture. If the attacker can turn a normal login into a usable browser session, the campaign is designed to bypass single-factor assumptions after the credentials are entered.

How to spot an AITM phishing campaign before the session is stolen

An AITM campaign is usually trying to do more than collect credentials. The giveaway is that the login flow behaves like a relay, not a normal sign-in, so the attacker can capture the authenticated browser session after the victim completes MFA. That means the page design, redirect path, and post-login behaviour matter as much as the password prompt itself.

One of the clearest signs is inconsistency between the page the user thought they were opening and the page that actually handles authentication. If a sponsored result, short-link, or embedded redirect lands on a login page that is visually correct but hosted or routed unexpectedly, treat it as suspicious. Identity Provider and SSO Security Guide is useful here because AITM activity often depends on abusing trust in the IdP entry point rather than breaking the password itself.

A second sign is MFA behaviour that repeats, loops, or appears out of sequence. A normal login should not keep re-prompting the user after successful approval, and it should not produce a second browser context that suddenly inherits the session. When the attacker is relaying the flow in real time, the victim may see a believable MFA challenge while the attacker quietly exchanges the captured result for a usable session cookie or token.

Watch for the difference between credential capture and session capture. Password theft alone often ends with later account access attempts, but aitm phishing is designed to end with an active authenticated session in the browser. That can show up as unexpected persistence after login, strange device or browser fingerprints in the account history, or a user who reports “I already approved the login” but still gets prompted again or redirected.

What AITM changes in the attack path

AITM matters because it breaks the assumption that MFA ends the risk. If the attacker is positioned between the user and the real service, the user authenticates to the attacker’s relay, and the relay forwards enough of the exchange to obtain a live session. Workforce Identity Security Guide covers the practical consequence: phishing-resistant MFA reduces this class of abuse far more effectively than OTP-based approval flows.

The campaign often leaves clues in the browser journey. Examples include login pages that load from an unusual infrastructure path, an MFA prompt that appears after a delay that feels artificial, or a page that redirects multiple times before showing the expected application. In many cases, the phishing kit is not trying to be subtle about the page content, only about the timing and relay mechanics that make the session usable.

AITM also tends to target sessions that can be replayed quickly. If an attacker can turn a successful login into a session token, cookie, or browser-authenticated state, they may not need the password again. MFA Guide is relevant because the critical question becomes whether the chosen factor can be relayed, not simply whether MFA exists.

What defenders should verify when AITM is suspected

Do not stop at the user report of a fake page. Check whether the same sign-in produced abnormal token issuance, unfamiliar session age, impossible travel, or a fresh browser session with no prior history but full application access. If the environment supports conditional access, review whether the sign-in came through a trusted browser path or whether the attacker likely copied the authenticated state into another session.

Also inspect the front door controls around the IdP and SSO path. Hardening the IdP matters because AITM kits usually exploit weak entry-point trust, help-desk recovery paths, or legacy authentication edges. Ultimate Guide to NHIs — Standards is not about phishing itself, but it helps place session and token protections inside the broader control model where identity trust is verified rather than assumed.

Look for the campaign’s operational fingerprint across multiple users, not just one mailbox or one account. Repeated MFA prompts, the same suspicious redirect chain, and similar post-login session artefacts across victims usually indicate a kit or relay infrastructure, not random user error. The more the campaign succeeds, the more likely the attacker is harvesting active sessions for downstream mailbox, SaaS, or admin abuse.

Risk and Threat Considerations

AITM phishing is high-risk because it bypasses the normal “credentials plus MFA” mental model. Once the attacker can relay authentication in real time, the primary exposure shifts from password compromise to session compromise, which is harder to spot and can survive until the session expires or is revoked.

Failure mechanism: The attacker inserts a relay between the victim and the real service, captures the authenticated exchange, and reuses the resulting session artefact before the user realises the login was intercepted.

Impact: The attacker can access mail, SaaS, and admin portals as the victim without needing the password again, and the compromise may persist even after the user changes credentials unless sessions are explicitly revoked.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	AITM phishing targets authenticator strength and session trust after login.
Recommendation — Prefer phishing-resistant authenticators and session binding to reduce relay attacks.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	AITM campaigns exploit weaknesses in user authentication and sign-in verification.
	IA-5 — Authenticator Management	Session theft follows weak authenticator handling and insufficient token protection.
	AC-2 — Account Management	Suspicious sessions require rapid account and session lifecycle response.
Recommendation — Strengthen organizational user authentication against relay and MFA-bypass attacks. Rotate and protect authenticators, tokens, and session material promptly. Revoke compromised sessions and review account activity for abuse.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	AITM undermines assumed trust in the login path and authenticated session.
Recommendation — Verify each access request continuously instead of trusting prior sign-in success.

Practitioner Guidance

What to verify: Confirm whether the suspicious login produced a valid session in the target app, not just a successful password check. If you can see token issuance, session creation, or account activity immediately after MFA, treat the incident as session compromise rather than simple credential phishing.

Decision rule: If the login path involved an unexpected redirect chain, repeated MFA challenges, or a suspicious sponsored result, prioritise session revocation and sign-in trace review before focusing on password reset alone. A password change without session invalidation may leave the attacker active.

Practitioner takeaway: For AITM, the decisive signal is whether authentication ended in a live browser session that the attacker can reuse, because that is what turns a phishing event into an active account compromise.