For years, multi-factor authentication (MFA) has been the security world’s favorite answer to “what should we do about phishing?” But attackers don’t wait for the controls to get better—they evolve around them. Enter the mid-stage adversary: a new class of attacker that’s rapidly scaling intrusions with help from phishing-as-a-service (PhaaS) platforms and adversary-in-the-middle (AiTM) toolkits. These actors aren’t writing custom malware or launching zero-days. They’re using open-source tooling and commercial phishing kits that steal session tokens, bypass MFA, and let them walk straight into your cloud infrastructure.
This blog covers:
- Who mid-stage adversaries are, and how they differ from typical opportunistic or advanced threats
- A technical breakdown of how AiTM phishing works using tools like Evilginx2 and commercial kits like Typhoon 2FA
- Why traditional MFA isn’t cutting it anymore
- How to actually detect and defend against these threats
If you’re still assuming MFA is enough, it’s time to update your threat model.
Who Are Mid-Stage Adversaries?
Mid-stage adversaries sit in the operational sweet spot of cybercrime. They’re not smashing their heads against firewalls or hoping for luck. They’re strategic. They’re fast. And they’re leveraging a growing supply chain of cybercrime infrastructure to scale access and impact without needing deep technical capability.
They rely on:
- Initial Access Brokers for compromised credentials or entry points
- Phishing-as-a-Service platforms for MFA-bypassing campaigns
- Off-the-shelf tooling like Evilginx2, Modlishka, and custom loaders
- Common cloud services for staging and C2 (think Dropbox, Discord, and Notion)
Their objective is straightforward: get in, blend in, and escalate. Whether it’s ransomware deployment, business email compromise (BEC), or credential resale, they’re operating with maturity—and that makes them increasingly difficult to detect early.
They’re also part of a broader trend: the professionalization of cybercrime. They’re organized. They’re collaborating. And thanks to tools like Typhoon and Evilginx2, they don’t have to build their own infrastructure anymore.
Phishing-as-a-Service: Breaches Are Now Subscription-Based
The phishing game has evolved. You no longer need to build your own kit, infrastructure, or frontend. You rent it.
What PhaaS Platforms Offer
Platforms like Typhoon 2FA offer everything an attacker needs to launch a high-volume, MFA-bypassing campaign:
- Prebuilt templates for Microsoft 365, Google, Okta, and others
- CAPTCHA or Turnstile-based bot protection
- URL customization and tracking
- Session cookie capture and export
- Cloud-hosted dashboards to manage campaigns
- Support communities (often on Telegram) for troubleshooting
Pricing models vary, but it’s common to see “plans” like:
- \$120 for 10 days
- \$300 for a month-long campaign
- Add-ons for dynamic evasion, logo customization, or geofencing
These kits have hundreds of unique phishing domains cycling through redirect chains. They come with instructions, obfuscation mechanisms, and scripts that handle redirect cloaking and session capture—all without the attacker needing to write a single line of code.
Typhoon in particular has been linked to thousands of active campaigns targeting enterprise Microsoft 365 tenants, stealing both credentials and active session tokens at alarming scale.
Evilginx2: The Open-Source Tool That Makes Session Hijacking Accessible
Let’s talk about Evilginx2—the AiTM framework that laid the groundwork for commercial kits like Typhoon.
Originally built for red teaming, Evilginx2 is now a go-to tool for attackers who want to phish beyond MFA.
How It Works
Evilginx2 acts as a reverse proxy between the victim and the real authentication service (like login.microsoftonline.com). It doesn’t fake the login screen—it loads the real one. The victim enters their credentials and completes MFA—push notification, OTP, whatever.
Behind the scenes, Evilginx2:
- Intercepts every request and response
- Captures the session cookies and authentication tokens
- Forwards the legit login back to the victim
- Stores the stolen session token for the attacker
This gives the attacker a valid session cookie—meaning they can log in, skip MFA, and operate like a trusted user. Because the session is already authenticated, identity providers treat it like a legitimate login.
Why It’s Dangerous
- It doesn’t need malware
- It works on SSO platforms (Microsoft, Google, Okta, etc.)
- It bypasses almost all legacy MFA methods
- The setup takes 15 minutes
All it takes is:
- A cheap domain
- A VPS (Vultr, DigitalOcean, take your pick)
- A TLS cert (Let’s Encrypt is free)
- A phishlet template for the target service
- A list of users to target
From there, it’s plug-and-play.
A Technical Walkthrough: The AiTM Phishing Flow
Image Above Courtesy of Microsoft
Step 1: Infrastructure Setup
- Register a domain (e.g.,
login-yourorg-support[.]com) - Install Evilginx2 or deploy a PhaaS kit
- Configure DNS to point at attacker VPS
- Set up TLS using Let’s Encrypt
- Deploy a reverse proxy “phishlet” targeting Microsoft 365 or Google Workspace
Step 2: Lure Delivery
- Email, SMS, or QR code-based lure
- Subject lines like “You have a new secure message” or “Policy update required”
- Link embeds the victim’s email as a URL parameter
Step 3: Bot and Sandbox Filtering
- CAPTCHA or Turnstile to block scanners
- Fingerprinting via JavaScript (timezone, resolution, browser anomalies)
- Only serve the full phishing flow to real users
Step 4: Identity Harvest and Session Hijack
- Victim hits the page and sees a pixel-perfect login screen (proxied)
- Enters username and password
- Gets MFA challenge from real IdP
- Approves MFA
- Attacker captures session cookies and tokens (e.g.
AuthToken,SAML,Bearer, etc.)
Image Above Courtesy of Microsoft
Step 5: Post-Auth Redirect
- Victim is forwarded to the real app (e.g., OWA dashboard)
- Assumes everything worked fine
- Meanwhile, attacker logs in using stolen session
Post-Compromise Behavior: What Mid-Stage Adversaries Do Next
With a valid session token, attackers often:
- Search email inboxes for finance or legal communications
- Register new MFA devices for long-term persistence
- Set up forwarding rules to exfiltrate sensitive messages
- Use OAuth apps to embed deeper into cloud platforms
- Pivot into internal tools (Slack, Teams, GDrive, SharePoint)
In BEC campaigns, this access is used to craft convincing internal emails—impersonating the CFO, requesting wire transfers, or targeting downstream partners.
The stealthy nature of this access means an attacker could be active for days or weeks before detection—especially if session theft wasn’t considered in your threat model.
Why Traditional MFA and Detection Fail Here
MFA Doesn’t Help When You Authenticate the Attacker
Session cookies are valid after MFA is completed. There’s no secondary prompt. Unless your identity platform supports token binding or device-attested sessions, an attacker can replay the token from anywhere.
Detection Gaps
- Identity providers log the original user authentication—but not necessarily the cookie replay
- EDR won’t trigger if there’s no malware
- Network logs may show a new IP—but it might look like a VPN
- Impossible travel rules don’t always catch concurrent session usage
Unless you’re tracking session token anomalies, concurrent sessions, or new MFA enrollments, you’re likely flying blind.
Defending Against AiTM Phishing (What Actually Works)
Authentication Hardening
- Move to FIDO2 or WebAuthn
- Use token binding to limit session replay
- Require device compliance and attestation
- Enable re-authentication policies for sensitive actions
- Enable the Token Protection (Preview) Conditional Access Policy for EntraID
Identity Monitoring and Detection
- Alert on MFA method changes
- Flag multiple sessions from disparate locations
- Watch for inbox forwarding rules, OAuth consent grants, and new device fingerprints
- Leverage tools that map to MITRE ATT\&CK techniques like T1557.002 (AiTM)
- If you think there’s a compromise, don’t just reset the password. Revoke the Session as well. This can also be done via the API.
Threat Intelligence and Domain Defense
- Subscribe to feeds tracking PhaaS infrastructure (Typhoon, Evilginx variants)
- Block newly registered lookalike domains
- Enable URL rewriting and sandbox detonation—look for evasive behavior like nested redirects
Session Revocation and IR Playbooks
- Build automated playbooks to revoke tokens upon detection
- Kill active sessions, not just change passwords
- Train incident responders to recognize and escalate token theft cases
Final Thoughts: Mid-Stage Adversaries Are the New Normal
These actors aren’t throwing exploits—they’re using session hijacking at scale, with tools anyone can run. And they’re not targeting obscure services. They’re going after the platforms you use every day: Microsoft 365, Google Workspace, Okta.
MFA is no longer a failsafe. Identity is the new endpoint, and session security is now a frontline defense.
So what should you do?
- Assume post-auth compromise is possible
- Invest in phishing-resistant MFA
- Monitor and respond to suspicious session activity
- Harden your cloud identity configurations
- Treat session tokens with the same urgency as credentials
The adversary is in the middle—and they’re already inside the perimeter. It’s time to meet them there.
