13.1 Understanding AiTM Attacks

2–3 hours · Module 13

What Makes AiTM Different

Adversary-in-the-middle (AiTM) phishing is not traditional credential phishing. In a traditional attack, the attacker creates a fake login page, captures the username and password, and MFA stops them — they have credentials but cannot complete the second factor. AiTM defeats MFA entirely.

The attacker deploys a reverse proxy between the victim and the real Microsoft login page. The victim sees the genuine Microsoft interface. They enter their credentials. They complete MFA. Every step passes through the attacker’s proxy, which captures the complete session token — including the MFA claim. When the attacker replays that token, Azure AD sees a valid, MFA-authenticated session. No new MFA challenge is issued.

Figure 13.1: The complete AiTM flow. The victim completes a normal login through the proxy. The proxy captures the session token at step 8.

Session tokens vs refresh tokens

Understanding what the attacker captures is critical for containment:

Session token (access token): Short-lived (typically 60-90 minutes). Grants access to a specific resource (Exchange Online, SharePoint). Expires quickly — the attacker has a narrow window.

Refresh token: Longer-lived (up to 90 days). Used to request new access tokens without re-authentication. If the attacker captures the refresh token, they can maintain access for days or weeks — generating new access tokens silently.

The refresh token is the prize

Modern AiTM kits capture the refresh token, not just the session token. This means revoking the session token alone is not sufficient — you must revoke all refresh tokens. In Entra ID, "Revoke sessions" invalidates both. But if you only sign the user out of active sessions without revoking refresh tokens, the attacker can silently re-authenticate.

AiTM phishing kits in the wild

Kit	Model	Key characteristics	Prevalence
EvilGinx2	Open-source	Highly customisable, community “phishlets” for M365/Google/Okta, self-hosted	High — foundation for many custom deployments
Tycoon 2FA	Phishing-as-a-Service	Cloudflare turnstile CAPTCHA (blocks scanners), rotating domains, Telegram exfil	Very high — dominant kit in 2025-2026
Greatness	Service	M365-focused, built-in MFA relay, Telegram bot for stolen sessions	Moderate
Mamba 2FA	Service	Socket.io relay (newer technique), handles multiple MFA methods	Growing
NakedPages	Open-source	Go-based, lightweight, Docker deployment	Moderate

The commercial kits (Tycoon, Greatness) lower the barrier to entry significantly. An attacker does not need to understand reverse proxying — they subscribe to the service, configure the target domain, and receive stolen tokens via Telegram.

Tycoon 2FA's anti-analysis features

Tycoon 2FA places a Cloudflare turnstile CAPTCHA before the proxy page. This prevents automated URL scanners (including Microsoft's Safe Links detonation) from reaching the phishing page. The URL appears clean to automated analysis — only a human who completes the CAPTCHA reaches the proxy. This is why Wave 1's URL was clean at delivery and only flagged 23 minutes later.

Why MFA alone fails — and what works

MFA method	Stops traditional phishing?	Stops AiTM?	Why?
SMS OTP	Yes	No	OTP passes through the proxy
Authenticator push	Yes	No	User approves thinking it’s the real site
Authenticator OTP	Yes	No	OTP passes through the proxy
Phone call	Yes	No	Approval passes through the proxy
FIDO2 security key	Yes	Yes	Cryptographically bound to the real domain — proxy cannot complete the handshake
Certificate-based auth	Yes	Yes	Certificate verifies the server’s domain — proxy fails verification
Windows Hello for Business	Yes	Yes	TPM-bound, device-specific — cannot be proxied

Check your understanding

1. An attacker captures a refresh token via AiTM. You revoke the user's active sessions but do not revoke refresh tokens. What happens?

The attacker loses access permanently

The attacker loses access until the session token expires (60-90 min)

The attacker uses the refresh token to silently obtain new access tokens without re-authentication — maintaining access for up to 90 days

Refresh tokens are the persistence mechanism. They generate new access tokens silently. "Revoke sessions" in Entra ID invalidates both session and refresh tokens. If your containment only covers active sessions, the refresh token remains valid and the attacker maintains a foothold.

2. Why did the phishing URL appear clean to Safe Links at delivery time?

The phishing kit used a Cloudflare turnstile CAPTCHA that blocked automated scanners — only human visitors who completed the CAPTCHA reached the proxy page. Safe Links' automated detonation saw a CAPTCHA page, not a phishing page.

The URL was not yet active

Safe Links was disabled for this mailbox

Anti-analysis CAPTCHAs are a defining feature of modern AiTM kits. Automated URL scanners (Safe Links, sandbox detonation) hit the CAPTCHA and see a benign page. Only human visitors who solve the CAPTCHA reach the actual phishing proxy. This is why the URL was clean at delivery and only flagged after Microsoft's threat intelligence updated.

3. FIDO2 stops AiTM but authenticator app push does not. What is the fundamental difference?

FIDO2 is hardware-based; authenticator is software

FIDO2 requires biometric verification

FIDO2 cryptographically verifies the server domain — it checks that the login page is actually login.microsoftonline.com, not phishing-domain.com. The authenticator app just shows a push notification with no domain verification.

Domain binding is the key. FIDO2's cryptographic handshake includes the server's domain in the challenge. A proxy on phishing-domain.com cannot present a valid challenge for login.microsoftonline.com — the key detects the mismatch and refuses to authenticate. Push notifications and OTP codes have no concept of which domain requested them.

← 13.2 The Incident Briefing