Threat Spotlight: Phishing pages that exist only inside the victim’s browser

How attackers abuse Microsoft OAuth redirects, Teams domains, blob URLs, and service workers to deliver phishing pages without a traditional phishing site.

Key takeaways

• Barracuda researchers have analyzed an attack campaign that replaces the traditional phishing site with a phishing page generated inside the victim’s browser using blob URLs.
• Victims are routed through legitimate Microsoft services, making the attack appear trustworthy and reducing common warning signs.
• Service workers, sandboxed iframes and remote infrastructure allow attackers to dynamically control the phishing experience and evade traditional detection methods.

Most phishing campaigns rely on a hosted webpage that security tools can retrieve, analyze, categorize, and eventually block. A recent campaign analyzed by Barracuda researchers breaks that model.

Instead of delivering a phishing page from a web server, the malicious content is assembled inside the victim’s browser using a blob URL — a temporary browser-generated URL that points to content stored locally in memory rather than on a website.

By the time the phishing page appears, the victim has already been routed through legitimate Microsoft services, including Microsoft OAuth and Microsoft Teams, with little visible indication that anything malicious is taking place.

What makes this attack different?

Unlike conventional phishing campaigns that rely on a hosted lookalike website, this attack uses a browser-resident architecture designed to reduce its visibility to both users and security tools.

• No phishing page to block. The phishing content is never served as a conventional webpage. Instead, it is rendered from a blob URL generated inside the victim’s browser. Because the page exists only within that browser session, there is no persistent phishing URL for security tools to retrieve, analyze or blocklist in advance.
• Trusted Microsoft services throughout the attack chain. Rather than directing victims to an obviously suspicious website, the attack routes them through legitimate Microsoft infrastructure, including login.microsoftonline.com and Microsoft Teams. Because the visible navigation remains within trusted Microsoft services, users and automated scanners may be less likely to identify the activity as malicious.
• Browser-based phishing execution. Once the blob-based phishing page loads, it registers a service worker and executes part of the workflow inside a sandboxed iframe. Together, these components help manage requests, control navigation and coordinate the phishing experience from within the browser session itself.
• Dynamic attacker control. The phishing page receives instructions from backend infrastructure using browser messaging mechanisms. Because the workflow is controlled dynamically rather than through hardcoded redirects, operators can modify destinations and behavior in real time.
• Added legitimacy. The email includes a calendar invitation file as a benign attachment. While not part of the malicious payload, it helps the message resemble routine business communication and may increase recipient trust.

Attack flow

1. The victim receives a DocuSign-themed email.

2. A calendar invite file is attached to the email. It does not appear malicious because it points to a legitimate Microsoft OAuth endpoint. It is included to make the email look like a normal business meeting or calendar invitation. 

3. A crafted redirect parameter routes the user to Microsoft Teams.

4. Microsoft Teams loads an external resource hosted on cdn.bloom[.]io.

5. The browser converts that content into a blob URL.

6. The blob URL renders the phishing page locally within the browser.

7. Service workers, iframes and backend controls manage the phishing workflow and user navigation.

8. Hidden command-and-control configuration shows this is not a standalone page but part of a managed phishing platform that can be centrally operated, updated and steered across many victims at once.

Together, these mechanisms provide the attacker with real-time control over the phishing workflow within the victim’s browser session, enabling a level of flexibility and evasiveness not typically seen in static phishing pages.

Detection and defense

This campaign demonstrates how phishing is evolving beyond fake websites and suspicious domains and reducing many of the indicators that security teams have traditionally relied upon for detection.

Organizations should focus on identifying malicious behavior and identity controls rather than simply blocking known phishing URLs. Key defensive measures include:

• Monitoring OAuth authorization flows and redirect chains for unusual or unexpected destinations.
• Inspecting browser activity involving blob URLs, particularly when they are used to render login pages or authentication workflows.
• Detecting suspicious service worker registrations associated with externally sourced content.
• Applying phishing-resistant multifactor authentication methods such as FIDO2 security keys and passkeys.
• Using email security controls that analyze the full click path rather than relying solely on the initial URL.
• Training users to be cautious of unexpected document-signing requests, even when links appear to use trusted Microsoft infrastructure.

As attackers increasingly move phishing workflows into the browser itself, defenders will need to place greater emphasis on identity protection, browser security and behavioral detection. The challenge is no longer just spotting a malicious website. In campaigns like this, the phishing page may never exist anywhere except in the victim’s browser.