1/12/2026. The days of simple password theft are far behind us. Now we're dealing with
AiTM phishing attacks that bypass MFA by stealing your active session instead of your credentials. Think about it: you log in through what appears to be the real website, complete your two-factor authentication, and everything seems normal. But a proxy server just captured the session token your browser received after authentication. That token is all an attacker needs to impersonate you without touching your password or MFA at all.
TLDR:
- AiTM attacks steal your active session token after you complete MFA, bypassing passwords entirely
- 84% of compromised accounts had MFA active because tokens grant access without re-authentication
- Phishing-as-a-Service toolkits cost $100-$1,000/month and require minimal technical skills to deploy
- Behavioral biometrics detect stolen sessions by analyzing typing patterns and mouse movements
- Roundtable stops AiTM attacks by identifying non-human behavior in real time without disrupting users
What is an Adversary-in-the-Middle (AiTM) Attack
Adversary-in-the-Middle attacks intercept your entire login session in real time. The attacker creates a proxy server between your browser and the real login page. When you enter credentials, the proxy captures them and relays them to the actual service. You see the real login interface and complete authentication normally, including multi-factor authentication challenges.
The critical difference: attackers steal your active session token, the digital key proving you've already authenticated. With this token, they access your account without re-authenticating, making traditional password theft look primitive by comparison.
The Business Impact of AiTM Attacks
Credential theft marks only the beginning of an AiTM attack. The business impact can be profound:
- Attackers use compromised accounts to execute wire transfer fraud that averages $125,000 per incident.
- Business email compromise schemes study victim communication patterns for weeks before impersonating executives to authorize fraudulent payments.
- Data exfiltration targets email archives, SharePoint repositories, and customer databases. Intellectual property, strategic plans, and sensitive client information move through authenticated sessions that appear legitimate to security tools, avoiding detection.
Recovery extends beyond immediate financial losses:
- Investigation efforts span months as teams determine compromise scope and notify affected parties
- Regulatory penalties apply when breached data falls under GDPR or HIPAA requirements
- IT teams must revoke sessions organization-wide, reset authentication systems, and validate every user account
- Business processes stop during forensic investigation and remediation
The trust built through compromised executive accounts becomes the mechanism for fraud, making prevention far less expensive than response.
How AiTM Attacks Bypass Multi-Factor Authentication
MFA creates a false sense of security. The authentication token generated after successful MFA verification becomes the target. This token tells the service "this user already proved their identity," bypassing any need for passwords or secondary verification.
- You receive a legitimate MFA prompt through the proxy.
- You approve it on your phone or enter your code.
- The service generates a session cookie confirming successful authentication.
- The proxy intercepts this cookie before your browser receives it.
- The attacker now holds a valid session token.
84% of compromised accounts had MFA in place, according to Obsidian Security. MFA protects the authentication moment, not the session that follows. Once attackers possess your session token, they impersonate an already-verified user.
AiTM vs MiTM: Understanding the Key Differences
Man-in-the-Middle attacks intercept network traffic at the transport layer, eavesdropping on unencrypted communications or exploiting weak SSL implementations. These attacks are largely passive, collecting data as it flows between two parties. Network-level defenses like proper certificate validation and encrypted connections prevent most MiTM scenarios.
AiTM operates at the application layer with active manipulation. The attacker doesn't listen but participates in the authentication flow, relaying every interaction between the user and the legitimate service while modifying requests when needed.
The critical difference: AiTM defeats SSL/TLS encryption by becoming an authorized endpoint. Users establish an encrypted connection to the proxy, which establishes its own encrypted connection to the real service. Both connections use valid certificates, making detection extremely difficult.
Network monitoring tools struggle to identify AiTM because the traffic appears legitimate. Phishing domains often use convincing lookalike URLs with proper HTTPS certificates, making visual verification challenging for users.
The Role of Reverse Proxy Technology in AiTM Attacks
Reverse proxy servers sit between victims and legitimate services, forwarding requests and relaying responses in real time. This differs from traditional phishing, which relies on static login page copies that quickly become outdated.
The attack flow operates as follows:
- the proxy retrieves the actual login page from the target service,
- captures credentials as victims enter them,
- forwards authentication requests to the real server,
- intercepts session tokens and cookies from the response,
- then passes authenticated sessions back to the victim's browser.
Since all content originates from the legitimate service, victims see an exact replica. And,
open-source toolkits have reduced the technical barrier to entry. Attackers can configure proxies against any web service in minutes without writing custom code for different authentication methods.
Popular AiTM Phishing Toolkits and Phishing-as-a-Service
Phishing-as-a-Service has converted AiTM attacks from specialized operations into accessible campaigns.
Microsoft tracked a 146% increase in adversary-in-the-middle attacks over the last year as these toolkits spread. These services function as subscription offerings. Attackers pay monthly fees between $100 and $1,000 for complete AiTM infrastructure, including hosted reverse proxies, phishing email templates, and victim dashboards that display captured credentials and session tokens.
Current toolkits need minimal technical skills. Users select a target service from a dropdown menu, customize the phishing URL, and launch campaigns within minutes. The toolkit manages proxy configuration, SSL certificate generation, and token extraction automatically. This commoditization has expanded AiTM attacks beyond nation-state actors to financially motivated criminals.
Microsoft 365 as a Primary Target for AiTM Campaigns
Microsoft 365 accounts grant single sign-on access to email, file storage, collaboration tools, and financial systems. One compromised account opens extensive organizational access beyond credential theft alone. Most successful AiTM attacks against Microsoft 365 lead to business email compromise.
Attackers monitor compromised mailboxes for days or weeks, studying communication patterns, vendor relationships, and payment processes while using
bot detection tools to evade automated security systems. They identify wire transfer requests, invoice approvals, and executive communications to execute financial fraud.
Cloud-based access amplifies the threat. Stolen session tokens let attackers operate from any location while appearing as legitimate remote workers while network perimeter defenses provide zero visibility into these authenticated sessions, letting attackers exfiltrate data, manipulate documents, or redirect payments without triggering alerts.
Session Hijacking: The Ultimate Goal of AiTM Attacks
Session tokens act as "master keys" that grant access long after initial login. Once attackers steal a valid token, they skip password entry, MFA prompts, and verification checks. Services treat the token itself as identity proof until expiration.
Part of the challenge in dealing with AiTM is that token lifetimes vary widely between services. Microsoft 365 sessions can last hours or days depending on conditional access settings. Attackers use this window to exfiltrate emails, alter permissions, set up forwarding rules, and create backdoors.
Traditional credential theft forces re-authentication at every login, but session hijacking removes this barrier. Attackers paste the stolen token into their browsers and instantly access your live session from any location.
And, password resets fail to stop these attacks. Changing credentials after token theft doesn't invalidate active sessions. Attackers retain access until tokens expire or administrators manually revoke all sessions for the compromised account.
Detecting AiTM Attacks in Your Environment
So, what can you do to identify AiTM attacks in your environment? Here are a few best practices:
- Authentication logs. These contain clear indicators of AiTM compromise. Watch for multiple sign-ins from distant geographic locations within short windows, revealing session token reuse. Account activity jumping between continents in minutes flags impossible travel patterns.
- Device and browser inconsistencies expose stolen sessions. Users don't typically switch from Chrome on Windows to Firefox on Linux mid-session. Changes in user agent strings between authenticated requests point to different devices accessing identical sessions.
- Analyze session duration against normal user patterns. Sessions active during off-hours, weekends, or lasting abnormally long compared to baseline behavior warrant investigation.
Phishing-Resistant Authentication Methods
FIDO2 security keys and passkeys rely on cryptographic challenges tied to the exact domain you access. During authentication, your browser verifies the origin matches the registered domain. Proxy servers operate through different URLs, which breaks this cryptographic binding even when the domain appears visually identical.
These authentication methods never transmit passwords or tokens to the server. Your device signs a challenge with a private key that never leaves the hardware. A proxy can relay this signature, but can't reuse it for future logins or different domains.
Certificate-based authentication works the same way, binding credentials to specific device certificates. Session token theft becomes meaningless because attackers can't replay authentication without physical access to your security key or device.
Building Defense Layers Against AiTM Threats
Stopping AiTM attacks requires layered protections that increase difficulty at each attack stage. Consider each of the following layers as you build out a strategy to thwarting AiTM attacks:
- Conditional access policies
- Session management controls
- Security awareness training
- Behavioral analytics
- Behavior detection and invisible security
Conditional Access Policies
Configure policies that restrict sign-ins to managed devices only while requiring device compliance checks verifying updated security software and encryption before granting access. This blocks attackers from using stolen session tokens on unmanaged systems, even with valid credentials.
Session Management Controls
Set aggressive token expiration windows to limit attacker opportunity and configure re-authentication requirements every few hours instead of allowing sessions to persist for an entire day. In addition, implement risk-based triggers that force re-authentication when users access sensitive resources or exhibit unusual behavior.
Security Awareness Training
Train employees to verify exact URLs before entering credentials and identify common phishing indicators. You should run regular simulations to maintain sharp security awareness, though this should complement, not replace technical defenses.
Behavioral Analytics
Deploy monitoring that tracks typing patterns, mouse movements, and navigation behaviors throughout active sessions. These solutions detect when session tokens are used by different actors, catching post-authentication compromises that perimeter controls cannot identify.
Defense Layer Overview
The table below provides an overview of the different defense layers.
| Defense Layer |
Implementation Details |
How It Stops AiTM Attacks |
Limitations |
| Conditional Access Policies |
Restrict sign-ins to managed devices only; require device compliance checks verifying updated security software and encryption before granting access |
Blocks attackers from using stolen session tokens on unmanaged systems, even with valid credentials |
Doesn't prevent initial token theft; attackers with access to managed devices can still exploit stolen tokens |
| Session Management Controls |
Set aggressive token expiration windows (hours instead of days); configure re-authentication requirements every few hours; implement risk-based triggers for sensitive resource access |
Limits attacker opportunity window by forcing frequent re-authentication; reduces time available for exploitation after token theft |
Requires balance between security and user experience; may impact legitimate users with frequent prompts |
| Security Awareness Training |
Train employees to verify exact URLs before entering credentials; identify common phishing indicators; run regular phishing simulations |
Prevents users from entering credentials into proxy servers in the first place; reduces initial compromise success rate |
Human error remains a factor; sophisticated phishing domains with valid HTTPS certificates are difficult to identify visually |
| Behavioral Analytics |
Deploy monitoring that tracks typing patterns, mouse movements, and navigation behaviors throughout active sessions |
Detects when session tokens are used by different actors post-authentication; identifies non-human activity patterns that attackers can't replicate |
Requires baseline establishment period; may generate false positives during initial deployment |
| Phishing-Resistant Authentication |
Implement FIDO2 security keys and passkeys that use cryptographic challenges tied to exact domains; deploy certificate-based authentication |
Breaks cryptographic binding when proxy servers use different URLs; prevents token replay attacks as private keys never leave hardware |
Requires hardware investment and deployment logistics; user adoption and training needed for new authentication methods |
Behavioral Detection and Invisible Security
Behavioral biometrics reveal what authentication logs can't: the difference between a legitimate user and an attacker wielding stolen tokens, providing
invisible human verification that works continuously. Typing rhythm, mouse movement patterns, and navigation behavior create unique signatures that attackers can't replicate, even with valid session credentials.
Roundtable analyzes these behavioral markers continuously throughout sessions, identifying anomalies like programmatic typing or unnatural cursor movements that expose compromised accounts. These invisible checks run without disrupting legitimate users, detecting non-human activity in real time.
Attackers who steal session tokens through AiTM attacks possess valid credentials but lack the actual behavioral patterns of the actual user. When session activity suddenly transitions from organic human interaction to mechanical patterns, behavioral detection surfaces the compromise immediately.
Final thoughts on AiTM attack prevention
The rise of
AiTM attacks shows that authentication is just the beginning of security, not the end. Stolen session tokens let attackers bypass every defense you've built around the login process. Continuous behavioral analysis detects when sessions shift from human to attacker, catching compromises in real time. Start tightening your session controls and monitoring authenticated activity differently.
FAQ
How do AiTM attacks bypass multi-factor authentication?
AiTM attacks intercept your session token after you complete MFA verification, not your password or authentication code. The attacker's proxy relays your MFA approval to the real service, captures the session token that proves you authenticated successfully, then uses that token to access your account without needing to authenticate again.
What's the main difference between AiTM and traditional MiTM attacks?
Traditional MiTM attacks passively intercept network traffic and are blocked by SSL/TLS encryption. AiTM attacks actively participate in the authentication process at the application layer, becoming an authorized endpoint with valid HTTPS certificates that makes detection extremely difficult through standard network monitoring.
How can I detect if my organization has been compromised by an AiTM attack?
Check authentication logs for impossible travel patterns (sign-ins from distant locations within minutes), device inconsistencies (sudden switches between different browsers or operating systems mid-session), and unusual session durations (activity during off-hours or sessions lasting abnormally long compared to normal user behavior).
Why don't password resets stop AiTM attacks?
Password resets don't invalidate active session tokens that attackers already stole. The token acts as proof of authentication independent of your password, so attackers retain access until the token expires naturally or administrators manually revoke all sessions for the compromised account.
What authentication methods actually prevent AiTM attacks?
FIDO2 security keys and passkeys prevent AiTM attacks because they use cryptographic challenges tied to the exact domain you're accessing. Since proxy servers operate through different URLs, the cryptographic binding breaks even when the domain looks identical, and attackers can't replay the authentication signature on different domains.