AiTM Phishing in 2026 — How EvilProxy, Mamba, Tycoon, and Astaroth Defeat Microsoft 365 MFA

If your security awareness training still teaches “look for misspelled URLs in phishing emails,” it is teaching a 2015 threat model. Modern phishing kits proxy your real bank or Microsoft 365 login page, capture your password AND your MFA approval, and replay your authenticated session — all in real time, from a domain that looks plausible if you don’t read carefully. The defence is not better awareness; it is moving to phishing-resistant authentication.

How AiTM phishing actually works

The classic phishing kit cloned the target login page, captured the password, and tried to reuse it. MFA defeated this — the attacker had the password, but the session also needed an OTP that they couldn’t get.

AiTM kits flip the model. The attacker’s site is a real-time reverse proxy to the legitimate login page:

1. Victim clicks a phishing link to microsft-365-secure.com/auth.
2. Victim sees the real Microsoft 365 login page — because the attacker’s server is fetching it live and serving it through.
3. Victim types email; the proxy forwards to real Microsoft, gets the password prompt, shows it.
4. Victim types password; proxy forwards. Real MS asks for MFA.
5. Victim approves the push notification on their phone (or types OTP). Real MS issues a session cookie.
6. Proxy intercepts the session cookie. Attacker now has it.
7. Proxy displays a fake “Login successful, redirecting…” page; victim never realises anything wrong happened.
8. Attacker imports the cookie into their own browser → instant authenticated session as the victim, valid for the cookie’s lifetime (typically 24 hours).

The session cookie bypasses MFA because MFA already happened. The attacker is the legitimate session.

Active kits and operators (2024-2026)

EvilProxy — the original commercial service, ~$400/week subscription. Targets Microsoft, Google, Yahoo, Apple, Twitter logins. Sold openly on Russian-language forums.

Mamba 2FA — newer (2024), targets Microsoft 365 specifically. Bypasses MFA via push approval interception. Sells for $250/month.

Tycoon 2FA — Telegram-distributed, focuses on Microsoft + Google. Anti-bot screening (Cloudflare Turnstile) to keep researchers out of the kit infrastructure.

Astaroth — late 2024 entrant, distinguishes by including “session cookie monetisation” — automatically syncing captured sessions to a Telegram channel where buyers bid on access.

Why this targets Indian SaaS companies

The economics: Microsoft 365 + Google Workspace are the SaaS layer for ~95% of Indian product companies above seed stage. Most Indian SMBs and even Series B startups configure Microsoft Authenticator push as their only MFA factor. AiTM kits work against push approval. Indian companies have lower adoption of Conditional Access policies, FIDO2 keys, and number-matching-on-push than Western peers — making them disproportionately easier wins for AiTM operators.

Documented Indian victims (BleepingComputer + threat-intel feed reporting): IT services firms, healthcare aggregators, education-tech companies, fintech-adjacent startups. Common breach pattern: AiTM-stolen Microsoft 365 admin session → mailbox rule auto-forwards finance email to attacker → invoice fraud / wire-fraud / customer impersonation.

Detection — what your tenant logs reveal

Every AiTM session leaves fingerprints in Microsoft Entra ID (formerly Azure AD) logs:

• Sign-in from a new device immediately after a successful sign-in from the user’s normal device — concurrent sessions with different fingerprints.
• Source IP geographically anomalous — typically a US/EU VPN or hosted-VPS IP for the AiTM server, while the user’s real session IP is in India.
• User agent mismatch — AiTM proxy often forwards a slightly different UA string than the user’s actual browser.
• Token claims — KQL hunt for sign-in events where UserAgent or DeviceDetail changes within seconds of authentication.

Microsoft Sentinel KQL hunt:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| extend asn = tostring(LocationDetails.countryOrRegion)
| summarize logins=count(), distinct_ip=dcount(IPAddress), distinct_asn=dcount(asn)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where distinct_asn > 1 and logins > 2

Any user authenticating from 2+ countries within an hour after MFA approval is investigation-worthy.

The defence — phishing-resistant authentication

SMS OTP, TOTP, Microsoft Authenticator push, even number-matching push are all defeatable by AiTM. The categorical fix is phishing-resistant MFA:

1. FIDO2 / WebAuthn — the authenticator binds to the actual origin; a phishing site at a different domain cannot use the same passkey. Hardware: YubiKey, Google Titan, Apple/Google passkeys synced via iCloud/Google Password Manager.
2. Certificate-based authentication (CBA) — Microsoft Entra supports CBA on managed devices. Cert + private key in TPM, never sent to the auth server, cannot be replayed.
3. Conditional Access — require compliant device + corporate network for admin roles. Even if cookie is stolen, attacker’s non-compliant device fails the policy.
4. Continuous Access Evaluation (CAE) — when Entra detects sign-in anomalies, sessions can be revoked mid-flight, not just at next token refresh.
5. Risk-based sign-in policies — Entra’s sign-in risk and user risk signals integrate well with Conditional Access; high-risk sign-ins force re-auth with FIDO2 even if MFA already passed.

Migration path for Indian organisations

1. Week 1 — issue YubiKey 5 NFC (or equivalent) to every administrator. Enable FIDO2 on Entra ID. Require FIDO2 for Global Admin, Conditional Access Admin, Security Admin roles.
2. Week 2-4 — deploy Conditional Access policies: block sign-in from non-compliant devices for admin roles; require FIDO2 for Office 365 admin portals, Azure Portal, AWS console SSO, GitHub/GitLab admin.
3. Month 2 — pilot passkey rollout for end users via Microsoft Authenticator passkey support. Most users adopt within 60 days if you remove the SMS-fallback option.
4. Month 3-6 — phase out SMS OTP entirely. SMS-based authentication is the lowest-cost path for AiTM operators; eliminating it removes the easiest attack.
5. Ongoing — quarterly review of sign-in logs for AiTM patterns; threat-hunt above query as a scheduled rule.

FAQ

What about Microsoft Authenticator’s number matching — is that phishing-resistant?

Better than push-approve-anywhere, not phishing-resistant. The AiTM proxy displays the number it gets from the legitimate sign-in attempt; victim types it on their phone, attacker passes it through. Same outcome. Number matching defeats accidental MFA fatigue, not real-time AiTM proxies.

Are Google passkeys safe against AiTM?

Yes for Google itself — passkeys bind to accounts.google.com origin; phishing site at g00gle-secure.com cannot use the same passkey. Same protection for Microsoft passkeys against MS phishing. The catch: only works for the specific service. SaaS apps that don’t support passkeys still vulnerable.

Will FIDO2 hurdle our remote-employee productivity?

Brief friction: setting up first key takes 5 minutes per user. Long-term: faster login than typing-and-OTP. Modern hardware keys with NFC tap to phone are quicker than SMS OTP. The “FIDO2 is friction” claim is largely outdated; pilot on yourselves first.

What’s the cost of YubiKey deployment in India?

YubiKey 5 NFC: ~$50 USD (₹4,200) per key. Recommend two keys per admin (one primary, one backup) — ₹8,400 per admin. For a 200-person company with 30 admins: ~₹2.5 lakh hardware spend. Cheaper than one mid-size AiTM-driven invoice fraud incident.

Is conditional-access alone enough without FIDO2?

Conditional Access requiring compliant device blocks attacker’s non-compliant browser. Strong defence. But token-replay attacks from the user’s own compromised device defeat it; FIDO2 + CAE is the higher bar.

⚖️ Legal: AiTM phishing platforms exist publicly on the internet, but operating one against any organisation you don’t have authorisation from is unauthorised access (IT Act §66) plus identity theft (§66C) plus impersonation for cheating (§66D). Pen-testing AiTM scenarios for your own org requires written consent from leadership; we can scope and run such an exercise — see /services/.