AiTM Phishing: Detection and Containment Checklist

Adversary-in-the-middle (AiTM) phishing occurs when a successful multi-factor authentication (MFA) login marks the start of the breach, not its end. The victim signs in through what appears to be a normal portal, completes MFA, and lands where they expected. Behind the scenes, the attacker relays the real authentication in real time, then steals the session token or cookie that proves the user is authenticated.

That stolen session is the problem. It can be replayed from the attacker’s device, reused to maintain existing sessions or obtain new access tokens via refresh token flows, and leveraged to access email, file storage, billing tools, and support systems without triggering the classic red flags teams associate with phishing detection. This checklist focuses on AiTM-specific signals and first-hour containment actions that prevent account takeover from escalating into customer-facing fraud.

Summary

AiTM phishing is session theft after legitimate MFA. Detection hinges on post-MFA anomalies across identity timelines, session and token behavior, browser fingerprints, and network context. Containment in the first hour is about killing active sessions, removing re-entry paths, and hunting for persistence before the account is weaponized.

What Is AiTM Phishing, and What Actually Gets Stolen?

AiTM phishing is a relay attack that steals the authenticated session, not just the password. The attacker uses a reverse proxy or relay service to sit between the victim and the legitimate login page, forwarding traffic in real time so the victim is effectively logging in “for real,” just through an attacker-controlled middle layer.

What typically gets stolen is one or more of the following:

Session cookies that represent an authenticated browser session.
Access tokens used to call APIs or access applications.
Refresh tokens that let the attacker silently mint new access tokens after the initial session expires.
Session attributes that help the attacker maintain continuity, such as cookie values, session IDs, or client identifiers. These vary by app and IdP.

If the environment does not tightly bind tokens to device posture, network context, or phishing-resistant MFA, the attacker can replay what they captured and move quickly.

Why Does AiTM Break Standard Phishing Detection?

AiTM breaks standard phishing detection because it avoids the obvious failure signals most security programs are tuned for. There may be no password guessing, no repeated MFA denials, and no brute-force noise. The login often completes successfully, and the victim may even land on the legitimate app after authentication.

That creates two common blind spots:

Success bias: Teams treat “successful MFA” as proof of safety rather than as the start of an investigation.
Control mismatch: Policies designed to prevent credential theft do not always stop session replay, token theft, or conditional access bypass.

AiTM is a workflow problem as much as a technical problem. It forces defenders to correlate identity, endpoint, and network signals rather than trusting a single log source.

What Should You Verify First When AiTM Is Suspected?

Start by proving or disproving token replay and session theft. That is faster than arguing whether the email lure looked suspicious.

Fast Triage Checks (10 to 15 Minutes)

Timeline integrity: MFA approval time and session creation time should make sense for the same user, device, and network. If MFA occurs in one context and the session appears in another context immediately afterward, assume theft until proven otherwise.
Session concurrency: Two sessions for the same user, close in time, with different fingerprints, is a major red flag. Especially when one session immediately touches high-value apps.
Token churn: New token issuance or refresh activity followed by abnormal access patterns. This often shows up as “new session, new app, new location, no warm-up activity,” or repeated token refreshes from a client context the user has never used.
Policy anomalies: Conditional access or step-up that normally triggers does not trigger. Or the sign-in is marked as compliant, even though it contradicts the device posture you expect.

If you cannot answer these quickly, your telemetry and dashboards are not built for AiTM response.

How Do Reverse Proxies Show Up in Real Attacks?

Reverse-proxy AiTM kits have to operate at scale, and scale leaves artifacts. You are not looking for perfect proof in the first pass. You are looking for infrastructure patterns that repeat across lures and victims.

Infrastructure and Delivery Clues

Lookalike domain strategy: Domains that mimic common SSO portals, HR systems, file sharing, or vendor payment workflows. Many are short-lived and rotate often, but the naming patterns tend to repeat.
Redirect choreography: Multi-step redirects that are too consistent across different lures, or redirects that pass through multiple unrelated domains before landing on the login flow.
Path and parameter mimicry: URLs that copy the structure of legitimate SSO routes, including familiar path fragments and query parameters intended to lower suspicion.

Flow Clues Inside the Browser

Unexpected interstitials: “Verify your browser,” “Hold on,” or extra loading steps inserted before the real IdP appears. These can be used to stabilize the relay or hide a transition.
Odd persistence: Repeated prompts, repeated login loops, or a second MFA prompt that does not match the organization’s normal cadence.

None of this alone proves AiTM. Together, it gives you a hypothesis to validate against identity and session behavior.

What Identity and Session Telemetry Matters Most for AiTM Detection?

The most reliable AiTM detection is sequence-based. The question is not “was MFA used.” The question is “what happened after MFA.”

Identity Signals That Carry Weight

Post-MFA session creation from a new context: A legitimate MFA approval event followed by a session created from a different network, device, or geo.
New device, valid MFA, and rapid privilege use: The session immediately accesses mail, file storage, finance apps, admin consoles, or customer data without normal navigation.
Impossible travel and rapid context changes: Shifts in geo, ASN, IP type, or device fingerprint in a timeframe a real user cannot reproduce.
Inconsistent authentication method history: The user normally authenticates using managed device signals, but the AiTM session shows no such indicators.

Session and Token Behaviors That Scream Replay

Session reuse across contexts: A valid session continues even as the client context changes in ways a real user would not. Examples include a sudden IP or ASN change immediately after MFA, a new device fingerprint paired with an existing authenticated session, or parallel sessions in which one immediately pivots to high-value apps.
Refresh token reuse patterns: Refresh tokens used from unfamiliar client types or network contexts, often with a steady, automated rhythm.
App access clustering: Immediate access to a small set of high-value apps across multiple compromised users, suggesting a campaign playbook.

If your identity provider supports risk scoring, treat risk scores as hints, not verdicts. Many AiTM sessions look “low risk” by default because the credentials and MFA were valid.

What Browser and Endpoint Signals Point to Token Theft?

Browser and endpoint signals matter because AiTM often turns a legitimate MFA event into an abnormal client session. The key is mismatch: a session that is authenticated correctly but behaves like it is being operated from a different device, a different browser profile, or a different “intent” than the user’s normal work pattern.

Focus first on client consistency. Compare the session’s device posture and browser fingerprint to the user’s baseline, then flag gaps that should not exist for that user, like missing managed-device markers, missing endpoint identifiers, or a sudden switch to a fresh browser profile with no prior history. Next, look for interaction patterns that feel operator-driven rather than user-driven: unusually fast navigation, minimal dwell time, and a tendency to move directly into sensitive areas without the normal warm-up activity that usually precedes high-impact actions. Finally, treat any abrupt changes to client context during the same session, like rapid user-agent shifts or quick pivots between environments, as a strong indicator that the session is being replayed or handed off.

Browser Fingerprint and Client Clues

User-agent mismatch: A user-agent that does not match the user’s known device history, or an unusual combination of OS, browser version, and client type that conflicts with the organization’s standard fleet.
Fresh profile behavior: No prior cookies, no normal extension footprint, no history of the device interacting with your apps.
Unnatural navigation: Straight-line pathing to inbox rules, OAuth consent screens, billing settings, or export functions with minimal “human” interaction.

Endpoint and Access Pattern Clues

No endpoint posture signals where you expect them to be: Managed devices typically present stable posture artifacts. If those are missing, question whether you are seeing a replayed session from an unmanaged client.
Sudden access to remote admin tools or credential stores: Attackers often go hunting for secrets immediately after landing.

Browser and endpoint clues become more valuable when you correlate them with identity timelines. Alone, they can look like edge cases.

What Network Clues Help Confirm AiTM Activity?

Network telemetry can confirm what identity logs only suggest. Focus on context, not just IP reputation.

Network Signals Worth Pulling

New autonomous system number (ASN), new device, new session: A three-way change offers higher confidence than any single change.
Residential versus corporate shifts: A sudden shift from corporate egress to consumer networks, or to hosting-provider infrastructure, especially right after MFA.
Traffic timing around sign-in: The relay phase often produces unusual timing patterns, such as repeated short bursts around authentication and token issuance.
Campaign-level clustering: Multiple users interacting with the same small set of domains or IP ranges within a short window.

If you see the same infrastructure touched by multiple identities, treat it like a campaign, not a one-off compromise.

What Should Teams Do in the First Hour?

The first hour is about denying the attacker the session they already stole, and denying re-entry through refresh tokens, mailbox persistence, or delegated access.

First-Hour Containment Checklist

Revoke active sessions across devices. Do not just sign the user out of one app. Terminate sessions broadly so replay stops immediately.
Revoke refresh tokens. This is the difference between “contained” and “attacker comes back tonight.”
Disable or revoke OAuth app sessions and newly granted consents tied to the user, especially if you see unfamiliar apps with mail, file, or directory permissions.
Reset credentials after revocation. If you reset first, you can tip off the attacker while they still have a live session.
Force MFA re-registration if warranted. Use this when you suspect factor enrollment tampering, push fatigue confusion, or account settings changes.
Block known AiTM infrastructure. Add blocks in DNS, secure web gateway, email security, and any browser isolation controls you have.
Scope access quickly. Identify which apps were accessed, which data were touched, and whether any privileges were changed.
Preserve evidence. Capture sign-in logs, session events, and relevant email artifacts before automated retention or remediation wipes them.

To pressure-test whether teams catch post-MFA session theft cues, run a realistic scenario and compare response timing against this checklist using a controlled phishing simulation or tabletop exercise. If the user is in a high-impact role, such as finance, support, comms, or IT admin, treat it as a priority incident even if you do not yet see data theft. Those roles are often used as fraud launchpads.

How Do You Hunt for Persistence After AiTM?

AiTM often starts as session theft, then escalates to persistence via email, OAuth grants, and rule changes that survive password resets.

Persistence Hunting Checklist

Mailbox rules and forwarding: New rules that auto-forward, hide messages, move replies, or route invoices and password resets away from the user.
Delegated access: Added delegates, shared mailbox access changes, or permission shifts that create silent persistence.
OAuth app consent: New or recently authorized apps with mail read, file access, or directory permissions. These can persist beyond password resets.
Recovery channel changes: Updated recovery email, phone number, or MFA device changes. These are classic lockout moves.
Suspicious login approvals: Patterns of MFA approvals outside normal hours, especially clustered around new token issuance.

This is also where coordination matters. The identity team may “fix the login,” while fraud and comms teams later discover the account was used to send trusted messages to customers.

How Do You Stop Compromised Accounts From Being Used for Customer Comms and Invoice Fraud?

Containment is not complete until you block the account’s ability to become a credible sender.

Anti-Fraud Controls That Matter After AiTM

Out-of-band verification for payment changes: require verification steps that do not rely solely on email for bank details updates, invoice reroutes, or vendor onboarding.
Elevated scrutiny for outbound support responses: Attackers love to reply in existing threads because they inherit trust and context.
Temporary guardrails for high-risk users: Limit external forwarding, restrict external auto-replies, and enforce stricter conditional access for roles that touch customer communications.
Customer-facing monitoring: Watch for lookalike domains and impersonation attempts that appear shortly after internal compromise, since attackers often pair stolen accounts with external brand assets.

This step is where brand protection teams and security teams should be tightly aligned. AiTM is a technical compromise that often ends as a trust compromise.

Key Takeaways

AiTM detection lives after MFA. Watch post-MFA session creation, token replay, and concurrency.
Sequence-based correlation across identity, browser, endpoint, and network signals is the fastest path to confidence.
First-hour containment requires revoking the session and the refresh token, then resetting the credentials and rotating the factors when warranted.
Persistence hunting must include mailbox rules, forwarding, delegated access, OAuth grants, and changes to the recovery channel.
Treat AiTM as a fraud-enablement risk. Compromised accounts often become tools for customer comms and invoice fraud.

What Should You Do Next?

Turn this checklist into muscle memory. Run it against two recent “successful sign-ins that felt off,” and document where your telemetry is missing or slow. Fix those gaps before the next campaign forces a rushed response.

Teams that want to validate detection and containment against realistic attacker playbooks often run controlled exercises using Simulation to identify where handoffs and telemetry break down.