For years, “enable MFA” was the one-step answer to email security. Add multi-factor authentication, and your accounts were safe. That logic held for a while. But in 2024, the game changed — permanently.

Microsoft Threat Intelligence has tracked AiTM (Adversary-in-the-Middle) phishing campaigns since September 2021, targeting more than 10,000 organizations. By 2024, these campaigns had shifted almost entirely from credential harvesting to proxy-based interception — capturing session cookies in real time, bypassing every MFA method that can’t bind authentication to the real domain.

The catalyst: Phishing-as-a-Service (PhaaS) toolkits. EvilProxy launched in 2022 at $400/month. Evilginx — the open-source version — made AiTM accessible to anyone. By 2025, Tycoon 2FA was generating 13 million+ malicious emails per month, according to Microsoft Defender for Office 365 data. Other kits like Mamba 2FA, NakedPages, Storm-1167, and Sneaky 2FA added to the arsenal.

The numbers are stark:

This isn’t a theoretical risk for enterprises. SMBs are primary targets — you have fewer security tools, less visibility, and attackers know it. The same PhaaS kit that targets a Fortune 500 CFO also targets a 35-person accounting firm controller.

This guide breaks down exactly how AiTM works, why your current MFA setup likely isn’t enough, and the practical 7-point defense checklist any SMB can act on this week.

How AiTM Phishing Works in 90 Seconds

Standard phishing: attacker creates a fake login page, user types password, attacker steals password. MFA stops this — the attacker doesn’t have the second factor.

AiTM changes the equation. Here’s the sequence:

1. Phishing email lands in inbox. It impersonates Microsoft, Google, DocuSign, or a trusted vendor. It contains a link to what looks like a legitimate login page. By 2024, these emails often route through legitimate services (SharePoint, OneDrive) to bypass email filters.

2. Victim clicks the link. They land on a phishing page controlled by the attacker — but it doesn’t look fake. It looks exactly like Microsoft’s real login page, because it is loading Microsoft’s real login page. The attacker’s server is sitting in the middle, proxying traffic back and forth in real time.

3. User enters credentials and approves MFA. Everything the user types — password, OTP code, push approval — is relayed in real time to Microsoft’s actual servers. The MFA challenge completes successfully. Microsoft issues a session cookie.

4. The attacker captures that session cookie. The session cookie proves to Microsoft: “This person already authenticated.” The attacker copies it into their own browser. Now they have a valid, authenticated session — no password needed, no MFA prompt triggered.

5. Attacker logs in as the user. They access the inbox, contacts, files, vendor payment portals, anything connected to that account. MFA is bypassed, and the victim has no idea it happened.

The key insight: AiTM doesn’t break MFA’s cryptography. It exploits how MFA is used. Standard MFA (SMS, TOTP, push approvals) relies on the user completing an authentication step on whatever page they’re on. If that page is attacker-controlled, the attacker receives the same authentication response the real site does.

Source: Microsoft Threat Intelligence Center (MSTIC), “From cookie theft to BEC: attackers use AiTM phishing sites as entry point to further financial fraud,” Microsoft Security Blog, July 2022 — technique now industrialized via EvilProxy, Tycoon 2FA, Mamba 2FA, and other PhaaS kits.

Real SMB Walkthrough: The Alden CPA Firm Incident

This is a fictional scenario, but it’s built from real attack patterns. Names are changed.

The company: Alden & Associates, a 35-person CPA firm in Columbus, Ohio. Tax season. Controllers, managers, and partners all on Microsoft 365.

The attack timeline:

Monday, 11:47 AM — Controller Karen Marsh opens an email: “Microsoft 365 Security Alert: Your mailbox has been placed in quarantine pending review.” The sender is no-reply@microsoft-365-quarantine.help. The email has Microsoft’s logo. It says she’s received 14 messages that have been held — click to release them.

Karen clicks. It takes her to what looks like microsoft365.com/signin. She enters her email. The page loads a real Microsoft login. She enters her password. A Microsoft Authenticator prompt appears — “Approve sign-in.” She approves it. Microsoft issues the session cookie.

The attacker has already captured it.

Monday, 12:15 PM — The attacker logs into Karen’s Microsoft 365 from a VPS in Eastern Europe. They immediately export the global address list — all employees, their roles, their email patterns. They check Karen’s email rules. They find the firm uses ACH for wire transfers. They find vendor emails with banking details on file.

Monday, 1:30 PM — The attacker registers a lookalike domain: @alden-cpa-financial.com. They send an email to the AP clerk, impersonating a long-time client (their real emails are in Karen’s sent folder): “We’re updating our banking info for the Q2 retainer. New account below.” The email is polite, brief, timed to look normal.

Tuesday, 9:00 AM — The AP clerk processes the wire: $185,000 to the “client’s” new account. She confirms via the email reply chain.

Tuesday, 2:00 PM — The real client calls asking why their invoice hasn’t been paid. The AP clerk says it was paid yesterday. The call goes to Karen. Karen checks her email — no record of the client’s banking change request.

The attacker had set up a rule in Karen’s inbox to delete any incoming emails from the real client’s domain.

Total losses: $185,000 wired out. $22,000 in forensic accounting fees. $8,500 in legal costs. Client relationships damaged. Cyber insurance claim filed.

The attacker spent approximately $150 on tooling — a one-month EvilProxy subscription. The firm lost $215,500.

Quick Test

Could your team pass a phishing simulation?

Most SMB teams don't know how bad their phishing exposure is until an attack succeeds. Take 3 minutes to get a real-world baseline of your team's detection ability.

Take the 60-Second Phishing IQ Quiz →

Why Standard MFA Fails Against AiTM

MFA works by adding a second check: something you know (password) plus something you have (phone, authenticator, key). The problem is what is being checked — and in standard MFA, it’s not bound to where you’re logging in.

Here’s what each common MFA method does — and doesn’t — protect against:

MFA Method Stops Password Theft Stops AiTM Cookie Theft
SMS OTP ✅ Vulnerable
TOTP (Authenticator app) ✅ Relayed in real time
Push notification ✅ Proxiable
Hardware security key (FIDO2) ✅ ✅ Origin-bound
Passkey / WebAuthn ✅ ✅ Origin-bound
PIV/CAC smartcard ✅ ✅ Cryptographic binding

SMS OTP, TOTP, and push notifications are all vulnerable — not because they’re badly designed, but because the authentication response (the code you type, the approval you click) is transmitted to whatever site is asking. An AiTM proxy in the middle receives the same response as the legitimate site, and forwards it on. Both complete successfully.

What makes FIDO2/WebAuthn different: Instead of transmitting a code that can be intercepted, the authenticator performs a cryptographic operation that is bound to the origin domain of the legitimate service. When a FIDO2 key signs an authentication challenge, the signature is only valid for that specific domain. A phishing proxy on a different domain receives a cryptographic response that fails validation — and authentication is denied.

Source: CISA, “Implementing Phishing-Resistant MFA” Fact Sheet, 2024 — explicitly names FIDO2/WebAuthn as the only phishing-resistant MFA methods; all others (OTP, SMS, push) are classified as vulnerable.

Source: NIST SP 800-63B — FIDO2/WebAuthn meets Authenticator Assurance Level 3 (AAL3) when implemented with hardware authenticators.

Detection Signals Your SMB Team Can Actually Check

You may not have a SOC, but you can check these signals in Microsoft 365 or Google Workspace admin consoles — in under 20 minutes:

1. Unusual sign-in locations — Check the sign-in logs for any login from a country where you don’t do business. AiTM attackers typically operate from VPS infrastructure in Eastern Europe, Southeast Asia, or the Middle East.

2. Impossible travel — A user logs in from New York at 9 AM and from London at 10 AM. That’s physically impossible. Microsoft Entra ID flags this automatically — but check your conditional access policies are enforcing it, not just auditing it.

3. New session cookies on unrecognized devices — Look for “first time device” sign-ins in your admin portal. AiTM attacks often use a device the real user has never used — check if the browser fingerprint, OS version, or IP range looks off.

4. Mailbox rules you didn’t create — Immediately after an AiTM compromise, attackers often set up inbox rules to delete emails from specific domains (e.g., your client’s real domain) or forward copies to an external address. Check this weekly — it’s the fastest way to catch an active session hijack.

5. OAuth app consent anomalies — Check which third-party apps have been granted access to your M365 or Google Workspace tenant. AiTM attackers sometimes use OAuth to maintain persistence even after the initial session expires.

Source: MITRE ATT&CK Technique T1539 — Steal Web Session Cookie.

How to access these logs:

7-Point SMB Defense Checklist

1. Migrate high-risk accounts to phishing-resistant MFA (FIDO2 or passkeys) — Prioritize: CEO/CFO/admin accounts, anyone with access to financial systems or wire transfers, anyone with access to your primary email tenant. CISA recommends starting with email, cloud admin, and financial access. FIDO2 keys (YubiKey, Google Titan, etc.) cost $20–$70 each — not expensive at this scale.

2. Implement conditional access policies — Require phishing-resistant MFA for sensitive sign-ins. Block sign-ins from high-risk countries. Require compliant devices. In Microsoft Entra ID, this is under Security → Conditional Access. Set it and forget it — it runs automatically.

3. Harden session timeouts — Reduce session validity windows. Configure continuous access evaluation (CAE) so that policy changes (new location, new device) trigger re-authentication on active sessions, not just new ones.

4. Train your team on URL inspection — specifically — Generic “don’t click suspicious links” training misses AiTM. Train your team specifically on: hover to check the domain before logging in, check the address bar after the login page loads, never enter credentials from an email link — navigate directly to the service instead.

5. Enforce DMARC on your domain — DMARC prevents attackers from spoofing your domain in phishing emails. Set your policy to “quarantine” or “reject.” Most email providers make this available in their admin console. This protects your team from spoofed emails using your own domain.

6. Enable browser-level link protection — DNS filtering at the browser or network level can block known phishing domains before your team reaches them. Tools like Cloudflare Gateway, Cisco Umbrella, or even browser extensions for high-risk users add a layer between the email click and the malicious page.

7. Build an incident response playbook for compromised accounts — Know what to do before it happens. If an account is compromised: (a) revoke all active sessions immediately, (b) check and remove any mailbox rules the attacker created, (c) reset MFA — including removing any authenticator app the attacker may have enrolled, (d) audit OAuth app permissions, (e) check all financial accounts for unauthorized changes, (f) file a report at IC3.gov within 24 hours if funds were transferred.

The Bottom Line

MFA is still essential. It blocks the vast majority of credential-based attacks. But in 2026, “MFA enabled” is not the same as “account protected.” AiTM attacks are the adversary’s response to widespread MFA adoption — and they’ve industrialized it to the point where a $150 monthly subscription can drain a mid-sized firm’s operating account.

The good news: the fix is achievable for SMBs. Phishing-resistant MFA (FIDO2 keys or passkeys) for your highest-risk accounts, layered with conditional access, session hardening, and basic detection logging, closes the gap that AiTM exploits. It doesn’t require a Fortune 500 budget. It requires prioritization.

CTA Block

Ready to close the gap?

SecurEveryone runs live, instructor-led phishing defense training built around the techniques SMBs actually face — including AiTM and BEC. No pre-recorded videos. Real scenarios, real responses.

Quick Test

Could your team pass a phishing simulation?

Most SMB teams don't know how exposed they are until an attack succeeds. Take 3 minutes to get a real-world baseline of your team's detection ability.

Take the 60-Second Phishing IQ Quiz →