1.4 Manage Microsoft Defender for Endpoint Investigations

This subsection teaches you to navigate the device page, read device timelines, interpret process trees, take response actions, use live response for remote forensics, collect investigation packages, and investigate files and evidence entities. Module 2 covers the full Defender for Endpoint deployment and configuration. This subsection focuses specifically on the investigation and response skills you use when an endpoint alert fires in the XDR incident queue.

By the end of this subsection you will be able to navigate the device page and its tabs, read a device timeline to identify malicious process chains, perform all device response actions in the correct sequence, use live response to collect forensic artifacts remotely, interpret investigation package contents, and use KQL against DeviceProcessEvents and DeviceNetworkEvents to build a complete endpoint investigation narrative.

---

The device page

Every device onboarded to Defender for Endpoint has a dedicated device page in the Defender portal. You reach it by clicking a device entity in an incident, searching for a device name in the global search bar, or navigating to Assets, then Devices and selecting from the inventory.

The device page has a top section showing the device risk level, exposure level, health state, sensor status, and tags. Below that are several tabs that each provide a different investigation lens.

The Overview tab shows active alerts, logged-on users, and the security assessment score. The cards at the top tell you how many alerts are currently active on this device and how many users have logged on in the past 30 days. The most frequent interactive user is highlighted — this is often the user whose account you need to investigate if the device is compromised. Note that the "most frequent" calculation only considers interactive logons, so the "All users" side panel may show additional accounts that accessed the device through service logons or remote sessions.

The Incidents and alerts tab lists every incident and alert associated with this device, sorted by severity. This is your starting point for understanding the scope of compromise. If a device has alerts from multiple Defender products — an email alert from Defender for Office 365 (phishing delivery), an identity alert from Entra ID (suspicious sign-in), and a process alert from Defender for Endpoint (malware execution) — all three appear here, correlated into the same incident.

The Timeline tab is the most important for investigation and is covered in depth below.

The Security recommendations tab shows unpatched vulnerabilities and configuration weaknesses on this specific device. During an investigation, check this tab to understand whether the attacker exploited a known vulnerability to gain access.

The Software inventory tab lists every application installed on the device with version numbers. Use this to identify whether the attacker installed tools (for example, a remote access tool like AnyDesk or a network scanner like Advanced IP Scanner) or whether vulnerable software (an unpatched browser, an outdated Java runtime) provided the initial entry point.

The Discovered vulnerabilities tab lists CVEs affecting the software installed on the device. If you find CVE-2023-23397 (Outlook privilege escalation) on a device that received a suspicious calendar invite, the investigation narrative writes itself.

---

The device timeline

The device timeline is a chronological record of every event the endpoint sensor captured. It is the single most detailed investigation data source for device activity. Events include process creations, network connections, file operations, registry modifications, logon events, DNS queries, and AMSI (Antimalware Scan Interface) detections.

By default, security event data in Defender for Endpoint is retained for 180 days on Plan 2. If your tenant forwards logs to a connected Microsoft Sentinel or Log Analytics workspace with a longer retention period, timeline events may be available for extended durations as defined by your workspace retention settings.

Navigating the timeline. The timeline opens with a date range selector at the top. You can highlight a specific time window by dragging across the mini-timeline, which is useful when you know the approximate time of compromise. Below the date selector, events appear in reverse chronological order. Each event shows a timestamp, the event type (process, network, file, registry), and a brief description.

Filtering the timeline. Use the Filters panel to narrow the timeline to specific event types. The most common investigation filters are Process events (to trace execution chains), Network events (to identify command-and-control connections), File events (to find dropped payloads), and Flagged events (events you have marked during investigation). You can also toggle between showing Events only, Techniques only, or both.

Techniques in the timeline. Defender for Endpoint maps observed behaviors to MITRE ATT&CK techniques directly in the timeline. Techniques appear as bold entries with a blue icon and the corresponding ATT&CK ID. For example, if the sensor detects a process performing credential dumping from LSASS memory, the timeline entry includes the technique tag T1003.001 (OS Credential Dumping: LSASS Memory). Selecting a technique opens a side pane with additional context including the tactic, a description of the technique, and related ATT&CK sub-techniques. This mapping accelerates investigation because you immediately understand the attacker's objective without needing to manually classify each event.

Event flags. While investigating a long timeline, you can flag specific events for follow-up using the flag icon in each event row. After flagging, use the Flagged events filter to see only your marked events — this creates a curated investigation narrative from potentially thousands of timeline entries.

Exporting timeline data. You can export the device timeline for the current date or a specified date range (up to seven days) as a CSV file. This is useful for offline analysis, for attaching to incident reports, or for importing into a SIEM for correlation with other data sources.

Reading process trees. The most critical skill for endpoint investigation is reading parent-child process relationships. Legitimate software follows predictable patterns: explorer.exe → outlook.exe → winword.exe (user opens Outlook, opens Word attachment). Malicious behavior creates anomalous chains: winword.exe → cmd.exe → powershell.exe (macro launches command shell, downloads payload).

When you click an alert in the device timeline, the alert detail panel opens and shows the process tree — the full parent-child chain that triggered the alert. Read the tree from top to bottom: the topmost process is the root (often explorer.exe for interactive sessions), and each level below represents a child process. Red-highlighted nodes indicate processes that triggered alert logic. Expanding a node shows the command line, file hash, file path, signing status, and network connections for that specific process.

Key patterns that indicate malicious activity in process trees: Office applications (winword.exe, excel.exe, powerpnt.exe) spawning cmd.exe, powershell.exe, wscript.exe, or mshta.exe. Any process running with Base64-encoded command-line arguments (the -enc or -encodedcommand flag in PowerShell). A legitimate Windows binary like rundll32.exe or regsvr32.exe loading a DLL from a temp directory or user profile. Services spawning unexpected child processes, such as w3wp.exe (IIS) launching cmd.exe (web shell execution). Svchost.exe with unusual parent processes or running from non-standard paths.

---

Response actions from the device page

Response actions run along the top of the device page. Each action has specific use cases and sequencing requirements. Getting the sequence wrong can destroy evidence or leave an attacker with continued access.

The Contain user action deserves special attention. When Defender XDR identifies a compromised user account (either automatically through attack disruption or manually by an analyst), the Contain user action prevents that user from performing any lateral movement to other onboarded devices. The contained user is blocked from network access on all Defender for Endpoint devices. This action works through Defender for Identity if the account is hosted in Active Directory, or directly through Entra ID for cloud-native accounts. You can view blocked access attempts in the device timeline under DeviceEvents with the action type "Contain User."

---

The investigation package

When you click "Collect investigation package," the Defender agent on the device gathers a comprehensive snapshot of the current system state and uploads it as a downloadable ZIP file. The package typically takes one to five minutes to generate depending on system load.

The investigation package contains the following forensic artifacts:

Autoruns capture every program configured to start automatically via registry Run keys, Startup folders, scheduled tasks, and services. Malware almost always establishes persistence via one of these mechanisms. Compare the autoruns output against a known-clean baseline to identify attacker-added persistence entries.

Installed programs list all software with version numbers. Look for remote access tools (AnyDesk, TeamViewer, ngrok), offensive security tools (Mimikatz, Rubeus, SharpHound), or recently installed applications that do not match the device's standard build image.

Network connections show all active TCP and UDP connections at collection time, including the remote IP address, port, and owning process. This is where you find active C2 channels. Look for connections to non-standard ports (4444, 8080, 8443, 9090), connections to IP addresses that resolve to VPS providers or bulletproof hosting, and processes that should not have outbound connections (notepad.exe connecting to an external IP is always suspicious).

Prefetch files record evidence of every executable that has run on the system, including the last eight execution timestamps and the files loaded by the executable. Prefetch survives reboots and process termination, making it invaluable for historical analysis even after malware has been cleaned.

Running processes provide a snapshot of all processes with their PIDs, parent PIDs, command lines, and memory usage. Cross-reference this with the timeline to identify processes that were active during the attack window.

Scheduled tasks show all configured tasks with triggers, actions, and run history. Attackers frequently use scheduled tasks for persistence and for executing payloads at timed intervals.

Security event log contains logon events (4624, 4625), privilege use (4672), process creation (4688 if enabled), and account management events. This log serves as a fallback data source when sensor telemetry is incomplete.

Services list all Windows services with startup type, binary path, and current state. Look for services running from temp directories, services with unusual names, or recently created services configured to start automatically.

The package also includes a forensics collection summary document that records exactly which commands the agent ran to collect the data, the timestamps of collection, and any errors encountered. This document is important for chain-of-custody documentation if the investigation leads to legal or HR action.

---

Live response

Live response provides a remote command-line shell directly to the device through the Defender cloud management channel. Unlike RDP or other remote access tools, live response works even when the device is network-isolated — the management channel remains active during isolation. This makes live response the primary tool for post-isolation forensic collection.

Live response supports two permission levels. Basic commands include directory listing (dir), file viewing (fileinfo), process listing (processes), network connection enumeration (connections), and trace collection (trace). Advanced commands include running PowerShell scripts (run), downloading files from the device (getfile), uploading investigation scripts to the device (putfile), and executing remediation commands. Advanced live response requires a separate enablement toggle in the portal settings.

To start a session, navigate to the device page and click "Initiate live response session." A command console opens in the browser. The session connects through the Defender cloud relay — response time depends on network quality and system load between the portal and the target device.

Common live response investigation commands:

processes lists all running processes with PIDs and command lines. Use this for a quick snapshot of what is currently executing, rather than waiting for the full investigation package.

connections shows active network connections including remote IP, port, and owning process. Use this to identify C2 channels before isolation, or to verify isolation is effective (only Defender management channel connections should remain).

dir C:\Users\j.morrison\AppData\Local\Temp lists the contents of the user's temp directory, where initial payloads are commonly dropped.

getfile "C:\Users\j.morrison\Downloads\invoice.exe" downloads a specific suspicious file from the device for malware analysis. The file is uploaded to the Defender cloud and available for download from the Action Center.

run CollectForensics.ps1 executes a PowerShell script that was previously uploaded to the live response library. You can build custom forensic collection scripts that gather artifacts beyond what the standard investigation package includes — browser history, Outlook rules, clipboard contents, or memory dumps of specific processes — and deploy them across multiple compromised devices during a large-scale incident.

getfile "C:\Windows\System32\winevt\Logs\Security.evtx" downloads the full Security event log for offline analysis with tools like Event Log Explorer or EvtxEcmd.

---

Evidence and entity investigation

Beyond device-focused investigation, Defender for Endpoint provides investigation pages for individual evidence entities: files, IP addresses, URLs, domains, and user accounts. Each entity page aggregates information from across your entire tenant, not just a single device. This is how you determine the blast radius of an incident.

File entity page. When you click a file hash in a process tree or timeline event, the file page opens. It shows the file's prevalence in your organization (how many devices have seen this file in the last 30 days), its global prevalence (how common it is across all Defender for Endpoint customers worldwide), its VirusTotal detection ratio, and its Microsoft Defender Antivirus classification. The "Observed in organization" section is critical for scoping: if a malicious file has been seen on 50 devices, your incident has scaled from a single-device compromise to a potential widespread breach. The "File content" tab for PE (Portable Executable) files shows imports, exports, strings, and capabilities — useful for determining malicious intent without detonating the file.

IP address entity page. Shows all devices in your organization that communicated with the IP address, the ports used, and the timestamps. Cross-reference with threat intelligence to determine whether the IP is associated with known C2 infrastructure, bulletproof hosting, or anonymization services. If 15 devices contacted the same external IP on port 443 over the past week, and that IP belongs to a VPS provider with no legitimate business association to your organization, you likely have a multi-device C2 channel.

URL and domain entity page. Similar to IP investigation but resolves to domain-level information. Particularly useful for phishing investigations where the attacker used a domain that mimics a legitimate service (microsofft-login.com, sharepo1nt-docs.com). The page shows which devices visited the URL, through which process, and at what time.

User entity page. Shows all devices the user has logged on to, all alerts associated with the user across all devices, and the user's risk level from Entra ID Protection. During a compromised-account investigation, the user entity shows you the blast radius: every device where the attacker used the stolen credentials. The "Observed in organization" section shows lateral movement patterns — if a user who normally only logs on to one workstation suddenly appears on five servers, that is a strong indicator of credential theft and lateral movement.

---

Behavioral blocking and containment

Defender for Endpoint does not only detect threats — it actively blocks malicious behavior in real time through behavioral blocking. When the sensor observes a process performing actions that match known attack patterns (credential dumping, process injection, registry-based persistence, file encryption behavior), it can terminate the process and quarantine associated files without waiting for a signature match.

Behavioral blocking operates at two levels. Client-side behavioral blocking runs on the endpoint sensor and terminates suspicious processes in real time as the behavior unfolds. Feedback-loop blocking operates through cloud analysis — if a file that was initially allowed to execute is later determined to be malicious through cloud detonation or machine learning analysis, the verdict is pushed to all endpoints across the tenant to block the file retroactively. This is why you sometimes see alerts marked "threat was blocked" even though no antivirus signature existed for the file at the time of execution.

During investigation, check the "Automated investigation" section on the device page. If behavioral blocking terminated a process, the automated investigation shows the complete chain: what triggered the block, what remediation actions were taken (process termination, file quarantine, persistence removal), and whether any actions require manual approval. If your automation level is set to "Semi — require approval for any remediation," pending actions appear in the Action Center and wait for analyst approval before completing.

Automatic attack disruption is the most aggressive form of automated response. When Defender XDR detects a high-confidence attack pattern (such as ransomware or business email compromise) with signals from multiple products, it can automatically isolate devices, disable compromised user accounts, and block malicious files — all without analyst intervention. Attack disruption operates at the incident level, not the individual alert level, and only triggers when the AI model has high confidence that the correlated activity represents an active attack. You can review disruption actions in the incident timeline and reverse them if they were applied to a benign activity.

---

Endpoint investigation workflow

When an endpoint alert fires in the incident queue, follow this structured workflow:

Step 1 — Triage (2 minutes). Open the alert. Read the alert title, severity, and MITRE ATT&CK mapping. Check whether the automated investigation already remediated the threat. If the alert is a known false positive pattern for your environment, classify it as FP and move on.

Step 2 — Process tree analysis (5 minutes). Click into the alert to view the process tree. Read parent-child relationships from root to leaf. Identify the suspicious node: what launched it, what command line did it run, did it create child processes, did it make network connections, did it write files to disk?

Step 3 — Device timeline deep dive (5-10 minutes). Open the device timeline. Filter to the time window around the alert — 30 minutes before to 2 hours after. Look for additional suspicious process launches, file drops to temp directories, network connections to external IPs, registry modifications that establish persistence, and logon events from other devices (indicating lateral movement inbound).

Step 4 — Collect and contain (1 minute). If the evidence confirms compromise: collect investigation package, then isolate the device. If the alert involves a compromised user account, also use "Contain user" to prevent the attacker from using those credentials elsewhere.

Step 5 — Entity investigation (5-10 minutes). Pivot from the device to entity pages. Check the file hash: is the malicious file on other devices? Check the C2 IP: which other devices communicated with it? Check the user: which other devices did they log on to in the suspicious time window? Each entity pivot either expands or narrows the scope of your incident.

Step 6 — Advanced Hunting (10-15 minutes). Write KQL queries against DeviceProcessEvents, DeviceNetworkEvents, and DeviceFileEvents to construct the complete attack timeline. Use cross-product union queries from subsection 1.8 to correlate endpoint activity with email delivery (EmailEvents), sign-in activity (IdentityLogonEvents), and cloud app activity (CloudAppEvents).

Step 7 — Document and escalate (5 minutes). Update the incident with your findings. Add comments describing the attack chain, list all affected devices and users, document containment actions taken, and note remaining investigation steps. If the scope exceeds a single device, escalate to Tier 2 or the incident commander.