AiTM: The Complete Guide

📋In This Guide

What is AiTM?
How an AiTM Attack Works – Step by Step
What the Attacker Walks Away With
Why Your Current Defenses Have a Gap
The Passwordless Problem: AiTM Evolved
What SpyCloud Detects and How
Automated Response: Closing the Loop by IdP
Incident Response: What to Do When SpyCloud Alerts
Quick Reference Glossary

Section 1: What is AiTM?

Adversary-in-the-Middle (AiTM) is a phishing attack technique where the attacker operates as an invisible relay between the target user and a legitimate website.

Unlike traditional phishing that simply captures credentials entered on a fake page, AiTM proxies the real authentication flow in real time – including all multi-factor authentication challenges.

The result: the attacker captures not just credentials, but an authenticated session cookie and, in most enterprise environments, a long-lived refresh token. These are the artifacts that give an attacker persistent, authenticated access to the target's accounts – without ever needing the password again.

🍪 Session Cookie

A short-lived credential issued by a web application after successful authentication. Presented with each subsequent request to prove the user is authenticated. Valid for hours to days depending on the application.

Stolen session cookies allow an attacker to operate as an authenticated user without re-authenticating.

🔑 Refresh Token

A long-lived credential whose lifetime varies by IdP and configuration – typically measured in days to months. If an attacker is actively using a stolen refresh token to silently refresh sessions, the inactivity clock never runs.

A stolen refresh token is operationally more valuable to an attacker than a stolen password in any MFA-protected environment: it has already cleared the MFA gauntlet, survives password resets and MFA re-enrollment, and silently mints new sessions for as long as it remains valid.

Section 2: How an AiTM Attack Works – Step by Step

The following sequence describes a typical AiTM attack against an enterprise target using a modern reverse-proxy phishing kit.

Step 1 – The Phish Lands

The target receives a convincing phishing email. With AI-assisted lure generation, success rates have climbed from 12% to 50%. The email may appear to come from a known contact, a service the user relies on, or a security notification requiring urgent action.

Step 2 – The User Clicks

The target clicks the link and arrives at a site that looks identical to the legitimate login page. This is not a static fake. It is a live reverse proxy relaying every request to the real site in real time.

Step 3 – The MFA Challenge is Proxied

The real authentication flow begins. The legitimate site sends an MFA challenge – push notification, TOTP code, or other factor. The proxy relays this to the user. The user completes the challenge. The proxy relays the response back. MFA succeeds.

Step 4 – The Session is Captured

The real site issues an authenticated session cookie and refresh token to the proxy. The proxy delivers a copy to the attacker's collection server before forwarding the session to the user. The user is now logged in normally. Nothing felt wrong.

Step 5 – The Attacker Operates with a Stolen Session

Using the captured session cookie, the attacker opens the same application in their own browser. They are already authenticated. No login. No MFA. No behavioral signal.

In practice, this step is often automated: the phishing kit itself assumes the session immediately and keeps it alive through automated activity until the threat actor can be physically present to use the account. Using the refresh token, they can maintain this access and silently mint new session cookies for as long as the token remains valid and in use.

⚡Attack Timeline

The entire attack takes seconds from the user's perspective. The attacker's window of access begins the moment the MFA challenge completes – before the user has finished reading the page they were sent to.

Section 3: What the Attacker Walks Away With

🍪 Session Cookie

Valid for: Hours to days

Allows the attacker to operate as an authenticated user in any application that trusts the cookie. Survives password resets. Does not survive IdP session termination.

Reset by: IdP session termination. Does not require knowing which specific cookie was stolen – user-level revocation kills all active sessions.

🔑 Refresh Token

Valid for: Varies by IdP and configuration – typically days to months; longer if actively used

Silently mints new session cookies without MFA. Survives password resets, MFA re-enrollment, and standard session kill actions. The attacker stays in even as you lock the door.

Reset by: Administrative API revocation through the IdP (Okta revokeSignInSessions, Entra ID revokeSignInSessions). SpyCloud automates this.

Section 4: Why Your Current Defenses Have a Gap

AiTM does not exploit a vulnerability in any security product. It succeeds above the control layer, not through it.

Understanding why helps explain why detection must come from a different source entirely.

Defense Layer	What It Does	Why AiTM Bypasses It
MFA (TOTP / Push)	Requires a second factor beyond the password	AiTM proxies the MFA challenge and response in real time. The user completes MFA. The attacker captures the post-MFA session.
Email Security / Filtering	Blocks known malicious links, domains, and senders	AiTM kits rotate domains constantly and often use legitimate infrastructure (Cloudflare Workers, Azure) to host the proxy. Most filtering tools cannot keep up.
EDR / Endpoint Protection	Detects and blocks malicious processes on the device	The attack happens in the browser, in the authentication flow. No malicious process runs on the endpoint. 66% of malware we recapture came from devices with active endpoint protection.
SIEM / Behavioral Analytics	Detects anomalous user behavior post-authentication	Authentication looked clean – the IdP logged a successful MFA event. Behavioral anomalies may not surface until the attacker takes an unusual action, which may be hours or days later.
Identity Provider (IdP)	Manages authentication, issues sessions and tokens	The IdP received a legitimate MFA response and issued a valid session. It has no visibility into where that session token went after issuance.

🎯The Detection Gap

The detection signal cannot come from your existing tools, because all of them see a clean authentication. It must come from criminal infrastructure itself – where the stolen session token or refresh token lands after the attack. That is what SpyCloud recaptures.

Section 5: The Passwordless Problem – AiTM Evolved

Passwordless authentication – passkeys, FIDO2, magic links, certificate-based authentication – eliminates a meaningful category of credential risk. AiTM was built to operate without requiring a password. Moving to passwordless does not remove the AiTM attack surface. It changes it.

Classic AiTM (Password + MFA)

Mechanism: Proxies the full authentication flow including the password entry and MFA step. Captures session + refresh token.

Key insight: Password no longer required. Session and refresh token still issued. Still captured.

Device Code Phishing

Mechanism: Attacker initiates a legitimate device code flow, generating a device code and user code from the IdP. The attacker sends the victim a lure directing them to the real login page to enter the user code. The victim authenticates normally – including MFA. Because the attacker initiated the device code flow, they are the party polling the token endpoint – they receive the resulting access and refresh tokens directly. The victim may see a successful authentication; the attacker has the tokens.

Key insight: No fake page. No proxy. The user authenticates entirely on legitimate Microsoft infrastructure – which is why this variant is invisible to URL filtering, email security, and any control that looks for malicious infrastructure. Note: while other providers support RFC 8628-compliant device code flows, only Microsoft's Device Code Grant is currently being abused at scale by PhaaS kits in this way.

Infostealer on Passwordless Environment

Mechanism: Malware on the device exfiltrates valid, in-use session cookies directly from the browser session store, alongside saved autofill data and target URLs.

Key insight: Passwordless stops credential theft. Infostealer bypasses authentication entirely by stealing the active session.

Section 6: What SpyCloud Detects and How

SpyCloud recaptures identity data from closed criminal communities, active phishing campaigns, active malware infrastructure, and infostealer logs – at the source, before it is used against the organizations it was stolen from.

🍪 Session Cookie Recapture

SpyCloud's collection infrastructure infiltrates criminal communities where stolen session data is traded and stored. When a harvested session cookie appears in these markets, SpyCloud recaptures it and correlates it to the affected user identity via email, device fingerprint, and associated domain context.

🔑 Refresh Token Detection

AiTM kit infrastructure is monitored and infiltrated at the collection layer. SpyCloud identifies when refresh token artifacts appear in criminal infrastructure associated with specific user identities, enabling targeted revocation before the attacker acts.

📦 Infostealer Log Recapture

Infostealer logs contain session cookies exfiltrated from the victim's browser session store, alongside saved credentials, browser fingerprints, and target URLs. SpyCloud recaptures these logs and surfaces the specific session artifacts at risk.

🔗 IDLink Identity Correlation

A single data point – a corporate email, a device fingerprint, a session artifact – is correlated across SpyCloud's corpus to build a complete identity picture. An employee's personal email address where the phishing landed, their work account where access was used, and the device that was infected can all surface from a single match.

Section 7: Automated Response – Closing the Loop by IdP

SpyCloud does not produce an alert and wait. When a session cookie, refresh token, or credential is detected in criminal infrastructure, SpyCloud signals the customer's identity provider to take automated action through its administrative controls.

Okta — via Okta Identity Threat Protection + Okta Workforce Guardian

SpyCloud's Okta Workforce Guardian calls Okta's administrative API to revoke all active sign-in sessions and refresh tokens for the identified user by user ID or email.
This is a user-level administrative action – it revokes all active tokens simultaneously, not just the specific token that was detected.
The revocation is immediate and fully automated. No analyst interaction required.

Microsoft Entra ID — via Entra ID Guardian

Entra ID Guardian calls the revokeSignInSessions API, which invalidates all refresh token sign-in sessions for the user simultaneously.
Also accessible via Microsoft Graph API and PowerShell. Guardian automates this path without requiring manual execution.

Active Directory — via Active Directory Guardian

Active Directory Guardian forces an immediate password reset for the identified user, which invalidates the current credential.
For session and refresh token revocation specifically, Active Directory Guardian signals the connected SSO (Okta or Entra ID) to terminate active sessions.
Deploys in under 30 minutes. Integrates with existing AD infrastructure without production system changes.

Application-Layer Session Cookies: The Remaining Gap

Application session cookies live on the application's own domain, outside the IdP's authority. There are two paths to close this gap:

OIDC Back-Channel Logout implemented: The IdP sends a signed logout token to the application endpoint the moment SpyCloud triggers session termination. The application drops the local session immediately. The attacker's cookie stops working within seconds.
Back-Channel Logout not implemented (most enterprise environments): The application cookie is orphaned the next time the user accesses the application and re-authenticates. The old compromised cookie remains valid until that re-authentication moment occurs.

A forced password reset alone does not touch the application session cookie. Only re-authentication through a terminated IdP session orphans the old cookie.

Section 8: Incident Response – What to Do When SpyCloud Alerts

The following describes recommended actions when SpyCloud surfaces different types of identity exposure. Actions should be taken in order where multiple apply.

🍪 Session Cookie Detected

Immediate Actions:

Trigger IdP session termination (Guardian automates this).
Check email account for outbound anomalies or malicious rules.
Analyze logs to identify persistence mechanisms like new apps or OAuth grants.
Determine blast radius – who was in the affected user's contact list.

Why: Session revocation closes active access. Email account review determines if outbound phishing occurred during the window.

🔑 Refresh Token Detected

Immediate Actions:

Trigger full token revocation via Guardian (revokes all active tokens, not just the detected one).
Force password reset as belt-and-suspenders.
Review access logs for the preceding 90 days.

Why: Refresh tokens enable silent, months-long persistence. Full revocation is the only effective response.

📦 Infostealer Infection Detected

Immediate Actions:

Isolate or remediate the infected device.
Trigger password reset for all credentials exfiltrated (ADG automates this).
Revoke sessions for all applications listed in the exfiltrated data.
Check for additional users on the same network segment.

Why: Infostealer logs contain every saved credential and active session on the device. All of them should be treated as compromised.

🎣 Phished Credential Detected

Immediate Actions:

Immediate password reset (ADG automates this).
Check whether the credential was reused elsewhere.
Review account activity for unauthorized access.
If session artifacts were also captured: follow session cookie procedure above.

Why: Credential alone requires a reset. If the phish was an AiTM kit, session artifacts were also captured and require separate action.

🚨 AiTM Incident (Session + Token)

Immediate Actions:

Revoke all active sessions and tokens (Guardian).
Review email account outbound activity for the window between phish and detection.
Identify and notify all recipients of any outbound mail from the compromised account during that window.
Document the notification scope.

Why: The blast radius of an AiTM incident extends beyond the victim to every contact who received mail from their compromised account. The notification scope is almost always larger than the initial incident scope.

Section 9: Quick Reference Glossary

AiTM

A phishing technique where the attacker operates a live reverse proxy between the target user and a legitimate website, capturing the authenticated session after MFA completes.

Session Cookie

A short-lived credential issued by a web application after successful authentication. Presented with each request. Stolen cookies enable authenticated access without re-login.

Refresh Token

A long-lived credential – typically days to months. Enables applications to obtain new session cookies without re-authentication. More valuable to an attacker than a stolen password: survives password resets and MFA re-enrollment.

IDLink

SpyCloud's identity correlation engine. Matches a single data point (corporate email, device fingerprint, session artifact) to a complete digital identity across work accounts, personal accounts, device fingerprints, and associated PII.

Post-Infection Remediation (PIR)

SpyCloud's framework for comprehensive remediation of an infostealer malware infection – covering all exfiltrated credentials, session artifacts, and associated application data, not just the initial detected credential.

OIDC Back-Channel Logout

A mechanism where an IdP sends a signed logout token to an application endpoint when a user's session is terminated, enabling immediate application-layer session cookie invalidation without waiting for user re-authentication.

Infostealer

Malware designed to exfiltrate credentials, session cookies, browser data, and device information from infected devices. Logs from infostealer campaigns are recaptured by SpyCloud from criminal infrastructure.

Holistic Identity

SpyCloud's approach to identity correlation that goes beyond the corporate email address to include personal email aliases, device fingerprints, session artifacts, and PII – the same view of a person that a criminal operator has.

Adversary-in-the-Middle (AiTM)

See AiTM above. Also referred to in older literature as Man-in-the-Middle (MiTM) when applied to phishing proxy kits specifically targeting post-authentication session capture.

💬Have Questions?

Reach out to your SpyCloud Customer Success Manager or log in to submit a support ticket