{"id":1655,"date":"2026-09-15T11:32:35","date_gmt":"2026-09-15T06:02:35","guid":{"rendered":"https:\/\/www.hexnode.com\/threat-watch\/?p=1655"},"modified":"2026-09-16T16:34:35","modified_gmt":"2026-09-16T11:04:35","slug":"blob-url-phishing-browser-generated-pages","status":"publish","type":"post","link":"https:\/\/www.hexnode.com\/threat-watch\/blob-url-phishing-browser-generated-pages\/","title":{"rendered":"Blob URL Phishing: How Browser-Generated Pages Challenge Enterprise Identity Defense"},"content":{"rendered":"

Introduction<\/h2>\n

Most employees know to check a website\u2019s address before entering their credentials. However, that habit becomes less reliable when the final phishing page uses a temporary address generated inside the browser.<\/p>\n

Security researchers disclosed a blob URL phishing campaign on September 9, 2026. The attack begins with a DocuSign-themed email and calendar invite before routing the victim through legitimate Microsoft services. External content then becomes a browser-generated blob URL that displays the phishing page locally.<\/p>\n

The campaign combines a familiar business lure with trusted platforms and browser-native features. This approach can complicate phishing detection without exploiting a vulnerability in DocuSign, Microsoft Teams, or blob URL functionality.<\/p>\n \t\t

\r\n \t\t\t \t\t\t \t\t\t\t

\r\n \t\t\t\t\t Who is behind the blob URL phishing campaign?<\/strong><\/p>\n

No publicly identified threat actor or established cybercriminal group has been linked to this campaign. Therefore, the activity should be treated as an unattributed phishing operation rather than assigned to a known group.<\/p>\n

Researchers found hidden command-and-control configuration that indicates the phishing page formed part of a centrally managed platform. Its operators could reportedly update the workflow and direct victims through backend infrastructure. However, the available analysis does not establish the operators\u2019 identity, location, usual targets, campaign scale, or financial motive.<\/p>\n

The DocuSign branding and calendar invitation suggest that the operators aimed to make the message resemble routine workplace communication. These details describe the campaign\u2019s social engineering approach, but they do not prove that DocuSign or Microsoft systems were compromised.
\n \t\t\t\t<\/p>\r\n \t\t\t \t\t\t\r\n \t\t<\/div>\r\n \t\t\n

How the browser-based phishing attack works<\/h2>\n

The campaign changes where defenders encounter the final phishing page. Instead of directing the victim straight to a conventional lookalike website, it uses a longer chain involving legitimate services, an external resource, and browser-generated content.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Attribute<\/th>\nDetails<\/th>\n<\/tr>\n<\/thead>\n
Disclosure date<\/strong><\/td>\nSeptember 9, 2026<\/td>\n<\/tr>\n
Threat actor<\/strong><\/td>\nNo named or verified actor<\/td>\n<\/tr>\n
Target<\/strong><\/td>\nIndividual recipients of DocuSign-themed business emails; specific organizations and sectors were not disclosed<\/td>\n<\/tr>\n
Initial contact<\/strong><\/td>\nA phishing email presented as a DocuSign-related message<\/td>\n<\/tr>\n
Social engineering<\/strong><\/td>\nAn attached calendar invitation makes the email resemble normal business communication<\/td>\n<\/tr>\n
Platforms used<\/strong><\/td>\nA legitimate Microsoft OAuth endpoint and Microsoft Teams appear in the redirect chain<\/td>\n<\/tr>\n
External resource<\/strong><\/td>\nMicrosoft Teams loads content from an external domain identified as cdn.bloom[.]io<\/code><\/td>\n<\/tr>\n
Browser behavior<\/strong><\/td>\nThe browser converts the content into a blob URL and renders the phishing page within the browser session<\/td>\n<\/tr>\n
Workflow control<\/strong><\/td>\nService workers, sandboxed iframes, browser messaging, and backend infrastructure manage requests and navigation<\/td>\n<\/tr>\n
Credentials and MFA<\/strong><\/td>\nThe page creates a credential-phishing risk, but confirmed credential theft or MFA bypass was not reported<\/td>\n<\/tr>\n
Persistence<\/strong><\/td>\nNo endpoint persistence was confirmed; service-worker use alone does not establish persistent device compromise<\/td>\n<\/tr>\n
Confirmed impact<\/strong><\/td>\nResearchers confirmed the phishing delivery chain and browser-rendered page<\/td>\n<\/tr>\n
Uncertain impact<\/strong><\/td>\nThe number of recipients, successful compromises, stolen data, affected organizations, and follow-on activity remain unknown<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The calendar invitation is not the malicious payload. Instead, it adds legitimacy and points into the redirect chain. A crafted redirect then sends the user to Microsoft Teams, which loads the external resource used to construct the final page.<\/p>\n

A blob URL represents data that a browser or web application has placed into a Blob object. In this campaign, the browser uses that mechanism to render the phishing content locally. As a result, the final address begins with blob:<\/code> rather than displaying a persistent phishing domain that defenders can crawl and block in advance. Conventional domain and network blocklists cannot directly inspect or block the blob URL itself because the browser dynamically generates it in client-side memory using URL.createObjectURL()<\/code>. The blob address does not have its own external DNS record or IP address to resolve and evaluate; defenders must instead detect or block the underlying external resource, redirect chain, browser activity, or related authentication events.<\/p>\n

Service workers and sandboxed iframes help coordinate the workflow inside the browser. Meanwhile, backend controls can send instructions and modify navigation. This architecture makes the page more dynamic than a static phishing site, but it does not make the campaign invisible. The external resource, redirect activity, browser events, network connections, and authentication attempts can still produce useful security signals.
\n

<\/div>

Top 7 Hexnode XDR Capabilities to Assess Before Deployment<\/h4>

Assess seven Hexnode XDR capabilities that improve threat visibility, response speed, and analyst efficiency.<\/p><\/div><\/div><\/div><\/a><\/div><\/div><\/div><\/p>\n

Why this matters<\/h2>\n

Traditional domain blocklists work best when defenders can identify and repeatedly inspect a stable malicious URL. Blob URL phishing removes that final static page from the normal workflow, which can leave tools that examine only the initial link with an incomplete view.<\/p>\n

The use of Microsoft services also creates a trust problem. Employees may see familiar domains during the redirect process and assume the destination is safe. However, a trusted platform appearing in a navigation chain does not validate every external resource that follows.<\/p>\n

If a user submits credentials, the attacker could attempt to access SSO-connected applications and enterprise data. Still, the reported campaign did not demonstrate MFA bypass or confirm stolen credentials. Security teams should treat MFA bypass risk as a possible follow-on concern, not a verified outcome.<\/p>\n

Effective phishing detection must therefore combine full-chain link analysis with identity monitoring, endpoint visibility, device compliance, and user verification.<\/p>\n

How Hexnode can help<\/h2>\n

Hexnode UEM: Establish a secure endpoint baseline<\/h3>\n

Hexnode UEM<\/a> can help administrators enroll devices and apply security policies before those endpoints access business applications. Depending on the operating system and management mode, teams can configure browser settings, manage applications, enforce password and encryption requirements, and control software updates.<\/p>\n

Application allowlisting or blocklisting can reduce exposure to unapproved browsers and other risky software. Web-content controls can also restrict known malicious or prohibited destinations on supported platforms. However, UEM web-content filtering cannot directly block the blob:<\/code> scheme because blob URLs are generated locally within the browser rather than resolved through an external domain. On supported platforms and management modes, Hexnode UEM can instead restrict browser-extension installations and enforce strict browser security baselines, helping mitigate unauthorized script execution.<\/p>\n

Hexnode can assess device compliance using factors such as enrollment status, encryption, password protection, OS version, and other supported security conditions. These checks give access systems a stronger device-trust signal, although they cannot determine whether every page opened on a compliant device is legitimate. Hexnode compliance documentation<\/a><\/p>\n

Hexnode XDR: Investigate suspicious endpoint behavior<\/h3>\n

Hexnode XDR<\/a> provides endpoint telemetry that administrators can query for process, file, authentication, script, registry, WMI, and network events. Security teams can use these signals to investigate suspicious processes, unusual connections, credential-related activity, and any endpoint behavior that follows a phishing interaction.<\/p>\n

If an incident produces a detected threat, Hexnode XDR supports investigation through threat details and process relationships. Available response actions include terminating processes, quarantining malicious files, and isolating affected endpoints.<\/p>\n

However, endpoint telemetry should complement dedicated email and browser-security controls. Pure credential harvesting that occurs entirely within a browser session can leave no endpoint file footprint for XDR to detect. Hexnode XDR should therefore serve as a safety net for secondary actions, such as malware downloads, unexpected command-line process spawns, suspicious scripts, or lateral network traffic following the phishing interaction.
\n

\n
\n
\n
\n \"resources_thumbnail_blu\"\n <\/div>\n <\/div>\n
\n
\n Feature Resource \n <\/h5>\n

\n Device Lifecycle Management: Complete End-to-End Framework\n <\/h4>\n

\n Visualize the complete device lifecycle and automate management with Hexnode effortlessly.\n <\/p>\n \n Get the infographic\n \n \n \n \n <\/g>\n <\/svg>\n\n <\/a>\n <\/div>\n <\/div>\n <\/section><\/p>\n

Hexnode IdP: Apply identity and device-aware access<\/h3>\n

Hexnode IdP<\/a> can enforce access policies based on user identity, device compliance, and security context. Organizations can assign approved applications, apply role-based permissions, require additional authentication, manage session duration, and review authentication activity.<\/p>\n

In this scenario, device-aware access can restrict protected applications to approved users on compliant devices. This control can reduce the usefulness of harvested credentials when an attacker attempts to sign in from an untrusted endpoint. Sign-in and authentication reports can also support investigations into unusual access attempts. Hexnode\u2019s automated cross-product feedback loop can enable IdP to immediately invalidate a user\u2019s active sessions across connected enterprise applications when Hexnode XDR detects post-phishing behavior.<\/p>\n

Identity policies do not prevent users from opening a phishing page or guarantee that submitted credentials remain safe. Organizations should combine them with phishing-resistant authentication, email protection, browser monitoring, and rapid credential revocation.<\/p>\n

Strengthening defenses against browser-generated phishing<\/h2>\n

Blob URL phishing shows why security teams cannot judge a link solely by its first domain or the brand displayed during navigation. In this campaign, a familiar DocuSign lure and legitimate Microsoft services lead to externally sourced content that becomes a phishing page inside the browser.<\/p>\n

Organizations should configure email tools to inspect complete redirect paths rather than only the initial URL. They should also monitor unusual OAuth redirects, unexpected service-worker registrations, suspicious login pages loaded from blob URLs, and authentication attempts from unfamiliar devices. Phishing-resistant MFA can further reduce reliance on reusable passwords and verification codes. For managed web applications and portals that embed external content, administrators should enforce restrictive iframe sandbox parameters and avoid granting both allow-scripts<\/code> and allow-same-origin<\/code> unless operationally necessary. Disabling scripts for untrusted content or keeping that content in an isolated origin helps prevent it from creating unisolated blob contexts.<\/p>\n

Hexnode UEM can strengthen endpoint posture, while Hexnode IdP can apply identity and device-aware access rules. Hexnode XDR can help investigate endpoint activity and respond when a phishing interaction leads to suspicious processes, files, or connections.<\/p>\n

Security teams should test these controls together and document a rapid response process for reported DocuSign and collaboration-platform lures.
\n

<\/div><\/div>
Try\u202fHexnode\u202fFree for 14 Days\u202f\u202f\u202f\u202f\u202f\u202f\u202f <\/h5>

Strengthen device and identity security against advanced phishing attacks with Hexnode.\r\n<\/p>