Push + Endpoint Security: Extending detection and response to the browser

EDR is still the best tool for attacks that touch the endpoint

Endpoint Detection and Response (EDR) tooling is fundamental to modern security. It earned its place as a foundational control by moving defense away from static, known-bad indicators and toward deep, real-time detection, investigation, and response based on behavior observed in a live environment.

By running an agent inside the operating system, EDR gave defenders something they never had before: visibility into what was actually happening on the host as it happened, and the ability to act on it.

That agent-level visibility is still incredibly powerful. File system changes, process execution, memory behavior, or registry modifications is the kind of telemetry that enables threat hunting, exposes fileless attacks, and allows teams to contain incidents by isolating a device or killing a malicious process. For anything that touches the endpoint, EDR remains the right tool.

But that’s the key constraint: for anything that touches the endpoint.

But modern attacks have moved beyond the endpoint

The reality of how work gets done has shifted. Most applications are now SaaS-based and accessed entirely through a browser. Employees authenticate, move data, administer systems, and interact with customers inside a browser window. And attackers have followed them there.

When attacks play out in the browser, endpoint-level signals often never appear. From the operating system’s perspective, there’s just a browser process behaving normally. The EDR agent is doing exactly what it was designed to do, but the activity that matters is happening within the browser itself.

That’s the gap teams are running into. EDR protects the integrity of the host, but it has no visibility into the live application session inside the browser. And as attackers consciously avoid the endpoint entirely, that blind spot is becoming harder to ignore.

Attackers are consciously evading EDR

The gap endpoint teams are running into isn’t accidental. It’s the result of attackers adapting to where defenders are strongest (and weakest).

Modern EDR has made compromising the host operating system expensive and noisy. Deep telemetry and constant monitoring mean that even when an attacker manages to execute code on a device, that action is quickly under scrutiny. From there, progress is slow. After all, lateral movement and persistence take time, and all of it carries risk and generates signals defenders are good at catching.

So attackers take a different route. Instead of targeting the OS, they operate inside the browser session, abusing legitimate access paths to cloud applications directly over the internet. The endpoint just sees a browser session, not the malicious activity that's happening inside it.

EDR agents are extremely good at protecting the operating system, but their visibility largely stops at the browser boundary. They can see that a browser process is running. They can’t see what a user is actually interacting with inside a specific tab, or what code is executing within the browser.

This is the shift security teams are feeling. Attacks don’t trigger endpoint alerts because they aren’t endpoint attacks. They unfold inside the browser, over standard web sessions, using legitimate accounts. To EDR, the host is unaffected. To the business, the damage is already underway.

How modern attacks bypass EDR

Examples of modern attacks that are consciously evading EDR include:

• AiTM phishing: Sophisticated attacker-in-the-middle phishing kits render convincing login pages directly in the browser and proxy authentication in real time, stealing credentials or MFA tokens as the user enters them. From the OS perspective, nothing appears unusual; EDR can’t see the page structure or scripts running inside the tab.

• Session hijacking: When attackers obtain a valid session token, they gain persistent access to an account without needing a password at all. Once in use, the session typically blends into normal browser activity, generating no endpoint data.

• Malicious browser extensions: Malicious extensions (either made by attackers or hijacked by them) can read page content, intercept credentials, or siphon session tokens. Because extensions operate inside the browser’s execution model, their behavior is largely invisible to endpoint tooling focused on OS-level activity.

Even attacks that nominally involve the endpoint often stay outside EDR’s strongest visibility. ClickFix-style social engineering is a good example. Attackers manipulate users into taking risky actions that look legitimate, the most prominent example being executing malicious commands on the host that are deliberately obfuscated or broken into benign-looking steps. While EDR may catch the code execution (and any malware the execution attempts to install), these techniques are designed to stay ambiguous enough to avoid reliable detection.

All of these attacks succeed for the same reason: the activity unfolds inside the browser. And because EDR was never designed to observe or control what happens inside a live browser session, attackers can operate there with far less resistance.

Extending detection and response to the browser

Defenders need to meet attackers where they actually operate. That means establishing real detection and response capabilities inside the browser itself.

When endpoint security evolved, it did so by putting an agent on the host to observe behavior, collect telemetry, and act at the source — getting inside the data stream. The same logic applies here. If the browser is where credentials are entered, sessions are established, and attacks unfold, then it needs to be treated as a security surface in its own right. That doesn't mean just looking at web traffic, but examining client-side browser processes and activity that are the best, earliest indicators of bad activity.

This doesn’t replace EDR. EDR secures the host. Identity tools govern authentication. But the browser, the layer that connects users to everything else, is a blind spot. Extending detection and response into that layer fills the gap while complementing the controls that already work.

Your browser detection and response checklist

• Browser-native protection: Running inside the browser is the only way you can see what page a user is interacting with, what scripts are running, and how the session is behaving in real time. It’s also the only place you can reliably distinguish between normal user activity and attacker-driven manipulation.

• Behavioral detection: Detection can’t rely on static indicators. It has to be based on behaviors — like how pages render, how credentials are submitted, and how sessions are established and abused.

• Real-time interception: Response has to be immediate. Blocking credential submission, interrupting a malicious action, capturing high-fidelity context, all of that needs to happen at the point of interaction — before an account is compromised.

This is what it means to extend detection and response to the browser: not another tool bolted onto the stack, but a necessary evolution in how modern attacks are actually stopped.