TL;DR: As work shifts into SaaS and browser sessions, attackers are bypassing endpoint telemetry through AiTM phishing, session hijacking, and malicious extensions, according to Push Security. The blind spot is structural: EDR protects the host, but it cannot observe the live application session where credentials and actions are now being abused.
At a glance
What this is: This is an analysis of why endpoint detection and response loses visibility once attacks move inside the browser session.
Why it matters: It matters because identity, authentication, and session abuse now happen in the browser layer that sits between users and cloud applications, forcing IAM and security teams to treat browser telemetry as part of the control plane.
👉 Read Push Security's analysis of browser-based attacks and EDR blind spots
Context
Endpoint detection and response was built to observe what happens on the host: process execution, memory behaviour, file changes, and other operating-system signals. That model still matters, but it assumes the attacker has to touch the endpoint in a way the agent can see. The primary keyword here is browser-based attacks, and that is where the traditional visibility boundary starts to fail.
Modern work is increasingly mediated through SaaS applications in the browser, which means authentication, session establishment, data movement, and administrative actions can all occur without producing meaningful endpoint telemetry. For IAM and security teams, the governance problem is no longer only host compromise. It is visibility and control over the browser session where identity is actually exercised.
Key questions
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.
Q: Why do browser-based attacks complicate identity and access management programmes?
A: Because identity is exercised inside the browser session, not only at the login boundary. Once an attacker has a valid session or manipulates the authentication flow, the browser becomes the place where access is abused. That means IAM teams must care about session integrity, token use, and interaction context, not only authentication success.
Q: What do security teams get wrong about session hijacking?
A: They often treat it as a pure authentication problem when it is also a session-control problem. A stolen or replayed token can make the session look legitimate to endpoint tooling and to some identity systems. Defenders need monitoring for abnormal token use, session context changes, and suspicious browser behaviour.
Q: What should organisations do when attackers avoid the endpoint entirely?
A: They should move detection closer to the layer where the attack actually happens. That means browser-native protection, behavioural detection inside the session, and immediate response that can block unsafe actions at the point of interaction. If the attack never touches the host in a visible way, the browser must become part of the control surface.
Technical breakdown
Why endpoint telemetry stops at the browser boundary
EDR is strong because it instruments the operating system and watches for behaviour at the host layer. That gives defenders rich evidence when code executes, files change, or processes behave suspiciously. But a browser is itself a container for activity that is largely opaque to host-level telemetry. The operating system can see the browser process, not the page structure, scripts, tab content, or user interaction inside a session. That boundary matters because modern attacks now avoid host compromise and instead manipulate identity and application usage through standard web sessions.
Practical implication: treat browser activity as a distinct telemetry domain, not as an extension of endpoint logs.
How AiTM phishing and session hijacking evade host controls
Attacker-in-the-middle phishing proxies the login flow in real time, capturing credentials or MFA tokens as the user enters them. Session hijacking is different: the attacker acquires a valid token and acts inside an already-authenticated session without needing a password prompt at all. In both cases, the malicious behaviour can look normal from the endpoint's perspective because the browser is still doing what browsers do. The control failure is not merely weak detection. It is that the attack lives inside the authentication session itself, where host tools have little context.
Practical implication: add browser-native session controls for credential entry, token use, and abnormal session behaviour.
Why browser-native detection changes response timing
Browser-native protection moves detection to the point where credentials are submitted and sessions are established. That timing difference matters because many browser-based attacks succeed in seconds, not after long dwell times. Behavioural detection in the browser can inspect page rendering, credential submission patterns, malicious extension activity, and suspicious redirection chains before the account is fully abused. This is not a replacement for EDR or identity controls. It is a layer that closes the visibility gap between authentication and application use, where most browser-based abuse now occurs.
Practical implication: design response to interrupt the interaction itself, not just investigate after compromise.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser-based attacks are exposing a control boundary that endpoint security was never designed to cross. EDR remains effective for host-level compromise, but it cannot observe the live application session where modern attackers now operate. That shifts the real security question from endpoint containment to browser-session governance. Practitioners should treat the browser as an identity enforcement point, not just a user interface.
Session hijacking shows why host-centric visibility is insufficient once authentication is already complete. A valid session token can give an attacker persistent access without triggering password or malware signals. That means the breach path is not endpoint compromise but identity reuse inside a trusted session. The implication is that session state has become a primary security object, not just an authentication by-product.
Browser-native detection is now a named control gap, not a niche enhancement. The browser session is where credentials are entered, cloud applications are reached, and attacker manipulation is executed. That is a distinct security surface with its own telemetry, its own response timing, and its own governance needs. Teams should stop treating browser visibility as optional hardening and start treating it as part of identity assurance.
Identity governance now extends to where users actually operate, not where devices are managed. Endpoint tools protect the host, but browser-based abuse exploits the gap between identity authentication and application interaction. That gap affects human IAM first, but the same pattern matters wherever browser-mediated access is used for privileged administration or cloud operations. The practitioner conclusion is simple: if the browser is the execution layer, it must be governed as one.
Browser-session risk is becoming the shared failure mode across human identity and cloud access. AiTM phishing, malicious extensions, and session hijacking all exploit legitimate access paths rather than noisy malware. That makes them harder to catch with legacy endpoint thinking and easier to miss in blended IAM, PAM, and security operations workflows. Teams should align controls around session integrity, not only device integrity.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and another 47% reporting only partial visibility, according to The State of Non-Human Identity Security.
- That same research found only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which helps explain why session and browser-layer controls are becoming a governance priority.
- For a broader control lens, 52 NHI Breaches Analysis shows how exposed credentials and weak lifecycle control keep turning identity gaps into incident paths.
What this signals
Browser-based abuse is widening the identity governance scope beyond device management. Teams that still anchor detection in the endpoint will keep missing the layer where sessions, tokens, and cloud interactions are actually being abused. Browser-native monitoring should now sit alongside IAM, PAM, and EDR as a standard part of identity assurance.
Session integrity is becoming a more useful control concept than login success. A successful authentication event tells you very little if the session is immediately hijacked, proxied, or manipulated inside the browser. Practitioners should expect more pressure to prove what happened after login, not just who authenticated.
The next governance step is to align browser visibility with identity risk tiering, especially for privileged SaaS access and administrative workflows. The organisations that do this first will see fewer blind spots between authentication and action, which is where browser-based attacks now succeed.
For practitioners
- Instrument browser-session telemetry Measure page rendering, credential submission, token use, and suspicious redirection inside the browser, because host telemetry will not reveal those interaction patterns.
- Block high-risk credential submission events Stop credential entry when the page structure, origin, or behaviour does not match the expected authentication flow, especially during real-time proxy attacks.
- Detect abnormal session reuse Watch for valid tokens being used in unusual locations, sequences, or interaction patterns, since session hijacking often bypasses password-based alarms.
- Review privileged browser workflows Map where administrative and SaaS actions depend on browser sessions, then apply stronger session assurance where those actions can change access, data, or configuration.
Key takeaways
- Browser-based attacks exploit the gap between endpoint visibility and live session activity, which makes host-only detection incomplete.
- The evidence in this article shows that legitimate access paths, not malware alone, are now the main route for AiTM phishing, session hijacking, and extension abuse.
- Security teams need browser-native telemetry and response if they want to stop credential theft and session abuse before the account is fully compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Browser sessions now carry identity risk that OWASP-NHI expects teams to govern. |
| NIST CSF 2.0 | PR.AC-4 | Session-aware access control fits the need to verify and limit identity use in context. |
| NIST Zero Trust (SP 800-207) | PR.AC-7 | Continuous verification is relevant when attackers abuse valid browser sessions. |
Review browser-mediated access paths against PR.AC-4 and tighten session assurance for sensitive apps.
Key terms
- Browser-native protection: Security controls that run inside the browser and can observe page content, script behaviour, session state, and user interaction directly. For identity security, this matters because the browser is where modern authentication and application abuse increasingly happen, beyond the endpoint's field of view.
- Session hijacking: The theft or replay of an active session token so an attacker can act as an authenticated user without re-entering credentials. In browser-centric environments, session hijacking can look like normal web activity unless controls inspect token use, context changes, and abnormal interaction patterns.
- AiTM phishing: Attacker-in-the-middle phishing proxies the login flow through a malicious relay that captures credentials or MFA tokens in real time. The user sees a convincing authentication experience, while the attacker receives the resulting access artefacts and can reuse them inside a legitimate-looking browser session.
- Session integrity: The condition that an authenticated browser session remains authentic, unchanged, and consistent with the expected user and device behaviour. In practice, session integrity is about detecting tampering, token abuse, and context drift after login, not just confirming that authentication succeeded.
Deepen your knowledge
Browser-based attack detection and session-aware governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to close the gap between endpoint security and identity assurance, this is a useful place to start.
This post draws on content published by Push Security: browser-based attacks and the limits of endpoint-only EDR. Read the original.
Published by the NHIMG editorial team on 2026-01-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org