Endpoint Detection (Defender's View)
This is the defensive counterpart to malware/edr-evasion.md. That file shows how attackers evade EDR; this one covers how endpoint detection actually works, what telemetry it produces, and how you write detections on it across Windows, Linux, and macOS. The endpoint is where attacker behavior becomes concrete — a process spawns, a file is written, a connection is made — so it's the richest detection surface there is.
Last verified2026-06
How EDR Works
EDR (Endpoint Detection and Response) is an agent on the host that observes low-level system events and streams them to a backend for detection. Understanding how it sees is what lets you reason about both detections and evasions.
What an EDR observes
every process creation, with parent process, command line, user, and hashes. The single most valuable telemetry.
creation, modification, deletion (catches dropped payloads, ransomware encryption).
connections per process (which process talked to which IP).
(Windows) — persistence keys, configuration tampering.
DLLs loaded into processes (catches injection, sideloading).
on Windows historically via user-mode hooks; increasingly via kernel callbacks and ETW.
How it observes (Windows)
the OS notifies the driver on process/thread/image events. Hard for user-mode malware to evade.
the EDR patches the start of ntdll functions to inspect calls. Powerful but evadable — this is what "unhooking" and "direct/indirect syscalls" attack (see edr-evasion.md).
a built-in telemetry firehose; ETW-TI (Threat Intelligence) provides high-value events. Attackers try to patch/blind ETW.
The detection splitEDRs do some detection on the endpoint (fast, works offline, but limited context) and stream raw telemetry to the backend for richer correlation (cross-host, historical, heavier logic). As a detection engineer you often write logic against that streamed telemetry in your SIEM/data lake, not just rely on the vendor's built-in rules.
The Process Tree Is Everything
The most powerful endpoint-detection concept: parent-child process lineage. A process in isolation is often ambiguous; a process in the context of what spawned it is frequently a smoking gun.
Benign: explorer.exe → winword.exe (user opened a doc)
Malicious: winword.exe → powershell.exe -enc <b64> (a document spawned an
encoded PowerShell — Office
apps don't do this normally)
Malicious: w3wp.exe → cmd.exe → whoami (the IIS worker process
spawned a shell — webshell!)Most high-value endpoint detections are parent-child anomalies: "a process that should never spawn a shell just did." Office apps, web server workers, and database processes spawning command interpreters are classic webshell / exploitation signals. When you read or write endpoint detections, think in trees, not single events.
Windows Telemetry: Sysmon & Event Logs
Sysmon (System Monitor, from Sysinternals) is a free driver that produces high-quality, detection-grade event logs — the closest thing to free EDR telemetry. Key event IDs every detection engineer should know:
| Sysmon Event ID | What it captures | Why it matters |
|---|---|---|
| 1 | Process creation (cmdline, parent, hashes) | The backbone of behavioral detection |
| 3 | Network connection (per process) | Process-to-IP attribution |
| 7 | Image/module load | DLL sideloading, injection |
| 8 | CreateRemoteThread | Classic process injection |
| 10 | ProcessAccess | LSASS access (credential dumping — T1003) |
| 11 | File create | Dropped payloads, ransomware |
| 12/13/14 | Registry events | Persistence (Run keys), tampering |
| 22 | DNS query | C2 domain resolution per process |
A good Sysmon config (the community SwiftOnSecurity config and Olaf Hartong's sysmon-modular are the standard starting points) is itself a detection-engineering artifact — what you log determines what you can detect.
Native Windows Security event IDs also matter:
process creation (enable command-line auditing or you only get the path, not the args).
successful / failed logon. Logon type is critical: type 3 = network, type 10 = RDP, type 5 = service. Lateral movement shows up as unusual type-3 logons.
special privileges assigned (admin logon).
new service installed (a classic persistence/lateral-movement signal, e.g. PsExec).
Linux Telemetry: auditd & eBPF
Linux endpoint detection has two main telemetry sources:
| auditd | eBPF | |
|---|---|---|
| What it is | The kernel's built-in audit subsystem | Programmable, sandboxed kernel instrumentation |
| How you use it | Write rules for specific syscalls and files (log every execve, watch /etc/shadow) | Load programs that observe syscalls, process and network events |
| Strengths | Always available, reliable, well understood by auditors | Low overhead, rich context, can enrich in-kernel |
| Weaknesses | Verbose and heavy at scale; limited context | Needs a modern kernel; the verifier is itself attack surface |
| Tools | auditd, ausearch, Laurel | Falco (see kubernetes/security.md), Tracee, Tetragon, most modern Linux EDR |
What to detect on Linux
binaries running from /tmp, /dev/shm or /var/tmp, where dropped payloads land.
bash -i, or any process whose stdin/stdout is redirected to a socket.
new cron entries or systemd units, edits to ~/.bashrc or /etc/profile.d, changes to SSH authorized_keys.
reads of /etc/shadow, SSH private keys, cloud credential files like ~/.aws/credentials.
history clearing, log tampering, loading kernel modules.
macOS Telemetry: ESF & Unified Logs
macOS matters because corporate fleets (and most large consumer tech companies) are heavily Mac. Detection sources:
Apple's modern API for observing process, file, and system events; the foundation of modern macOS EDR. Replaced the older kernel-extension approach.
log)the OS-wide structured log stream.
unique to macOS: LaunchAgents/LaunchDaemons (~/Library/LaunchAgents, /Library/LaunchDaemons), login items, configuration profiles.
What to detect on macOSabuse of osascript (AppleScript) for execution and phishing dialogs; curl/bash piped execution; TCC (privacy permission) database tampering; gatekeeper/quarantine-attribute removal (xattr -d com.apple.quarantine); unsigned or ad-hoc-signed binaries executing; new LaunchAgents/Daemons.
Behavior over signatures (again)
Legacy antivirus matched file signatures (a hash or byte pattern). It fails against any novel or recompiled malware. Modern endpoint detection is behavioral — it doesn't care what the file is called or hashes to; it cares what it does. "A process injected a thread into another process, which then connected to an external IP" is a behavior that catches an entire class of attacks regardless of the specific tool. This is the same Pyramid-of-Pain logic from detection-engineering.md, applied at the host level: signatures are the volatile bottom, behavioral detections are the durable top.
Understanding Evasion Makes You a Better Detector
Because attackers actively evade EDR (full catalog in malware/edr-evasion.md), endpoint detection engineering is partly about detecting the evasion itself:
designed to bypass user-mode hooks → detect via the kernel-callback and ETW telemetry the evasion doesn't blind, and via anomalies like a syscall instruction originating from non-ntdll memory.
(living off the land) — attackers use signed, trusted Windows binaries (certutil, regsvr32, mshta, rundll32) to avoid dropping malware → detect via how they're used (e.g., certutil downloading a file, rundll32 with no module arguments).
blinding telemetry → detect the patching attempt (memory modification of amsi.dll/ETW functions) and treat a gap in expected telemetry as suspicious.
The principle: when an attacker blinds one sensor, detect on the sensors they can't easily blind, and treat the silence of a normally-chatty source as a signal in itself.
Interview Questions
Process creation events with full lineage — parent process, command line, user, and hashes (Sysmon Event ID 1, or Windows 4688 with command-line auditing on). It's the most valuable because the majority of high-signal endpoint detections are parent-child anomalies: a process is often ambiguous alone but damning in context. Word spawning an encoded PowerShell, or an IIS worker process spawning cmd.exe, are smoking guns you can only see if you have the process tree. Command line is essential too — without it you see that PowerShell ran but not what it did, and the arguments are usually where the malice is.
Traditional AV is signature-based — it matches files against known-bad hashes or byte patterns, so it fails against anything novel or recompiled. Modern EDR is behavioral: an agent observes low-level events — process creation, file and registry changes, network connections, module loads, API/syscall activity — and detects based on what software does rather than what it is. So "a process injected a thread into another process which then beaconed out" catches a whole class of attacks regardless of the specific malware. EDR also adds response (isolate the host, kill the process) and streams rich telemetry to a backend for cross-host correlation and historical hunting, which AV never did.
User-mode hooks are only one of an EDR's sensors, so I detect on the ones direct syscalls don't blind. Kernel callbacks still fire on process, thread, and image events regardless of user-mode tampering, and ETW — especially ETW-TI — provides telemetry from below the hooked layer. There are also tell-tale anomalies of the technique itself: a syscall instruction executing from memory that isn't ntdll (legitimate syscalls almost always originate inside ntdll), or unusual call stacks. And more broadly, I'd correlate — even if the injection is stealthy, the objective usually isn't: the payload still has to make a network connection, access credentials, or persist, and those downstream behaviors are detectable. The principle is to never depend on a single sensor an attacker can blind.
LOLBins — living-off-the-land binaries — are legitimate, signed, trusted OS tools that attackers abuse so they don't have to drop their own malware: things like certutil, regsvr32, mshta, rundll32, bitsadmin on Windows. Since the binary itself is trusted, you can't detect on its presence — you detect on anomalous usage. Certutil is legitimate, but certutil downloading a file from the internet is not its normal job; rundll32 launched with no module export argument is suspect; regsvr32 fetching a remote scriptlet (the Squiblydoo technique) is malicious. So the detections are behavioral patterns around known LOLBins, and the LOLBAS project catalogs the abusable functions to build coverage from.
Because endpoint detection is an adversarial game — attackers actively study and bypass the sensors. If I understand that unhooking and direct syscalls target user-mode hooks specifically, I know to lean on kernel callbacks and ETW that those techniques don't blind. If I understand ETW and AMSI patching, I know to detect the patching attempt itself and to treat an unexpected silence from a normally-chatty telemetry source as a signal. Knowing the evasion catalog tells me where my blind spots are and which sensors are resilient, so I build defense-in-depth across telemetry sources rather than trusting any single one. It's the same reason red and blue teams work best together — you can't reliably detect what you don't understand how to evade.