BlobPhish: The Fake Login Page That Never Touches the Internet

Most phishing pages are real websites. An attacker rents a server, uploads a copy of a Microsoft 365 login screen, and sends out a link. That server is also the weak point in the attack, because security tools can look it up, score its reputation, and block it. BlobPhish was built to remove that weak point. The fake login page never sits on a server waiting to be found. It is assembled inside the victim's own browser at the moment they click.

Researchers at ANY.RUN have tracked this campaign since October 2024, and activity climbed sharply in early 2026. It targets Microsoft 365, OneDrive, SharePoint, webmail, and major financial institutions, which are the same logins our staff uses every day. The lure is an ordinary email: a shared document, an urgent account alert, a payment notice, or a reservation problem. The link often passes through a trusted-looking service or a shortened address before landing on a small loader page.

That loader carries the entire fake login screen as an encoded block of text. Using JavaScript, it decodes the text and builds it into a Blob object, which is a temporary chunk of data held in browser memory. It then tells the browser to open that object through a special blob: address. Once the page is on screen, the loader revokes the address and cleans up after itself, so by the time anyone investigates, the cache has nothing to show.

Consider what each of our controls actually looks at. Email gateways and URL reputation services judge the link in the message, and that link points to a loader, not to a login form. Web proxies see the redirect and later the stolen credentials leaving, but they never see a request for the page the user was looking at. File-based endpoint tools find nothing written to disk. With no persistent phishing domain serving the login page, there is nothing for most tools to flag, which is a large part of why the technique has stayed productive for so long.

There is a second problem. One research report links similar kits to a phishing service built to relay multifactor codes in real time, passing whatever the user types into the fake page along to the real service while the attacker waits. If that is what a victim is facing, a correct code entered on the wrong page still hands over the account, so multifactor authentication alone cannot be treated as a safety net.

The most reliable clue on the user side is the address bar. A genuine Microsoft login comes from a Microsoft address such as login.microsoftonline.com. A BlobPhish page starts with blob:https:// followed by a long string of characters. Everything after that prefix names the site that built the page, so a familiar-looking login form sitting on top of an unfamiliar name is a mismatch that should stop anyone before they type.

The password manager offers a second clue. It matches saved logins to real addresses, so when it stays silent on a page that looks identical to one it normally fills, that silence is worth treating as a warning. After the fact, victims often describe the page disappearing or changing once they submitted, or they notice unexpected multifactor prompts or lockouts on the real account.

When a user reports a login prompt that felt wrong, the first job is to stop further damage and preserve evidence. Have them close the tab without entering anything more, then open a fresh window and reach the official site by typing the address themselves. Collect the original email with its headers, the full address from the address bar if they still have it, and a description of the message. If they typed a password, make sure they do not reuse it anywhere else until it has been changed.

Any confirmed credential entry should go straight to the security team, because the account needs review and session revocation, not only a password reset. Several similar reports in a short window should be treated as one coordinated campaign rather than separate tickets, since that pattern is what allows broader monitoring and a targeted warning to the people most likely to receive the same lure.

Speed matters because an attacker holding a valid session may already be inside the mailbox. Revoke sessions and reset credentials first. Then review mailbox rules, application consent grants, newly registered devices, and any added authentication methods, since those are how attackers keep access after a password changes. Examine proxy and endpoint logs for the initial redirect domains and for POST requests to exfiltration paths such as res.php, a path ANY.RUN documented in this campaign. If more than one account shows the pattern, widen the hunt across the environment and update detection content.

Scope matters just as much as speed. A compromised mailbox that held player information or tribal member data raises notification questions and data sovereignty obligations, so compliance and legal contacts should be brought in early rather than after the technical work is done.

Because a page like this cannot be blocked by reputation, the stronger defenses shrink the value of what gets stolen and the time available to use it. Conditional access policies that require compliant devices, paired with continuous access evaluation, make a stolen password far less useful on its own. Phishing-resistant authentication such as security keys or passkeys goes further, because those methods are tied to the real site and will not complete on a fake one, which removes the code relay problem entirely. Shorter session lifetimes and mandatory reauthentication for sensitive actions narrow the window for a stolen token. Strict SPF, DKIM, and DMARC enforcement limits spoofed senders, and browser management and application control policies reduce the chance that an unapproved loader runs at all.

A fake login that never touches the network cannot be caught by a filter that watches the network. What catches it is a team member who glances at the address bar, a help desk analyst who asks for the right details, and an administrator who revokes a session in minutes instead of days. Our frontline staff is the first line of defense against malicious actors who would seek to compromise organizations like ours, and BlobPhish is a clear example of why. If a login page feels wrong, close it and report it. A report that turns out to be nothing costs a minute. A password typed into the wrong page can cost a great deal more.