July 14, 2026 - 8 min read

By PhishClean Research Team

Ghost Phishing: Why a Clean URL Scan No Longer Means a Clean Page

A phishing wave that researchers are calling "ghost phishing" ships its malicious page as encrypted code. Scanners that check the link see harmless ciphertext. The real login-stealing page only appears once it decrypts inside your browser.

Security teams reported a campaign in July 2026, tracked as EvilTokens, that targets businesses across the US and Europe with a technique now being described as ghost phishing. According to reporting from The Hacker News and multiple threat blogs, the campaign has hit technology, manufacturing, education, banking, consulting, financial services, and managed security providers - and it is built specifically to defeat the tools most organizations rely on to catch phishing before it reaches a person.

How ghost phishing works

The trick is where the malicious content lives. Instead of shipping a recognizable fake login page, the attacker delivers the page as encrypted HTML - reportedly using AES-GCM - alongside a small, generic-looking decryption script. When an automated scanner fetches the URL, it sees opaque ciphertext and a bit of JavaScript. There is no fake Microsoft logo to match, no credential form to flag, no suspicious keywords. So it scores the page as clean.

The page only becomes dangerous when a real browser runs the script. The browser decrypts the HTML, renders the phishing content into the page, and then walks the victim through a Microsoft device-code flow designed to hand the attacker access to a Microsoft 365 account.

Why traditional defenses miss it

Most email and URL-scanning defenses inspect the response the server sends without fully executing its JavaScript. That model has worked for years because phishing pages usually contained their giveaway - a spoofed brand, a login form, a suspicious redirect - right there in the HTML. Ghost phishing removes the giveaway from the response entirely and reconstitutes it only at render time. The result is a genuine visibility gap: the security control and the victim are looking at two different pages.

What to do if you land on one

Do not enter credentials or type a device code that a page or caller gives you. Close the tab. If the message claimed to be from your employer's IT or a known vendor, verify through a channel you already trust - not a link or number in the message. If you already completed a device-code prompt, treat it as an account compromise: sign out all sessions, reset your password, review recent sign-ins and app grants, and tell your security team. Because device-code phishing can capture a session, a password reset alone may not be enough.

Session tokens matter as much as passwords

Device-code and consent-style phishing flows are popular for a blunt reason: when they succeed, the attacker usually ends up holding tokens, not just a password. A valid session or refresh token lets someone read mail, download files, and grant app permissions while looking like you - with no further login screen to trip over. That changes what recovery means. Resetting a password changes what you know; it does not automatically cancel what the attacker already holds. So when a flow like this is involved, revoking sessions and tokens is not an optional extra - it is the step that actually ends the intrusion. We cover how stolen sessions get used, and how to cut them off, in our guide to session hijacking attacks.

Questions to ask before you enter any device code

Legitimate device-code sign-ins exist - for TVs, consoles, and command-line tools - but they always begin with something you did on a device you control. Before typing a code anywhere, run through this:

• Did I start this flow myself, on my own hardware, within the last few minutes?
• Does the confirmation screen name the specific app I expect, or something vague?
• Did the code, or the instruction to enter one, arrive from an email, a page, or a caller? If so, stop - supplying that code is the entire attack.
• Am I on the provider's real sign-in domain, reached by typing it or a bookmark, not by a link I was handed?

There is no legitimate scenario in which a message from someone else supplies a code for you to approve.

When "the scanner said clean" is not enough

None of this makes URL scanners useless - it narrows what a clean verdict proves. It proves the scanner saw nothing wrong in what it could see, which for a runtime-decrypted page is very little. The practical adjustment is to keep judging messages on context: whether you expected them, whether they manufacture urgency, and whether the link ends at an authentication prompt. For security teams, the same logic argues for controls that watch pages where they render, and for making it easy for staff to report a page even after a scanner passed it. And if a click already happened, follow the steps in what to do if you clicked a phishing link rather than waiting for a verdict to change.

Why the browser is the right place to catch this

Ghost phishing is a clear example of why the last mile matters. By the time the dangerous page exists, it exists in the browser - which is also the one place that sees the decrypted DOM, the injected form, and the device-code prompt as the user sees them. PhishClean analyzes the page after it renders and re-checks it as it changes, so a payload that only appears at runtime is still analyzed at runtime, not waved through because the link looked fine.

Last updated: 13 August 2026