EvilTokens, a phishing-as-a-service (PhaaS) kit that surfaced in mid-February 2026, chains two techniques that together defeat both static URL scanning and multi-factor authentication. The phishing HTML ships encrypted with AES-GCM and only decrypts and paints itself into the DOM once the victim's browser renders it — a "ghost phishing" behavior. What the decrypted page then runs is Microsoft Device Code Phishing: the victim is walked through a genuine Microsoft 365 / Entra ID login on Microsoft's own domain, and the valid OAuth access and refresh tokens that result are handed straight to the attacker. No password is stolen, and MFA is satisfied by the victim — so it never blocks the attack.
Image source: The Hacker News / ANY.RUN
Summary
An EvilTokens email can pass every static check your gateway performs and still lead to a full Microsoft 365 account takeover. The malicious content stays encrypted until it renders in the employee's browser, so URL reputation and network-level inspection see a benign-looking response while the employee sees a working Microsoft login. Because the kit abuses the OAuth device-code flow, the attacker ends up holding valid tokens even though the victim completed MFA correctly — the account is compromised without a stolen password. The campaign has concentrated on the United States and Europe, hitting technology, manufacturing, education, banking, consulting, financial services, and managed security providers. The single most effective control most organizations are missing is a Conditional Access policy that blocks the device-code authentication flow for standard users; pair it with detonating suspicious links in a browser-capable sandbox rather than trusting a clean URL verdict.
What EvilTokens is
EvilTokens is a PhaaS toolkit that automates device-code phishing against Microsoft 365 and Entra ID environments. Traditional phishing harvests a username and password on a fake login page. EvilTokens does not need either. It abuses the OAuth 2.0 device authorization grant — a flow designed for input-constrained devices such as smart TVs — to trick the user into authorizing the attacker's session on Microsoft's real infrastructure.
The mechanics matter for detection. The attacker's backend initiates a device-code request (observed hitting an /api/device/start endpoint), receives a short user_code, and presents that code to the victim through the phishing page. The victim, believing they are completing a normal sign-in, enters the code on a legitimate Microsoft page and authenticates — MFA included. Microsoft then issues an access token and a refresh token to the attacker's polling session. The refresh token is the real prize: it grants durable access that survives password resets and outlives the original session.
"Ghost phishing": encryption that hides from the gateway
The evasion layer is what makes this campaign worth studying. The phishing page's HTML is encrypted with AES-GCM and is inert until the browser decrypts it in memory and injects the rendered content into the DOM. A secure email gateway or a URL sandbox that only fetches the initial HTTP response sees ciphertext or a near-empty shell — not the Microsoft-branded phishing screen the employee will actually see. Static URL reputation, signature matching on the response body, and network-level controls all inspect something that does not contain the attack.
That visibility gap directly translates into slower response: a longer exposure window on the compromised account, delayed containment, and incomplete evidence for blocking related infrastructure. The attack only becomes visible when you observe the page after it decrypts.
Decrypted DOM revealed after browser render — source: The Hacker News / ANY.RUN
Attack flow
The chain, as reconstructed from ANY.RUN's interactive analysis, runs entirely in the browser:
Lure. The victim receives a link that abuses a legitimate SaaS surface for credibility — in the analyzed sample, a Calendly booking link (hxxps://calendly[.]com/d/dvnf-pts-7sz).
Redirect to attacker infrastructure. The flow reaches a page hosted on Cloudflare Workers (*.workers[.]dev), flagged in the sandbox via ET INFO signatures for workers.dev in the TLS SNI and DNS queries.
In-browser decryption. The AES-GCM-encrypted HTML decrypts and the phishing content appears in the DOM, tied to a Fetch/XHR request.
Device-code initiation. The backend triggers the Microsoft device-code flow via /api/device/start and surfaces the user_code to the victim.
Legitimate authentication. The victim completes a real Microsoft 365 / Entra ID sign-in, satisfying MFA.
Token theft. Microsoft issues valid OAuth access and refresh tokens to the attacker, granting account access with no password and no MFA prompt on the attacker's side.
Sandbox evidence
ANY.RUN's interactive sandbox (analysis dated June 15, 2026, Windows 10 Pro) returned a Malicious verdict with the tags oauth-ms-phish, phishing, and eviltokens. The concrete behavioral findings:
Microsoft OAuth device-code phishing detected inside the Edge renderer process.
PHISHING detected via Suricata on the network service process.
Anti-analysis: the page enables developer-hotkey prevention, blocking DevTools access to frustrate manual inspection.
Browser-only footprint: zero executables dropped, no registry writes (373 read events, 0 writes) — consistent with a pure credential/token-theft operation rather than a malware dropper.
Infrastructure: the malicious flow rides Cloudflare Workers (workers.dev), with a Calendly link as the front door.
Where it is hitting
Per The Hacker News, EvilTokens activity has concentrated across the United States and Europe, targeting technology, manufacturing, education, banking, consulting, financial services, and MSSPs. As a proxy for how exposed these sectors are, ANY.RUN's 2026 sandbox-submission data across roughly 15,000 organizations put overall phishing exposure at 75.6% in consulting, 72.8% in financial services, 71.9% in manufacturing, 67.9% in technology, 66.7% in banking, and 66.1% among MSSPs. These figures describe general phishing exposure rather than EvilTokens specifically, but they map onto exactly the sectors this campaign is chasing.
Image source: The Hacker News / ANY.RUN Threat Intelligence
MITRE ATT&CK mapping
| Tactic |
Technique |
ID |
Where it shows up |
| Resource Development |
Acquire Infrastructure: Web Services |
T1583.006 |
Phishing hosted on Cloudflare Workers (*.workers.dev) |
| Initial Access |
Phishing: Spearphishing Link |
T1566.002 |
Lure link (e.g., Calendly booking URL) |
| Execution |
User Execution: Malicious Link |
T1204.001 |
Victim opens the link in a browser |
| Defense Evasion |
Obfuscated Files or Information |
T1027 |
Phishing HTML encrypted with AES-GCM |
| Defense Evasion |
Deobfuscate/Decode Files or Information |
T1140 |
Browser-side decryption into the DOM |
| Defense Evasion |
Debugger Evasion |
T1622 |
Developer-hotkey / DevTools prevention |
| Credential Access |
Steal Application Access Token |
T1528 |
Device-code phishing yields OAuth tokens |
| Defense Evasion / Lateral Movement |
Use Alternate Authentication Material: Application Access Token |
T1550.001 |
Attacker uses the issued access/refresh tokens |
| Persistence |
Valid Accounts: Cloud Accounts |
T1078.004 |
Durable M365/Entra access via refresh token |
Indicators and detection
IOCs (defanged) — from the ANY.RUN task; treat the Calendly link and hashes as pivots, and hunt on the Cloudflare Workers pattern rather than a single burnable domain:
Lure URL: hxxps://calendly[.]com/d/dvnf-pts-7sz
Backend infra: *.workers[.]dev (Cloudflare Workers)
Device code: /api/device/start
MD5: 23111B7048DA3DB16BDA411260C64B8D
SHA1: 7B8216BE97C3E6D1340E3514352E586666BCEE08
SHA256: 0F744BC8BB75DEDA97FD63C202166EBD4B012DA90B85BAC7A41FF0B30EFCA5FA
The durable detection opportunities are identity- and behavior-based, not IP-based:
Entra ID sign-in monitoring — the highest-value control. Alert on any interactive sign-in where the authentication protocol is Device Code. Standard human users almost never legitimately use this flow, so its appearance for a normal account is a strong compromise signal. Watch especially for a device-code grant correlating with an anomalous IP/ASN/geo (the attacker polls from their own infrastructure while the victim authenticates from theirs).
Conditional Access. Block the device-code authentication flow for all users who do not have a documented need for it.
Network / email. Hunt for click chains that land on *.workers.dev, and treat legitimate-SaaS lure links (e.g., Calendly) that redirect to Cloudflare Workers as suspicious. Because ghost-phishing HTML defeats static URL scanning, detonate suspicious links in a sandbox that inspects the post-decryption DOM, not just the initial response.
Response. On suspected compromise, revoke refresh tokens and active sessions immediately, reset the account, and audit OAuth app grants and consents.
Assessment and relevance for Vietnam
The strategic point of EvilTokens is that it turns "we enabled MFA" into a false sense of safety. The victim does everything right — real Microsoft page, correct password, approved MFA prompt — and the attacker still walks away with valid tokens, because the abused flow was never designed to distinguish a legitimate device from an attacker's polling session. Layering AES-GCM ghost phishing on top means the initial email survives the exact controls most organizations lean on hardest.
For Vietnam, this is squarely relevant: Microsoft 365 and Entra ID are the default identity backbone for a large share of Vietnamese enterprises, and the lure pattern — a legitimate SaaS link plus disposable Cloudflare Workers hosting — sidesteps domain-blocklist defenses that many local SOCs still rely on. Teams that have invested heavily in MFA rollout but have not touched device-code flow or token-based detections are precisely the profile this campaign converts. The good news is that the strongest mitigation costs nothing but a policy change: most organizations can block device-code authentication outright and lose nothing operationally.
Recommendations
Now: In Entra ID Conditional Access, block the device-code authentication flow for users who don't need it; alert on any device-code sign-in.
This week: Add hunting for click chains landing on *.workers.dev and legit-SaaS lures that redirect there; sandbox suspicious links with post-decryption DOM inspection.
On compromise: Revoke refresh tokens and sessions, reset the account, and review OAuth grants — a stolen refresh token survives a password reset.
References
