Browser-based attacks expose the limits of endpoint-only EDR

At a glance

What this is: This analysis argues that browser-based attacks can bypass endpoint-only EDR because the malicious activity happens inside the live session, not on the host.

Why it matters: IAM, PAM, and NHI teams need to treat the browser as an enforcement point because credential use, session abuse, and application actions now occur there.

Context

Endpoint Detection and Response is designed to observe host behaviour, not the contents of a browser tab. That works when an attack executes on the operating system, but it leaves a gap when the attacker stays inside a live SaaS session and uses the browser as the attack surface.

The governance problem is that modern work now happens in browser-delivered applications, where authentication, session establishment, and privileged actions occur outside the visibility of endpoint tooling. For identity programmes, that means control boundaries must follow the session, not stop at the device.

Browser-based attacks are not a niche exception. They are the result of attackers choosing the layer where defenders have the least direct visibility and where legitimate access makes malicious activity easier to hide.

Key questions

Q: Where does endpoint-only EDR fail against browser-based attacks?

A: Endpoint-only EDR fails when the attacker stays inside the browser session rather than executing malware on the host. In that case the OS sees a normal browser process, while credential theft, token abuse, and application actions occur inside the tab or session context. The practical failure is a visibility boundary, not a tuning problem.

Q: Why does browser-based work increase security risk for SaaS and cloud access?

A: Browser-based work expands risk because the browser becomes the main place where users authenticate, access cloud services, and move data. That concentrates phishing exposure, shadow IT, and leakage risk into one interface that traditional endpoint or network tools may not fully control. As organisations shift away from central offices, the browser becomes a prime attack surface.

Q: What are the signs that browser-session security is failing?

A: The clearest signs are successful logins followed by abnormal in-session behaviour, unexplained credential submissions, suspicious token use, or activity driven by unfamiliar extensions. If security teams only learn about the problem after SaaS actions have already happened, the browser layer is not being observed well enough.

Q: How should security teams handle browser-based attacks when EDR is already deployed?

A: Teams should treat EDR and browser protection as complementary, not interchangeable. EDR remains necessary for host compromise, but browser-based attacks often never produce meaningful endpoint signals. Security teams need browser-native telemetry, session-aware controls, and response actions that can interrupt credential submission or malicious session behaviour before the account is abused.

Technical breakdown

Why endpoint telemetry stops at the browser boundary

EDR works by instrumenting the operating system, which gives defenders visibility into process execution, file activity, registry changes, memory behaviour, and other host signals. That model is effective when malware runs on the device. It is far less effective when the browser is simply the container for a legitimate SaaS session, because the sensitive activity happens inside the page, script context, or token flow rather than as a distinct host event. The result is a visibility boundary: the OS can see a browser process, but not the exact interaction occurring in a tab. Practical implication: treat the browser as a separate security surface, not as an extension of endpoint telemetry.

Practical implication: add controls that observe browser-session behaviour directly instead of assuming the host agent can see it.

How AiTM phishing and session hijacking bypass host-based detection

AiTM phishing proxies a real login flow in real time, stealing credentials or MFA tokens as the user authenticates. Session hijacking is different but related: once an attacker has a valid session token, they can act as the user without re-entering credentials. In both cases, the browser session looks legitimate from the endpoint perspective, so host-level detections may never trigger. This is why browser-born attacks are so effective against controls that assume compromise begins with malware execution on the device. Practical implication: focus detection on credential submission, token use, and anomalous session establishment rather than waiting for endpoint artefacts.

Practical implication: monitor authentication and session behaviour where tokens are issued and consumed, not only where malware would run.

Why malicious browser extensions are especially hard for EDR to see

Browser extensions run inside the browser execution model, which means they can inspect page content, intercept form data, and manipulate session activity without looking like traditional endpoint malware. The host may show only normal browser processes, while the extension quietly reads credentials or siphons session tokens from the page. That makes extensions a governance problem as much as a detection problem, because the browser is effectively another software runtime with its own attack and trust boundaries. Practical implication: manage extension allowlists, privilege, and review as part of identity and access governance, not just endpoint hardening.

Practical implication: govern browser extensions as privileged software because they can directly observe and alter identity-related activity.

NHI Mgmt Group analysis

Browser visibility is now an identity control problem, not only an endpoint problem. When authentication, session establishment, and privileged application actions all happen in the browser, host-only detection cannot represent the real security boundary. That changes how teams should think about where identity enforcement begins and where it must be observed. The practitioner conclusion is simple: if the browser is the place where access is used, it has to be treated as part of the access control plane.

Endpoint-only EDR assumes malicious activity becomes visible when code touches the host. That assumption fails when attackers stay in the browser and use legitimate sessions, which means the security event is not a malware execution problem but a session integrity problem. The implication is that browser-layer telemetry becomes a necessary complement to EDR for modern SaaS-heavy environments.

Browser-based attacks create identity blast radius without host compromise. Once credentials or tokens are abused inside the session, the attacker can move through business applications while endpoint controls see nothing abnormal. That expands the practical blast radius of a single stolen session from one user action to multiple application-level actions. The practitioner conclusion is to govern browser session trust as a first-class identity risk.

Browser-native detection and response is the missing control layer for SaaS work. The control gap is not that EDR failed at its job, but that its job ends before the browser session where modern abuse now lives. This is why identity, endpoint, and browser telemetry need to be correlated instead of managed as isolated tools. The practitioner conclusion is to re-evaluate where session trust is actually enforced.

The browser has become a privileged execution environment for identity abuse. Extensions, rendered phishing pages, and in-session token theft all operate in a layer that is operationally normal for the user but security-critical for the defender. That makes browser governance part of identity governance, not a niche web control. The practitioner conclusion is to include browser behaviour in access-risk decisions.

What this signals

Browser-session governance is becoming a core identity control requirement. Teams that still treat the browser as a simple access channel will miss the point of modern attack paths. The session, not the device, is now where credentials are entered, tokens are established, and abuse can unfold without endpoint alarms.

Identity programmes need a control layer that can see into live SaaS interactions. When the same browser that authenticates the user also carries the attacker’s activity, the old boundary between endpoint security and identity security breaks down. Practitioners should expect browser-native enforcement to become part of baseline access governance, especially where SaaS administration and customer data access converge.

For practitioners

• Define the browser as an identity enforcement surface Map authentication, session creation, and privileged application actions to controls that can observe activity inside the browser, not only on the host.
• Correlate browser and identity telemetry Join browser-session signals with authentication and SaaS activity so AiTM phishing, token replay, and abnormal in-session behaviour can be identified earlier.
• Restrict high-risk browser extensions Review extension inventory, block unknown extensions, and treat extension permissions as part of privileged access because extensions can read page content and steal tokens.
• Block suspicious credential submission paths Interdict risky login flows and abnormal credential entry patterns before the account is fully established in a malicious browser session.
• Revisit SaaS access assumptions Assume the endpoint may remain clean while the browser session is abused, and rework detection and response around the live application session.

Key takeaways

• Browser-based attacks can bypass endpoint-only EDR because the malicious activity happens inside the live session rather than as host-level malware.
• AiTM phishing, session hijacking, and malicious extensions show how attackers can abuse legitimate browser activity while the device still looks normal.
• The missing control is browser-layer visibility, so practitioners need to correlate identity, session, and browser signals instead of relying on endpoint telemetry alone.

Key terms

• Browser Security: Browser security is the set of controls that protects data moving through web sessions, where many users now access SaaS apps, upload files, and interact with AI tools. It helps detect, block, redact, or monitor sensitive content in the browser before information is copied, shared, or exposed outside policy.
• AiTM Phishing: Adversary-in-the-middle phishing inserts attacker infrastructure between the victim and the real login service. The attacker relays the login in real time, captures the issued token, and bypasses MFA by stealing the authenticated session rather than guessing the password.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• Browser Extension Risk: Browser extension risk is the chance that an installed browser add-on will expose data, weaken controls, or enable unauthorized actions. Extensions can read pages, capture credentials, inject code, or alter traffic, so their permissions, provenance, update path, and runtime behavior must be governed as part of endpoint and identity security.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.