EDR and what it can and cannot see

Why this matters

Endpoint detection and response is the tool that makes lesson 7 possible. It is the source of process ancestry, command lines, persistence changes and memory indicators, and it is usually the fastest route to both answering and ending an intrusion.

It is also routinely over-trusted. "EDR is deployed" gets treated as though the endpoint problem is solved, when the honest position is that EDR sees a great deal, misses specific and predictable things, and can be attacked itself. The exam tests the boundary.

The lesson

Telemetry an EDR agent collects

An EDR agent is a sensor that lives inside the operating system and reports what it observes. Typically:

• Process events: creation and termination, full command line, parent, user context, and the hash of the image.
• File events: creation, modification, deletion, and rename.
• Registry events on Windows, especially in persistence locations.
• Network events, tied to the process that made them — the connection that a network sensor sees anonymously, attributed here to a binary.
• Module loads, which is how injected and hijacked libraries surface.
• Authentication and logon events in local context.
• Script content, where the platform can capture it before execution.
• Memory operations: handle access to other processes, remote thread creation, unusual memory protections.

The attribution is the point. A firewall log says an address connected somewhere; EDR says this binary, launched by this parent, running as this user, connected somewhere. That is the difference between an alert and an answer.

Most platforms then enrich centrally: reputation on hashes, prevalence across the estate ("this binary exists on one machine in ten thousand"), and mapping to a technique framework.

Detections, preventions and the difference

Two different behaviours, frequently conflated, and the distinction matters operationally.

Detection observes and reports. The activity happened; you were told.

Prevention blocks. The activity was stopped, and you were told.

Why it matters to an analyst:

• A prevented event usually means the attacker's attempt failed — but they were present to attempt it, and prevention on one technique rarely means nothing else succeeded. A blocked credential-dumping attempt is not a closed case; it is proof of an intruder on that host.
• A detected but not prevented event means the activity completed. Scope it.
• Prevention has a false-positive cost that detection does not. Blocking a legitimate business application is an outage, which is why many organisations run substantial parts of the policy in detect-only mode. That decision is invisible in the console unless you check, and "the EDR would have blocked it" is a claim worth verifying before repeating.

Most platforms also offer response actions short of blocking: kill the process, quarantine the file, isolate the host. These matter in the containment lesson.

Isolating a host, and when not to

Network isolation is the headline EDR response: the agent cuts the host's network access while keeping a channel to the management console, so you retain visibility and control without the machine being able to talk to anything else.

It is fast, reversible and usually the right first move for a confirmed compromise.

When to think first:

• Isolation is visible to the attacker. Command and control stops responding. A sophisticated adversary may react by burning what they have — deploying ransomware, destroying logs, or abandoning that host and accelerating elsewhere. If you are mid-investigation and the attacker is active across multiple hosts, isolating one can start a race you have not prepared for.
• Critical systems. Isolating a domain controller, a production database or a medical device has consequences that may exceed the intrusion's. That is a business decision, not an analyst's, as established in lesson 1.
• Evidence. Isolation does not destroy memory, but the disruption may trigger a reboot by a confused user, and a reboot does. If memory matters, capture first.
• Coverage. Isolation protects the network from the host. It does nothing about a local encryption payload already running.

A workable default: for a single compromised workstation with active malicious activity, isolate immediately. For a suspected wider intrusion, coordinate so that containment happens across all known footholds at once — the reasoning developed properly in the containment lesson.

Live response: pulling artefacts without a reimage

Most EDR platforms offer a remote shell or scripted collection against a live host. Used well, this collapses hours of forensic work into minutes.

Well-suited to live response:

• Collecting the targeted artefacts from lesson 7 — prefetch, registry hives, event logs, scheduled tasks, a memory image if supported.
• Listing running processes, connections and loaded modules now.
• Retrieving a suspicious binary for analysis.
• Checking for a specific indicator across many hosts at once, which is the single highest-value thing this capability offers.

Discipline that keeps it defensible:

• Record what you ran and when. Your own commands appear in the telemetry and will later be interpreted by someone else.
• Prefer collection over modification. Deleting the attacker's file feels productive and destroys evidence you may need.
• Hash on collection, as covered in the evidence lesson.
• Mind the order of volatility: memory before disk, live connections before anything that requires a reboot.
• Remember it is a privileged remote-execution tool. An attacker who compromises the EDR console has an excellent one.

Evasion: unhooking, tampering and agent gaps

EDR is software on a machine the attacker may control, and it is attacked directly.

Techniques to recognise:

• Unhooking. Many agents monitor by hooking API calls in user space; malware restores the original code from a clean copy on disk and the hooks stop reporting. The process still runs, the agent still shows healthy.
• Direct syscalls, bypassing the hooked layer entirely.
• Tampering and service disruption: stopping the service, killing the process, uninstalling. Modern agents have protection against this; it is not absolute.
• Bring-your-own-vulnerable-driver: loading a signed but flawed driver to gain kernel access and disable protections from underneath.
• Blind spots by design: many agents have reduced visibility into kernel activity, firmware, hypervisors, and certain script hosts.
• Coverage gaps — the plainest evasion of all. Unmanaged devices, contractor laptops, appliances, network equipment, legacy systems that cannot run an agent, and newly built hosts before deployment. The attacker does not need to defeat your EDR if they can work on a machine that never had it.

The detections that matter here are about the agent itself: agent stopped reporting, agent service stopped, tamper protection triggered, driver loaded that is known-vulnerable. And the highest-value one is the coverage comparison from the logging lesson — agent inventory against an independent asset list.

Which brings back the recurring theme, now in its sharpest form: an EDR console showing no alerts is indistinguishable from an EDR agent that was switched off an hour ago, unless something is explicitly watching for the silence.

Topics this lesson owns

• [x] Telemetry an EDR agent collects
• [x] Detections, preventions and the difference
• [x] Isolating a host, and when not to
• [x] Live response: pulling artefacts without a reimage
• [x] Evasion: unhooking, tampering and agent gaps