EvilTokens/ARToken: device-code attacks on Microsoft 365 — move to FIDO2

Excerpt — On July 3, 2026, BleepingComputer and Cisco Talos exposed “ARToken,” a platform linked to EvilTokens that hijacks the OAuth device-code flow to take over Microsoft 365 accounts despite MFA. Here is how phishing-resistant MFA (FIDO2/WebAuthn) and access controls block the attack and substantiate GDPR Article 32.

What happened

On July 3, 2026, BleepingComputer reported that ARToken, a phishing-as-a-service (PhaaS) offering, abuses OAuth 2.0’s Device Authorization Grant (“device code”) to hijack authentication to Microsoft 365. Cisco Talos researchers linked ARToken to the EvilTokens kit based on identical APIs and shared infrastructure. According to published details, the operator displays a device code on a fake page, then pushes the victim to the legitimate Microsoft site to enter that code. Once the user completes authentication (including MFA) on the legit portal, the attacker receives an OAuth token that can be used to read mailboxes, create hidden rules, launch BEC, and pivot to other SaaS.

Public indicators of compromise (IOCs) associated with these campaigns include:

• Kit API patterns: /api/device/start and /api/device/status seen by Talos and public sandboxes; on the wire, the X‑Antibot‑Token header outside legitimate hosts is a strong signal.
• Clustered hosting on Cloudflare Workers (ephemeral names) already linked to EvilTokens/ARToken.

These technical artifacts are documented by BleepingComputer (07/03/2026) and sandbox analyses that detail recent device-code kits’ API calls and headers (BleepingComputer); also see a Q2 summary by Cisco Talos on July 28, 2026, confirming phishing as the #1 entry vector and detailing the ARToken↔EvilTokens link (Cisco Talos). The Register relays Microsoft’s scale estimate: 10–15 campaigns/day observed since March 15, 2026 (The Register).

The applicable legal framework

For companies in Luxembourg, Belgium, France, Germany, and the EU, GDPR Article 32 mandates “appropriate technical and organizational measures” to ensure a security level appropriate to risk, and the ability to demonstrate their effectiveness. The CNPD highlights this obligation and the need to prove proportionality and effectiveness (logging, access control, strong authentication, etc.) (Article 32, CNPD), (CNPD — Security: issues and objectives). EU case law confirms that controllers must demonstrate their measures and their suitability to risk (Arts. 24 and 32) (CJEU, C‑340/21). For an overview of your GDPR obligations in this area, see our dedicated resources.

In practice, theft of OAuth tokens via the device-code flow exposing mailboxes and personal data engages the controller’s responsibility: they must show that deployed authentication is phishing‑resistant, that risky flows (device code, OAuth consents) are governed, and that detection and remediation are operational.

The technical solution to deploy

Phishing‑resistant MFA (FIDO2/WebAuthn) + Conditional Access policies tailored to OAuth. The goal: prevent credential capture and reduce the value of a lure to near‑zero. Additionally, constrain or disable the device code flow and protect tokens.

• FIDO2/WebAuthn (passkeys): public‑key authentication (no shared secret), cryptographic binding to origin, preventing proxy/MITM kits from replaying a challenge. References: ISO/IEC 27001:2022 Annex A 5.17 (authentication information), A 5.15 (access control); NIST CSF 2.0 PR.AA; CIS Control 6.7 (Require MFA).
• OAuth/Entra ID controls: restrict or block the Device Authorization Grant if unnecessary; enforce Conditional Access (device compliance, geo, risk); require phishing‑resistant MFA at each consent; use Token Protection when available and enable Continuous Access Evaluation.
• Targeted detections: SIEM/XDR rules on ARToken/EvilTokens IOCs (/api/device/start, /api/device/status, X‑Antibot‑Token, correlated workers.dev clusters); alerts on mailbox rule creation, anomalous OAuth consents, and unexpected device‑code sign‑ins.
• Session hygiene: proactively revoke refresh tokens at the first suspicion; rotate application secrets; inventory and quarterly review authorized OAuth apps.
• Helpdesk hardening: high‑assurance MFA enrollment procedures to thwart social engineering (vishing) aiming to register new factors.

Why this satisfies Article 32: you document measures “appropriate to risk” (advanced phishing targeting M365), traceable and testable (auth logs, SIEM rules), and proportionate (FIDO2 for higher‑risk profiles, conditional policies for all), aligned with CNPD/EDPB expectations (CNPD), (EDPB — Secure personal data).

How Luxgap delivers this

• Our ISO 27001 governance: scoping authentication policies (A 5.15/5.17), risk matrix, effectiveness evidence (KPIs on phishing‑resistant auth failures, OAuth consent reviews), and Article 32 evidence packs ready for CNPD audit.
• Our 24/7 managed SOC: ingest Entra ID/M365 logs, correlate ARToken/EvilTokens IOCs (URIs/headers/destinations), detect atypical device‑code sign‑ins, and run SOAR playbooks to revoke tokens and purge malicious rules.
• Our e‑learning platform: concise “spot device‑code phishing” modules, just‑in‑time training embedded in Microsoft 365, and completion certificates to demonstrate organizational measures (Art. 32).

Case study in Luxembourg/EU

A Luxembourg asset manager subject to NIS 2 faced a red‑team device‑code phishing attempt on its M365 admins. In 6 weeks we: (1) rolled out FIDO2 for privileged and finance staff; (2) disabled the device‑code flow except for inventoried displays; (3) enforced Conditional Access (compliant device + trusted location); (4) streamed auth logs to SIEM with ARToken/EvilTokens IOC rules; (5) trained support for “zero‑vishing” MFA enrollment. Result: two real attempts detected the following week, tokens revoked in under 12 minutes, no personal data exposed, Article 32 evidence kept current.

Practical first steps

1. Map your authentication methods (Entra ID → Authentication methods) and enforce FIDO2/WebAuthn for admins and sensitive roles this week.
2. Disable the “device‑code” flow wherever not strictly needed; otherwise, restrict via Conditional Access (compliant device, geo, business hours).
3. Inventory authorized OAuth apps, revoke inactive tokens, and alert in SIEM on any mailbox rule creation and any high‑risk consent.
4. Deploy IOC‑based detections for ARToken/EvilTokens: /api/device/start / /api/device/status requests, X‑Antibot‑Token header, correlated workers.dev clusters, and device‑code sign‑ins outside approved profiles.
5. Brief the helpdesk: strengthened identity‑verification script before any MFA enrollment/replacement; reject phone‑initiated enrollment requests without out‑of‑band validation.

Official sources

• BleepingComputer — ARToken PhaaS exposes EvilTokens’ Microsoft 365 phishing toolkit (07/03/2026)
• Cisco Talos — IR Trends Q2 2026: phishing and ARToken/EvilTokens (07/28/2026)
• The Register — EvilTokens device‑code phishing kit (07/01/2026)
• CNPD — GDPR, Article 32: security of processing
• CJEU C‑340/21 — burden of proof and appropriate measures (Arts. 24 and 32)
• EDPB — Secure personal data