Attackers are taking phishing to a new level by using browser-generated blob URLs and Microsoft Teams to render fake login pages entirely within victims’ browsers. Instead of directing users to external malicious sites, these cybercriminals use local browser memory so that malware detection tools have difficulty spotting the danger early on.
The campaign begins with a calendar invite themed around DocuSign. The email embeds a link that initially connects to Microsoft’s OAuth system—thought of as safe—before redirecting through Microsoft Teams. It’s during this redirect that the phishing interface is delivered via a blob URL, meaning the malicious content shows up in the browser without ever being hosted on a server that filters usually flag.
How Blob URLs Are Being Weaponized
Blob URLs are temporary addresses created by browsers to represent data held in local memory. In this case, an external resource is loaded through Teams, then converted into a blob URL. The phishing page appears as though it’s part of the Microsoft Teams interface. Because this content doesn’t come from a remote host, URL filters are less likely to catch the threat early.
In many cases, the blob-based phishing page registers a service worker and operates inside a sandboxed iframe. These methods enable it to manage navigation, handle requests, and even receive dynamic instructions from remote infrastructure. All of this works together to make detection harder—both for end users and security tools.
Why It Works—And What To Do About It
The credibility trick here is in the redirection chain. Emails begin with familiar domains and Microsoft branding—names most filters and users trust. Once the email’s link passes through Microsoft OAuth into Teams, all semblance of legitimacy remains intact until the harmful blob URL triggers the fake login page. Users see something that looks trustworthy and are more likely to enter credentials.
This kind of spoofed login page isn’t just a password-grab. Submitting details—or approving any downstream OAuth or identity request—can lead to email compromise, data access, or full business account takeovers. Security tools that don’t follow the full redirect chain from email to blob are likely to miss the plot until it is too late.
Defensive Measures & Red Flags
Security teams should track every stage of a link click, not just the first URL. Suspicious signs include unconventional OAuth requests, odd redirect behavior, blob URLs showing login prompts, and external service-worker registrations loading content not hosted in trusted infrastructure. Stronger identity verification mechanisms like FIDO2 keys or passkeys go a long way in reducing exposure—if attackers get only a password, those methods can block misuse.
For employees, caution around unexpected calendar invites or document-signing messages is critical. If you see a login page after clicking through what looked like a legitimate service or after a calendar invite, leave it—double-check through your company’s trusted process before entering credentials.
This campaign underscores that a familiar brand name or recognizable domain isn’t enough to ensure safety. Malicious actors increasingly use trusted services—OAuth, Teams—to deliver threats. Effective security now means examining behavior, not just appearance. Monitoring logs, email headers, and browser events can catch what static defenses miss.
Indicators of compromise include items like redirected external resources hosted on domains such as cdn.bloom[.]io, and legitimate OAuth endpoints like login.microsoftonline.com used early in the redirection chain. Organizations should share and defend against these paths proactively.
What this means is clear: the security industry must raise its bar. It’s no longer enough for filters to spot shady domains; they must understand the full journey from email to browser-rendered content. For businesses, investing in phishing-resistant authentication, encouraging employee skepticism, and improving detection of complex redirect chains will be essential going forward.
