ARToken PhaaS: device-code phishing is the M365 lane defenders keep leaving open

Cisco Talos published a look at ARToken, a phishing-as-a-service platform tied to the EvilTokens operation that BleepingComputer wrote up on July 3. The panel is React with roughly 80 API endpoints, hosts affiliate phishing infrastructure on Cloudflare Workers, and exists to sell one thing: Microsoft 365 tokens delivered by way of the OAuth 2.0 Device Authorization Grant. Sekoia documented the EvilTokens parent operation back in March at a $1,500 setup fee and $500/month. ARToken looks like an affiliate distribution layer bolted on top of it.

If your reaction is “we have MFA, we’re fine,” stop.

What actually happens

Device code flow is a legitimate Microsoft OAuth grant designed for input-constrained devices — kiosks, smart TVs, conference-room hardware, printers, IoT boxes that can’t feasibly show a full browser login. The device asks Microsoft for a short code; the user types that code into microsoft.com/devicelogin on any browser, authenticates against the real identity provider, satisfies MFA, and Microsoft hands the token back to the device that asked for it. That last step is the entire attack surface. If the “device that asked for it” is an attacker box running a phishing lure, and the “user typing the code in” is your accounts-payable staffer following a socially engineered invoice email, the token lands in the attacker’s session. MFA is not defeated in any cryptographic sense. The user completed it. On the real IdP. On the correct origin. Everything the identity signal sees is clean.

That is why this class keeps working, and why detection at the login step is the wrong place to spend hours.

Talos found ARToken during incident response, per the BleepingComputer writeup. Post-compromise, the affiliate toolkit chains into Primary Refresh Token acquisition — the persistent asset that survives password rotation because it isn’t tied to the password — and from there into Outlook, SharePoint, and OneDrive read access, plus BEC automation. This is not a new attack surface. It’s the same PRT / long-lived-refresh-token substrate that ConsentFix and ClickFix (covered separately today) land on from a different door. Different lure, different grant type, same asset.

The scale

Push Security reported in April that device-code phishing attempts jumped 37x year-over-year. BleepingComputer notes at least 11 kits currently offer device-code phishing as a feature. This isn’t fringe tradecraft anymore; it is a productized off-the-shelf capability for anyone with $500 a month.

What to do — in priority order

1. Turn on the Conditional Access policy that blocks device code flow, today, for every identity that doesn’t need it.

Microsoft ships this as a policy control. Most tenants haven’t scoped it. The legitimate use cases (kiosks, conference-room devices, specific service accounts, some IoT) are a small and knowable list. Everything else — every user identity in a normal knowledge-worker tenant — should be blocked from initiating device code flow at all. When the attacker’s box asks for a code on your user’s behalf, the grant type never issues. The lure becomes inert.

If you can only do one thing this week, do this one.

2. Alert on unusual OAuth grant types per identity.

Your SIEM is already ingesting Entra ID sign-in logs. Filter for authenticationProtocol = deviceCode and correlate against the small set of identities you actually expect to see it from. Any hit outside that list is either a policy misconfiguration or an attempt in progress. Treat both as page-worthy.

3. Hunt AP-team invoice lures specifically.

BleepingComputer notes the current wave leans heavily on invoice-themed phishing to accounts payable. That is a targeted, high-signal search. Your mail hygiene tool sees the volume; a saved query for invoice-themed inbound to your AP distribution list, filtered against sender reputation, will surface the campaign fast. This isn’t clever — it’s boring, and boring is what works.

4. Rotate PRTs for any user you suspect touched a device-code lure — password rotation alone will not clear an attacker’s session.

This is the piece that catches people. Revoke the refresh tokens. In Entra: revoke sign-in sessions for the identity, then require MFA re-registration. Do not assume a password reset ended the incident.

Priority call

Block device code flow via Conditional Access this week. Everything else on this list is worth doing, but that single policy change turns off the mechanic that ARToken, EvilTokens, and the other ten kits are all built on. Deprioritize new anti-phishing training rollouts, deprioritize AI-behavioral-email-security pilots — those catch some of the lures, but the policy control catches the grant itself, before a user gets the chance to make the wrong call.

Sources

• BleepingComputer, ARToken PhaaS exposes EvilTokens’ Microsoft 365 phishing toolkit (July 3, 2026)
• Cisco Talos (ARToken discovery during incident response, per BleepingComputer)
• Sekoia (prior EvilTokens documentation, March 2026, per BleepingComputer)
• Push Security (37x device-code phishing surge, April 2026, per BleepingComputer)