Phishing-as-a-Service in India: How to Stop AiTM Attacks Before They Bypass Your MFA

• 02 August, 2026
• No Comments

Multi-factor authentication (MFA) was once considered the gold standard of identity security. Today, an entire criminal industry has grown up around defeating it. Phishing-as-a-Service (PhaaS) platforms such as Evilginx, Modlishka, and their commercial successors now let low-skilled attackers run Adversary-in-the-Middle (AiTM) campaigns that capture session cookies in real time, effectively rendering SMS OTP and even time-based authenticators useless. Indian enterprises—particularly those in banking, insurance, and IT services—are prime targets. This post examines how AiTM phishing works, what the Indian threat landscape looks like in 2025, and the concrete controls that actually stop these attacks.

What Is Adversary-in-the-Middle (AiTM) Phishing?

Classic phishing tricks a user into handing over their password on a fake login page. AiTM goes further: the attacker operates a reverse proxy that sits between the victim’s browser and the legitimate identity provider. When the victim types their credentials and completes MFA on the attacker’s proxy site, the proxy relays those credentials to the real site—obtaining a valid, authenticated session token. That token is then stolen and replayed by the attacker from a different device entirely, with MFA already satisfied.

The result: the victim sees a normal login experience. The attacker gains a fully authenticated session—usually a cloud email, SaaS application, or corporate VPN portal—without ever knowing the password again.

PhaaS Platforms Lower the Bar Dramatically

A decade ago, running a convincing reverse-proxy phishing campaign required significant technical skill. Commercial PhaaS kits have collapsed that barrier. An attacker can rent infrastructure, choose from a library of pre-built lure templates (including bank portals, Microsoft 365 login pages, and GST filing portals popular in India), and launch a campaign targeting thousands of corporate mailboxes in under an hour. Detection-evasion features—rotating domains, Cloudflare-hosted proxies, CAPTCHA challenges to block security scanners—are bundled in.

The Indian Enterprise Exposure

India’s digital transformation has outpaced its identity security maturity in many sectors. Several factors amplify AiTM risk for Indian organisations:

• Microsoft 365 and Google Workspace dominance: Both platforms are high-value targets and have well-documented PhaaS lure kits.
• SMS OTP still widely deployed: Telecom-delivered OTPs are trivially bypassed by AiTM because the proxy relays the OTP challenge in real time.
• Remote and hybrid work: Staff accustomed to logging in from multiple networks are less likely to notice an unfamiliar domain.
• Spear-phishing via known-sender compromise: Once an attacker steals one session token and gains inbox access, they send the AiTM lure from the victim’s own address, dramatically lifting click rates within the same organisation.
• CERT-In and RBI regulatory pressure: Breaches originating from credential theft fall squarely within the CERT-In 6-hour reporting obligation, amplifying the operational and reputational cost of a successful attack.

Why Traditional MFA Fails Against AiTM

It is important to be precise about what MFA does not protect against. TOTP codes, SMS OTPs, and push-notification approvals all authenticate a single point in time. Once the proxy relays that authentication to the real identity provider and captures the resulting session cookie, the credential is spent and the attacker holds an authenticated token that is good until it expires—typically hours or days for cloud email sessions.

The controls that do resist AiTM are those that bind authentication to a specific cryptographic context or device:

• FIDO2 / Passkeys: The authenticator signs a challenge that includes the origin domain. An attacker proxying from a spoofed domain receives a signature that is cryptographically invalid for their domain—the credential cannot be replayed.
• Certificate-based authentication (CBA): Client certificates issued to managed devices achieve similar binding.
• Conditional Access with device compliance: Enforce that only devices enrolled in your MDM with current patch posture can receive tokens.

Detection Signals That Actually Surface AiTM Activity

Even with strong authentication controls, detection layers matter—both for catching gaps in coverage and for meeting CERT-In incident reporting timelines. AiTM campaigns leave characteristic signals:

Identity and Access Logs

• Impossible travel / token replay: A session authenticated from Chennai at 14:00 IST, with a new access event from Eastern Europe thirty minutes later using the same session token.
• User-agent mismatch: The original authentication came from Chrome on Windows; subsequent API calls carry a different user-agent string (the attacker’s tooling).
• Inbox rule creation immediately post-login: Attackers frequently create mail-forwarding or deletion rules within minutes of gaining access to hide their activity and intercept password-reset emails.

Network and Proxy Logs

• Domain lookalike resolution: DNS logs showing staff devices resolving domains that are visually similar to corporate identity providers (e.g., login.microsoftonIine.com with a capital I instead of l).
• Certificate transparency anomalies: Fresh TLS certificates for lookalike domains, often issued within 24 hours of campaign launch.
• Referer chains: A click from a corporate mail client leading to an intermediate redirect domain before the real identity provider.

A Practical AiTM Defence Checklist for Indian IT Leaders

The following steps can be implemented in a phased roadmap. Phases 1 and 2 address the highest-impact controls; Phase 3 extends coverage for mature security programmes.

Phase 1 — Immediate (0–30 days)

• Audit your MFA deployment: identify any users or service accounts still on SMS OTP or email OTP and begin migration to authenticator apps as an interim step.
• Enable sign-in risk policies in your identity platform (Microsoft Entra ID or Google Workspace) to flag impossible travel and unfamiliar sign-in properties.
• Deploy URL rewriting and link-time scanning in your email gateway (FortiMail’s anti-phishing engine is a strong choice) to catch lookalike domains at click time.
• Block legacy authentication protocols (IMAP, POP3, SMTP AUTH without modern auth) which bypass MFA entirely.

Phase 2 — Short-term (30–90 days)

• Roll out FIDO2 security keys or platform passkeys for all privileged accounts (IT admins, finance, HR).
• Implement Conditional Access policies requiring device compliance for cloud application access.
• Onboard identity logs (Entra ID sign-in logs, Google Workspace activity) into your SIEM with correlation rules targeting the impossible-travel and inbox-rule-creation patterns described above.
• Run a phishing simulation specifically using an AiTM-style proxy to measure staff susceptibility before and after training.

Phase 3 — Medium-term (90–180 days)

• Extend FIDO2 to all staff, not just privileged accounts.
• Deploy DNS-layer filtering with RPZ (Response Policy Zones) or a cloud DNS security service to block lookalike domain resolution at the network level.
• Integrate Certificate Transparency monitoring to receive alerts when lookalike domains obtain TLS certificates.
• Conduct a tabletop exercise simulating a successful AiTM compromise to validate your incident response runbook and CERT-In 6-hour reporting capability.

FortiGate and FortiMail: Layered Controls at the Network Edge

Identity-layer controls are necessary but not sufficient. Network-level defences catch campaigns before credential theft occurs. At PJ Networks, we deploy FortiGate Next-Generation Firewalls with deep packet inspection enabled for outbound HTTPS to enforce SSL certificate inspection of corporate browsing, allowing us to inspect traffic to lookalike domains even when they carry valid certificates.

FortiMail provides multi-layer email security—anti-phishing heuristics, URL rewriting, sandboxed URL analysis, and FortiGuard threat intelligence integration—to intercept AiTM lure emails before they reach staff mailboxes. When both layers work together and are tuned with current threat intelligence, the attack surface for AiTM campaigns narrows significantly.

Combined with FortiClient Endpoint Security for device posture enforcement and FortiAuthenticator for strong MFA management, the Fortinet Security Fabric gives Indian enterprises an integrated architecture that addresses AiTM at every layer: email, network, endpoint, and identity.

PrahiX Ora: Unified SecOps Visibility to Detect What Gets Through

Even the best preventive controls are defeated by a determined attacker eventually. The question is how quickly your operations team detects and responds to a successful AiTM session hijack—a question that becomes legally significant under CERT-In’s 6-hour reporting direction.

PrahiX Ora is a unified SecOps platform built by PrahiX Tech Pvt Ltd. PJ Networks is its primary field deployment and operations partner, and we deploy and operate it for clients across India. Ora brings four integrated pillars together:

SIEM: Correlation That Finds the Needle

Ora’s SIEM ingests logs from identity providers, FortiGate firewalls, FortiMail, endpoint agents, and cloud audit trails into a single correlation engine. Attack storylines are reconstructed using graph-based analysis mapped to the MITRE ATT&CK framework—so an analyst sees not just “suspicious sign-in” but the full chain: lure email delivered → link clicked → authentication from new geography → inbox rule created → email exfiltration attempted. Tiered retention (hot, cold, and archive tiers) addresses CERT-In’s direction on 180-day in-country log retention, keeping forensic evidence available without runaway storage costs.

NMS: Seeing Across the Estate

AiTM campaigns often target organisations with fragmented NOC visibility—where the SOC sees identity logs but not network-layer DNS queries, or vice versa. Ora’s NMS provides unified observability across FortiGate firewalls, managed switches, wireless access points, and WAN/SD-WAN links from a single pane. LLDP/CDP topology discovery builds an accurate network map automatically; network path tracing helps analysts confirm whether suspicious traffic actually transited corporate infrastructure. For organisations running multi-vendor estates across multiple sites—common in Indian manufacturing, retail, and financial services—this eliminates the blind spots that attackers exploit.

Video Surveillance (VMS): Physical and Cyber Under One View

AiTM attacks are purely digital, but insider threat scenarios—where a compromised staff member assists external attackers—sometimes have a physical component. Ora’s video surveillance (VMS) pillar integrates ONVIF, Hikvision, and Dahua camera streams with video analytics under the same operations console, allowing security teams at manufacturing facilities, retail chains, and multi-site corporate campuses to correlate physical access events with network activity. A server room access event at 03:00 alongside an anomalous sign-in from an internal IP is a very different risk posture than either event in isolation.

SOAR: Making the 6-Hour Window Realistic

CERT-In’s 6-hour incident reporting window sounds achievable in theory; in practice, manual triage, escalation, and evidence gathering routinely consume that entire window before a report is drafted. Ora’s SOAR capability changes the equation with playbook automation. Pre-built connectors include direct integration with FortiGate—allowing the platform to push blocklists and isolate suspected attacker IP ranges automatically within minutes of a confirmed AiTM indicator. Pre-built playbook templates cover credential-theft scenarios: session revocation, forced MFA re-enrolment, inbox rule removal, and evidence packaging for the CERT-In report. The time between detection and containment shrinks from hours to minutes, making the reporting obligation achievable rather than aspirational.

If you are evaluating a unified SecOps platform for your Indian operations, we are happy to walk you through an Ora demonstration in the context of your current environment. Visit ora.prahix.com to explore the platform’s public capability documentation.

Building Your AiTM Incident Response Runbook

A detection capability without a tested response process fails at the worst moment. The following runbook outline covers a confirmed AiTM session hijack:

1. Containment (T+0 to T+15 minutes): Revoke all active sessions for the affected account across all connected applications. Reset credentials and force re-enrolment in MFA. If SOAR is deployed, this can be triggered automatically from the initial detection alert.
2. Evidence preservation (T+0 to T+30 minutes): Snapshot sign-in logs, inbox rule history, mail flow logs, and any exfiltrated-mail indicators. Do not delete—preserve for forensics and CERT-In reporting.
3. Scope assessment (T+15 to T+60 minutes): Determine whether the attacker pivoted from the compromised account to other accounts (via lateral phishing from the victim’s mailbox), accessed sensitive data, or established persistence mechanisms (OAuth app consents, forwarding rules to external addresses).
4. CERT-In notification (T+0 to T+6 hours): File the initial report with CERT-In even if investigation is incomplete. CERT-In expects an initial report within 6 hours and accepts follow-on updates. Do not delay reporting while waiting for full scope clarity.
5. Post-incident review (T+48 to T+72 hours): Document the initial attack vector, detection time, dwell time, and containment actions. Update phishing awareness training and Conditional Access policies based on findings.

Conclusion: MFA Is Not Enough—But the Gaps Are Closeable

The rise of PhaaS platforms means that MFA alone is no longer sufficient to protect Indian enterprise identities. Adversary-in-the-Middle techniques have commoditised session hijacking to the point where any organisation relying on SMS OTP or TOTP as its sole second factor should treat credential compromise as a matter of when, not if.

The path forward combines phishing-resistant authentication (FIDO2/passkeys), network-level controls (FortiGate SSL inspection, FortiMail anti-phishing), and a unified SecOps platform capable of detecting session anomalies and automating response fast enough to meet CERT-In’s reporting requirements. None of these controls is individually sufficient; together, they close the gaps that AiTM exploits.

PJ Networks helps Indian enterprises design, deploy, and operate the full stack of controls described here—from FortiGate NGFW and FortiMail at the perimeter, to ZTNA for remote access, to 24/7 NOC/SOC operations running on the PrahiX Ora platform. If AiTM phishing is a concern for your organisation—or if a recent incident has raised the question—we invite you to contact our team for a no-obligation architecture review.