Phishing-as-a-service (PhaaS) Explained

Last Updated on May 27, 2026 by Arnav Sharma

Multifactor authentication was supposed to end the phishing problem. For most of the last decade, the standard guidance was simple: enable MFA and credential theft becomes a non-issue. That guidance is now dangerously incomplete. Phishing-as-a-service has industrialized the adversary-in-the-middle attack to the point where SMS codes, push notifications, and time-based one-time passwords are intercepted in real time, at commercial scale, by operators who paid less than $200 for the toolkit. By early 2025, between 60% and 70% of all phishing attacks observed by major threat research teams originated from PhaaS infrastructure. This article examines how the PhaaS supply chain actually works, which platforms are operating right now, why conventional defenses are failing, and what architecture-level controls close the gap.

What Is Phishing as a Service? The Cybercrime Business Model Explained

PhaaS is a cybercrime model that mirrors software-as-a-service in its commercial structure. A PhaaS provider builds and maintains the attack infrastructure, then leases access to it on a subscription or pay-per-campaign basis. The subscriber, often a low-skilled cybercriminal with no development background, receives everything needed to launch sophisticated phishing campaigns without writing a single line of code.

A typical PhaaS subscription includes:

• Ready-made phishing templates that convincingly replicate Microsoft 365, Google Workspace, Okta, and other enterprise login pages
• Managed hosting infrastructure with automatic domain rotation to evade blocklists
• Credential harvesting dashboards where stolen usernames, passwords, and session cookies appear in real time
• Automation for phishing email distribution, including contact list management and scheduling
• Customer support, with some providers offering Telegram-based technical assistance and uptime guarantees
• Evasion tooling built into the kit, handling anti-bot measures, IP filtering, and cloaking

PhaaS platforms recruit cybercriminals primarily through Telegram channels and dark web forums. Pricing is accessible. Tycoon 2FA, the dominant kit through most of 2025, rented for as little as $120 for a 10-day campaign. This price point removes any meaningful barrier to entry for aspiring attackers.

The downstream consequences extend beyond the initial phishing attack. The cybercrime supply chain now runs in layers: PhaaS operators provide the initial access, credential theft results in account compromise, and Initial Access Brokers sell that foothold to ransomware operators who have no involvement in the phishing campaign itself. This separation of roles makes attribution and disruption significantly harder. Arresting the subscriber does not shut down the phishing kit. Taking down the phishing kit does not stop the IABs who already hold stolen sessions.

How Phishing-as-a-Service Works: The Technical Architecture

Understanding why PhaaS is effective requires understanding the specific attack mechanics that distinguish it from traditional phishing. The sections below break down how phishing-as-a-service work operates at each layer of the attack chain, from initial delivery through session cookie exfiltration.

The Adversary-in-the-Middle Reverse Proxy Model

Classic phishing redirected users to a static fake website that captured credentials and stopped there. PhaaS platforms built around the adversary-in-the-middle (AiTM) model operate differently. The attacker deploys a reverse proxy server that sits between the victim and the legitimate service. When the victim navigates to the phishing URL, they are actually communicating through the proxy in real time. Every request they make to what appears to be the real login page is forwarded to the actual service. Every response from the real service is forwarded back to the victim. From the victim’s perspective, the login sequence looks and functions exactly like the real thing.

This architecture is what makes standard MFA irrelevant against these platforms. The victim completes the full authentication sequence, including MFA challenge, against the real service. The proxy captures the authenticated session cookie that the legitimate service issues after successful login. The attacker now holds a valid, post-authentication session token and can access the account without knowing the password or possessing the MFA device.

Session Cookie Theft vs. Password Theft

The shift from password theft to session cookie theft is a critical architectural distinction. A stolen password is limited by whatever authentication controls protect the account. A stolen session cookie bypasses authentication entirely. The legitimate service has already verified the user’s identity. The session token is proof of that verification. When the attacker replays that cookie, the service sees an authenticated session, not a login attempt. Password resets and MFA enforcement have no effect on an already-authenticated session unless Continuous Access Evaluation (CAE) or conditional access token lifetime policies are in place.

Evasion Layers

Modern PhaaS kits implement multiple layers of evasion that complicate detection:

• CAPTCHA gates that filter automated scanning tools, ensuring only real users (and their credentials) reach the phishing page
• Browser fingerprinting to identify and block known security research infrastructure
• AES-encrypted JavaScript that conceals malicious code from static analysis
• IP and geofencing filters that return benign content to visitors from data center IP ranges
• Cloaking via legitimate redirect chains using Google Accelerated Mobile Pages (AMP), Cloudflare Workers, and trusted URL shorteners to mask the final phishing destination
• Autograb functionality that pre-fills phishing forms with the victim’s email address, increasing the appearance of legitimacy

The Active PhaaS Ecosystem in 2025-2026

The PhaaS market expanded significantly through 2025. The number of known kits doubled over the course of the year, creating a varied threat landscape with both dominant established players and aggressive new entrants.

Platform	Market Share	Key Capability	Notes
Tycoon 2FA	~76%	AiTM, session cookie theft, MFA bypass	Europol takedown March 2026, infrastructure persists
EvilProxy	~8%	Reverse proxy, random URL generation	Targets M365, Google, cloud platforms
Sneaky 2FA / Kratos	~3%	Browser-in-the-browser (BitB) popups, autograb	Sold via Telegram by Sneaky Log
Mamba 2FA	Part of remaining 10%+	AiTM, evolving evasion	10 million attacks in late 2025 alone
EvilTokens	Emerging	Weaponizes legitimate PaaS (Railway)	340+ orgs hit in recent campaign
GhostFrame / Whisper 2FA	Emerging	Novel evasion, anti-analysis techniques	New entrants from 2025

Tycoon2FA was the dominant PhaaS platform through most of 2025, responsible for 62% of all phishing attempts blocked by Microsoft at its peak and generating over 30 million malicious phishing emails in a single month. On March 4, 2026, Europol coordinated a technical disruption involving law enforcement from six countries, seizing 330 domains that formed the platform’s core infrastructure. Within weeks, Tycoon2FA activity had already resumed through new infrastructure. The takedown reduced volume temporarily but did not neutralize the operation.

EvilProxy operates using a reverse proxy architecture and is notable for its accessibility. It requires minimal technical skill to operate, making it popular among cybercriminals targeting Microsoft 365, Google, and other major cloud platforms, and generates randomized URLs with each campaign, complicating URL-based blocking. Microsoft’s identity threat team tracks EvilProxy-based campaigns hitting thousands of organizations monthly.

The EvilTokens campaign documented in early 2026 illustrates the evolution of infrastructure abuse. The platform weaponized Railway, a legitimate cloud deployment service, to host credential-harvesting infrastructure. Attack chains ran through Railway-hosted proxies, Cloudflare Workers landing pages, compromised legitimate websites, and trusted URL redirectors. More than 340 organizations across the US, Canada, Australia, New Zealand, and Germany were compromised before the campaign was identified.

The post-Tycoon2FA disruption environment has not meaningfully contracted the threat. When law enforcement in September 2025 took down RaccoonO365, Tycoon2FA’s primary competitor at the time, the market simply redistributed volume to other platforms. The same pattern has held after every major PhaaS disruption: the infrastructure is replaced faster than it is neutralized.

Why Traditional Defenses Fail Against Phishing Attacks Powered by PhaaS

The standard enterprise email security stack was built to address a different threat model. Understanding the gap requires examining each layer.

SPF, DKIM, and DMARC prevent domain spoofing and are necessary controls. They are not sufficient against PhaaS. These protocols authenticate the sending domain but cannot evaluate the content of a phishing email that arrives from a legitimately authenticated domain, a compromised third party, or through a redirect chain hosted on legitimate infrastructure. An email delivered through Google’s servers with valid authentication headers can still carry a phishing link to a Tycoon2FA proxy.

Secure Email Gateways detect known-malicious URLs, suspicious attachments, and behavioral anomalies. PhaaS operators defeat these controls through infrastructure rotation (new domains and IPs for every campaign), multi-hop redirect chains that obscure the final destination at scan time, and cloaking that returns benign content to scanner IP ranges. The Egress Phishing Threat Trends Report documented a 52% increase in phishing emails bypassing SEG detection in just the first quarter of 2024. The 2025 data is worse.

Standard MFA is the most consequential gap. The widely held assumption that MFA stops credential phishing attacks is false for all MFA types that rely on shared secrets transmitted by a human. SMS codes, TOTP authenticator apps, and push notification approvals all share the same vulnerability: the user must transmit a value (or approval) to what they believe is the legitimate service. An AiTM proxy intercepts that value in real time and forwards it to the real service. The authentication completes successfully. The session cookie is stolen. The attacker has access.

The scope of this problem is substantial. The Canadian Centre for Cyber Security documented over 100 AiTM campaigns targeting Microsoft Entra ID accounts between 2023 and early 2025. Cisco Talos reported that MFA bypass techniques were present in half of all incident responses they conducted in 2024.

Legitimate infrastructure abuse creates an additional blind spot. When a phishing link passes through Google AMP URLs, Cloudflare Workers, or a trusted marketing redirect service, reputation-based URL filtering has nothing to act on. The redirect appears clean until the final destination resolves, often after the user has already clicked.

How to Protect Your Company Against PhaaS: A Tiered Defense Framework

Effective PhaaS defense requires addressing the specific mechanisms PhaaS exploits, not just layering more of the same cybersecurity controls. The following tiers are ordered by impact, not by implementation effort. Each addresses a specific gap in the cybersecurity stack that PhaaS operators actively exploit. Organizations that treat phishing threats as a user awareness problem rather than an architectural one will continue to lose ground.

Tier 1: Deploy Phishing-Resistant Authentication

This is the single highest-impact control available. Phishing-resistant MFA, as defined by NIST SP 800-63B and implemented through FIDO2/WebAuthn standards, uses cryptographic key pairs bound to specific origin domains. The private key never leaves the user’s device. During authentication, the device signs a challenge that includes the origin domain. If the user is connecting through an AiTM proxy with a different domain, the cryptographic handshake fails. There is nothing to intercept or replay.

Passkeys (platform authenticators using device biometrics), hardware FIDO2 security keys, and certificate-based authentication all implement this origin-binding property. SMS codes, push notifications, and TOTP applications do not.

Microsoft’s 2025 Digital Defense Report indicated that phishing-resistant MFA blocks over 99% of identity-based attacks. Despite this, enterprise adoption remained below 50%. For security architects, the priority sequence should be: admin accounts and privileged access first, then finance and legal, then all external-facing services, then general workforce.

The critical caveat: phishing-resistant authentication deployed alongside MFA fallbacks inherits the weaknesses of those fallbacks. If a user can fall back to SMS verification when a hardware key is unavailable, attackers will target the fallback path. Fallback policies require the same scrutiny as the primary authentication method.

Tier 2: Harden Email Security Architecture

Email security remains a valid layer, but it requires specific capabilities to address PhaaS evasion:

• AI and LLM-based anomaly detection that evaluates email content, sender behavior, and relationship patterns rather than relying solely on URL reputation and known-malicious signatures
• Attachment sandboxing and URL detonation that follows redirect chains at click time, not scan time, to evaluate the final destination
• Strict DMARC enforcement at p=reject for all owned domains, with SPF hard-fail and DKIM signing on all outbound mail flows
• DMARC monitoring covering all third-party sending services that handle mail on your domain’s behalf
• Impersonation detection for vendors, executives, and trusted partners (PhaaS kits frequently mimic internal senders)

DMARC alone will not stop PhaaS. Enforcing it does remove a significant attack surface and is a prerequisite for other controls.

Tier 3: Identity and Session Controls

Because PhaaS targets authenticated sessions rather than passwords, identity and session management controls matter as much as authentication:

• Continuous Access Evaluation (CAE) enforces access policy changes and revocation in near-real time for supported clients. A session cookie stolen from a CAE-enabled session loses its value faster, reducing the attacker’s window
• Conditional Access policies that enforce phishing-resistant authentication for high-risk applications, privileged roles, and sensitive data access
• Token lifetime policies that shorten session validity windows for high-risk users and applications, reducing the utility of stolen session cookies
• CASB and OAuth app governance to detect and revoke unauthorized application consent granted through phishing (a common PhaaS post-compromise step)
• Risky sign-in detection using identity protection platforms that flag anomalous session usage, including impossible travel, unfamiliar device, and atypical location signals

Tier 4: Detection and Response for PhaaS-Specific TTPs

Defending against PhaaS at the detection layer requires SIEM rules and threat intelligence feeds oriented toward AiTM-specific indicators rather than traditional phishing signatures:

• Monitor for sign-ins from unfamiliar IP ranges immediately following a successful MFA event (the attacker replaying the stolen session)
• Alert on token refresh activity from geographies inconsistent with the user’s recent activity
• Track and correlate failed CAPTCHA interactions and suspicious redirect chains in proxy and email gateway logs
• Ingest PhaaS-specific IOC feeds covering known Tycoon2FA, EvilProxy, and EvilTokens infrastructure
• Monitor for unusual OAuth consent grants, particularly to newly registered applications requesting broad mail or calendar access

CrowdStrike’s Counter Adversary Operations documentation for Tycoon2FA specifically identifies CAPTCHA-page redirection, JavaScript-based email extraction, and credential proxying to legitimate Microsoft 365 cloud infrastructure as the key TTP chain to detect.

Tier 5: Security Awareness Training and Phishing Simulation Reframed

Security awareness training retains value in the PhaaS era, particularly because cybercriminals increasingly target non-technical employees, but its objective must shift. Training employees to identify phishing emails is insufficient when PhaaS kits produce convincing phishing pages that are technically indistinguishable from legitimate services. The focus should move from recognition to behavior: verify out-of-band before taking action on any financial or credential request, regardless of how legitimate the source appears. Treat any unexpected request to re-authenticate as a potential phishing attempt. Report unusual login prompts immediately rather than attempting to assess them independently.

Regular phishing simulation exercises remain useful for measuring baseline susceptibility, but they should be used to identify high-risk populations for additional controls, not as the primary defense mechanism against sophisticated PhaaS attacks.

Assessing Your PhaaS Exposure: Questions to Evaluate Phishing Threats in Your Environment

If you are reviewing your organization’s current posture, these questions identify the most common architectural gaps:

1. Are any privileged accounts, admin portals, or external-facing services protected only by SMS, push, or TOTP-based MFA? If yes, those accounts are vulnerable to AiTM attacks using current PhaaS platforms.
2. Is your DMARC policy enforced at p=reject for all owned domains, including subsidiary and legacy domains? Permissive or absent DMARC creates a reliable spoofing path for PhaaS operators.
3. Do your Conditional Access or Zero Trust policies enforce phishing-resistant authentication for high-value applications? A policy that allows standard MFA as a fallback for convenience negates the control.
4. What is the token lifetime for your most sensitive applications? Session cookies with long validity windows give attackers extended operational time after a successful AiTM capture.
5. Are your SIEM detection rules explicitly designed to catch AiTM-specific behavioral indicators (session replay, geographic anomalies post-authentication, unusual token refresh patterns)?
6. Has your security awareness program been updated to address AiTM mechanics, where visually convincing fake login pages that function correctly are the attack vector, not obvious fake emails?