BlobPhish Attack Targets Microsoft 365 Logins

Meta Description

BlobPhish uses browser Blob URLs to steal Microsoft 365 and banking credentials while evading email, proxy, and file-based defenses.

Introduction

Phishing is no longer limited to suspicious links, fake login pages, and poorly written emails.

Modern phishing campaigns are becoming quieter, more evasive, and harder for traditional security tools to inspect.

The BlobPhish campaign is a strong example of that shift.

BlobPhish is a memory-resident phishing attack that uses browser Blob objects to generate fake login pages directly inside the victim’s browser. Instead of hosting a visible phishing page on a normal attacker-controlled website, the campaign creates the phishing interface in memory using JavaScript.

That difference matters.

If the fake page exists only inside the browser, many conventional defenses struggle to see it. Secure email gateways may not inspect the final payload. Proxy logs may not show a suspicious phishing page request. File-based tools may find no file written to disk. Cache forensics may return little or nothing if the Blob URL is revoked.

This is why BlobPhish is dangerous.

It does not only target users.

It targets the assumptions behind phishing detection.

For organizations using Microsoft 365, OneDrive, SharePoint, financial platforms, webmail portals, and banking services, this campaign is a reminder that credential theft remains one of the fastest paths to business email compromise, data theft, financial fraud, and ransomware staging.

There is no confirmed CVE behind BlobPhish.

The attack does not depend on exploiting a traditional software vulnerability.

Instead, it abuses legitimate browser functionality, social engineering, compromised websites, and weak credential controls.

That makes user behavior, identity security, threat hunting, and penetration testing essential parts of defense.

What Happened

Cybersecurity researchers reported a sustained phishing campaign known as BlobPhish.

The campaign has reportedly been active since October 2024 and continued through April 2026, with a notable spike in activity in February 2026.

BlobPhish targets credentials for high-value platforms, including:

• Microsoft 365
• OneDrive
• SharePoint
• Chase
• Capital One
• FDIC-themed portals
• E*TRADE
• Charles Schwab
• Morgan Stanley and Merrill Lynch-themed pages
• American Express
• PayPal
• Intuit
• Webmail services

The attack begins with phishing delivery.

Victims may receive emails that mimic financial alerts, invoices, shared documents, DocSend-style links, shortened URLs, or PDF attachments containing QR codes.

Once the victim follows the link, they are redirected to an attacker-controlled or compromised page containing a JavaScript loader.

That loader performs the core BlobPhish trick.

It decodes a Base64-encoded phishing payload, creates a browser Blob object, generates a blob:https:// URL, and forces the browser to open the phishing page from memory.

The victim then sees a convincing fake login page.

The browser address bar may show a blob:https:// scheme, which many users do not recognize as suspicious.

When the victim enters credentials, the data is sent to attacker-controlled endpoints.

Researchers observed exfiltration endpoint patterns such as:

• res.php
• tele.php
• panel.php

Many of these endpoints were reportedly hosted on compromised legitimate WordPress sites.

The phishing page may also force repeated credential entry through failed-login prompts. This increases the attacker’s chance of collecting accurate credentials before redirecting the victim to a legitimate service to reduce suspicion.

Why This Issue Is Critical

BlobPhish is critical because it weakens several layers of conventional phishing defense.

Many organizations rely on secure email gateways, URL reputation checks, proxy logs, endpoint tools, and user training to stop phishing.

BlobPhish challenges all of them.

The phishing page is generated in the browser after delivery. It is not always visible as a normal external URL in the same way traditional phishing pages are. The page may not be cached. It may not be written to disk. It may not appear as a suspicious page request in proxy logs.

This creates a visibility gap.

Security teams may see the initial email or redirect chain, but miss the final phishing interface that appears inside the browser.

That is especially dangerous when the campaign targets Microsoft 365 credentials.

A stolen Microsoft 365 account can lead to:

• Business email compromise
• Mailbox rule manipulation
• Invoice fraud
• Internal phishing
• SharePoint and OneDrive data theft
• OAuth application abuse
• MFA fatigue attacks
• Session hijacking
• Lateral movement
• Ransomware preparation
• Executive impersonation

The campaign also targets financial institutions and investment platforms.

That can create direct fraud risks for individuals and businesses, including unauthorized transfers, account manipulation, and identity theft.

The key issue is not only that users can be tricked.

The issue is that defenders may not see the final stage clearly enough to respond quickly.

What Caused the Issue

BlobPhish is caused by the abuse of legitimate browser functionality and weaknesses in traditional phishing detection models.

Browser Blob objects are not malicious by design.

They are used by web applications to create temporary object URLs for data held in memory. Developers use Blob objects for legitimate functions such as file previews, downloads, media handling, local processing, and dynamic content generation.

BlobPhish abuses that feature.

The campaign uses JavaScript to create a temporary phishing page in the browser’s memory. That page is referenced through a blob:https:// URL rather than a normal hosted phishing page.

Several factors make this attack effective.

Legitimate Browser Functionality

Blob URLs are valid browser features.

Security tools cannot simply block all Blob behavior without breaking legitimate web applications.

Memory-Resident Delivery

The phishing page may exist only in memory.

That limits traditional file scanning, cache inspection, and URL reputation analysis.

Compromised Infrastructure

Attackers reportedly use compromised legitimate WordPress sites for loaders and exfiltration endpoints.

This helps the campaign blend into normal web traffic.

Trusted-Looking Delivery

The attack may use document-share themes, financial alerts, invoices, DocSend-style pages, shortened URLs, and QR-code PDFs.

These lures are familiar to employees and customers.

Credential Replay Value

Stolen Microsoft 365 and financial credentials can be monetized quickly through account takeover, fraud, data theft, or further phishing.

Weak MFA Controls

If accounts rely on passwords alone, or weak MFA that can be phished or bypassed, credential theft becomes far more damaging.

How the Attack Chain Works

BlobPhish follows a multi-stage credential theft chain designed to avoid static detection and reduce forensic visibility.

Initial Delivery

The victim receives a phishing email or link.

The lure may appear to be a document share, invoice, financial alert, bank notification, cloud file, or QR-code PDF.

The goal is to make the victim click.

Redirect to Loader Page

The link sends the victim to a trusted-looking service, shortened URL, or compromised website.

The attacker-controlled page hosts a JavaScript loader rather than a normal visible phishing page.

Base64 Payload Decoding

The loader contains or retrieves an encoded payload.

Using JavaScript functions such as atob(), the script decodes the Base64 content into HTML.

That decoded HTML contains the fake login page.

Blob Object Creation

The loader creates a Blob object with the decoded HTML and sets the type as text/html.

This turns the phishing content into a browser-managed object.

Blob URL Generation

The script uses browser APIs to generate a temporary blob:https:// URL.

This URL points to the in-memory phishing page.

Silent Navigation

The loader may create a hidden anchor element, attach the Blob URL, simulate a click, and navigate the victim into the fake login page.

To the user, the transition may look like a normal page load.

Evidence Reduction

After navigation, the script can revoke the Blob URL and remove the hidden anchor from the DOM.

This reduces traces available for investigation.

Credential Harvesting

The victim enters their username, password, MFA response, or other account details.

The page may intentionally show failed-login prompts to make the victim enter credentials multiple times.

Exfiltration

Captured data is sent through HTTP POST requests to attacker-controlled endpoints, commonly using paths such as res.php, tele.php, or panel.php.

Redirect to Legitimate Service

After harvesting credentials, the victim may be redirected to the real Microsoft 365, banking, or financial service page.

This reduces suspicion and delays reporting.

Why This Incident Matters for Cybersecurity

BlobPhish matters because it shows how phishing is evolving from simple web impersonation into browser-based evasion.

The campaign does not rely on malware installation.

It does not require a zero-day vulnerability.

It does not need to drop a file.

It does not need to host the final fake login page as a traditional webpage.

Instead, it manipulates the browser into building the phishing page locally.

That changes the defensive problem.

Security teams can no longer rely only on blocking known phishing URLs. They need behavior-based detection, browser telemetry, identity monitoring, and stronger account protection.

BlobPhish also matters because it targets services that are central to business operations.

Microsoft 365 is not just email.

It includes identity, collaboration, files, calendars, Teams integrations, SharePoint, OneDrive, and access to connected SaaS systems.

A compromised Microsoft 365 account can become a launchpad for wider attacks.

Attackers may use stolen credentials to:

• Search mailboxes for invoices and contracts
• Create forwarding rules
• Send internal phishing emails
• Access OneDrive or SharePoint files
• Steal sensitive documents
• Register malicious OAuth apps
• Attempt MFA bypass
• Impersonate executives
• Prepare wire fraud
• Pivot into other SaaS accounts

For financial platforms, the risk is equally serious.

Credential theft can lead to account takeover, fraudulent transactions, investment manipulation, and identity theft.

This is why BlobPhish should be treated as a major credential security threat, not just another phishing page.

Common Risks Highlighted by the Incident

BlobPhish highlights several risks that many organizations still underestimate.

Secure Email Gateway Bypass

Because the final phishing page materializes after the user clicks, email security tools may not fully inspect the payload during delivery.

URL Reputation Blind Spots

A blob:https:// page is not a standard internet-hosted phishing URL.

This can limit the usefulness of reputation-based blocking.

Proxy Log Visibility Gaps

The final phishing page may not appear as a normal external HTTP request in proxy logs.

This makes investigation harder.

Credential Theft

The campaign directly targets Microsoft 365, banking, webmail, and financial credentials.

These accounts are high-value targets.

Business Email Compromise

Stolen Microsoft 365 credentials can lead to mailbox compromise, fraudulent invoices, supplier payment scams, and internal phishing.

Compromised WordPress Abuse

Attackers may use legitimate but compromised websites to host loaders and exfiltration endpoints.

This makes blocking harder because infrastructure can rotate quickly.

Weak MFA Exposure

Password-based access or phishable MFA increases account takeover risk.

Phishing-resistant MFA is far more effective against credential harvesting campaigns.

User Confusion Around Blob URLs

Most users do not understand blob:https:// URLs.

Attackers benefit from that lack of familiarity.

Potential Impact on Organizations

The impact of BlobPhish can be significant because stolen credentials often create more damage than the original phishing email.

A successful compromise may lead to:

• Microsoft 365 account takeover
• Business email compromise
• Unauthorized access to SharePoint and OneDrive
• Sensitive document theft
• Internal phishing from trusted accounts
• Financial fraud
• Payroll redirection scams
• Supplier invoice manipulation
• OAuth token abuse
• MFA fatigue follow-up attacks
• Credential stuffing across other platforms
• Ransomware staging after lateral movement
• Regulatory reporting obligations
• Customer trust damage

The risk is especially high for executives, finance teams, HR teams, IT administrators, legal teams, and employees with access to sensitive files.

For example:

• A finance employee may expose supplier invoice workflows
• An HR employee may expose employee records
• An executive may expose strategic communications
• An IT user may expose administrative access paths
• A legal user may expose confidential documents
• A sales user may expose customer contracts and CRM data

Attackers do not need every employee account.

They only need the right one.

BlobPhish increases the chance of success by making the final phishing page harder to see and harder to block.

What Organisations Should Do Now

Organizations should treat BlobPhish as a credential theft and identity security threat.

Recommended actions include:

• Educate employees about blob:https:// phishing pages
• Warn users that unexpected login pages after document links are suspicious
• Enforce phishing-resistant MFA for Microsoft 365 and critical financial accounts
• Review Microsoft Entra ID sign-in logs for suspicious activity
• Monitor failed and successful logins from unusual locations
• Hunt for known BlobPhish loader patterns
• Search for traffic to res.php, tele.php, and panel.php endpoints
• Inspect suspicious DocSend-style links, shortened URLs, and QR-code PDFs
• Block known compromised domains linked to BlobPhish infrastructure
• Use sandbox analysis that executes JavaScript in real browsers
• Review mailbox forwarding rules and suspicious inbox rules
• Revoke sessions after suspected credential theft
• Rotate passwords for impacted users
• Review OAuth applications and consent grants
• Monitor SharePoint and OneDrive file access after suspicious logins
• Add BlobPhish scenarios to phishing simulations and security awareness training

Organizations should also update incident response playbooks.

A BlobPhish report should trigger identity investigation, not only email cleanup.

If credentials were entered, security teams should assume account compromise until proven otherwise.

Detection and Monitoring Strategies

Detection must focus on behavior, identity, browser activity, and exfiltration patterns.

Security teams should monitor for:

• blob:https:// URLs appearing after suspicious link clicks
• JavaScript loaders creating Blob objects from Base64 payloads
• Use of atob() followed by new Blob()
• Use of window.URL.createObjectURL()
• Use of window.URL.revokeObjectURL()
• Hidden anchor creation followed by forced navigation
• HTTP POST requests to res.php
• HTTP POST requests to tele.php
• HTTP POST requests to panel.php
• Suspicious traffic to compromised WordPress sites
• Repeated failed login prompts on fake pages
• Redirects to legitimate Microsoft or banking sites after credential entry
• Shortened URL chains
• QR-code phishing delivery
• Unusual Microsoft 365 sign-ins
• Impossible travel alerts
• MFA challenges from unfamiliar locations
• New mailbox forwarding rules
• New inbox rules hiding emails
• New OAuth consent grants
• Suspicious SharePoint or OneDrive downloads

Security teams should correlate signals from:

• Secure email gateways
• Browser security tools
• Endpoint detection and response
• DNS filtering
• Proxy logs
• SIEM platforms
• Microsoft Entra ID
• Microsoft Defender for Office 365
• Microsoft Defender for Cloud Apps
• CASB platforms
• Threat intelligence feeds
• Sandbox platforms

Because the final phishing page may be generated in memory, real-browser sandboxing is especially important.

Static link analysis may not be enough.

The sandbox must execute JavaScript, follow redirects, observe Blob object creation, and capture credential-exfiltration behavior safely.

The Role of Incident Response Planning

BlobPhish reinforces the need for incident response planning around credential theft and browser-based phishing.

Many organizations still treat phishing as a user training issue.

That is not enough.

Modern phishing can defeat email filters, bypass static inspection, and lead directly to tenant compromise.

A strong incident response plan should define:

• How users report suspicious blob:https:// pages
• How security teams preserve phishing samples
• How links are detonated safely
• How JavaScript loaders are analyzed
• How Microsoft 365 accounts are reviewed
• When sessions should be revoked
• When passwords should be reset
• When MFA methods should be re-registered
• How mailbox rules are reviewed
• How OAuth grants are inspected
• How SharePoint and OneDrive access is audited
• How financial fraud risk is escalated
• How executives and finance teams are notified
• How repeat phishing from compromised accounts is contained

The response plan should also include communication templates.

If users receive a phishing campaign, they need clear instructions:

• Do not enter credentials
• Do not approve MFA prompts
• Close the browser tab
• Report the email
• Contact IT if credentials were entered
• Do not reuse passwords elsewhere
• Watch for suspicious account activity

Fast reporting can prevent one stolen account from becoming a full business email compromise incident.

The Role of Penetration Testing

Penetration testing can help organizations understand whether BlobPhish-style attacks would succeed against their users, controls, and identity systems.

This type of assessment should go beyond basic phishing simulations.

A strong penetration test can evaluate:

• Whether secure email gateways detect memory-resident phishing loaders
• Whether browser security tools flag Blob URL phishing behavior
• Whether users recognize suspicious blob:https:// login pages
• Whether phishing-resistant MFA is enforced on critical accounts
• Whether Microsoft 365 accounts are protected against session abuse
• Whether mailbox rules are monitored
• Whether OAuth consent abuse is detected
• Whether suspicious SharePoint and OneDrive access triggers alerts
• Whether credential theft leads to lateral movement
• Whether finance users can be targeted for invoice fraud
• Whether SOC teams can investigate BlobPhish-style behavior

A red team exercise can simulate the full attack path:

• Deliver a document-share lure
• Redirect through a controlled loader page
• Generate a safe fake login page in browser memory
• Measure user interaction
• Test reporting procedures
• Evaluate identity alerts
• Attempt controlled post-compromise actions
• Validate incident response timing

The goal is not to embarrass users.

The goal is to find security gaps before attackers do.

Penetration testing helps answer the question executives should care about:

If an employee enters Microsoft 365 credentials into a sophisticated phishing page, how quickly would we detect and contain it?

Protection and Mitigation Measures

Organizations should use layered defenses against BlobPhish.

Enforce Phishing-Resistant MFA

Use FIDO2 security keys, passkeys, or certificate-based authentication where possible.

Phishing-resistant MFA reduces the value of stolen passwords.

Use Conditional Access

Apply risk-based access controls based on device trust, location, session risk, and user role.

High-risk sign-ins should be blocked or challenged.

Improve Browser Security

Deploy browser isolation, browser security extensions, or enterprise browser controls that can detect suspicious Blob URL behavior.

Use Real-Browser Sandboxing

Email and web security tools should detonate suspicious links in real browsers that execute JavaScript and observe in-memory payload behavior.

Monitor Microsoft 365 Identity Signals

Watch for impossible travel, unfamiliar devices, new MFA registrations, suspicious OAuth grants, and unusual session activity.

Harden Mailbox Rules

Alert on new forwarding rules, suspicious inbox rules, and rules that hide or delete security notifications.

Block Known Infrastructure

Use threat intelligence feeds to block known loader pages, compromised domains, exfiltration endpoints, and recurring patterns such as res.php, tele.php, and panel.php.

Train Users on Blob URLs

Employees should understand that unexpected login pages using blob:https:// are suspicious.

Training should include screenshots and practical examples.

Reduce QR-Code Phishing Risk

Inspect QR-code attachments and educate users not to scan codes from unexpected emails.

QR phishing can move users from protected desktops to less-monitored mobile devices.

Review Financial Workflows

Because stolen credentials can enable business email compromise, finance teams should verify payment changes through separate channels.

Revoke Sessions After Suspicion

If credentials may have been entered, reset passwords, revoke sessions, review MFA methods, and inspect OAuth grants.

Strengthen WordPress and Third-Party Risk Monitoring

Attackers often abuse compromised legitimate sites.

Organizations should not assume a familiar domain is safe without behavioral inspection.

Suggested Internal Links

Add internal links naturally in these sections:

• Link “penetration testing” to the Digital Warfare Penetration Testing Services page
• Link “vulnerability assessment” to the Digital Warfare Vulnerability Assessment page
• Link “incident response” to the Digital Warfare Incident Response page
• Link “cloud security testing” to the Digital Warfare Cloud Security Testing page when discussing Microsoft 365 and SaaS identity controls
• Link “web application penetration testing” when discussing compromised websites, phishing loaders, and web-based attack chains
• Link “cybersecurity blog” to the Digital Warfare blog archive for related phishing and credential theft analysis

Suggested placement examples:

In the “The Role of Penetration Testing” section, link the first mention of penetration testing.

In the “What Organisations Should Do Now” section, link vulnerability assessment.

In the “The Role of Incident Response Planning” section, link incident response.

In the “Protection and Mitigation Measures” section, link cloud security testing when discussing Microsoft 365 controls.

Key Takeaway

BlobPhish shows how phishing attacks are evolving beyond traditional fake login pages.

By using JavaScript Blob objects and blob:https:// URLs, attackers can generate phishing pages directly inside the victim’s browser. This allows the campaign to evade many conventional defenses, including static URL inspection, proxy visibility, cache forensics, and file-based detection.

The campaign is especially dangerous because it targets Microsoft 365, OneDrive, SharePoint, banking platforms, investment services, PayPal, Intuit, and webmail accounts.

A single stolen credential can lead to business email compromise, financial fraud, tenant takeover, data theft, internal phishing, and ransomware preparation.

There is no confirmed CVE behind BlobPhish.

The risk comes from browser feature abuse, social engineering, compromised infrastructure, and weak identity controls.

Organizations should enforce phishing-resistant MFA, improve browser and email sandboxing, monitor Microsoft 365 activity, hunt for suspicious Blob behavior, train users to recognize blob:https:// login pages, and include advanced phishing scenarios in penetration testing.

The message is clear:

Phishing is no longer just about suspicious links.

It is now about what happens inside the browser after the click.