> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Cybercriminals are building phishing pages that exist only inside victims’ browsers
- URL: https://f4n6.co.uk/security-feed/cybercriminals-are-building-phishing-pages-that-exist-only-inside-victims-browsers/
- Published: 2026-09-10T08:52:32.000Z
- Updated: 2026-09-10T08:52:32.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 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

| Article                                                                     | Trigger (the fact in this item)                                                                                                                                                                                                                                          | Practical impact                                                                                                                                                                                                                             |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 18: classification of ICT-related incidents and cyber threats     | This campaign is a distinct, evolving cyber-threat technique (blob-URL phishing through genuine Microsoft infrastructure) that clients should classify and feed into threat-led detection priorities, per the classification of ICT-related incidents and cyber threats. | Ensure the threat taxonomy used for classification captures infrastructure-abuse phishing that produces no malicious domain to block, so incidents of this type are classified consistently and major ones escalate correctly.               |
| DORA Art. 24: digital operational resilience testing — general requirements | The technique specifically defeats controls that resilience testing typically validates (URL reputation, first-hop link scanning, domain blocklists); testing that does not exercise the full redirect chain and browser-side rendering will not detect it.              | Include full-link-path traversal (OAuth redirect chains, Teams-hosted resources, blob URL rendering, service worker registration) in threat-led penetration testing and purple-team scenarios against the M365/Entra ID authentication path. |

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.

| Type   | Value                | Confidence                           | Source                          |
| ------ | -------------------- | ------------------------------------ | ------------------------------- |
| domain | cdn\[.\]bloom\[.\]io | Medium — single-sourced to Barracuda | Barracuda via Help Net Security |

```iocs
domain  cdn[.]bloom[.]io

```

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

| Behaviour                                                                                                                        | Where to observe                                                     | Confidence                                       |
| -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------ |
| Navigation to a genuine Microsoft OAuth endpoint followed by a redirect to Microsoft Teams carrying a crafted redirect parameter | Proxy / SWG / DNS logs; browser history                              | High (source-stated)                             |
| Microsoft Teams loading an externally hosted resource (cdn.bloom\[.\]io)                                                         | Proxy / SWG logs — referer chains                                    | High (source-stated)                             |
| Phishing page rendered from a blob: URL in a login/authentication context                                                        | Browser telemetry, EDR browser-event collection, SWG                 | High (source-stated)                             |
| Service worker registration tied to externally loaded content                                                                    | Browser telemetry / endpoint browser-event logs                      | High (source-stated)                             |
| Page logic running inside a sandboxed iframe receiving live instructions via browser messaging                                   | Browser developer telemetry; difficult without instrumented browsers | Medium (source-stated, hard to observe at scale) |
| DocuSign-themed email carrying a calendar invite attachment pointing to a Microsoft OAuth endpoint                               | Email security gateway logs                                          | High (source-stated)                             |

## 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.

```yaml
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 →](https://www.helpnetsecurity.com/2026/09/10/browser-based-phishing-blob-urls-microsoft-oauth/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*