ARToken PhaaS: Exposing EvilTokens' Microsoft 365 Phishing Toolkit
artokeneviltokensmicrosoft 365phishingmfa bypassdevice code flowcybersecuritycisco talossekoiasharepointprt persistencesocial engineering

ARToken PhaaS: Exposing EvilTokens' Microsoft 365 Phishing Toolkit

The Incident: ARToken PhaaS Targets Microsoft 365

Cisco Talos recently identified ARToken, a sophisticated Phishing-as-a-Service (PhaaS) operator panel specifically targeting Microsoft 365 users. This ARToken PhaaS platform appears to operate as an affiliate of the notorious EvilTokens platform, sharing infrastructure, API contracts, and operational patterns. EvilTokens was first detailed by Sekoia in March 2026, with Microsoft confirming its scale in April 2026, highlighting the growing threat of such advanced phishing operations.

These groups are not casting wide nets. They target specific roles: finance professionals, HR staff, and logistics personnel. For instance, I observed a lure from April 20, 2026. It was an invoice query, spoofing a legitimate Wisconsin contractor and targeting, for instance, an accounts-payable recipient at a U.S. life-sciences company. The email itself had some red flags – SPF, DKIM, and DMARC all failed – but the visible link in the email looked like a genuine SharePoint URL.

How They Get In: The Device Code Loophole

  1. The Lure: The victim receives a highly personalized email, often concerning an invoice or a document, with a link appearing to lead to a legitimate Microsoft SharePoint site.

  2. The Redirect: Clicking the link directs them not to a fake login page, but to an attacker-controlled Microsoft 365 workspace, still hosted on a genuine sharepoint.com domain. This initiates the device code flow. This initial access method aligns with MITRE ATT&CK technique T1566.002 (Phishing: Spearphishing Link).

  3. The Device Code: The phishing page, deployed via Cloudflare Workers (e.g., a domain like clear90489058903-document.workers[.]dev), displays a device code and instructs the victim to navigate to microsoft.com/devicelogin. This is a legitimate Microsoft URL.

  4. The MFA Bypass: The victim, recognizing a genuine Microsoft domain, enters the device code. Microsoft then, as designed, issues authentication tokens directly to the attacker's backend. This completely bypasses traditional MFA prompts because the victim authenticates through a legitimate Microsoft flow, not a fabricated one. This design, while legitimate, becomes a critical vulnerability when exploited through social engineering. The successful capture of authentication tokens directly maps to T1528 (Steal Application Access Token).

This method is not a zero-day exploit. Instead, attackers exploit Microsoft's OAuth 2.0 Device Authorization Grant (RFC 8628, which defines this grant) as designed, but with a social engineering layer.

Smartphone showing Microsoft device login page, exploited by ARToken PhaaS for Microsoft 365 phishing
Smartphone showing Microsoft device login page, exploited by
A smartphone displaying the legitimate Microsoft device login page, where victims are directed to enter the attacker-provided code.

The Mechanism: Persistence and Post-Compromise Control

Primary Refresh Token (PRT) Persistence is a significant concern. The ARToken API surface includes endpoints like /prt/setup, /prt/refresh, /prt/renew, /prt/reacquire, and /prt/cookie. This indicates their ability to escalate captured tokens to a Primary Refresh Token. A PRT grants persistent access to Microsoft 365 services, even if the victim changes their password. The UI even advertises "PRT-enabled - Persists across password changes." This capability aligns with T1098.001 (Account Manipulation: Additional Cloud Credentials), enabling deep, long-term compromise.

ARToken's phishing kit incorporates a sophisticated multi-layered client-side anti-analysis system. It checks User-Agents, navigator.webdriver, browser features, window dimensions, requires mouse moves or touch events, and analyzes movement patterns. This sophisticated anti-analysis system leverages techniques like T1497.001 (Virtualization/Sandbox Evasion: System Checks). Notably, ARToken's JavaScript payloads are delivered XOR-encrypted, a technical distinction from EvilTokens' documented AES-GCM Web Crypto API encryption, further complicating analysis and aligning with T1027 (Obfuscated Files or Information).

Token theft is merely the initial step; the objective is monetization. EvilTokens is reported to leverage AI models for scoring financial exposure and generating tailored BEC scenarios. This is not generic spam, but highly targeted, personalized fraud.

The React-based ARToken panel, central to the ARToken PhaaS Microsoft 365 operation, with over 80 API endpoints, provides operators a full toolkit:

  • Token Management: Refresh, export, import, and share tokens with other operators, including granular permissions.

  • Email Operations: Full Outlook inbox read access, sending emails as the victim (with BCC batch support and delays), creating inbox rules for forwarding or auto-deletion, and keyword monitoring across all compromised accounts. These email operations align with T1114.002 (Email Collection: Remote Email Collection).

  • SharePoint/OneDrive Access: Browse, upload, download, and manage permissions on victim files.

  • Infrastructure Automation: Integrates with Cloudflare's API to deploy phishing templates directly to Workers. This is an example of T1583.006 (Acquire Infrastructure: Web Services).

  • Desktop Session Browser: A standalone Windows application, similar to EvilTokens' "Portal Browser," for browsing victim Microsoft 365 sessions outside the web panel.

The ability to use captured tokens for session browsing and other operations, as seen in Token Management and the Desktop Session Browser, is a clear example of T1550.001 (Lateral Movement: Use Alternate Authentication Material: Application Access Token).

ARToken also introduces new capabilities not present in earlier EvilTokens research, such as cross-account keyword monitoring, programmatic inbox rule manipulation, and geo-dynamic templates that resolve lure placeholders based on victim location. This positions ARToken as a comprehensive, commercial-grade attack platform.

The Impact: Trust Exploitation and Persistent Threats

Practically, an attacker with this access can obtain legitimate tokens for the victim's account. The effectiveness of these attacks often stems from exploiting trust in Microsoft's own infrastructure. Victims are directed to legitimate Microsoft domains, rendering traditional "check the URL" advice less effective.

Cisco Talos's findings, echoed by other industry reports, highlight significant concern within the cybersecurity community regarding the sophistication of device code phishing, PRT persistence, and AI-driven BEC operations. By April 2026, Sekoia had already documented approximately 500 Cloudflare Workers domains and over 1,000 total phishing pages associated with EvilTokens, underscoring the scale of this threat.

Traditional defenses, including MFA, are being circumvented due to the exploitation of legitimate Microsoft authentication flows. A stolen password, in this context, represents a deep, persistent compromise that is difficult to detect and even harder to evict. Countering ARToken PhaaS Microsoft 365 attacks requires a multi-layered defense.

Abstract visualization of cloud authentication pathways, highlighting flows leveraged by ARToken and EvilTokens
Cloud authentication pathways, highlighting flows leveraged by ARToken
An abstract visualization of cloud authentication pathways, highlighting the legitimate but exploitable flows leveraged by ARToken and EvilTokens.

The Response: Beyond Basic MFA

The FBI has issued warnings about similar PhaaS platforms, indicating this is a widespread threat, not an isolated incident. We cannot solely rely on "enable MFA" as a defense strategy.

Conditional Access Policies serve as a primary defense. Restrict the OAuth 2.0 Device Authorization Grant flow where it is not absolutely needed. Enforce trusted devices, geo-restrictions, and compliant device states for access to sensitive resources. If a user authenticates from an unusual location or device via device code, block the attempt.

Beyond policy, the strength of MFA implementation matters. Push notifications via authenticator apps are generally more secure than SMS or email codes, which are susceptible to interception.

We need to evolve user education beyond generic warnings. Educate users specifically about the device code flow. Teach them what legitimate Microsoft prompts look like and, critically, what actions they shouldn't take (e.g., entering a code on microsoft.com/devicelogin unless explicitly instructed by a trusted internal process).

Proactive monitoring is essential. Look for suspicious device code authentication attempts in your Microsoft 365 logs. Monitor for new device registrations, unusual inbox rule creations, or unexpected API calls from user accounts. Pay attention to Cloudflare Workers activity if deployed.

Endpoint Detection and Response (EDR) systems play a role in detecting the deployment and activity of tools for desktop session browsing. Look for unusual processes interacting with Microsoft 365 services.

Finally, Email Security Gateways (ESG) need continuous tuning. While SPF/DKIM/DMARC failed in the example lure, these platforms are improving. Your ESG needs to be configured to detect sophisticated lures, even those with legitimate-looking domains in the link text.

Relying solely on MFA is insufficient when attackers exploit Microsoft's native trust mechanisms. Effective defense requires focusing on the authentication process itself and user behavior within trusted environments. This approach is crucial for countering sophisticated PhaaS operations, like those run by ARToken PhaaS Microsoft 365.

Daniel Marsh
Daniel Marsh
Former SOC analyst turned security writer. Methodical and evidence-driven, breaks down breaches and vulnerabilities with clarity, not drama.