EDR Basics

What EDR Actually Does

• Endpoint detection and response is security software focused on endpoint visibility, detection, investigation, and response.
• Instead of only checking whether a file is known malware (traditional antivirus), EDR watches behavior at the OS and kernel level — process creation, command-line activity, file changes, logons, network connections, registry modifications, and suspicious parent-child process relationships.
• Good EDR alerts should be near real time, actionable, and connected to enough evidence for an analyst to understand scope without chasing a dozen different log sources.
• EDR differs from antivirus in its response capability: isolate a host, kill a process, quarantine a file, collect a memory dump, run a script — all from the console without needing hands on the keyboard.

EDR Telemetry Sources — What Your EDR Collects

The value of EDR depends entirely on the breadth and depth of its telemetry. A sensor that only records process creation is blind to half the attack surface.

Critical Telemetry Gaps to Check

Detection — EDR Alert Triage

Step-by-Step Triage Workflow

When an EDR alert fires, do not click “resolve” until you have answered every question in this workflow:

Alert received
    │
    ▼
Step 1: Determine the alert type
   ├─ Malware detection (file hash match, AMSI trigger, signature match)
   ├─ Behavioral detection (suspicious process tree, anomalous network connection)
   ├─ Indicator match (IOC match from threat intel)
   └─ Custom rule trigger (detection rule written by your team)
    │
    ▼
Step 2: Examine the process tree
   ├─ What process spawned the alerting process?
   ├─ What did the alerting process spawn?
   ├─ What command line arguments were passed?
   ├─ Is the process running from a normal location? (C:\Windows\System32 vs C:\Users\Public\Downloads)
   └─ Is the process signed? (Microsoft signed? Signed by an unknown publisher?)
    │
    ▼
Step 3: Scope the host
   ├─ What network connections did it make in the last 24 hours?
   ├─ What file system changes preceded the alert? (script files dropped? DLLs written?)
   ├─ What registry persistence mechanisms were created?
   ├─ What other processes ran under the same user account?
   └─ Is the host domain-joined? (enables lateral movement analysis)
    │
    ▼
Step 4: Scope the environment
   ├─ Does the same indicator appear on other endpoints?
   ├─ Is this a known attacker behavior pattern? (common TTP mapping)
   ├─ Does the parent process correlate with a known campaign?
   └─ Have any other alerts fired in the same time window?
    │
    ▼
Step 5: Determine response
   ├─ Isolate the host (immediately if high confidence / active C2)
   ├─ Kill the process
   ├─ Quarantine the file
   ├─ Collect a full memory dump
   └─ Initiate formal incident response process if evidence suggests hands-on-keyboard activity

Critical Indicators by EDR Telemetry Type

Process tree anomalies (always investigate):

Memory / handle access anomalies:

SPL Query — Find LSASS Handle Events

index=endpoint sourcetype=process_access
| search target_process="lsass.exe"
| where source_process!="Lsaiso.exe" AND source_process!="TrustedInstaller.exe" AND source_process!="Csrss.exe"
| eval alert = if(source_process IN ("procdump*", "mimikatz*", "powershell*"), "HIGH — known credential dumping tool accessing LSASS", "MEDIUM — unknown process accessing LSASS — investigate")
| eval alert_severity = if(alert LIKE "HIGH%", "high", "medium")
| stats values(access_mask) as AccessMask, count by host, source_process, source_process_id, user, alert, alert_severity
| sort - count
| table host, source_process, user, AccessMask, count, alert

SPL Query — Find Suspicious Process Trees (Office → Script Host)

index=endpoint sourcetype=process_creation
| search parent_process IN ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| search child_process IN ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "regsvr32.exe")
| eval alert = "HIGH — " . parent_process . " spawned " . child_process . " — malicious macro or document exploit"
| table _time, host, user, parent_process, parent_command_line, child_process, child_command_line, alert
| sort _time desc

EDR Vendor Comparison

No EDR is perfect. Each has strengths, blind spots, and operational trade-offs. The table below reflects common analyst experience as of early 2026.

Critical Evaluation Questions for Any EDR

1. Can the agent survive a kernel-level attack? Does the sensor run in kernel mode? Can an attacker kill the agent with a simple taskkill?
2. How does your EDR handle offline detection? If the host is disconnected from the network for 8 hours, does it replay telemetry on reconnect?
3. What is the storage retention period? How far back can you search telemetry? 30 days? 90 days? 365 days?
4. Can you write custom detection rules? Natively? Via Sigma? Via YARA? The flexibility to write custom rules directly matters more than the pre-built rule count.
5. How does it handle macOS and Linux? If your environment is 50% Windows and 50% Linux, an EDR with weak Linux coverage leaves half your footprint unprotected.
6. API maturity: Can you ingest alerts into your SIEM via API? Can you trigger response actions via API for SOAR integration?
7. Agent resource consumption: CPU, memory, disk usage during baseline and during heavy scan. High overhead = user complaints = agents disabled.

EDR Bypass Techniques — How Attackers Evade Endpoint Sensors

Understanding EDR bypass is critical for analysts. When an EDR fails to detect an attack, it is often because the attacker used a known bypass technique — not because the EDR is broken.

SPL Query — Detect Potential Process Injection (CreateRemoteThread)

index=endpoint sourcetype=process_access
| search access_mask="0x1FFFFF" (full access) OR access_mask="0x43A" (thread creation)
| eval alert = if(source_process="svchost.exe" OR source_process="wmiprvse.exe", "MEDIUM — unexpected CreateRemoteThread from " . source_process, "HIGH — CreateRemoteThread detected from " . source_process . " to " . target_process)
| table _time, host, source_process, source_process_id, target_process, target_process_id, access_mask, alert
| sort _time desc

EDR Triage Decision Matrix

When multiple alerts fire simultaneously, prioritize by this matrix:

Prevention and Hardening — EDR Configuration Best Practices

Deployment-Level Controls

Rule-Level Controls

Analyst Workflow Integration

Related

• Indicators: IoC, IoA, and TTP — covers the indicators: ioc, ioa, and ttp concepts
• Kill Chain — covers the kill chain concepts
• Living-off-the-Land Binaries — how living-off-the-land binaries attacks work and how to detect them
• Process Injection (T1055) — detection and response for T1055 techniques
• XSS — detection and response for T1059.007 techniques

Sources

• Microsoft Defender for Endpoint — Event ID Reference
• Microsoft — Event 4688: A new process has been created
• Sysmon — Event IDs Reference
• MITRE ATT&CK T1059 — Command and Scripting Interpreter
• MITRE ATT&CK T1003 — OS Credential Dumping
• MITRE ATT&CK T1055 — Process Injection
• MITRE ATT&CK T1562 — Impair Defenses
• Microsoft — Attack Surface Reduction Rules
• SpecterOps — EDR Bypass Techniques
• MDEDR — EDR Telemetry
• Vulnerable Driver Blocklist