The Phishing Site Was Never Online. It Was Built Inside Your Browser.
A security scanner looking for the phishing page on the public internet could find nothing. The page did not exist there in the conventional sense. It was assembled inside the victim’s browser after the click.
Barracuda researchers analysed a DocuSign-themed campaign that combines a calendar invitation, legitimate Microsoft redirect services, a browser blob: URL, a service worker and attacker-controlled infrastructure. SecurityWeek independently reported the findings on 9 September.
This is not a browser vulnerability and it is not a zero-click attack. The victim must follow the lure. The defensive significance is the location of the deception: the malicious credential page is created locally, outside the familiar model of a persistent phishing URL that defenders can crawl, classify and block.
The attack borrowed trust at every step
The email presents a document-signing request and includes a calendar attachment. Opening the event reveals another link. Barracuda says the redirect path then moves through legitimate Microsoft OAuth and Teams infrastructure before reaching an external resource.
Each recognisable service can reassure the victim and complicate simple filtering. A security control may see Microsoft domains early in the chain, while the user sees a business process they already understand.
The chain eventually loads attacker-controlled content from cdn.bloom[.]io. JavaScript converts that material into a blob object and assigns it a temporary URL inside the current browser context. The resulting address begins with blob: rather than an ordinary web scheme.
A blob URL is a browser object, not a normal website
Web applications use blob URLs for legitimate local data such as generated files, media and previews. The browser holds the object in memory and gives the page a temporary reference to it.
That same capability can hold malicious HTML. The final phishing interface appears in the browser, but there may be no stable public URL containing the complete page for a gateway or takedown provider to retrieve later.
A blob URL is also scoped to the browser context that created it. Copying the visible address into another system may not reproduce the page. Analysts need the redirect chain, network requests, script behaviour and browser state, not only the final address bar.
The service worker keeps the workflow flexible
Barracuda says the campaign registers a service worker and uses a sandboxed iframe as part of the locally generated page. Service workers normally support offline applications, caching and background web behaviour. Here, the attacker uses browser functionality to coordinate a credential-stealing workflow.
The backend can decide what a particular visitor sees, redirect unsuitable traffic or alter the page without publishing one permanent artefact. That makes automated detonation less reliable when the analysis environment does not follow the same path as the intended victim.
The technique does not make the attack invisible. The browser still requests external code and sends captured information somewhere. It changes which evidence is durable and which controls see the complete chain.
Blocking the last URL is too late and too narrow
Traditional phishing response often begins with the final landing page. Teams add the domain to block lists, submit it for takedown and search email for the same URL. A locally assembled page weakens that centre of gravity.
Defenders need to retain the full sequence: the original message, the calendar object, every redirect, the external script requests, service-worker registration and any credential submission. Trusted domains in the middle should be treated as hops, not proof that the destination is safe.
What defenders should change
- Inspect calendar attachments and invitations as active phishing content, not harmless context around an email.
- Follow complete redirect chains through OAuth, Teams and other high-reputation services before assigning trust.
- Alert on suspicious credential interfaces loaded from blob URLs, especially when preceded by an external script or document-signing lure.
- Collect browser and network telemetry that records service-worker registration, iframe creation and data submission.
- Use phishing-resistant FIDO2 credentials or passkeys. A convincing fake page cannot replay an origin-bound authentication assertion to a different domain.
- Train responders to preserve the original browser session when safe. The final blob URL alone may not reproduce the evidence.
- Review controls that automatically allow trusted redirectors. Reputation must be evaluated across the whole path.
The BlackTree view
The web platform is designed to let applications generate content, cache resources and compose experiences inside the browser. Attackers are using those same capabilities to move the decisive malicious artefact closer to the victim and further from the scanning infrastructure.
The answer is not to block every blob URL or service worker. Modern applications depend on them. The answer is to stop treating a URL as the whole attack. In this campaign, trust was accumulated across the chain and the phishing page was only the final local product.
Sources
- Barracuda: Browser-based phishing uses blob URLs and Microsoft redirects, published 9 September 2026. The page provides no exact publication time.
- SecurityWeek: New Phishing Attack Creates Malicious Pages Inside the Victim’s Browser, published 9 September 2026 at 06:00 ET.
