EDR Architecture and Detection Engineering Skill

Core Model: How EDRs Work

An EDR has four components:

┌─────────────────────────────────────────────┐
│               EDR Agent                     │
│  ┌──────────┐ ┌──────────┐ ┌─────────────┐  │
│  │ Sensors  │ │Telemetry │ │  Detections │  │
│  └──────────┘ └──────────┘ └─────────────┘  │
└─────────────────────────────────────────────┘
         ↕ kernel-mode driver
┌─────────────────────────────────────────────┐
│            Windows Kernel                   │
│  Callbacks │ Filter Drivers │ ETW Providers  │
└─────────────────────────────────────────────┘

• Agent: user-mode process + kernel-mode driver
• Sensors: data collectors (kernel callbacks, hooks, ETW)
• Telemetry: raw event data streamed to analysis engine
• Detections: rules applied to telemetry (brittle = exact match, robust = behavioral)

Brittle vs. Robust Detections

• Brittle: match on specific strings, hashes, or exact sequences. Easy to evade by changing surface.
• Robust: match on behavior patterns, relationships, and context. Harder to evade without changing the goal itself.

Detection engineering principle: build detections at the level of attacker behavior (what they need to do), not attacker tooling (what they happen to use today).

---

EDR Sensor Types

1. Function-Hooking DLLs

How it works: EDR injects a DLL into every process. The DLL patches the first bytes of target functions in ntdll.dll with a JMP to the EDR’s inspection code. When your process calls NtCreateProcess, execution goes through the EDR first.

Architectural implication for defenders:

• Only covers user-mode API calls
• If a process calls syscalls directly (bypassing ntdll), hooks don’t fire
• Provides good visibility into API usage sequences

Detection opportunities:

• Hook presence verification (detect processes that have unhooked their own ntdll)
• API call sequence analysis (CreateRemoteThread → WriteProcessMemory patterns)
• Anomalous DLL load patterns

2. Process/Thread-Creation Callbacks (Kernel)

How it works: PsSetCreateProcessNotifyRoutine registers a kernel callback that fires on every process creation/termination. EDR driver receives: PID, parent PID, command line, image path.

Key data available:

• Command line of new process
• Parent/child relationship (process lineage)
• Process image path and flags

Detection opportunities:

• Spawning cmd.exe or powershell.exe from unexpected parents (Word, Outlook, svchost variants)
• Suspicious command-line patterns (encoded payloads, LOLBin abuse)
• Process lineage anomalies

Common evasion attempts (for detection tuning):

• Command line tampering: create process with spoofed command line
• PPID spoofing: specify a different parent PID to appear as child of a trusted process
• Process image modification: change the path in PEB after process creation

3. Object Notifications (Kernel)

How it works: ObRegisterCallbacks lets drivers intercept handle requests to process objects. Fires when any process tries to open a handle to another process (e.g., for credential theft from lsass.exe).

What’s monitored:

• Handle requests to lsass.exe (credential access)
• Handle requests with sensitive access rights (PROCESS_VM_READ, etc.)

Detection opportunities:

• Any process opening lsass with read permissions outside of known-good tools
• Suspicious handle request patterns (many short-lived handles to different processes)

4. Image-Load Notifications

How it works: PsSetLoadImageNotifyRoutine fires when a DLL or executable is loaded. Provides path and image base.

Detection opportunities:

• DLLs loaded from non-standard locations (temp directories, AppData)
• Known-malicious DLL names
• DLLs that shadow system DLLs (DLL search order hijacking)

5. Filesystem Minifilter Drivers

How it works: Filter driver registers at a specific altitude in the I/O stack. Can inspect all file operations (reads, writes, creates, deletes).

Detection opportunities:

• Ransomware patterns: mass file rename operations, entropy changes in modified files
• Executable files dropped to disk followed by execution
• Suspicious file writes to startup/registry paths

6. Network Filter Drivers

How it works: Windows Filtering Platform (WFP) callout driver intercepts network traffic.

Detection opportunities:

• Process-to-network activity mapping (which process made which connection)
• Unusual outbound connections from system processes (svchost connecting to rare IPs)
• DNS queries from unexpected processes
• Beaconing patterns (regular intervals, constant byte lengths)

7. Event Tracing for Windows (ETW)

How it works: EDRs subscribe to ETW providers including Microsoft-Windows-Threat-Intelligence (requires PPL protection) and process-level providers.

Key providers for security:

• Microsoft-Windows-Kernel-Process: process/thread/image events
• Microsoft-Windows-Kernel-File: file I/O
• Microsoft-Windows-Kernel-Network: network events
• Microsoft-Windows-Threat-Intelligence: high-privilege threat detection events (LPAC)

Detection advantage: ETW events are harder to suppress than usermode hooks (requires kernel access to disable).

8. AMSI (Antimalware Scan Interface)

How it works: Windows component that lets EDRs scan content at runtime. Integrated into PowerShell, VBA, JScript, .NET, and other script hosts.

What it scans: script content before execution (not file on disk).

Detection opportunities:

• Malicious PowerShell one-liners (even if obfuscated — PowerShell passes deobfuscated content to AMSI)
• Malicious .NET assembly loading (Reflection.Assembly.Load is AMSI-scanned)
• COM scripting engine abuse

9. ELAM (Early Launch Antimalware)

How it works: ELAM driver loads before all third-party drivers. Can classify unknown drivers as good/bad/unknown, preventing malicious kernel drivers from loading.

Detection/protection: kernel-level driver signing + integrity verification at boot.

---

Detection Architecture Principles

The Detection Hierarchy (most to least robust)

Goal-level (attacker objective)       ← hardest to evade
    └── TTP-level (technique)
        └── Tool-level (specific C2 IOCs)
            └── Hash/signature-level  ← easiest to evade

Build detections targeting TTPs. Hash-based detections are defeated by recompilation.

Correlated Detection (Context-Aware)

Single events are often insufficient. Correlate sequences:

• svchost.exe spawning → cmd.exe spawning → whoami execution = suspicious sequence
• File write (DLL) + Registry modification (persistence) + Outbound connection = probable compromise chain

Tuning for Environment Baseline

What’s suspicious in one environment is normal in another. Good detections:

1. Establish baseline of normal behavior per organization
2. Alert on deviations from baseline, not universal rules
3. Reduce false positives by enriching with asset classification

Telemetry Coverage Gaps

Every sensor type has blind spots:

• User-mode hooks: bypassed by direct syscalls
• Kernel callbacks: limited info per event
• ETW: can be disabled with kernel access
• AMSI: pre-execution only, not behavioral

Defense principle: layer multiple sensor types so that bypassing one doesn’t blind the entire system.

---

Red Team Assessment Methodology (for authorized engagements)

Sensor Enumeration

Before testing detection coverage:

1. Identify which sensors the EDR uses (registry, service analysis, driver list)
2. Map which operations are monitored vs. unmonitored
3. Identify detection gaps to include in pentest scope

Detection Validation Testing

For each sensor type, create a benign test case that exercises the sensor:

• Does process creation with known-malicious parent/child get alerted?
• Does AMSI scan test strings correctly?
• Does the EDR detect handle access to lsass?

Document gaps → prioritize hardening.