Introduction
A user enters their password.
They approve the MFA request.
Everything looks normal.
And yet the attacker logs in anyway.
This is not a failure of the user.
It is a failure of how identity security is designed.
Adversary in the Middle phishing is one of the most effective attack techniques today because it does not break authentication. It operates inside it.
If your organization relies on passwords and MFA alone, you are exposed.
Table of Contents
What Is AiTM Phishing
AiTM phishing is an attack where the attacker places a proxy between the user and the real login service.
The user believes they are logging into a legitimate platform such as Microsoft 365. In reality, their traffic is routed through an attacker-controlled proxy.
This allows the attacker to capture:
- Credentials
- MFA responses
- Session cookies and tokens
The critical detail is this:
The attacker does not need to break authentication.
They capture the result of successful authentication.
How AiTM Attacks Actually Work
Step 1: Lure
The attacker sends a phishing message that looks legitimate. This could be a document share, login request, or security alert.
Step 2: Proxy
The victim lands on a page that perfectly mirrors the real login page.
This is not a static fake site. It is a live relay to the real service.
Step 3: Credential Input
The user enters their username and password.
The proxy forwards these to the real service.
Step 4: MFA Challenge
The real service triggers MFA.
The user approves it.
Step 5: Token Issuance
The identity provider issues:
- Session cookies
- Access tokens
- Refresh tokens
This is the moment where trust is granted.
Step 6: Interception
The proxy captures these tokens in real time.
Step 7: Session Replay
The attacker reuses the tokens to access the account.
No password required
No MFA required
Image Block
Image prompt:
A dark minimal cybersecurity diagram showing a user connecting to a login server through a hidden proxy layer in the middle. Clean flow arrows from user to proxy to server. Highlight the interception point at token issuance. Dark blue and black background with subtle gold accents. No hacker clichés.
Alt text:
AiTM phishing proxy intercepting authentication session between user and server
Caption:
AiTM attacks intercept trust at the moment authentication succeeds
Why MFA Fails Against AiTM
MFA was designed to protect against credential theft.
It works when:
- A password is stolen
- An attacker tries to log in separately
It fails when:
- The attacker is inside the login flow
Once authentication succeeds, the system issues a session token.
That token represents access.
AiTM attacks target this exact moment.
This is why MFA enabled is not a strong security guarantee.
The Real Problem: Session Trust
Modern identity systems such as Microsoft Entra ID rely on token-based authentication models. According to Microsoft Entra ID documentation, session tokens represent authenticated access and are reused across services.
Industry guidance such as the OWASP Session Management Cheat Sheet shows how improper session handling increases the risk of session hijacking attacks.
Modern identity systems rely on:
- Single Sign On
- OAuth and OpenID Connect
- Token-based authentication
Authentication is no longer a single event.
It is the beginning of a session.
After login, the system grants trust through tokens.
These tokens:
- Are often not bound to a device
- Are rarely continuously validated
- Can be reused if stolen
This creates a gap between authentication and session ownership.
AiTM phishing operates inside that gap.
Session Theft vs Credential Theft
AiTM phishing changes how we should think about identity attacks.
Most organizations still think in terms of credentials.
They ask: did the attacker get the password?
Modern attacks ask a different question.
Did the attacker get the session?
Credential theft:
- Password is stolen
- MFA may still stop access
Session theft:
- Token is stolen
- MFA already completed
- Immediate access
This is a completely different threat model that many organizations fail to understand.
AiTM phishing proves that session security is now the primary attack surface.
Why This Attack Works
AiTM is not just technical. It leverages human behavior.
- Trust in familiar login pages
- Routine approval of MFA requests
- Authority of known brands
- Real-time interaction without delay
The user completes the attack themselves without noticing.
Impact of AiTM Attacks
Direct Impact
- Account takeover
- Access to email and files
Operational Impact
- Business Email Compromise
- Invoice fraud
- Internal phishing
Strategic Impact
- Privilege escalation
- Tenant-wide compromise
- Supply chain exposure
One successful session can lead to a full attack chain.
How to Reduce AiTM Risk
You cannot fully eliminate AiTM. You can reduce exposure.
Identity controls
- Conditional Access policies
- Device compliance enforcement
- Location-based restrictions
- Risk-based authentication
Session controls
- Short session lifetimes
- Session binding to device or context
- Continuous evaluation of sessions
Strong authentication
- Passkeys
- Hardware security keys
These methods are resistant to proxy-based attacks.
User awareness
- Focus on login flow manipulation
- Avoid generic phishing training
Internal Links
- How Cyber Attacks Happen
- Phishing Attack Explained
- Why MFA Does Not Stop Phishing
- Session vs Credential Theft
- Why Session Cookies Matter More Than Your Password
CTA
Identity Security Review
AiTM phishing risk assessment for Microsoft 365 environments.
If your organization uses Microsoft 365 or Entra ID, relying on MFA alone is not enough.
We analyze:
- Where session theft is possible
- Where MFA creates false confidence
- Where Conditional Access reduces real risk
You get a clear and prioritized hardening plan based on real attack paths.
Conclusion
AiTM phishing works because it targets the gap between authentication and access.
Not the password.
Not the MFA code.
The session.
As long as systems treat authentication as a one-time event and trust as persistent, this attack will continue to work.
Internal Linking Suggestions
Pillar:
Supporting: