Cybercriminals are building phishing pages that exist only inside victims’ browsers

1. Executive summary

Barracuda researchers describe an active phishing campaign that routes victims through genuine Microsoft OAuth and Teams infrastructure and then renders the credential-harvesting page entirely inside the victim's own browser using a blob URL — a temporary browser-generated URL pointing to content held in local memory rather than served from a web server. Because the malicious page is never hosted at a static, blockable location, traditional URL reputation and domain takedown controls are largely blind to it. The page registers a service worker and runs logic in a sandboxed iframe, receiving live instructions from the operator's backend via browser messaging — Barracuda assesses it as part of a centrally managed phishing platform rather than a standalone page. Attribution is not stated in the source material; no MITRE actor profile is resolved for this item, so treat any attribution as unconfirmed. Primary risk to EMEA financial services is Microsoft 365 / Entra ID credential and OAuth-token theft that bypasses link-scanning and domain-blocking controls, with follow-on risk of mailbox access, fraud enablement, and OAuth consent abuse.

2. Regulatory framing

No other specific DORA/NIS2/UK NIS article is directly engaged by this item on the facts available.

3. Technical analysis & attack chain

Confirmed attack chain (per Barracuda)

1. Initial access — DocuSign-themed email. The victim receives a phishing email impersonating DocuSign, carrying a calendar invite as an attachment. The invite is not the payload; it exists to make the message look like an ordinary meeting request.
2. Trusted redirect — genuine Microsoft OAuth endpoint. The lure points to a genuine Microsoft OAuth endpoint rather than an obviously suspicious destination. A crafted redirect parameter then sends the victim to Microsoft Teams.
3. External resource load. Teams loads a resource hosted on the external domain cdn.bloom[.]io.
4. Browser-resident rendering — blob URL. The external resource ultimately causes the phishing page to be rendered from a blob URL entirely on the victim's machine. The malicious content is assembled inside the victim's browser; the blob URL is a temporary browser-generated URL pointing to content stored locally in memory, not on a web server. There is no static phishing site to detect, block, or take down.
5. Persistence and live control. Once loaded, the page registers a service worker and runs part of its logic inside a sandboxed iframe. These components let the attacker's backend send live instructions to the page through browser messaging, allowing operators to change what the victim sees without relying on a hardcoded redirect.
6. Managed platform. Barracuda describes hidden command-and-control configuration showing 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.

Defender-relevant specifics

• Component abused: Microsoft OAuth authorization flow (redirect parameter abuse) and Microsoft Teams (external resource hosting/loading). The trust anchor is Microsoft's own infrastructure, not a spoofed domain.
• Why detection fails: URL scanners that inspect only the first hop see a legitimate Microsoft OAuth endpoint. The final credential-harvesting page never exists at a fetchable URL — it is generated client-side from a blob object.
• Live C2 channel: Service worker + sandboxed iframe + browser messaging gives the operators a dynamic channel into the rendered page. This means page content, and potentially the exfiltration destination, can be changed per-victim or mid-session.
• Observed impact: Credential capture against Microsoft login flows is the campaign's purpose; the source does not document post-compromise activity (mailbox access, token theft outcomes, or fraud transactions), so do not assume specifics beyond credential harvesting.

Context from related reporting (corroborating the trend, not this specific campaign): Check Point documented a separate campaign (June 25 – mid-July, 200+ phishing emails, ~120 organisations) abusing Microsoft's legitimate authentication system via Microsoft Planner task-assignment lures, and Unit 42 documented Browser-in-the-Browser phishing against Microsoft 365 users with fake login popups and spoofed OAuth URLs. These are distinct campaigns but confirm a sustained, multi-vendor-observed shift toward abusing genuine Microsoft authentication infrastructure rather than spoofing it.

Confidence caveat: The technical detail of this specific campaign — the DocuSign lure, the cdn.bloom[.]io resource, the service worker/sandboxed-iframe architecture, and the "managed phishing platform" assessment — is single-sourced to Barracuda via Help Net Security and SecurityWeek coverage of the same research. SecurityWeek corroborates the blob-URL technique and the Microsoft-services trust abuse but adds no independent technical detail. Verify before enforcement actions.

4. Mitigation & containment

P1 — within 24 hours

• Hunt for the technique, not the domain: query proxy, SWG, DNS, and EDR telemetry for the confirmed sequence: Microsoft OAuth/Teams referers followed by a load of cdn.bloom[.]io, and any blob: navigation or service worker registration occurring in an authentication context. Treat blob: URLs in login/authentication flows as suspicious by default.
• Block/monitor the one confirmed external indicator: add cdn.bloom[.]io to watchlists (block with caution — assess whether legitimate use exists in your estate first; the domain is the only external host named in the source).
• Enforce phishing-resistant MFA on all Microsoft 365 / Entra ID authentication: FIDO2 security keys or passkeys, per Barracuda's recommendation. Prioritise privileged and finance-function accounts. This is the single control that most directly blunts credential harvesting regardless of page realism.
• Review recent authentication anomalies for evidence of successful harvests: impossible travel, new device registrations, MFA-fatigue patterns, and token/session anomalies on accounts that received DocuSign- or calendar-invite-themed mail in recent weeks.

P2 — within 72 hours

• Upgrade email security link analysis to full-path traversal: Barracuda explicitly recommends email security tooling that follows a link's entire path — OAuth redirect parameters, Teams-hosted resources, and the final rendering context — rather than detonating only the first hop. If your current gateway only inspects the initial URL, this campaign is designed to defeat it.
• Browser/endpoint policy: where the enterprise browser stack supports it, restrict or alert on service worker registration from externally loaded content and on blob: navigations in authentication contexts. This is Barracuda's stated detection guidance.
• Conditional Access hardening: require compliant/managed devices for authentication, and review sign-in risk policies so a harvested credential alone is insufficient for access.
• User communication: brief staff that document-signing requests are to be questioned even when they run through trusted Microsoft infrastructure — the lure's calendar invite and OAuth redirect are genuine Microsoft elements by design.

P3 — within 7 days

• Update phishing simulation programme: add scenarios that use genuine OAuth redirect chains and browser-resident rendering rather than fake login pages on lookalike domains. Traditional simulations that test "spot the fake domain" do not exercise the judgement this campaign requires.
• Threat-led testing: incorporate the full chain (trusted-infrastructure redirect → external resource → blob URL render → service worker registration) into DORA Art. 24 resilience testing scenarios against the M365 authentication path.
• Detection engineering: build the Sigma-style logic in §6 into your SIEM if service worker registration and browser navigation events are collected.

5. Indicators of compromise

Only one atomic indicator is present in the source material. The campaign's core observable value is behavioural.

domain  cdn[.]bloom[.]io

Behavioural indicators (per Barracuda; these are the primary detection surface for this technique):

6. Detection

The sources contain one usable atomic artefact (cdn.bloom[.]io) and no file hashes, distinctive strings, mutexes, or command-line indicators from the phishing page itself. A YARA rule is not appropriate — there is no file content to match. Network/SWG detection is the correct surface.

title: Blob-URL Phishing via Microsoft OAuth/Teams and cdn.bloom.io
id: 7c1f2a44-8b3e-4d19-9f6a-2e5b8c1d0a47
status: experimental
description: >
  Detects the observed chain for the browser-resident blob-URL phishing campaign
  reported by Barracuda: a Microsoft OAuth/Teams context loading an external
  resource on cdn.bloom.io, which renders the phishing page from a blob URL.
  Correlate with service worker registration and authentication-context
  blob: navigations where browser telemetry is available.
references:

  - https://www.helpnetsecurity.com/2026/09/10/browser-based-phishing-blob-urls-microsoft-oauth/
  - https://www.securityweek.com/new-phishing-attack-creates-malicious-pages-inside-the-victims-browser/
author: Adverse Trace
date: 2026/09/10
logsource:
  category: proxy
detection:
  selection_bloom:
    cs-host|endswith: '.bloom.io'
  filter_legitimate:
    cs-referer|contains:

      - 'teams.microsoft.com'
      - 'login.microsoftonline.com'
  condition: selection_bloom
falsepositives:

  - Legitimate use of the bloom.io CDN, if any exists in the estate — validate before blocking
level: high

Note: the filter_legitimate selection is included for triage context (the attack chain routes through those Microsoft hosts); the condition fires on the external resource load regardless of referer. If your proxy logs preserve full redirect chains, additionally alert on any chain that begins at a Microsoft OAuth endpoint and terminates in a blob: navigation — that is the technique's signature and is not captured by any domain-based rule.

7. Sources

• Help Net Security — Cybercriminals are building phishing pages that exist only inside victims' browsers — https://www.helpnetsecurity.com/2026/09/10/browser-based-phishing-blob-urls-microsoft-oauth/ — 2026-09-10
• SecurityWeek — New Phishing Attack Creates Malicious Pages Inside the Victim's Browser — https://www.securityweek.com/new-phishing-attack-creates-malicious-pages-inside-the-victims-browser/ — 2026-09-10
• Help Net Security — Attackers are using Microsoft's legitimate login system to camouflage phishing attacks (context: corroborating trend, Check Point research) — https://www.helpnetsecurity.com/2026/07/30/microsoft-authentication-system-phishing/ — 2026-07-30
• Help Net Security — New Browser-in-the-Browser phishing uses fake login popups to steal Microsoft 365 credentials (context: corroborating trend, Unit 42 research) — https://www.helpnetsecurity.com/2026/06/10/browser-in-the-browser-phishing-microsoft-365-users/ — 2026-06-10

8. Adverse Trace position

This is a technique-level threat, not a vulnerability with a patch path: there is no CVE, no vendor fix, and no static infrastructure to take down, which is precisely the point of the design. Severity for EMEA financial services is high — the campaign targets the Microsoft 365 identity perimeter that nearly every client operates, defeats first-hop link inspection and domain blocklists by construction, and includes a live C2 channel into the rendered page, meaning per-victim adaptation and rapid infrastructure change. The core technical claims are single-sourced to Barracuda (corroborated in trend terms by independent Check Point and Unit 42 reporting on adjacent Microsoft-infrastructure-abuse campaigns); verify the cdn.bloom[.]io indicator against your own telemetry before enforcement, and treat attribution as unconfirmed — none is claimed in the source. Clients should move weight from URL-based controls to identity-based ones: phishing-resistant MFA (FIDO2/passkeys) everywhere, full-path link analysis at the email gateway, and behavioural detection of blob: authentication navigations and service worker registrations from external content. Adverse Trace will monitor for Barracuda's full technical report, independent corroboration of the platform infrastructure, and any post-compromise activity observed from harvested credentials, and will reissue if the IOC set expands or attribution emerges.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.