foyl Concepts / AiTM Phishing
Attack Technique

AiTM Phishing

The attack that defeats MFA not by breaking it -- but by stealing what MFA produces. A real-time proxy sits between the victim and the login page, capturing the session cookie the moment authentication succeeds.

T1566.002 Spearphishing Link T1539 Steal Web Session Cookie T1550.004 Web Session Cookie 6-step walkthrough Interactive
Key vocabulary in this page -- click any term to define it
AiTM Typosquat domain Session cookie Reverse proxy SPF DKIM/DMARC Session replay Phishing-resistant MFA
1
2
3
4
5
6
FINANCE-WS-01 marcus.chen victim browser ATTACKER EvilProxy invoices-ficsit.io 185.220.101.42 Microsoft 365 login.microsoftonline legitimate target phishing email invoices-ficsit.io → marcus.chen HTTPS HTTPS credentials captured session cookie stolen Attacker Browser session cookie replay no password, no MFA needed INTERCEPTING
Step 1 of 6
The key insight: MFA passes, and that is the problem
What makes AiTM fundamentally different from credential phishing

Most defenders think of phishing as a credential-theft problem. Block the email, the attacker doesn't get the password. Add MFA, and even if they do get the password, it's useless without the second factor.

AiTM phishing breaks this model entirely. The attacker does not need to defeat MFA. They let the victim complete MFA successfully -- and then steal the session cookie that Microsoft issues at the end of the flow.

The session cookie is what keeps you logged in between browser visits. It is not protected by MFA because MFA only guards the login process. Once issued, the cookie can be used from any browser, on any device, anywhere in the world.

Why this matters
Push MFA, TOTP codes, and SMS verification are all defeated by AiTM because the victim completes MFA on the attacker's proxy. The proxy then captures the resulting session. The only MFA methods that protect against AiTM are phishing-resistant MFA -- FIDO2 passkeys and hardware security keys.
What the victim actually sees
The IRON CHIMNEY incident: phishing email delivered to marcus.chen@ficsit-pioneer.corp
Why SPF and DKIM pass
SPF and DKIM both check the sending domain -- invoices-ficsit.io -- not whether that domain is pretending to be someone else. The attacker registered invoices-ficsit.io legitimately and configured valid SPF/DKIM records. Both checks pass. DMARC fails because the From header domain (invoices-ficsit.io) does not align with the legitimate company domain (ficsit-pioneer.corp) -- but only if Ficsit has published a DMARC reject policy, which many organizations have not.
Where defenders can catch this
Detection opportunities across the attack chain
StageDetection SignalTool
Email delivery DMARC failure, domain registered <30 days ago, link points to non-corporate domain MailGuard
Successful login from new location Sign-in from Tor exit node IP (185.220.101.42), impossible travel, new ASN Identity SIEM
Post-auth access Inbox rule created (forward all email to external address), new OAuth app consented Identity
Network level NGFW blocks connection to invoices-ficsit.io if domain was added to threat feeds NGFW TIP
SIEM correlation INV-2024-0087 created: email + auth from same external IP + mailbox rule creation within 8 minutes SIEM INV-2024-0087
How to actually prevent this
The only defense that stops AiTM at the authentication layer is phishing-resistant MFA. Push MFA, TOTP, and SMS all fail against AiTM. Beyond authentication: Conditional Access policies that require compliant devices block replay from unknown browsers. Short session lifetimes (1-hour access tokens instead of 24-hour) limit the replay window. Entra ID's sign-in risk engine can flag impossible travel and block the session before the attacker pivots.
See it in foyl Learn
AiTM phishing drives the IRON CHIMNEY incident -- it appears in every tool that touched this case
Where to lookWhat you will find
IRON CHIMNEY scenario Full incident timeline from phishing email to lateral movement and exfiltration
MailGuard The phishing email from invoices-ficsit.io in quarantine with header analysis
Identity tool marcus.chen sign-in from 185.220.101.42 (Tor exit node) with MFA success flag
SIEM Investigation INV-2024-0087 correlating email + auth + inbox rule creation
Threat Intel IoC: invoices-ficsit.io listed as phishing domain; 185.220.101.42 as Tor exit node
IR Lab Guided walkthrough: triage the AiTM alert, contain marcus.chen's session, investigate
Related concepts
Core Concept
MFA and Bypass Techniques →
Attack Technique
Lateral Movement →
Attack Technique
Credential Theft →