Module 2 · Phishing — AiTM, MFA Bypass, and the 2026 Defender Stack

Why this module exists. Email-borne phishing is no longer “click this link, enter password.” Modern kits proxy the entire login flow, capture session cookies post-MFA, and let the attacker step into the authenticated session. The defender’s playbook has evolved correspondingly. This module is the current state.

The 2026 attacker playbook

The modern phishing kit is not a static credential-harvest form. It is an Adversary-in-the-Middle (AiTM) reverse proxy:

1. Victim clicks the phishing link.
2. The phishing kit fetches the real login page from Microsoft, Google, or the target SaaS.
3. Victim sees the real page rendered through the kit’s proxy.
4. Victim enters credentials. Kit forwards to the real provider, captures the credential.
5. Provider sends MFA challenge. Victim completes it through the kit.
6. Provider returns a session cookie. Kit captures the cookie and forwards a success page to the victim.
7. Attacker now has a valid session cookie. MFA is bypassed without ever breaking it.

EvilGinx, Modlishka, and Muraena are the open-source toolkits. Commercial phishing-kits-as-a-service sell pre-configured AiTM templates for $50-200/month per target brand.

The signal — what AiTM phishing leaves behind

• Unusual login origin. The session cookie was obtained from the phishing-kit’s hosting IP, not the user’s expected geography. Microsoft Entra ID’s “Impossible Travel” risk detection catches some; signal degraded if the attacker proxies again through the victim’s country.
• Hostname mismatch in DNS / URL bar. The phishing site uses a homoglyph or near-match domain (login.micros0ft.com instead of microsoft.com). Defender: enforce TLS pinning where possible, train users on URL hygiene.
• Session-cookie age anomaly. The cookie was issued seconds ago but is being used from a different network ASN.

DMARC, DKIM, SPF — the email-authentication stack

The end state every Indian enterprise should reach: p=reject in DMARC. The journey: start at p=none with reporting on, monitor reports for legitimate-mail-being-rejected senders, fix them, escalate to p=quarantine, then p=reject. Most domains stall at p=none forever because nobody owns the migration.

Anti-phishing platforms — what they actually buy you

Mimecast, Proofpoint, Microsoft Defender for Office 365, Google Workspace Advanced Security. Capabilities:

• URL rewriting — links in inbound mail get rewritten to a scanner-checked URL.
• Attachment sandboxing — detonate every PDF/Office attachment in a sandbox before delivery.
• Display-name spoofing detection — block mail where the From display name matches your CEO but the underlying address is external.
• Business-email-compromise pattern detection — money-movement keywords in mail from new sender domains.

The capability is real, but coverage is partial. AiTM kits using newly-registered domains and benign-looking link patterns bypass most filters. Defender depth = anti-phishing platform + DMARC + user training + phishing-resistant MFA.

FIDO2 / Passkeys — the structural fix

Phishing-resistant MFA (FIDO2 security keys, platform passkeys) is the only authentication that does not break under AiTM. The credential is bound to the legitimate domain cryptographically; a phishing site cannot relay the FIDO challenge because the browser scopes it to the visited origin.

Deploy in priority order: privileged accounts (admins, finance) first, then customer-facing engineers, then full workforce. The transition takes 12-18 months in a 1000-person org. Start at the top of the privilege pyramid.

Training that works — and what does not

• Does not work: annual one-hour video, generic phishing examples, “click rate” as the metric.
• Works: targeted simulations every 4-6 weeks, custom-crafted to look like the kinds of phish that actually land in your inbox (your DMARC reports tell you what those are), follow-up coaching for repeat clickers, “report phish” button with rapid SOC feedback (“yes that was real, thank you”).
• Metric to watch: time-to-first-report. The faster someone in the org reports a real phish, the faster the SOC blocks it for everyone. Drive this number down.

India-specific considerations

• SMS-OTP phishing. Indian banks heavily use SMS-OTP for transaction approval. Attackers harvest both credentials and OTPs through AiTM, then complete fraudulent transactions in real time. The structural fix is moving banks off SMS-OTP to app-based push approvals.
• WhatsApp pretext. Indian-language WhatsApp messages impersonating senior management (“urgent, send vendor payment details”) bypass corporate email filters entirely. Awareness training has to extend to messaging platforms.
• Regulator-impersonation phish. RBI, SEBI, MeitY impersonation phish to finance teams. Defender: route all regulator communication through pre-known channels; verify out-of-band.

Key takeaways

• Modern phishing is AiTM reverse-proxy, MFA-bypass via session-cookie theft.
• DMARC at p=reject is the email-authentication end state; most orgs stall at p=none.
• Anti-phishing platforms help but do not catch AiTM with new domains; defence-in-depth required.
• FIDO2 / passkeys are the only phishing-resistant MFA; deploy top-of-pyramid first.
• Training works only with targeted simulations + fast SOC feedback + “time-to-report” as the metric.