Researchers at Barracuda documented a phishing campaign that never hosts a phishing page anywhere. The fake login screen is assembled inside the victim's browser using a blob URL, a temporary browser-generated address that points to content held in local memory. This analysis draws on reporting from Help Net Security.

"Instead of delivering a phishing page from a web server, the malicious content is assembled inside the victim's browser using a blob URL," Barracuda researchers explained.

The chain starts with a DocuSign-themed email carrying a calendar invite as an attachment. The invite is decoration. What matters is that the link points to a genuine Microsoft OAuth endpoint, and a crafted redirect parameter then hands the victim off to Microsoft Teams, which loads a resource from the external domain cdn.bloom[.]io.

Traditional phishing kits live on a server your security stack can fetch, render, and score. That is what has changed here. There is no attacker-controlled login page to retrieve, so URL scanners, secure email gateways, and proxy inspection follow the link and see legitimate Microsoft infrastructure.

For your organization, this means the controls that catch most credential theft attempts are structurally blind to this one. Domain reputation, URL blocklists, and detonation sandboxes all depend on malicious content existing somewhere remote. In this campaign, the malicious content only exists after it reaches the user's machine.

How the Browser Assembles the Phishing Page

The chain works because every hop before the final page resolves to infrastructure your users already trust. A crafted redirect parameter appended to the Microsoft OAuth request hands the session off to Microsoft Teams, and Teams then loads a resource from an external domain, cdn.bloom[.]io. At that point the victim's browser has done all the fetching, and the phishing content is rendered from a blob URL on the local machine.

That sequence matters for detection because the parts that look malicious never appear where security tooling usually looks. The domains in the redirect chain belong to Microsoft. The one third-party domain in the path serves what looks like a content delivery request.

Once the page is assembled in memory, two browser features carry the rest of the operation:

• A service worker registration. A service worker is a script the browser keeps running in the background, independent of the page that installed it. Registering one tied to externally loaded content gives the operator a persistent execution context inside the browser session.
• A sandboxed iframe. Part of the page's logic runs inside this nested frame, which splits the functional pieces of the attack across separate browser contexts instead of concentrating them in one inspectable document.
• Browser messaging as the control channel. The attacker's backend sends live instructions to the rendered page through this messaging path, so what the victim sees can be changed mid-session.

That last point is the operational difference from a static credential harvesting kit. A conventional phishing page has a hardcoded redirect and a fixed form, so once analysts pull it apart, its behaviour is known. Here the operators steer the page while the victim is still looking at it, which means two victims hitting the same chain can be shown different content.

Barracuda found hidden command-and-control configuration embedded in the page, and described the finding plainly: 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. Phishing-as-a-service platforms are run like products, with tenants, updates and support, and that changes the economics for defenders because a single takedown does not remove the capability.

Mapped to MITRE ATT&CK, the entry point is Phishing: Spearphishing Link (T1566.002) combined with Impersonation (T1656) through the document-signing pretext, and it depends on User Execution: Malicious Link (T1204.001) to complete. The distinguishing behaviour sits after the click, where the payload is constructed client-side and the malicious logic never traverses the network as a recognisable file or page.

The evasion value is straightforward. URL blocklists have nothing to match, because the final page has no URL that exists outside the victim's browser memory. Reputation scoring on the redirect chain returns clean results, because the hops are Microsoft OAuth and Teams. Email gateways that check only the first hop of a link see a legitimate destination.

For an organisation, the practical consequence is that a credential compromise here can occur without generating any of the artifacts an investigation normally starts from: no suspicious domain, no downloaded file, no blocked URL event. The trail runs through browser-side activity and identity telemetry, which is where the anomaly, if any, will show up.

Why Existing Email and Web Filtering Misses This

Your secure email gateway scores this message on the first hop, and the first hop is a genuine Microsoft OAuth endpoint. Reputation checks pass, domain age checks pass, and the sender lure references a document-signing request that arrives in most inboxes every week. Nothing in the message body gives the filter a reason to hold it.

URL rewriting has the same problem. Click-time protection resolves the rewritten link, sees a Microsoft authorization request, and lets the session through. The redirect parameter that steers the victim onward is a query string on a legitimate request, so the rewrite engine has no bad destination to compare against a blocklist.

Sandbox detonation adds little here. The calendar invite attached to the email carries no executable content, so detonating it produces a clean verdict. And because the final page pulls live instructions from the attacker's backend through browser messaging, what an automated analysis environment sees is under the operator's control. A sandbox and a real employee can be shown different things from the same starting link.

That combination means the money you have already spent on gateway filtering, link rewriting and attachment analysis does not reliably catch this chain. Those controls are still worth having for commodity phishing, but they are keyed to a server-hosted page and a suspicious domain, and this campaign has neither.

The business consequence starts with credentials. Once an operator holds a working Microsoft 365 login for one of your staff, the common outcome is business email compromise: mailbox rules that hide replies, quiet monitoring of finance threads, and payment redirection requests sent from a real internal account that your suppliers and clients have corresponded with for years. Your own customers absorb part of the damage, which turns a security incident into a commercial one.

Multi-factor authentication is not a complete backstop against a page the attacker can drive in real time. Barracuda's advice to move to FIDO2 keys or passkeys is a signal that one-time codes and push approvals are exposed when an operator can relay what the victim enters as they enter it. If a session is established that way, the attacker inherits an authenticated session and your MFA logs show a successful, policy-compliant sign-in.

Then comes the evidence problem, and this is where the cost tends to surprise finance. Your proxy logs record a chain of trusted Microsoft destinations and one external content fetch. There is no phishing URL to submit for takedown, no hosted page to preserve as evidence, and no copy of the fake login screen on any server you or law enforcement can seize, because it only ever existed in one browser's memory and vanished when the tab closed.

That gap shapes your notification decisions. Under GDPR and equivalent sector rules, you have to determine whose data was exposed and when, and here you are reconstructing that from sign-in telemetry, mailbox audit records and token issuance history rather than from a captured phishing kit that lists what fields it harvested. Investigations built on inference take longer, cost more in responder hours, and leave counsel less comfortable narrowing the notification scope.

Barracuda also noted hidden command-and-control configuration indicating a centrally managed platform operating across many victims. Practically, that means finding and resetting one compromised account in your tenant does not tell you the campaign has stopped targeting the rest.

Detection Signals Available at the Endpoint and Identity Layer

Every artifact this campaign produces lands on the victim's machine. The service worker registration, the sandboxed iframe, the browser messaging traffic to the operator's backend, and the blob: URI itself all exist as local browser state, which means endpoint and identity telemetry carry the evidence that network and email inspection never sees.

On the endpoint, process lineage is the first usable signal. A mail client spawning a browser process, followed within seconds by an authentication prompt and then a credential submission to a non-Microsoft destination, is a sequence EDR records in full even when every intermediate domain resolves cleanly. Correlating the child process with the calendar invite attachment gives investigators the initial delivery artifact, and attachment metadata at the gateway (text/calendar parts arriving alongside a document-signing lure) preserves the lure for retrospective hunting after a compromise surfaces elsewhere.

Browser telemetry adds the parts that URL-based tooling structurally cannot capture:

• Service worker registrations originating from externally loaded content, which is unusual behavior in an authentication context and is the mechanism that keeps the page under remote control.
• blob: and data: URI activity in the same tab session as a sign-in flow, visible in browser history and in extension or browser-security tooling that logs URI scheme usage where policy permits it.
• Rendered DOM inspection, which sees a Microsoft-styled credential form built in memory. The page looks legitimate at the URL layer and clearly forged at the DOM layer.
• Cross-origin postMessage traffic between the page and its iframe, which is how the operator changes what the victim sees mid-session.

In ATT&CK terms the delivery maps to T1566.002 (Spearphishing Link) with a phishing-for-credentials objective under T1656-adjacent impersonation of a trusted brand, while the browser-resident rendering functions as defense evasion against reputation and URL-path controls. For an IT manager, the practical translation is that the detection engineering surface moves from "block the bad domain" to "recognize the behavior on the host."

The identity layer supplies the second, often earlier signal set, because credential theft only pays off when the stolen material is used. Sign-in logs show the outcome of a successful capture: authentication from an ASN belonging to a hosting or VPS provider rather than a residential or corporate range, a device ID and user agent with no prior history for that account, and geographic sequences that fail impossible-travel logic. Token-based follow-on activity shows up as session replay without a corresponding interactive authentication event, mapping to T1539 (Steal Web Session Cookie) and T1550.001 (Application Access Token).

OAuth and consent telemetry deserves separate attention because this campaign already routes victims through an authorization endpoint. Directory audit logs record application consent grants, service principal additions, and new permission scopes, and any of those appearing shortly after a suspected click on a document-signing lure is a high-value correlation. Attackers who obtain a consent grant retain mailbox or file access after a password reset, which extends the exposure window well past the point when the phishing email is remediated (T1528, Steal Application Access Token).

Conditional Access sign-in logs, mailbox audit events such as new inbox rules or forwarding changes, and MFA registration or device-join records complete the picture. If your investigation starts from an identity anomaly and works backward to the endpoint process tree, both halves of the chain are recoverable.

Controls to Apply Now and Over the Next Quarter

Start with phishing-resistant MFA. Enforce FIDO2 security keys or passkeys on administrative accounts, finance and payables staff, and anyone who can change tenant configuration or approve a payment. Barracuda names this as the primary control for a reason: a hardware-backed authenticator binds the login to the real origin, so a credential form assembled locally in the browser has nothing usable to relay onward.

Before you can enforce browser restrictions, you need to know where you can enforce anything. Pull a list of accounts still sitting on SMS or push-approval MFA, and a list of endpoints where the browser is actually under enterprise policy management. Personal and unmanaged devices are where this technique keeps working, because none of the client-side controls below reach them.

Once that inventory exists, apply the preventive controls in this order:

• Block or quarantine .html and .htm attachments at the mail gateway, since locally rendered content is the delivery model this campaign depends on.
• Set browser policy to restrict navigation to data: and blob: URIs from top-level windows, which removes the container the fake login page renders in.
• Configure your email security tooling to follow a link's entire redirect path instead of scoring only the first hop, as Barracuda recommends.
• Turn on token protection and Conditional Access session controls so an issued session cannot be replayed from a different device or network.

Add browser-security or DOM-inspection tooling over the next quarter. It gives you visibility into what a page assembles after load, including service worker registrations tied to externally loaded content. For most firms this is the difference between knowing a user clicked and knowing what the page did once it was in memory.

That guidance points at your identity layer as the place where this campaign becomes visible and stoppable. In environments Capstone manages, Adlumin monitors authentication behavior and OAuth authorization flows across managed environments, surfacing redirect chains that resolve to unexpected destinations and sign-ins that do not match a user's normal device or location pattern.

Your response plan needs one specific capability: mass session revocation. Write the steps down and confirm who can execute them, because on a credential-compromise call you will be revoking refresh tokens tenant-wide, rotating affected passwords, and reviewing sign-in telemetry for the accounts involved. Revoke on suspicion rather than waiting for proof, since a valid session survives a password change on its own.

Rehearse that playbook as a tabletop and time it. If revoking sessions across your tenant takes hours because nobody has the right role assigned or the runbook lives in one person's head, you find that out during the exercise instead of during an incident.

Finally, rewrite your awareness training to match what users actually see here. The lure is a document-signing request with a calendar invite attached, and every domain in the chain before the final page belongs to Microsoft. Train staff to treat unexpected signature requests as worth verifying by a separate channel, even when the address bar shows a Microsoft authorization page. Then review the training content again after your next simulated campaign to see whether attachment-based and invite-based lures are actually being reported.

Shifting Detection to Where the Attack Actually Runs

The takeaway from Barracuda's research is narrow and useful: the phishing page in this campaign has no address you can block, because it only ever exists as browser memory on the machine of the person being targeted. That changes what your detection coverage is actually measuring. Email and network inspection answer whether a destination looks bad, and in this chain every destination resolves cleanly, so those tools return a clean verdict on a session that is stealing credentials.

The hidden command-and-control configuration Barracuda found matters for the same reason. Because the operators run this as a managed platform that can be updated and steered across many victims at once, the lure, the loaded resource, and what the victim sees at the end are all changeable settings. Any indicator you write against this campaign describes one configuration on one day, which is why identity behaviour and browser-level telemetry hold their value longer than a URL list.

The single action worth prioritizing is phishing-resistant authentication for your users. A credential typed into a form assembled locally is only valuable if it can be replayed against your tenant, and hardware-backed authenticators remove that possibility. As Ashitosh Deshnur of Barracuda put it, the emphasis belongs on identifying malicious behaviour and strengthening identity-based controls instead of blocking known phishing URLs. If you are deciding where to spend the next round of effort, put it there before adding another layer of link inspection.