EDR

An EDR agent sits below the applications and watches the operating system do its work. It records process creation with the full command line and the parent chain, module loads, file and registry changes, network connections, and script content as it is handed to the interpreter. On Windows that telemetry comes from kernel callbacks, from event tracing, and from an interface that lets security products see script and macro contents after they are decoded but before they run.

That stream goes two places. A local engine matches it against behavioural rules and can act immediately, killing a process or blocking a write. And a copy is shipped to a console where it is retained, correlated across machines and made searchable. The retention is the part that matters most in an incident: it is what lets a responder ask what this host was doing forty minutes before the alert, which is a question no preventive control can answer.

The response half is not decoration. Network isolation that keeps the agent connected but cuts everything else, remote shell access to a host you no longer trust, and the ability to retrieve a file or kill a process across a fleet, are what turn a detection into containment measured in minutes instead of days.

The detection logic is behavioural rather than signature-led. It is not looking for a known file. It is looking for a document process spawning a shell, a service binary writing to a user directory, a process reading the memory of the local security authority, or a host suddenly authenticating to forty other hosts. That is why it catches things nobody has seen before, and also why it produces alerts that need a human.

The failure we exploit most often is not evasion. It is coverage. An estate buys licences for the fleet and deploys to the fleet it knows about, and there is always a remainder: the domain controller nobody wanted to touch, the appliance the vendor forbids agents on, the build server, the jump host, the virtual desktop image that was cloned before the agent was installed, the Linux workloads that were out of scope for the rollout. On an internal test we look for the gap before we look for a bypass, because the gap is free and it is nearly always there.

The second failure is response mode. A large share of the deployments we meet run in detect-only, either everywhere or on the servers that matter, because a false positive once broke something. That is a defensible decision and it must be a stated one. In detect-only, the control is not the product: it is whoever reads the alert, and if the alert lands in a queue nobody watches out of hours, the mean time to response is the length of a weekend.

Then there is evasion proper, which is real and narrower than vendors and attackers both suggest. Techniques that restore the original system call path, that run entirely inside a trusted process, or that load a signed but vulnerable driver to act from the kernel, all exist and all work sometimes. What they do not do is make an attacker invisible: they suppress one sensor while the rest of the telemetry keeps flowing. On engagements the useful lesson for the client is rarely “your EDR can be bypassed”. It is that our activity was recorded, and the recording was never looked at.

The third failure is the quietest. Attackers who use only tools already on the host, which is living off the land, do not trip anything anomalous because nothing anomalous ran. Distinguishing an administrator using a remote management tool from an intruder using the same tool is not a product question. It is a question about whether anybody knows what normal looks like on that host.

These four are sold against each other and they are not the same kind of thing. Two are product categories, one is a delivery model, and one is a platform. Comparing them on features misses that.

The practical reading: MDR is orthogonal to the other three, because you can buy it on top of any of them. XDR is EDR plus more sensors from one vendor, which buys correlation and costs you portability. And SIEM does not replace EDR: it has no agent and no ability to act on a host. Where a compliance obligation requires log retention across the estate, the SIEM is what satisfies it, and no endpoint product does.

Deploying it and leaving the default policy. Defaults are tuned to avoid breaking anything on any customer. Tuning, exclusions and the decision about what blocks versus what alerts are the project, not the installation.

Excluding whole directories to silence noise. Every broad exclusion is a place to run from. We look for them, and where they are readable from a host we can reach, they are the fastest path.

Assuming full coverage. Reconcile the agent list against the directory, the hypervisor and the cloud inventory monthly. The number will not match, and the difference is the real finding.

Treating alert volume as the metric. The number that matters is how long it takes for someone to touch a high-severity alert at three in the morning, and whether they have authority to isolate a host without a change request.

Buying it to satisfy an auditor. An auditor asks what the control is and how you know it works. An agent count is not evidence of either.

Test the coverage before you test the detections. Reconcile agents against every source of truth you have, and treat any host that cannot take an agent as an accepted risk with a named owner and a compensating control, not as an exception in a spreadsheet.

Then test the detections deliberately rather than waiting to be attacked. Run a known technique in a controlled way, on a host that matters, and check three things in order: did the telemetry record it, did a rule fire, and did anyone act. Most estates pass the first, a good number pass the second, and the third is where the honest gap sits. That exercise is a purple team in its simplest form, and it does not need a large budget to be worth doing.

Map what fires to MITRE ATT&CK so the answer to “what are we blind to” is a list of technique identifiers rather than an impression. Watch for the agent going quiet: a sensor that stops reporting is either a broken host or a hostile one, and both need somebody to look.

In a red team or internal report, EDR appears twice. Once as coverage, where we list the hosts we reached that had no agent and where we got them from. And once as an outcome, where we record what we did, at what time, and whether it was detected, alerted, or acted on.

The evidence we hand over is a timeline: our action, the timestamp, and the client’s own console entry for it if one exists. That comparison is more useful than any pass or fail, because it shows precisely where the chain stopped. We have written reports where every step was recorded correctly and the finding was that nobody opened the console for nine days.

Severity is written against the consequence, not against the product. “The EDR did not block us” is not a finding on its own. “A privileged host had no agent and was our route to the domain” is.

This is one of the things an adversary emulation exercise measures directly.

Is EDR just a better antivirus? No. Antivirus decides whether a file is bad and blocks it. EDR records behaviour continuously, detects patterns of activity rather than files, retains the data for investigation, and gives a responder the ability to act on a host remotely. Most EDR products include the antivirus function as one part.

Can EDR be bypassed? Yes, and this is not the useful question. Specific sensors can be suppressed and specific rules avoided. Total invisibility across every telemetry source is much harder, and in practice attackers are found by the activity that was recorded rather than by the alert that fired.

Do we still need a SIEM if we have EDR? Usually yes. EDR sees hosts with an agent. Firewalls, identity providers, mail gateways, cloud control planes and applications do not have one, and log retention obligations cover all of them.

Does EDR stop ransomware? It stops a good deal of commodity ransomware automatically. It does much less against an operator who has valid credentials, uses built-in administrative tooling, and disables or uninstalls the agent from a privileged account before the encryption starts, which is the sequence in most serious cases.