MFA didn’t stop them. It helped them in.

The scenario:

The user entered their password. Then their MFA code. The login succeeded. For both of them. 

The phishing page wasn’t a fake login screen. It was a real-time proxy sitting between the user and Microsoft’s actual login page. Every keystroke was captured and replayed instantly. The MFA token was valid for 30 seconds. The attacker used it in 3. 

The attack:

STAGE 1: PHISHING DELIVERY 

Attacker sends a phishing email impersonating a shared document notification. 

Link points to an adversary-in-the-middle proxy (tools like Evilginx or Modlishka). 

The proxy presents the real Microsoft login page, not a clone. 

STAGE 2: REAL-TIME CREDENTIAL RELAY 

User enters their email and password. The proxy captures and forwards them to Microsoft in real time. 

Microsoft prompts for MFA. The user completes MFA on their phone. 

The proxy captures the session cookie issued after successful MFA. 

The user sees a normal SharePoint page. Nothing looks wrong. 

STAGE 3: SESSION HIJACKING 

Attacker imports the stolen session cookie into their own browser. 

They now have a fully authenticated session. MFA is bypassed. 

Access persists until the session token expires (often 24–72 hours). 

Attacker accesses email, OneDrive, SharePoint, and Teams. 

STAGE 4: PERSISTENCE AND EXFILTRATION 

Registers a new MFA device on the compromised account. 

Creates inbox rules to intercept security alerts. 

Begins monitoring email for financial transactions. 

Exports contacts for further phishing campaigns targeting the organisation. 

What stopped it:

A conditional access policy flagged the session being used from an unrecognised device and IP. The alert triggered a forced re-authentication that invalidated the stolen token.