Evading EDR

Hand's approach is to take an endpoint detection and response agent apart into its sensors and treat each one as an engineering component with a documented mechanism, a defined scope and therefore a defined blind spot. Function hooks, kernel notification callbacks, filesystem minifilters, network filters, event tracing, scanners, the scan interface, early-launch drivers.

The book is framed offensively, and the analysis is symmetrical: understanding exactly what a sensor observes is equally the defender's problem, because it is what tells you whether an absence of evidence means anything.

Why it is on this shelf

Because blue-team and threat-hunting challenges hand you telemetry and ask what happened, and answering that requires knowing where each event came from and what it could not have seen. An event log is not a recording of the system; it is the output of a specific sensor with specific limits.

Chapter 8, Event Tracing for Windows

Event Tracing for Windows is the mechanism most Windows telemetry ultimately comes from, and this chapter explains its architecture in the three parts that matter: providers, which are components that emit events; consumers, which read them; and controllers, which start and configure sessions.

The numbers make the point better than the description. A default Windows 10 installation registers around eleven hundred providers, each identified by a GUID and a friendlier manifest name, and only a handful are of interest for security. Knowing which ones - the scan interface provider, the .NET runtime provider, the threat intelligence provider - is what turns a wall of events into a source you can reason about.

The structural weakness he draws out is the same one every defender should internalise: a provider emits events because its developer chose to instrument that code path. Anything reached by a path nobody instrumented emits nothing at all, and a session can be stopped or its consumer starved. Endpoint telemetry for defenders covers what that means for reading a challenge's logs, and log analysis and threat hunting covers the analysis itself.

Chapter 10, Antimalware Scan Interface

The scan interface exists because of a specific problem: script languages and runtimes hand code to an interpreter after every layer of encoding and obfuscation has been undone, so a file scan of the original artefact sees nothing useful. The interface lets the runtime submit the content it is about to execute, in its final form, to whatever antimalware provider is registered.

His walkthrough follows a PowerShell script block through the pipeline: the compiler performs a security check before compilation, the script block reaches an internal scan utility, and that utility opens a session and calls the scan function, which invokes the registered providers. The value of following the stack is that it shows exactly when the scan happens - after decoding, before execution - which is what makes the interface effective against layered obfuscation and useless against anything that never passes through that runtime.

For CTF work the payoff is in reading obfuscated scripts. Every layer of encoding a sample applies has to be undone before the interpreter can run it, which means it can be undone by you as well, by the same steps in the same order. The PowerShell deobfuscator does that unwrapping, and malware anti-analysis tricks covers why the layers are there.

Where it stops

It is Windows only and deeply internal - kernel callbacks, driver architecture, undocumented structures. There is no Linux, no macOS and no network detection beyond the endpoint's own filters. It is also written for readers building tooling against these sensors, so long stretches are implementation detail you will read once.

It says nothing about the analysis side: no hunting queries, no detection engineering, no incident response. It tells you what the sensor sees, and stops there. For the model underneath the sensors, Windows Security Internals is the companion volume.

What to take into a challenge

Ask where each artefact came from before you interpret it. A process creation event, a script block log and a filesystem event are produced by three different mechanisms with three different coverages, and the difference decides which of them you can treat as complete.