Why EDR Alone Cannot Detect Every Browser-Based SaaS Attack

Article written by Andrius Buinovskis, VP of Product Strategy, NordLayer

Endpoint detection and response (EDR) remains essential when an attacker executes code on a host. The problem begins when teams expect EDR to identify every anomalous action, including browser-based SaaS activity that resembles a normal user session.

In SaaS-heavy environments, employees authenticate to cloud applications, approve OAuth requests, open sensitive files, and upload data through a browser. These actions may not create new executable files or processes that endpoint defenses classify as malicious.

This was demonstrated in the 2025 Salesloft Drift incident. UNC6395 obtained an OAuth token associated with a Drift integration and used it to make a large number of API calls to a customer’s Salesforce environment. Authenticated SaaS access enabled data theft without malware processes for EDR to inspect.

Browsers have become the primary access layer for enterprise SaaS applications, identity workflows, files, and management consoles. According to NordLayer’s browser security report, browser access was available across all 504 applications reviewed in 2026, while 79% of the tools were available only through a browser.

This makes the browser session a critical location for user actions that may not produce the endpoint artifacts EDR was designed to analyze.

EDR continues to detect host execution, malware, persistence, and process-level behavior. However, some attacks are carried out through browsers or identity workflows and never create the endpoint artifacts that EDR is built to inspect.

In a man-in-the-middle phishing attack, a malicious browser extension, a fraudulent upload, or a clipboard-based execution lure, the decisive action occurs within the browser or cloud application.

Man-in-the-Middle Phishing Attacks

In 2026, Microsoft tracked the threat actor Storm-2755 after it used search engine poisoning and malicious advertising to target Canadian employees. Victims searching for terms such as “Office 365” were redirected to a Microsoft 365 login page controlled by the attackers, according to Microsoft’s report.

The adversary-in-the-middle (AiTM) infrastructure proxied the authentication flow in real time, capturing credentials, session cookies, and OAuth access tokens issued after successful authentication.

Storm-2755 then replayed the stolen session. Microsoft observed the same session ID switching from the victim’s browser to the Axios user agent, indicating that authentication tokens were being reused from attacker-controlled infrastructure.

The attackers accessed Microsoft services, searched for payroll and human resources information, created inbox rules to hide messages about banking changes, and, in some cases, accessed Workday.

This mechanism is typical of AiTM phishing. The victim opens a phishing page positioned between the user and the legitimate identity provider. The page collects the username and password, relays a legitimate MFA challenge, and passes the user’s response to the actual service. The attacker can then capture authenticated session material.

The authentication flow may appear legitimate in normal endpoint process telemetry. The endpoint may not reveal that an AiTM proxy intercepted the session, although other endpoint, identity, network, or XDR signals may expose the attack.

The best way to prevent many AiTM attacks is to use phishing-resistant FIDO2 WebAuthn authentication. Authentication responses are cryptographically tied to their legitimate origin. Browser controls can also help block known phishing destinations, restrict access to unauthorized web applications, and stop attacks earlier in the process.

Compromised Browser Extensions

Browser extensions create another visibility challenge. The extension remains in the browser profile, and its code runs within the browser process. EDR may detect suspicious extensions or unusual network activity, but the extension’s behavior can still appear normal at the host level.

Malicious extensions can use standard browser APIs to read page content, monitor URLs, manipulate forms, and send data over HTTPS. These actions do not necessarily require new processes or suspicious executables.

Without browser-specific context, security teams may see browser traffic without knowing which extension initiated it, what data was accessed, or whether the extension was authorized.

In March 2026, Microsoft reported on a malicious Chromium extension that appeared to function as an AI assistant. The extensions were installed approximately 900,000 times, and activity was observed in more than 20,000 enterprise tenants.

The extension collected URLs and content accessed from ChatGPT and DeepSeek conversations and periodically sent the data to attacker-controlled infrastructure.

As a result, the host could show a normal browser process making an HTTPS connection. The security-critical activity was the extension reading and exporting page content. Endpoint tools may detect some of this behavior, but extension inventories, permissions, and policies provide the context needed to determine whether the activity should be allowed.

Security teams need direct control over the extension layer rather than waiting for malicious domains, known malware signatures, or endpoint alerts. Organizations need allowlists, installation controls, and permission reviews for extensions that can read or modify web content.

Browser Attacks That Happen Before Endpoint Execution

Some browser attacks are completed entirely within a web session. A compromised website, malicious advertisement, or injected script can modify rendered content, read data accessible from a page, redirect a session, or manipulate the clipboard.

These actions can be performed within the permissions granted to the browser. They do not require an attacker to write files, launch malware, or create new processes. Users can also upload sensitive files or paste sensitive text into unauthorized SaaS or AI services without malware being installed.

Although these actions can cause significant harm, they do not necessarily create the artifacts EDR was built to detect. ClickFix attacks, for example, use fake verification prompts and other web content to trick victims into copying and running malicious commands.

Microsoft observed this sequence during the August 2026 TerminalFix campaign, a ClickFix variant that compromised websites and displayed fake Cloudflare CAPTCHA prompts.

After clicking the fake verification step, the victim’s clipboard contained a malicious PowerShell command. The page then instructed the victim to open Windows Terminal or PowerShell and paste the command.

Before the command was executed, the attack relied on browser content, clipboard manipulation, and user interaction. Once the victim ran the command, the activity moved into endpoint telemetry. PowerShell was executed, a ZIP archive was downloaded and extracted, DLL sideloading continued, registry and scheduled task persistence was created, Active Directory discovery began, and the compromised host established a reverse tunnel.

Browser controls can stop these attacks before host execution by blocking malicious pages, restricting clipboard access, and limiting risky browser actions. Once a user runs the copied command, the activity moves to endpoint telemetry, where EDR can inspect PowerShell execution, downloaded files, persistence, discovery, and outbound connections.

Security Controls Must Match the Action

EDR alone cannot cover every high-risk action in a SaaS-heavy environment. If a team expects endpoint telemetry to identify every malicious login, OAuth authorization, browser upload, or extension action, it may miss activity that never occurs on the host.

SaaS-heavy environments require controls across three connected layers:

1. Browser
2. Identity and SaaS
3. Endpoint—the last stop

Browser controls are needed before data reaches unauthorized SaaS or AI services. When a user uploads a file, pastes sensitive text, or grants excessive browser access, endpoint telemetry may not provide enough context to explain or stop the action.

Web threat protection can block phishing and malicious sites. Extension policies can prevent unauthorized code from reading web content. Browser data loss prevention (DLP) can restrict uploads, downloads, and copy-and-paste operations based on the destination.

In SaaS-heavy environments, the browser is the primary access layer for corporate data, identity providers, and administrative workflows. Malicious logins, OAuth grants, extension access, uploads, and clipboard actions may not create endpoint artifacts, so security controls must operate at the same layer as the activity.

EDR is still required when an attacker executes code on the host. However, when an attack remains within a browser session, the browser becomes an attack surface—not simply an application to monitor.

For more information about browser exposure and an organization’s ability to address it, read NordLayer’s web-based threat report.

Explore the NordLayer browser in 30 minutes. Learn how your team can deploy managed browser controls, identify unauthorized application use, and enforce access policies across your organization. Book a demo.

About the Author

Andrius has more than 20 years of experience in the IT field and has had a strong interest in cybersecurity since 2015. He currently leads the team as Vice President of Product Strategy at NordLayer, a switch-enabled network security platform for businesses.

He drives the product development agenda through extensive market research, understanding client needs, and assessing technical capabilities. Andrius prioritizes fostering confidence within product teams, empowering them to address complex security challenges and translate discoveries into enhanced layers of protection for clients.

Sponsored and written by Nord Security.