Multi-factor authentication (MFA) was supposed to be the silver bullet against account takeover. For years, security teams told users: “Even if your password is stolen, attackers still can’t get in without your second factor.” Unfortunately, that’s no longer true.
Adversary-in-the-middle (AitM) phishing attacks are designed specifically to break that promise.
Instead of just stealing usernames and passwords, AitM attackers insert a malicious proxy between the victim and a genuine website, capturing live traffic, MFA codes, and – most importantly – session cookies and authentication tokens.
With those tokens, they can hijack an already authenticated session and walk straight past traditional MFA as if they were you.
In this in-depth guide, we’ll break down:
- What adversary-in-the-middle (AitM) attacks are, and how they evolved from classic man-in-the-middle (MitM) attacks
- How modern AitM phishing campaigns work step by step
- The tools and infrastructure (including phishing-as-a-service) that make these attacks accessible
- Realistic use cases – from executive spearphishing to financial fraud
- Red flags users and defenders can look for
- A layered, practical defense strategy, with both technical and human controls
Throughout, we’ll weave in concrete examples, technical depth, and actionable steps so you can translate theory into protection – whether you’re an individual user, security practitioner, or business decision-maker.
What is an Adversary-in-the-Middle (AitM) Attack?
An adversary-in-the-middle (AitM) attack is a type of cyberattack in which a malicious actor secretly positions themselves between two parties who believe they are communicating directly with each other.
In everyday terms: the attacker sits in the middle, intercepting, relaying, and often manipulating data between a user and a legitimate service (like a banking site, email provider, or cloud platform).
What makes AitM different from older, simple MitM scenarios is its level of interactivity and intent:
- The attacker doesn’t just listen; they actively impersonate both sides.
- They relay requests and responses in real time, modifying them when it benefits the attack.
- They often aim to steal authentication material – not only passwords, but also:
- One-time codes (OTP) sent via SMS/email/authenticator apps
- Push notification approvals
- Session cookies and authentication tokens that prove a user is already logged in
Those session cookies and tokens are the real prize. Once stolen, they act as digital keys: the attacker can import them into their own browser and instantly gain access to the victim’s account without needing to repeat a login or complete MFA again. This is called session hijacking.
Why AitM matters now
AitM isn’t new in concept, but it has exploded in relevance because:
- MFA adoption is now widespread: cloud services and enterprises rely heavily on SMS codes, authenticator apps, and push notifications.
- Attackers have adapted: instead of fighting MFA head-on, they go around it by capturing the post-login session.
- Phishing kits and phishing-as-a-service (PhaaS) give even low-skilled criminals AitM capabilities with polished templates for services like Microsoft 365, Google Workspace, or banking portals.
- AI-assisted tooling and automation make it easier to craft convincing lures and scale campaigns.
The result is a class of attacks that can compromise even “MFA-protected” accounts – especially where legacy, code-based MFA is used.
AitM vs. Classic MitM: What’s the Difference?
The terms man-in-the-middle (MitM), attacker-in-the-middle, and adversary-in-the-middle are closely related and often overlap. But there are meaningful differences in how attacks are typically carried out today.
Traditional MitM attacks
Classic MitM focuses on the network path between the client and server. The attacker inserts themselves by exploiting network-layer weaknesses, for example:
- Rogue Wi-Fi hotspots (e.g., a fake “CoffeeShop_Free_WiFi”) that users connect to in public spaces
- ARP spoofing/ARP poisoning, tricking devices into sending traffic to the attacker’s MAC address
- DNS spoofing/poisoning, redirecting a known domain (like example.com) to an attacker-controlled IP
- Gateway or ISP compromise, where traffic is intercepted from within the network infrastructure
In these scenarios, the attacker may:
- Passively sniff unencrypted traffic
- Attempt SSL/TLS stripping, downgrading HTTPS to HTTP
- Use forged or malicious certificates to intercept encrypted connections
The focus is often on broad interception, not necessarily on real-time interaction with specific web apps or MFA flows.
Adversary-in-the-middle (AitM) attacks
AitM attacks, by contrast, are application-centric. They typically use a reverse proxy at the application layer, positioned between the victim’s browser and the legitimate website.
Key differences:
Aspect | Man-in-the-middle (MitM) | Adversary-in-the-middle (AitM) |
Primary focus | Network traffic interception | Application-layer authentication & sessions |
Positioning | On-path: LAN, Wi-Fi AP, gateway, DNS | Reverse proxy on attacker’s domain |
Main goal | Eavesdropping, generic data theft | Session hijacking, MFA bypass, account takeover |
Technology | ARP/DNS spoofing, rogue APs, SSL stripping | Reverse proxies, TLS termination, phishing kits |
MFA bypass | Limited (e.g., OTP in real time) | Explicitly designed to bypass MFA via token theft |
User view | Often a fake or altered site | Live proxied version of real site (origin is wrong) |
In AitM phishing, the victim usually arrives at a malicious URL that looks legitimate (e.g., misspellings, subdomain tricks, or abuse of trusted cloud platforms). Behind the scenes, their browser connects to:
- The attacker’s server → which then connects to → the real website.
The attacker terminates TLS at their proxy, sees everything in cleartext, and then opens a second TLS session to the real site.
To the victim, the page looks perfect because it is the real page, just relayed. The only subtle difference is the origin – the domain and certificate belong to the attacker, not the real service.
How an AitM Phishing Attack Works
Modern AitM campaigns, especially those targeting corporate cloud accounts, typically follow a recognizable kill chain. Let’s walk through it from the attacker’s perspective.
1. Reconnaissance and target selection
Attackers often start with open-source intelligence (OSINT) to find:
- High-value organizations (e.g., law firms, financial institutions, SaaS providers, government agencies)
- High-value individuals (C-level executives, finance staff, IT admins, privileged engineers)
- Technologies in use (Microsoft 365, Google Workspace, Okta, specific VPNs, etc.)
They may scrape LinkedIn, corporate websites, and public data breaches to assemble lists of names, roles, and email addresses.
2. Setting up the AitM proxy infrastructure
Next, attackers deploy the technical backbone of the campaign:
- A reverse proxy (e.g., open-source tools like Evilginx, Muraena, Modlishka, or custom-built platforms)
- One or more malicious domains that resemble legitimate ones, for example:
- micros0ft-login[.]com instead of microsoft.com
- firm-name-login[.]com or a spoofed sharepoint-online[.]cloud domain
- TLS certificates (often using free certificate authorities), so the site still shows a padlock icon
Modern phishing-as-a-service (PhaaS) platforms bundle much of this:
- Pre-built templates for login pages of popular cloud services
- Scripts that modify login flows for specific tenants
- Automatic capturing and exfiltration of credentials and tokens
- Dashboards for tracking which victims have “logged in”, completed MFA, and which cookies are valid
3. Luring the victim: social engineering & redirection
With infrastructure in place, attackers launch phishing campaigns to drive traffic to the malicious AitM domain. Common lures include:
- “Your Microsoft 365 session has expired – sign in again to continue working.”
- “Important legal document for your review – access via secure portal.”
- “Unusual sign-in activity detected – verify your identity.”
- “Invoice overdue” or “Wire transfer confirmation” for finance teams.
They may send these via:
- Email (classic phishing and spearphishing)
- SMS (smishing)
- Corporate messaging (compromised Slack/Teams accounts)
- Malvertising or SEO poisoning (malicious ads or search results)
To evade security filters, campaigns often use chains of redirects and abuse legitimate cloud services (like document-sharing URLs or form platforms) as the initial click destination, before redirecting to the AitM proxy.
4. Application-layer positioning via reverse proxy
When the victim follows the link, their browser lands on the attacker’s domain – which immediately and transparently fetches the real login page from the legitimate service and renders it through the proxy.
Technically, the attacker sets up two TLS sessions:
- Between victim → attacker’s reverse proxy
- Between attacker’s reverse proxy → legitimate service
At their proxy, traffic is briefly decrypted, allowing the attacker to:
- Read and copy anything the victim submits (credentials, MFA codes)
- Modify or redact content (e.g., hide phishing-resistant MFA options)
- Inject additional elements (fake error messages, extra forms, malware links)
From the victim’s point of view, the login form works exactly as expected. That’s because they are talking to the real site – just indirectly, through the adversary in the middle.
5. Real-time credential and MFA capture
The victim now:
- Enters their username and password.
- Triggers MFA (SMS code, voice call, authenticator app, push notification).
The AitM proxy:
- Forwards credentials to the real service
- Waits for the MFA step
- Prompts the victim to enter the code or approve the push
- Relays that MFA response to the legitimate service in real time
At every step, the attacker records:
- The username and password
- The MFA codes used
- Any device and browser fingerprints
6. Session cookie theft and MFA bypass
Once MFA succeeds, the legitimate website creates a session and sends:
- Session cookies and/or
- Authentication tokens (e.g., OAuth tokens, JWTs)
to what it believes is the user’s browser. In reality, these land first at the attacker’s proxy.
The proxy:
- Forwards the cookies/tokens back to the victim so their session works as normal
- Copies and exfiltrates those same cookies/tokens to the attacker’s stash
At this point, the attacker usually no longer cares about the victim’s password or codes – they already have what they need: a live, authenticated session. By importing those tokens into their own browser, they can:
- Recreate the victim’s session
- Access mailboxes, files, dashboards, admin portals
- Act as the victim until the session expires or is revoked
This is how AitM bypasses MFA:
- The victim did use MFA.
- The system did enforce MFA.
- But the attacker piggybacked on the very session that MFA was protecting.
7. Cleaning up the UI (and covering tracks)
To avoid raising suspicion, attackers often:
- Redirect the victim to:
- A generic dashboard
- The legitimate home page
- Or even a benign error page (“Session timed out – please try again later”)
- Close the proxied session and log the event as “successful” in their own panel
The user walks away thinking:
“Weird, maybe I mistyped something. Anyway, I logged in.”
Meanwhile, the attacker is already in the account using the stolen session.
8. Post-exploitation: what attackers do after they’re in
Once the attacker has live access to the victim’s account, they may:
- Scan email and cloud storage for:
- Financial data
- Legal documents
- Credentials, API keys, internal project info
- Launch Business Email Compromise (BEC) by impersonating the victim in ongoing threads
- Reset passwords or add their own MFA methods to entrench access
- Pivot into connected systems via Single Sign-On (SSO)
- Exfiltrate sensitive files, trade secrets, or client data
- Attempt financial fraud, such as:
- Changing invoices
- Altering wire instructions
- Creating unauthorized payments
Because they’re using valid session cookies, many of these actions appear – at least initially – like normal user behavior.
Other Ways Adversaries Get in the Middle
While this article focuses on AitM phishing, it’s useful to understand the broader family of adversary-in-the-middle techniques. Many of the same concepts underpin both network- and application-layer attacks.
Rogue Wi-Fi and fake hotspots
In public places (cafés, airports, hotels, trains), attackers can set up a malicious Wi-Fi network that looks legitimate – for example, Airport_Free_WiFi or Cafe_Guest.
When users connect:
- All their unencrypted traffic can be sniffed.
- The attacker may inject malicious content or redirect users to phishing pages.
- In poorly configured scenarios, even some “secure” traffic might be downgraded or intercepted.
ARP spoofing / ARP poisoning
On local networks, attackers can exploit the Address Resolution Protocol (ARP) to mislead devices about where to send packets.
By associating their MAC address with the IP of the gateway or another device, they can route traffic through themselves and:
- Monitor connections
- Modify data
- Perform SSL stripping or inject malicious content
DNS spoofing / poisoning
By altering DNS responses, attackers can cause victims to resolve a legitimate domain (like bank.com) to an attacker-controlled IP. The site appears correct, but the victim is actually talking to the adversary.
SSL/TLS stripping
In an SSL/TLS stripping attack, an attacker downgrades a connection from HTTPS to HTTP, removing encryption.
For example:
- The user types example.com (without https://).
- The server normally redirects to HTTPS.
- An on-path attacker intercepts the redirect and keeps the session in plain HTTP.
This makes it easier to read or modify traffic, inject malware, or steal credentials.
Email hijacking
In some adversary-in-the-middle scenarios, attackers intercept traffic between a mail client and server. They might:
- Present a fake secure connection
- Read and alter messages
- Inject malicious attachments
This can be used for invoice fraud, BEC, and targeted espionage.
Session hijacking
Even outside reverse-proxy phishing, attackers can sometimes steal session identifiers (cookies, tokens) via:
- Insecure HTTP-only sessions
- XSS vulnerabilities
- Compromised devices or browsers
Once a session ID is stolen, the attacker may be able to impersonate the user without re-entering credentials.
Why AitM Phishing is Surging and Who’s Being Targeted
AitM phishing has become one of the most worrying trends in cybercrime for several reasons.
1. MFA is widespread – but often not phishing-resistant
Many organizations think, “We’ve rolled out MFA, we’re safe.” Unfortunately, not all MFA is equal.
Legacy MFA methods like:
- SMS one-time codes
- Voice calls
- Time-based one-time passwords (TOTP) in authenticator apps
- Push notifications
are phishable. An AitM proxy can capture the code or approval and immediately pass it through to the real service.
Phishing-resistant options like FIDO2 security keys, WebAuthn-based passkeys, and certain device-bound cryptographic authenticators don’t send reusable secrets, and they verify the origin of the website. But adoption is still uneven, and many systems retain backup login options using weaker methods.
2. Cloud is the new perimeter
Attackers no longer need to breach an internal network first. If they can compromise:
- A Microsoft 365 account
- A Google Workspace admin
- A cloud storage account (e.g., file transfer platform, document management system)
they often gain:
- Access to internal communications
- Sensitive client data and contracts
- Configuration of security tools, integrations, and SSO
A single stolen session cookie can be more valuable than an entire malware campaign.
3. Phishing-as-a-service (PhaaS) commoditizes AitM
Well-documented campaigns have shown:
- Tens of thousands of accounts targeted
- Hundreds of large organizations hit in just a few months
PhaaS providers offer:
- Ready-made proxy infrastructures
- Beautiful, localized templates for login portals
- Automation for logging credentials, tokens, and success states
This dramatically lowers the barrier to entry – attackers no longer need deep web development or cryptography skills.
4. High-value targets: who’s in the crosshairs?
While any user can be targeted, AitM phishing often focuses on:
- Executives and board members – for access to strategic communications and to power BEC scams
- Finance and payroll teams – to alter payments, invoices, and banking instructions
- IT and security admins – to take over identity providers, MDMs, and security consoles
- Legal and consulting firms – who hold sensitive client data and valuable documents
- Government agencies and critical infrastructure – for espionage and disruption
- Banks and fintechs – for direct access to money and financial transactions
- E-commerce platforms – to manipulate orders, payouts, or stored payment information
How to Spot Adversary-in-the-Middle Phishing as a User
AitM campaigns are deliberately designed to be almost invisible. The content and UX of the page are usually perfect, because they’re coming from the real site.
That means you can’t rely on obvious giveaways like poor grammar or broken layouts.
Instead, focus on the origin and the context.
1. Real content, wrong origin
The single most important clue:
The site looks exactly right, but the URL is wrong.
Watch for:
- Subtle misspellings: microsft, goggle, paypa1
- Extra or swapped characters: login-microsoftonline.com.security-check[.]com
- Unexpected subdomains or paths that don’t match what you usually see
- Domains that are “almost right” but not exactly the official one
If your Microsoft 365 login doesn’t happen at https://login.microsoftonline.com/ or your Google account doesn’t use https://accounts.google.com/, pause.
2. Saved passwords & passkeys don’t auto-fill
Password managers and passkeys are designed to:
- Only autofill credentials for the exact domain they were saved for.
If you reach a page that looks like your normal login but:
- Your password manager doesn’t offer to fill anything, or
- Your passkeys aren’t being suggested
…it may be because the underlying domain is different.
Treat that as a major red flag.
3. MFA that feels “off”
Signs that something unusual is happening with your MFA flow:
- You’re seeing different MFA methods than usual (e.g., SMS instead of security key)
- The page encourages you to choose a backup method like text message or email code when you normally use passkeys/hardware keys
- You’re prompted to authenticate repeatedly without explanation
- You receive push notifications when you’re not actually trying to log in
Attackers may manipulate the login page to hide phishing-resistant options (like passkeys) – a technique sometimes called Passkey Redaction – and push you toward weaker MFA methods they can intercept.
4. Suspicious emails or messages
Even the best AitM setup still usually starts with a phishing message. Watch out for:
- Unsolicited security alerts demanding immediate login
- Messages with urgent language (“your account will be closed”, “legal action pending”) or emotional pressure
- Links that, when hovered over, reveal odd or mismatched domains
- “From” addresses that are close but not exact (e.g., [email protected])
If in doubt, don’t click the link. Instead:
- Go to the service directly by typing the URL, or
- Use a trusted bookmark.
5. Strange redirects and landing pages
SSO and modern identity flows do use legitimate redirects – that’s normal. But you should still pay attention to where you end up.
Be cautious if:
- You bounce through several odd domains before seeing a login page
- The final landing domain doesn’t match your official identity provider or app
- You see a login prompt where you normally don’t
If something feels off, close the tab and start again from a known-good URL.
How Defenders can Detect and Disrupt AitM Campaigns
From a defender’s perspective (security teams, MSSPs, IT admins), detecting AitM can be challenging – but not impossible.
No single signal will catch everything, so visibility and correlation are key.
1. Email and web security controls
- Deploy advanced email security capable of:
- URL rewriting and time-of-click analysis
- Heuristics for credential-harvesting pages
- Detection of newly registered or suspicious domains
- Use DNS filtering / secure web gateways to block access to:
- Known malicious domains
- Domains with low reputation or obvious typosquatting patterns
2. Monitoring for risky sign-in patterns
Modern identity providers (e.g., Azure AD/Microsoft Entra ID, Google Workspace, Okta) offer rich logs. Use them to detect:
- Logins from unusual IP addresses or geolocations
- Impossible travel (e.g., user logging in from Europe and Asia within minutes)
- Sudden device changes (new OS/browser combinations) immediately after a login event
- Multiple simultaneous sessions from different locations using the same account
Where possible, feed these logs into a SIEM or cloud-native detection stack and write rules for:
- Suspicious token replay
- Sign-ins from known proxy/VPN providers that don’t match the user’s profile
3. Conditional access and risk-based policies
Conditional Access policies can automatically challenge or block risky sign-ins. Consider:
- Requiring strong MFA (e.g., FIDO2/WebAuthn) for:
- Admin roles
- Finance and payroll
- Remote access to sensitive apps
- Blocking logins from:
- High-risk countries or TOR/proxy networks (where appropriate)
- Requiring re-authentication and step-up MFA when:
- Accessing sensitive resources
- Changing security settings or MFA methods
4. Device posture and EDR
If an attacker does gain access, strong endpoint detection and response (EDR) can limit the blast radius.
- Ensure devices (laptops, desktops, smartphones) used for corporate access have an EDR agent installed.
- Use device compliance signals (patch level, disk encryption, OS health) as inputs to conditional access.
5. Threat intelligence and domain monitoring
Security teams should:
- Monitor for lookalike domains targeting their brand or key partners.
- Subscribe to threat intelligence feeds that track active AitM infrastructure and phishing kits.
- Use takedown services where appropriate to remove malicious domains.
Building a Layered Defense Against AitM Phishing
Because AitM phishing attacks target both technology and people, the only effective response is a defense-in-depth strategy.
Think in layers: identity, infrastructure, endpoints, and humans.
1. Strengthen authentication with phishing-resistant MFA
This is the single most important long-term control.
Prioritize migrating critical accounts to:
- FIDO2 security keys (hardware tokens)
- WebAuthn-based passkeys tied to device and origin
- Platform authenticators that bind authentication to the legitimate domain
These technologies:
- Don’t rely on codes that can be intercepted
- Cryptographically verify the website origin
- Are resistant to AitM proxying because authentication challenges are scoped to the true domain, not just what’s displayed in the browser
Minimize “backup” legacy MFA
Even with strong MFA deployed, many services allow:
- SMS codes
- Email-based codes
- Recovery questions
- Paper envelopes or printed one-time codes
Attackers love these backup paths. Where possible:
- Disable legacy MFA methods for high-value users (executives, admins, finance).
- Enforce strict policies: no SMS-only MFA for privileged access.
2. Harden identity and session management
- Set reasonable session lifetimes so stolen cookies have a shorter useful window.
- Enable sign-out from all sessions and make it easy for users to trigger if they suspect compromise.
- Use device binding and IP-based restrictions for highly sensitive applications.
- Monitor for:
- Unusual token reuse
- Tokens being used from different geos or devices than originally issued
3. Secure public and corporate networks
- Prefer encrypted Wi-Fi (WPA2/WPA3) with strong passphrases over open networks.
- Encourage or enforce the use of VPN when users must connect over public Wi-Fi.
- Segment internal networks so that compromise of one segment doesn’t give easy visibility into all traffic.
4. Protect email and collaboration tools
Because so many AitM attacks begin with phishing:
- Deploy mail server security with:
- Anti-phishing and anti-spam filters
- Attachment sandboxing
- URL analysis
- Implement DMARC, DKIM, and SPF to reduce spoofed emails.
- Regularly review rules for auto-forwarding and mailbox delegations (attackers often add these to maintain access).
5. Train and empower users (the human firewall)
Technology alone will not stop AitM. Humans need practical, scenario-based training.
Focus user education on:
- Checking URLs carefully, not just looking for the padlock
- Recognizing when password managers / passkeys don’t autofill, and treating that as a warning
- Spotting suspicious MFA activity, like unexpected prompts
- Using out-of-band verification for money movement (e.g., call the finance team or vendor on a known number)
Make it easy and safe for users to report suspicious messages or logins without fear of punishment.
6. Continuous monitoring, detection, and response
Finally, assume that some AitM attempts will succeed. Your job is to:
- Detect them quickly
- Contain them effectively
Practical steps:
- Pipe identity provider, VPN, and application logs into a central logging or SIEM platform.
- Create detections and playbooks for:
- Logins from new locations
- Sudden admin role assignments
- MFA method changes
- Mass download or exfiltration of data
- Periodically review security incidents and near-misses to refine controls.
Conclusion
Adversary-in-the-middle (AitM) phishing attacks represent a fundamental shift in how attackers go after our accounts. Instead of simply stealing passwords, they target the entire authentication flow – including MFA – and the session that results.
By sitting invisibly between users and legitimate websites, AitM attackers can:
- Proxy and manipulate real login pages
- Capture credentials and one-time codes
- Steal session cookies and tokens
- Walk straight into cloud accounts, email, and business apps as if they were the victim
The good news is that this is not an unsolvable problem. By combining:
- Phishing-resistant MFA and modern identity security
- Network and endpoint protections
- Intelligent detection and response
- Ongoing user education and awareness
organizations and individuals can dramatically reduce the risk and impact of AitM attacks.
Ultimately, defending against adversary-in-the-middle attacks is about recognizing that identity is the new perimeter. Protect that perimeter with strong, origin-bound authentication, layered defenses, and a culture where users are equipped – and encouraged – to question what’s in front of them.
When you treat every unexpected login request and unfamiliar URL with healthy skepticism, you make life much harder for the adversary in the middle.
