A phishing wave reported in early July 2026 is exposing a blind spot that sits between your email gateway and your users. Dubbed "ghost phishing" and attributed to a kit called EvilTokens, the campaign keeps its malicious page invisible to scanners by shipping it as encrypted data and only decrypting it once it has rendered inside the victim's browser. Worse, it does not bother stealing passwords at all — it abuses Microsoft's own device code authentication flow to trick users into handing attackers a valid session. The result is Microsoft 365 account takeover that passes clean through URL reputation checks and credential-phishing detection.
This article explains the mechanics, why conventional controls fail against it, who is in the blast radius, and — most importantly — what to actually do about it.
What is "ghost phishing"?
Ghost phishing is a delivery technique, not a single URL you can block. The phishing content is not present in the page a scanner fetches. Instead the served HTML is encrypted with AES-GCM, and the decryption and rendering happen client-side, in JavaScript, only after the page loads in a real browser. A security tool that fetches the link and inspects the response sees benign or meaningless content; the actual phishing page — the fake Microsoft login prompt — materialises in the DOM after the fact, where server-side and network-level inspection never looks.
The name captures the behaviour: the attack is a ghost that only appears once someone is standing in the room. Static analysis, URL sandboxes that grab the initial response, and email link-rewriting all inspect a page that is, at the moment of inspection, empty.
The device-code twist: no password required
The second half of the campaign is what makes it dangerous even for organisations that have moved past reused passwords. EvilTokens pairs ghost delivery with Microsoft Device Code Phishing. Device code flow is a legitimate OAuth mechanism designed for input-constrained devices — think a smart TV or a CLI tool — where the device shows a short code and the user finishes sign-in on a second device at a Microsoft URL.
In the attack, the adversary initiates a device-code sign-in against Microsoft, then lures the victim into entering the attacker-generated code at the genuine microsoft.com device-login page and completing MFA. Because the user authenticates on Microsoft's real endpoint, everything looks correct to them — real domain, real login, real MFA prompt. But the token that Microsoft issues is bound to the attacker's device session. The attacker walks away with valid access and refresh tokens, and the victim's password was never exposed or needed. This is a consent/token-theft attack wearing the costume of a normal login.
Why traditional email security misses it
Layered together, the two techniques defeat the usual controls in specific ways:
| Control | Why it fails here |
|---|---|
| URL reputation / blocklists | The initial fetch returns encrypted or benign content, so there is nothing malicious to score. Fresh infrastructure has no reputation history. |
| Static HTML / email body scanning | The phishing markup does not exist until JavaScript decrypts it in the browser, so signatures on page content find nothing. |
| Credential-phishing detection | No password is captured. The victim signs in on Microsoft's real page, so there is no fake credential form to detect. |
| MFA | The user completes genuine MFA — but authorises the attacker's device-code session, so MFA alone does not stop the token theft. |
| Sandboxes that grab the first response | Without in-browser rendering and DOM inspection, the sandbox never sees the decrypted phishing page or the device-code request. |
The practical consequence is a longer exposure window: the SOC makes containment decisions on partial evidence, escalations are noisier, and one compromised mailbox has more time to become business email compromise or lateral movement.
Who is being targeted
Reporting based on ANY.RUN sandbox telemetry from roughly 15,000 organisations places recent EvilTokens activity across the US and Europe, hitting technology, manufacturing, education, banking, consulting, financial services, and managed security providers. Phishing exposure in 2026 was measured 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. Sectors that hold sensitive data and run heavily on Microsoft 365 are the natural bullseye, and a compromised MSSP is a supply-chain multiplier that reaches every downstream client.
Detection: what to hunt for
Because the payload hides from content inspection, detection shifts to behaviour and sign-in telemetry rather than the email or the link:
- Device-code sign-ins. In Entra ID sign-in logs, filter for authentication protocol = Device Code. Legitimate device-code use is rare in most tenants; a spike, or device-code sign-ins from user accounts that never use them, is a strong signal.
- Impossible travel and new-location token use where the sign-in is followed by token redemption from unfamiliar ASNs, hosting providers, or geographies.
- New OAuth token grants and refresh-token activity shortly after a device-code authentication, especially access continuing from an IP the user has never signed in from.
- Post-compromise mailbox behaviour — new inbox rules that hide or forward mail, mass reads, or external auto-forwarding — the classic BEC follow-through.
- Detonate suspicious links in a browser-aware sandbox that renders JavaScript and inspects the DOM, so the decrypted page and the /api/device/start-style device-code request become visible for IOC extraction.
Recommendations: how to defend your tenant
The defences that matter most are identity and configuration controls, because the delivery technique is specifically built to evade email inspection.
- Block or tightly scope device code flow. This is the single highest-value control. In Microsoft Entra, create a Conditional Access policy that blocks the device code flow authentication transfer method for all users, then allow it only for the specific groups and locations that genuinely need it (for example, a small set of shared-device or kiosk scenarios). Most organisations can block it outright.
- Enforce phishing-resistant MFA. Move privileged and, ideally, all users to FIDO2 security keys, passkeys, or Windows Hello for Business. Phishing-resistant methods are bound to the origin and defeat the consent/token-theft pattern that ordinary MFA does not.
- Require compliant / managed devices for token issuance. Conditional Access requiring an Intune-compliant or hybrid-joined device breaks the attacker's ability to redeem a token from their own unmanaged machine. Add sign-in risk and user risk conditions via Identity Protection.
- Shorten token lifetimes and enable continuous access evaluation (CAE) so revocation and risk changes take effect in near real time rather than after an hour-long token happily persists.
- Lock down app consent. Restrict user consent to verified publishers and low-risk permissions, and review the app consent and enterprise-application audit logs for unexpected grants.
- Detonate links in a browser-rendering sandbox rather than relying on URL reputation, and feed the extracted domains, endpoints and hashes to your blocklists and threat hunting.
- Train users on the device-code lure specifically. The teachable rule: never enter a code someone else gave you into a Microsoft device-login page. A legitimate device code is one your own device displayed — not one that arrived in an email, chat, or call.
- Prepare the containment playbook. For a confirmed takeover, the first-hour actions are: revoke the user's refresh tokens/sessions, disable or reset the account, remove malicious inbox rules and OAuth grants, and purge the phishing email tenant-wide. Our Microsoft 365 incident response console covers automating these steps, and the Zero Trust guide covers the identity model that limits blast radius.
The bigger picture
Ghost phishing is part of a broader shift: attackers are moving away from stealing credentials and toward stealing sessions and tokens, and away from putting malicious content where scanners look and toward revealing it only to the human. Both trends push defence away from the email gateway and toward identity posture, device trust, and behaviour-based detection. If your anti-phishing strategy still assumes the malicious thing will be visible in the email or the first URL response, this campaign is the reminder to close that gap. Assume delivery will occasionally succeed, and make the identity layer the place the attack dies.
Frequently asked questions
What is ghost phishing?
Ghost phishing is a phishing delivery technique that hides the malicious page from security scanners by serving it as encrypted data (AES-GCM) and only decrypting and rendering it in JavaScript once the page opens in the victim's browser. Because the phishing content does not exist at the moment a URL scanner or email filter inspects the link, static and network-level controls see nothing malicious. The current wave is associated with a kit called EvilTokens and targets Microsoft 365 accounts.
How does the EvilTokens campaign take over Microsoft 365 accounts without a password?
It abuses Microsoft's legitimate device code authentication flow. The attacker starts a device-code sign-in and tricks the victim into entering the attacker-generated code on the real Microsoft device-login page and completing MFA. Microsoft then issues valid access and refresh tokens bound to the attacker's session. The victim's password is never captured because the sign-in happens on Microsoft's genuine endpoint — the attacker steals the resulting token, not the credential.
Why doesn't MFA stop this attack?
Ordinary MFA does not stop it because the victim really does complete a genuine MFA challenge — but in doing so they authorise the attacker's device-code session rather than their own. The fix is phishing-resistant MFA (FIDO2 keys, passkeys, Windows Hello for Business), which is bound to the legitimate origin, combined with a Conditional Access policy that blocks or tightly restricts the device code flow.
How can I detect ghost phishing / device-code attacks in my tenant?
Hunt in identity telemetry rather than email content. In Entra ID sign-in logs, look for device-code authentications (rare in most tenants), sign-ins followed by token use from unfamiliar IPs, ASNs or locations, new OAuth grants or refresh-token activity right after a device-code sign-in, and post-compromise mailbox rules that forward or hide mail. Detonating suspicious links in a browser-rendering sandbox exposes the decrypted page and the device-code request for IOC extraction.
What is the single most effective defence?
Blocking or tightly scoping the device code flow with a Microsoft Entra Conditional Access policy. Most organisations have little legitimate need for device code sign-ins, so blocking the method for all users (and allowing it only for specific groups or locations that require it) removes the exact mechanism this campaign depends on. Pair it with phishing-resistant MFA and device-compliance requirements.
Who is being targeted by the campaign?
Reporting places recent EvilTokens activity across the US and Europe, targeting technology, manufacturing, education, banking, consulting, financial services, and managed security providers. Sectors that hold sensitive data and rely heavily on Microsoft 365 are most exposed, and compromised managed security providers pose supply-chain risk to their downstream clients.