What Is an AiTM Attack?
An Adversary-in-the-Middle (AiTM) attack is a phishing technique that uses a reverse proxy to intercept credentials and session tokens in real time. Unlike static phishing pages, AiTM actively relays traffic to the legitimate identity provider, allowing attackers to bypass Multi-Factor Authentication (MFA) by capturing the authenticated session cookie.
The attack unfolds in three stages:
- Lure and redirect to a fake login. The attack begins with a phishing email designed to bypass standard filters and create a sense of urgency. Instead of a static attachment, the email contains a URL that directs the victim to the attacker’s proxy server rather than the legitimate service.
- Reverse proxy steals credentials and session cookies. Once the user engages with the fake site, the reverse proxy relays their inputs to the legitimate identity provider in real time. This “man-in-the-middle” position allows the attacker to capture not only the password but also the MFA response and the resulting session cookie.
- Account takeover and lateral movement. Armed with the valid session cookie, the attacker assumes the user’s digital identity without triggering further MFA prompts. This access is immediately leveraged to establish persistence, such as creating mailbox rules to hide activity, or to pivot laterally into critical systems, such as finance and cloud environments, for Business Email Compromise (BEC) campaigns.
AiTM vs. Classic Man-in-the-Middle (MitM): What’s the Difference?
Classic MitM attacks exploit network weaknesses to secretly intercept data as it moves, often by decrypting traffic on a compromised connection (such as public WiFi). In contrast, an AiTM attack targets the login process directly to hijack an identity session. It completely bypasses the network layer by using a reverse proxy to trick the user into giving the attacker access.
The main difference is the attack layer: MitM focuses on the network, while AiTM targets authentication. We compare the operational differences below:
| Feature | Classic Man-in-the-Middle (MitM) | Adversary-in-the-Middle (AiTM) |
| Primary Target | Network Traffic (e.g., Unsecured Wi-Fi) | Authentication Session (Identity) |
| Attack Method | Eavesdropping, ARP Spoofing | Reverse Proxy Relay, Phishing |
| MFA Impact | Often stopped by standard MFA | Designed specifically to bypass MFA |
| Defense | HTTPS Encryption (TLS) | FIDO2 / Hardware Keys |
What changes in the web era
Because TLS and HTTPS became common, older Man-in-the-Middle (MitM) attacks failed as encrypted data transfer became the norm. Before encryption, attackers could easily steal passwords on unprotected networks.
Now, because user-server traffic is encrypted, attackers can’t just “eavesdrop.” Attackers created AiTM attacks in response: the attacker sets up a proxy as the genuine endpoint, misleading the user into starting an encrypted session with the attacker rather than the real service.
Why session hijacking is the goal
Modern AiTM attacks primarily aim to capture the session cookie, not just the password. A password alone often fails against MFA, but a valid session cookie works as a post-authentication token. The attacker inherits the user’s verified status by stealing this token, allowing them to access resources and maintain persistence without triggering new MFA challenges or needing the victim’s device again.
The Rise of AiTM: Phishing-as-a-Service and Infrastructure
AiTM attacks surged by 46% in 2025 because the “Phishing-as-a-Service” (PhaaS) model became industrialized. This commoditization has made it easier for low-skilled actors to rent ready-made attack kits, which automate complex proxying and session-harvesting processes.
Below, we explore the specific tools and infrastructure that drive this growing threat.
1. Reverse proxy toolkits and phishing kits
PhaaS kits allow adversaries to deploy high-fidelity attacks without developing custom exploits. Attackers purchase subscriptions to toolkits like Evilginx2, Modlishka, or Muraena, which provide pre-built templates for major identity providers (Microsoft 365, Google Workspace, Okta). These automated scripts handle the real-time traffic relay, enabling even unsophisticated actors to bypass standard MFA at scale.
2. OAuth consent phishing and token abuse
A parallel tactic involves abusing OAuth permissions to bypass the need for credentials entirely. Attackers deceive users into granting a malicious “Third-Party App” access to their data, often masquerading as a system update or security tool. Once granted, the attacker obtains an OAuth token that persists independently of the user’s password, often surviving password resets and MFA changes.
3. Infrastructure footprint
AiTM campaigns require a physical footprint: a sprawling infrastructure of newly registered domains to host the proxy servers. Attackers frequently register “typosquatting” or lookalike domains that mimic the target organization’s brand to deceive users during the redirection phase.
Proactive digital risk management plays a critical role here by monitoring the open web for these impersonating domains and flagging active phishing kits before they can launch widespread campaigns against employees.
Who is Most Vulnerable to AiTM Attacks?
AiTM phishing attacks primarily target business users within cloud environments, specifically Microsoft 365 and Google Workspace, where a single authenticated session grants access to email, data, and payment systems.
While this threat affects all employees, adversaries prioritize high-privilege roles such as IT administrators and supply chain partners. Key targets include:
Executives, finance, and IT administrators
Privileged accounts are the primary objective because they facilitate high-impact actions. Compromising an IT Administrator’s session enables an attacker to escalate privileges, create backdoor accounts, or disable security configurations, such as MFA policies.
Similarly, accessing a Finance Executive’s email enables adversaries to inject fraudulent invoices or authorize wire transfers through Business Email Compromise (BEC) tactics.
Third parties
Supply chain partners and contractors often possess legitimate access to an organization’s internal SaaS environments but lack the same rigorous security controls. Attackers target these users to hijack sessions in trusted applications like Salesforce or AWS.
Once inside, they leverage the trusted vendor relationship to pivot into the primary target’s network, bypassing perimeter defenses that would otherwise block external threats.
How to Detect an AiTM Attack: Pre-Delivery to Post-Compromise
Detecting an AiTM attack requires identifying anomalies at three specific points: email delivery, external infrastructure, and user session behavior. Standard signature-based tools often miss these attacks because the proxy relays legitimate traffic.
Security teams must instead rely on behavioral signals and infrastructure intelligence. Here are the indicators of compromise (IoCs) for each attack stage:
1. Pre-delivery: email and lure analysis
The initial phishing email is the first opportunity to stop the attack. Attackers often use techniques such as QR codes (Quishing) or redirects via trusted sites to bypass standard email gateways.
Effective detection requires analyzing the intent and destination of every link, flagging urgency cues, and mismatches between the sender’s display name and their actual address before the user interacts with the message.
2. Infrastructure intelligence: mapping the adversary
Before launching an attack, adversaries must register domains to host their proxy kits. These are often “typosquatting” domains designed to visually mimic the target’s brand (e.g., sso-micr0soft[.]com).
Enterprises need automated monitoring to detect these lookalike domains the moment they are registered, flagging active phishing kits on the open web before they can be deployed against employees.
3. Post-compromise: session and behavioral anomalies
If a user is successfully proxied, detection logic must shift to the session itself. The primary indicator is “impossible travel”, which is basically a valid login originating from a geolocation that the user cannot physically reach, given their last known activity (e.g., logging in from New York one minute and then from Tokyo the next).
Other critical signals include a sudden change in the user-agent string (device fingerprint) or an authentication request coming from a known hosting provider IP/ASN rather than a standard residential ISP.
Defending Against AiTM Attacks: Beyond Standard MFA
Enterprises must shift to a defense-in-depth strategy because adversaries can now bypass standard protections like SMS and push notifications. Effective defense against AiTM attacks requires layering control.
Below are a few necessary security measures to defend against AiTM attacks:
1. Phishing-resistant authentication (FIDO2)
The most effective countermeasure is to decouple authentication from shared secrets. FIDO2/WebAuthn hardware keys and passkeys bind the login session to the specific domain of the legitimate service.
If a user attempts to log in via a malicious proxy site, the protocol detects the domain mismatch and blocks the credential exchange automatically, without user intervention.
2. Email and link protection
Preventing the email from reaching the user remains the ideal outcome. Advanced email security solutions analyze the behavior and intent of incoming messages, looking for signals of credential harvesting such as open redirects or newly registered domains.
SOC teams can eliminate the human-error variable entirely by neutralizing the lure before it lands in the inbox.
3. Conditional access and network controls
Organizations should restrict access based on the “who, where, and what” of the login attempt. Conditional access policies can block authentication attempts from unmanaged devices or unexpected geographic locations.
Additionally, protective DNS services can block connections to known malicious proxy domains (like those generated by Evilginx), preventing the browser from loading the phishing site even if the user clicks the link.
4. User coaching
Generic “don’t click” training is insufficient against high-fidelity AiTM lures. Education must focus on specific behavioral checks: verifying the URL after the page loads (checking for subtle misspellings), recognizing the difference between a standard login prompt and a proxied one, and understanding that an unexpected MFA prompt is a sign of an active attack, not a system glitch.
Post-Compromise Procedures: Revoking Access and Scoping the Breach
When an AiTM attack is successful, the adversary obtains a session token that is independent of the user’s password. Traditional password resets fail here.
Responders must execute a specific containment workflow: force-revoke all active sessions, hunt for persistence mechanisms, and scope the data impact.
Below are some critical steps:
1. Revoke sessions and tokens
Sever the attacker’s access immediately. Trigger the “Revoke All Sessions” command to invalidate every active token. Immediately after, reset the user’s password and audit and reset their MFA settings to ensure the attacker has not registered a backup device for persistence.
2. Scope the blast radius
In Business Email Compromise (BEC) scenarios, attackers create inbox rules to hide alerts or auto-forward finance emails. Audit mailbox configurations for these hidden forwarding rules, check for malicious OAuth application grants, and review access logs to spot mass file downloads from SharePoint or Drive.
3. Evidence, notifications, and compliance
Secure the relevant sign-in logs, audit trails, and mailbox rule configurations, as these are critical for forensic analysis and potential legal proceedings. If the scope confirms data exfiltration of PII or financial records, immediately engage your legal and compliance teams to determine whether regulator notification (GDPR or CCPA) is required within the mandatory reporting window.
30-Day AiTM Readiness Plan
A 30-day readiness plan to defeat Phishing-as-a-Service includes measures such as auditing privileged accounts in week one, deploying infrastructure monitoring in week two, and enforcing phishing-resistant authentication by month’s end.
This roadmap guides organizations through the methodical transition from a legacy setup to a Zero Trust Security architecture.
Days 1-7: Audit
- Map privileged accounts: Identify every account with administrative access (Global Admins, Finance Approvers). These are your highest-risk targets.
- Audit authentication methods: Review current MFA settings. Flag any high-value accounts relying solely on SMS or simple Push notifications.
- Review OAuth grants: Scan the environment for existing third-party applications with high-privilege scopes (e.g., Mail.ReadWrite) and revoke any unused or suspicious tokens.
Days 8-14: Visibility
- Deploy infrastructure monitoring: Activate automated monitoring for typosquatting domains. You cannot stop what you cannot see; knowing when a company’s login [.]net domain is registered allows you to block it before the phishing campaign launches.
- Tune email gateways: Update email filtering rules to flag or quarantine messages containing links to domains registered within the last 72 hours, which is a common trait of fresh phishing infrastructure.
Days 15-30: Hardening
- Pilot phishing-resistant MFA: Roll out FIDO2/WebAuthn hardware keys or passkeys for the identified high-risk group (Admins and C-Suite).
- Enforce device compliance: Activate Conditional Access policies that block login attempts from unmanaged or non-compliant devices. This ensures that even if a session token is stolen, it is useless on an attacker’s machine.
AiTM Defense Checklist
This checklist consolidates the critical controls required to defeat AiTM attacks, mapping specific technical interventions (like FIDO2 and DNS filtering) to prevention, detection, and response.
| Attack Phase | Objective | Critical Actions & Controls |
| Before (Prevention) | Stop the lure | • Deploy FIDO2/WebAuthn: Bind authentication to the specific domain to break proxying.
• Filter email lures: Analyze intent and sender reputation to block phishing emails at the gateway. • Monitor infrastructure: Detect and block newly registered “typosquatting” domains before they become active. |
| During (Detection) | Spot the anomaly | • Track impossible travel: Flag logins occurring from geologically impossible distances.
• Fingerprint devices: Alert on user-agent changes or logins from known hosting provider ASNs. • Block the connection: Use DNS filtering to prevent the browser from loading known proxy domains. |
| After (Response) | Kill the session | • Revoke all tokens: Force a global sign-out to invalidate stolen OAuth/session tokens.
• Audit persistence: Check for new MFA devices or OAuth apps registered during the session. • Scope impact: Review mailbox rules and file download logs to assess data exfiltration. |
Defeating AiTM Phishing with Group-IB
Defending against AiTM requires focusing on stopping the lure before it reaches users and on disrupting the infrastructure that keeps these campaigns going. This approach reduces the likelihood of a session being hijacked, even when attackers try to bypass basic email controls.
Group-IB helps teams put this into practice by covering both the inbox and the broader phishing infrastructure. Business Email Protection reduces exposure to AiTM lures at the inbox. It filters and quarantines phishing attempts that rely on common AiTM delivery tricks, including QR-based bait and redirect chains, so fewer employees reach a proxy login page.
Digital Risk Protection then helps you disrupt lookalike domains and phishing infrastructure earlier. It enables faster blocking and takedown actions by identifying brand impersonation and campaign assets across the open web, limiting the lifespan of malicious proxies and their spread.
Contact Group-IB experts today to explore a proof of concept tailored to your environment and improve defenses against AiTM attacks.
