Browser blind spots are where modern identity attacks succeed

At a glance

What this is: This is an analysis of why endpoint security stops short at the browser boundary and why identity attacks now concentrate in session-layer activity.

Why it matters: It matters because IAM, NHI, and human identity programmes all rely on trust signals that can disappear once authentication moves inside the browser tab.

By the numbers:

• 82% of attack detections are now malware-free, according to CrowdStrike's 2026 Global Threat Report.
• PhaaS-driven account compromise surged 389% year-over-year according to eSentire.
• Fake CAPTCHA lures used in ClickFix attacks increased 563% in 2025, according to CrowdStrike.
• Push has documented a 37x increase in device code phishing attacks this year.

👉 Read Push Security's analysis of browser-native identity attacks and EDR blind spots

Context

Browser-based identity attacks succeed because endpoint detection is built to observe the operating system, not the session where authentication, token issuance, and sensitive application use now happen. In practice, that leaves a blind spot between a clean endpoint process view and the real security event: a credential relay, consent grant, or hijacked session inside the browser.

That gap matters across IAM programmes because browser sessions have become the operational boundary for both human users and the service workflows they access. When controls do not instrument the browser layer, organisations can miss account takeover, session theft, and malicious consent even when EDR coverage is strong.

The article argues that attackers have adapted to this boundary by choosing techniques that look normal at the OS layer and abnormal only inside the browser. That starting point is now typical, not exceptional, for modern identity compromise.

Key questions

Q: How should security teams handle identity risk when authentication happens in the browser?

A: Security teams should treat the browser as part of the identity control plane, not just the place where authentication happens. That means instrumenting session behaviour, consent flows, extension access, and token handling alongside EDR. If the browser can issue or relay trust, it must also be observable and controllable at the same layer.

Q: Why do endpoint tools miss so many browser-based account takeover attacks?

A: Endpoint tools miss these attacks because their visibility ends at the operating system, while the attack happens inside the browser session. AiTM phishing, session hijacking, and device code phishing can all produce normal host activity. The result is a successful login or valid token with no suspicious endpoint event to catch.

Q: What breaks when organisations rely on EDR alone for browser security?

A: Reliance on EDR alone breaks the chain between page behaviour and identity compromise. The host may look clean while a user submits credentials to a cloned page, approves a malicious consent, or hands over a session token. Without browser-layer telemetry, teams often see the login success but not the attack that caused it.

Q: How can teams decide whether they need browser-native controls or more network filtering?

A: Teams should use browser-native controls when the risk is inside the session, such as credential relay, token theft, or malicious clipboard execution. Network filtering helps with known-bad destinations, but it cannot reliably see what happens after the page loads. If the attack is identity-driven, inspection must move into the browser.

Technical breakdown

Why EDR stops at the browser boundary

Endpoint detection and response works by watching operating-system activity such as process creation, memory behaviour, registry changes, and file writes. That model is strong against malware and many living-off-the-land techniques, but it ends where the browser session begins. Chrome or another browser looks normal to the endpoint agent even when the page inside it is a fake login, a credential proxy, or a token relay. The browser tab, DOM, script activity, and authentication flow are outside the endpoint observation model by design.

Practical implication: treat browser-layer telemetry as a separate control plane, not an extension of endpoint visibility.

How AiTM, session hijacking, and device code phishing bypass host controls

Adversary-in-the-middle phishing proxies a login in real time so the attacker receives the issued session token. Session hijacking reuses an already valid token stolen from an infostealer or malicious extension, which means no password prompt and no new login event. Device code phishing shifts the deception to the identity provider itself, tricking the user into entering a code on a legitimate page while the attacker completes the flow elsewhere. None of these require malicious code on the endpoint, so EDR sees normal browser activity rather than compromise.

Practical implication: instrument authentication outcomes and token handling, not only endpoint execution signals.

Why browser-native detection changes the response layer

Browser-native security can inspect page behaviour, DOM construction, clipboard events, and suspicious consent flows inside the session before credentials or tokens leave the organisation. That is a different mechanism from network filtering or OS-based detection because it evaluates what the page is doing, not just where it is hosted or whether a process executed. In browser-native attacks, the useful signal is behavioural and contextual: the form is cloned, the OAuth consent is abnormal, or the clipboard payload is malicious before the user runs it.

Practical implication: use controls that can block at the session layer before authentication completes or clipboard execution occurs.

Threat narrative

Attacker objective: The attacker wants a valid authenticated session that can be used for account takeover, SaaS abuse, and data theft without endpoint detection.

1. Entry occurs through browser-native delivery such as AiTM phishing, device code phishing, or a malicious browser lure that never needs endpoint malware.
2. Credential access happens when the attacker proxies the login, steals a session token, or replays an already valid token from a prior compromise.
3. Impact follows as the attacker uses the hijacked session to access SaaS applications, administer cloud services, or exfiltrate data without triggering endpoint-based alarms.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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-layer identity attacks expose a visibility gap, not just a detection gap. The core problem is that EDR observes the host while attackers now operate in the session, where authentication, token issuance, and application access converge. That makes browser telemetry a governance requirement for identity programmes, not an optional enhancement. Practitioners should treat browser visibility as part of identity control design, not a separate security tool category.

Session trust is the named concept this category now has to manage. A browser session can contain credential relay, OAuth consent abuse, token replay, and clipboard-assisted execution without ever looking malicious to the endpoint. That creates a distinct trust boundary inside the identity flow itself, and it is where many current controls are blind. Practitioners need to redefine where trust is granted, observed, and revoked.

Standing trust in the authenticated browser session is more fragile than standing access on the endpoint. Endpoint security assumes the host will reveal compromise through process or file behaviour, but browser-native attacks can preserve normal-looking host activity while the session is already lost. The implication is that identity governance must stop assuming the endpoint will surface the event in time.

Cross-domain identity governance now has to connect human login risk, SaaS access, and NHI-style session abuse. The same browser boundary can carry employee sign-in, admin console access, and delegated application sessions, which means one blind spot can span multiple identity programmes. Practitioners should evaluate browser-layer controls as part of a unified identity risk model rather than as a point product decision.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% only partial visibility.
• Browser-layer identity visibility is the next control problem, and the same governance blind spots that affect third-party OAuth exposure also affect session-level compromise paths.

What this signals

Session-level visibility is becoming a programme design issue, not a tooling preference. If identity compromise can occur after the login page loads, then the control boundary has moved. Teams should plan for browser-native telemetry, consent governance, and token visibility as part of their broader IAM and threat-detection architecture. Top 10 NHI Issues remains a useful lens for understanding how identity sprawl turns into control loss.

The same pattern is appearing across human identity and delegated access. When a browser session can carry admin access, SaaS access, or credential relay without endpoint alarms, the issue is not just detection coverage. It is programme architecture, because the browser has become an identity execution environment.

Session trust debt: organisations that still rely on host-centric monitoring are accumulating blind spots inside authenticated browser sessions. That debt grows faster as browser use absorbs more application administration, OAuth consent, and delegated workflow activity, which is why session-layer controls deserve a place in identity governance roadmaps.

For practitioners

• Map browser-covered identity flows Identify where authentication, consent, and sensitive application use now happen in browsers rather than in dedicated clients, and treat those flows as primary control points. Prioritise admin consoles, SaaS portals, and any workflow that issues reusable tokens. Use this map to decide where session-layer telemetry is mandatory.
• Instrument session-layer detection and response Deploy controls that can inspect DOM behaviour, suspicious script activity, clipboard events, and OAuth consent inside the browser session. The goal is to stop AiTM phishing, device code phishing, and malicious clipboard payloads before credentials or tokens leave the environment.
• Review browser extension and token risk together Audit extensions with access to pages, forms, or session data, then correlate that access with token handling and MFA coverage. If an extension can observe authentication or manipulate content, treat it as an identity control risk rather than just an endpoint hygiene issue.
• Bridge EDR with browser telemetry in incident workflows Ensure the SOC can pivot from endpoint signals to session evidence such as page behaviour, consent grants, and token issuance history. This shortens investigations by showing whether a login was legitimate, proxied, or hijacked, and it reduces time spent chasing clean host telemetry.

Key takeaways

• Modern identity attacks increasingly succeed inside the browser session, where EDR has little or no visibility.
• Browser-native techniques such as AiTM phishing, session hijacking, and device code phishing can produce valid sessions without host compromise.
• Teams need session-layer telemetry and response if they want identity controls to match where authentication and access now actually happen.

Key terms

• Browser-native identity attack: An attack that succeeds inside the browser session rather than by compromising the operating system. The user may see a normal login page or application flow while the attacker steals credentials, relays authentication, or captures a valid session token without triggering endpoint-based detection.
• AiTM phishing: Adversary-in-the-middle phishing is a relay attack that proxies the user’s login in real time so the attacker receives the authenticated session. The page can look legitimate to the user and to host-based tools, which makes the session token the real prize, not the password alone.
• Session hijacking: Session hijacking is the reuse of a valid session token that was stolen from another device, browser extension, or prior compromise. Because the attacker enters through an already authenticated state, the normal password and MFA steps may never occur, and endpoint monitoring can see only ordinary browser activity.
• Browser-layer telemetry: Browser-layer telemetry is the inspection of activity inside the session, including page behaviour, DOM structure, script execution, clipboard actions, and consent prompts. It gives security teams visibility into identity abuse that happens after the browser loads, where network and endpoint tools often lose the plot.

Deepen your knowledge

Browser-layer identity telemetry and session response are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still treats the browser as outside identity governance, the course is a practical next step.

This post draws on content published by Push Security: why the gap between EDR and browser activity creates an identity security blind spot. Read the original.