The EDR blind spot: 3 ways browser attacks evade endpoint telemetry

In SaaS-heavy environments, an employee can authenticate to a cloud application, approve an OAuth request, open sensitive files, or upload data through a browser session. The action may never create a new attacker-controlled executable or a process that endpoint defenses would classify as malicious.

Like in the 2025 Salesloft Drift incident: UNC6395 obtained OAuth tokens associated with Drift integrations and used them to make high-volume API calls against customers’ Salesforce environments. This way, authenticated SaaS access enabled data theft without a malware process for EDR to inspect.

The browser has become the primary access layer for corporate SaaS applications, identity workflows, files, and admin consoles. NordLayer’s Browser Security Report 2026 found that browser access is present across the full set of 504 reviewed applications, with 79% of tools available only through the browser.

That makes browser sessions a core location for user actions that may not produce the endpoint artifacts EDR was built to analyze.

EDR still detects host execution, malware, persistence, and process-level behavior. But in SaaS-heavy environments, some attacks are carried out through browser and identity workflows that do not create the endpoint artifacts EDR is built to inspect.

In adversary-in-the-middle phishing attacks, malicious browser extensions, unauthorized uploads, or clipboard-based execution lures, the decisive action happens inside the browser or the cloud application.

Adversary-in-the-middle (AiTM) phishing

In 2026, a threat actor that Microsoft tracks as Storm-2755 targeted Canadian employees through search engine poisoning and malicious ads. Victims searching for terms such as “Office 365” were redirected to a Microsoft 365 login page controlled by the attacker.

The AiTM infrastructure then proxied the authentication flow in real time and captured credentials as well as session cookies and OAuth access tokens issued after successful authentication.

Storm-2755 then replayed the stolen session. Microsoft observed the same session ID switch from the victim’s browser to an Axios user agent. It showed that the authentication token was being reused from an attacker-controlled infrastructure.

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

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

From ordinary endpoint process telemetry, the authentication flow may appear legitimate. The endpoint may not reveal that an AiTM proxy has intercepted the session (although other endpoint, identity, network, or XDR signals can expose the attack).

The best way to prevent many AiTM attacks is to use phishing-resistant FIDO2 WebAuthn authentication: the authentication response is cryptographically tied to the legitimate origin. On top of that, browser controls can help block known phishing destinations, restrict access to unapproved web applications, and stop the attack earlier.

Compromised browser extensions

Browser extensions create a different kind of visibility problem. They leave files in the browser profile, and their code runs inside browser processes. EDR may detect a suspicious extension or unusual network activity. But the extension’s behavior can still look ordinary at the host level.

A malicious extension can use standard browser APIs to read page content, observe URLs, interact with forms, and send data over HTTPS. None of those actions necessarily requires a new process or a suspicious executable. Without browser-specific context, a security team may see the browser traffic but not know which extension initiated it, what data it accessed, or whether the extension was approved.

A recent example: in March 2026, Microsoft reported on malicious Chromium extensions that looked like AI assistants. These extensions were installed about 900,000 times, with activity confirmed across more than 20,000 enterprise tenants. The extensions collected visited URLs and content from ChatGPT and DeepSeek conversations and periodically sent this data to an attacker-controlled infrastructure.

The host can therefore show an ordinary browser process making HTTPS connections, while the security-relevant action is an extension reading and exporting page content. Endpoint tools may detect parts of the activity, but extension inventory, permissions, and policy provide the context needed to determine whether that behavior should have been allowed.

Security teams should control the extension layer directly rather than waiting for a malicious domain, known malware signature, or endpoint alert. Organizations need extension allowlists, installation controls, and permission reviews for any extension that can read or modify web content.

Some browser attacks complete inside the web session. A compromised website, malicious advertisement, or injected script can change rendered content, read page-accessible data, redirect the session, or manipulate the clipboard. These actions can happen within browser-granted permissions. They do not need to write files, launch malware, or create a new process. A user can also upload a sensitive file or paste confidential text into an unauthorized SaaS or AI service without any malware being installed.

While that may be damaging, it does not necessarily create the artifacts EDR is built to find. For example, ClickFix attacks use fake verification prompts or other web content to persuade a victim to copy and execute a malicious command.

Microsoft observed this sequence in its August 2026 TerminalFix campaign, a ClickFix variant that compromised websites and displayed fake Cloudflare CAPTCHA prompts. Clicking the fake verification step copied a malicious PowerShell command to the clipboard, while the page instructed the victim to open Windows Terminal or PowerShell and paste it.

Until then, the attacker had relied on browser content, clipboard manipulation, and user interaction. Executing the command changed the telemetry: PowerShell ran, a ZIP archive was downloaded and extracted, DLL side-loading followed, registry and scheduled-task persistence were created, Active Directory discovery began, and the compromised host established a reverse tunnel.

Browser controls can stop the attack before host execution by blocking the malicious page, restricting clipboard access, or limiting risky browser actions. If the user runs the copied command, the activity moves into endpoint telemetry, where EDR can inspect PowerShell execution, downloaded files, persistence, discovery, and outbound connections.

The control should match the action

EDR alone does not cover every high-risk action in a SaaS-heavy environment. If teams expect endpoint telemetry to flag every malicious login, OAuth approval, browser upload, or extension action, they can miss activity that never becomes host execution.

A SaaS-heavy environment needs controls at 3 connected layers:

1. Browser
2. Identity and SaaS
3. Endpoint

Browser controls are needed before data reaches an unauthorized SaaS or AI service. Once a user uploads a file, pastes confidential text, or grants excessive browser access, endpoint telemetry may not show enough context to explain or stop the action. Web threat protection can block phishing and malicious sites. Extension policies can prevent unapproved code from reading web content. Browser DLP can restrict uploads, downloads, and copy-and-paste actions by destination.

In SaaS-heavy environments, the browser is the primary access layer for corporate data, identity providers, and admin workflows. Controls need to operate at that layer because malicious logins, OAuth grants, extension access, uploads, and clipboard actions may not create endpoint artifacts. EDR remains needed for host execution. But when an attack stays inside a browser session, the browser is not just another application to monitor, but the attack surface.

For data on browser exposure and organizations’ ability to address it, read NordLayer’s Web-based threats report.

About the author:

Andrius has over 20 years of experience in the IT field and has been keenly interested in cybersecurity since 2015. He now leads his team as the VP of product strategy at NordLayer, a toggle-ready network security platform for business.

He drives the development agenda by extensively researching the market, understanding client needs, and assessing technical capabilities. Andrius prioritizes fostering confidence within the product team, empowering it to address intricate security challenges and translate discoveries into enhanced layers of protection for clients.