Instead of sending victims to a hosted credential-harvesting page, the attackers generate the phishing page directly inside the victim’s browser using a blob URL.
This technique makes detection harder because the phishing page does not exist as a normal internet-accessible webpage.
Security tools cannot easily crawl, analyze, categorize, or blocklist it before a victim opens the link. The page is created temporarily in the browser’s memory during the attack session.
The campaign also uses legitimate Microsoft services, including Microsoft OAuth redirects and Microsoft Teams domains, to make the attack chain appear more trustworthy.
Victims may see Microsoft infrastructure in the browser rather than an unfamiliar phishing domain, reducing obvious warning signs.
Browser-Embedded Phishing Pages Emerge
The attack begins with a DocuSign-themed phishing email designed to look like a business document request. The message includes a calendar invitation file, which helps make the email appear routine and less suspicious.
The calendar file itself does not directly contain a conventional phishing link. Instead, it points to a legitimate Microsoft OAuth endpoint.
Attackers abuse a crafted redirect parameter to route the victim through Microsoft’s authentication infrastructure and then to Microsoft Teams.
The attack flow is designed to exploit trust in familiar services:
- The victim receives a DocuSign-branded email with a calendar invite attachment.
- The attachment directs the victim to a legitimate Microsoft OAuth address.
- A manipulated redirect sends the browser to Microsoft Teams.
- Teams retrieves an external resource from
cdn.bloom[.]io.
A blob URL is generated by the browser and points to data stored in the local browser session rather than a remote web server. As a result, the phishing content is not exposed through a stable, publicly accessible URL that defenders can scan or block.
Barracuda researchers said the phishing page uses service workers and sandboxed iframes to manage the attack workflow.
A service worker is a browser component that can intercept requests, control caching, and support background activity. In this campaign, it can help attackers control navigation and phishing-related requests after the page loads.
The sandboxed iframe adds another layer of separation and control. It allows parts of the phishing process to run inside an embedded browser frame, making the overall activity more difficult to inspect with traditional URL-based controls.
The phishing page also receives instructions from attacker-controlled backend infrastructure through browser messaging functions.
This means the operators do not need to hardcode every redirect or destination into the phishing page.
They can dynamically change the victim’s path, update phishing content, or redirect users to different login prompts in real time, Barracuda said.
Researchers found hidden command-and-control configuration indicating that the operation is part of a centrally managed phishing platform.
This gives attackers flexibility to update campaigns across multiple targets without deploying a new phishing site each time.
Detect 58% more threats with fresh intelligence from 16K+ organizations. Integrate TI Feeds in you SOC
