In this section
Manage Microsoft Defender for Endpoint Investigations
Scenario
The AiTM phishing incident from Section 1.2 has escalated. After j.morrison clicked the phishing link and the attacker replayed the stolen token, Defender for Endpoint now flags suspicious PowerShell execution on DESKTOP-NGE042. The timeline shows encoded commands downloading a secondary payload from an external IP. You need to determine what the payload does, whether it established persistence, and whether the attacker moved to other devices.
The device page
Every device onboarded to Defender for Endpoint has a dedicated page in the portal. You reach it by clicking a device entity in an incident, searching for a device name in the global search, or navigating to Assets, then Devices.
Defender Portal
security.microsoft.com → Assets → Devices → select device
The device page shows risk level, exposure level, health state, and sensor status at the top. The tabs below provide different investigation lenses: Overview (active alerts, logged-on users, security assessment), Incidents and alerts (every alert across all Defender products for this device), Timeline (the full event history), and Security recommendations (unpatched vulnerabilities).
The top section shows the most frequent interactive user, which is often the account you need to investigate if the device is compromised. The Incidents and alerts tab lists every incident and alert associated with this device across all Defender products. If a device has a phishing email alert from MDO, a suspicious sign-in from Entra ID Protection, and a malware execution from MDE, all three appear here, correlated into the same incident.
The Security recommendations tab shows unpatched vulnerabilities on this specific device. During investigation, check whether the attacker exploited a known vulnerability for initial access. The Software inventory lists every installed application with version numbers. Look for tools the attacker may have installed: remote access software like AnyDesk or TeamViewer, offensive tools like Mimikatz or Cobalt Strike beacons, or vulnerable software that provided the initial entry point.
The device timeline and process trees
The Timeline tab is the primary investigation data source for endpoint alerts. It records every process creation, network connection, file operation, registry modification, logon event, DNS query, and AMSI detection the sensor captures. Timeline data is retained for 180 days on Plan 2.
The timeline opens with a date range selector. Drag across the mini-timeline to focus on the attack window. Events appear in reverse chronological order with timestamp, event type, and description. Filter by event type to narrow the view: Process events for execution chains, Network events for C2 connections, File events for dropped payloads, Flagged events for items you have marked during investigation.
While investigating a long timeline (a device may generate thousands of events per hour under normal operation), flag specific events for follow-up using the flag icon. After flagging, switch to the Flagged events filter to see only your marked items. This creates a curated investigation narrative from overwhelming raw data. You can also export the timeline as CSV for offline analysis or for attaching to incident reports.
Defender for Endpoint maps observed behaviors to MITRE ATT&CK techniques directly in the timeline. If the sensor detects credential dumping from LSASS memory, the entry includes T1003.001 with a technique icon. This mapping accelerates investigation because you immediately understand the attacker's objective without manually classifying each event. Selecting the technique tag opens context with the tactic category, description, and related sub-techniques.
Beyond detection, the endpoint sensor actively blocks malicious behavior in real time through behavioral blocking. When the sensor observes a process performing actions that match known attack patterns, such as credential dumping, process injection, or file encryption, it can terminate the process and quarantine associated files without requiring a signature match. If a file that initially passed scanning is later determined malicious through cloud analysis, the verdict is pushed to all endpoints to block the file retroactively. During investigation, check the automated investigation section on the device page to see whether behavioral blocking acted and what remediation steps were taken or are pending your approval.
The most critical investigation skill is reading parent-child process relationships. Legitimate software follows predictable patterns: explorer.exe launches outlook.exe, which opens winword.exe for an attachment. Malicious behavior creates anomalous chains: winword.exe spawns cmd.exe, which launches powershell.exe with encoded arguments. When you click an alert in the timeline, the process tree opens showing the full parent-to-child chain. Red-highlighted nodes indicate processes that triggered the alert logic. Expand a node to see command line arguments, file hash, digital signature status, and network connections.
Key patterns to recognize: Office applications (Word, Excel, PowerPoint) should never spawn cmd.exe, powershell.exe, wscript.exe, or mshta.exe directly. If they do, the user opened a document with a macro or embedded object that executed code. svchost.exe should always be a child of services.exe; if it appears under another parent, it is likely a renamed malicious binary. rundll32.exe with a command line referencing a DLL in a temp folder or user profile directory is a common payload execution method.
Figure 1.5: A malicious process chain. Word spawns cmd, which launches encoded PowerShell that downloads a payload and establishes C2 communication. Each node in the tree is an evidence artifact.
Response actions
When the timeline and process tree confirm a compromise, response actions contain the threat. The sequence matters.
Collect investigation package before isolating. The package captures running processes, active network connections, DNS cache, autoruns, event logs, and scheduled tasks. Once you isolate, live connections drop and volatile evidence is lost. The package takes a few minutes to generate and appears as a downloadable ZIP in the Action Center.
Live response provides a remote command-line shell through the management channel. It works during isolation because it uses the same channel Defender maintains for telemetry. Basic commands include processes (list running processes), connections (active network state), and dir (directory listing). Advanced commands include getfile (download a file from the device for analysis), putfile (upload investigation scripts), and run (execute PowerShell scripts). The getfile command is how you retrieve a suspicious executable, browser history databases, or full Security event logs from an isolated device. Advanced live response requires separate enablement in Settings, Endpoints, Advanced features.
Live response sessions have a 30-minute timeout per connection. If your investigation requires extended access, reconnect when the session expires. The session runs under SYSTEM context, which gives you access to all files and processes on the device. Be aware that any command you run is logged in the device's action history and visible to other analysts. When collecting evidence, use getfile to download files to the live response library rather than modifying them in place, preserving forensic integrity.
Contain user blocks the compromised user account from accessing other onboarded endpoints. This prevents lateral movement through stolen credentials without disabling the account in Entra ID. The containment operates through the Defender sensor on each endpoint.
Restrict app execution limits the device to running only Microsoft-signed executables. Use this when confirmed active malware is present and you need to prevent attacker tools from executing while you investigate.
Entity investigation: determining blast radius
Beyond the device, Defender for Endpoint provides entity investigation pages for files, IP addresses, URLs, and user accounts. Each page aggregates data across your entire tenant.
The file entity page shows organizational prevalence (how many devices have seen this file in the last 30 days) and global prevalence across all Defender customers. If a malicious file appears on 12 devices, your incident has scaled from a single compromise to a network-wide breach. The page also shows the file's first and last seen timestamps, digital signature status, and VirusTotal detection rate if the hash has been submitted.
The IP entity page shows every device that communicated with a specific address, with ports and timestamps. Fifteen devices contacting the same external IP on port 443 over a week, where the IP belongs to a VPS provider with no business relationship to your organization, indicates multi-device C2. The page includes geolocation, ASN ownership, and whether the IP appears in Microsoft's threat intelligence feeds.
The user entity page shows all devices the user logged on to, all associated alerts, and the Entra ID risk level. During a compromised-account investigation, this reveals the blast radius: every device where the attacker used stolen credentials. A user who normally logs on to one workstation but suddenly appears on five servers indicates credential theft and lateral movement. The time gap between the first and last device logon tells you how fast the attacker is moving through the environment.
That query answers the critical scoping question: how widespread is this file? A malicious executable in C:\Users\*\AppData\Local\Temp\ on 12 devices across 30 hours indicates active attacker distribution. Each device needs investigation and containment. The entity page shows you the count; the KQL query shows you the timeline and distribution pattern.
The endpoint investigation workflow
When an endpoint alert fires in the incident queue, follow this sequence.
Triage (2 minutes). Open the alert. Read the title, severity, and ATT&CK mapping. Check whether automated investigation already handled the threat. If this is a recognized false positive pattern, classify and close.
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 use, did it create child processes, did it make network connections, did it write files to disk?
Timeline deep dive (5-10 minutes). Open the device timeline. Filter to 30 minutes before the alert through 2 hours after. Look for file drops to temp directories, network connections to external IPs, registry modifications establishing persistence (Run keys, scheduled tasks, services), and logon events from other devices indicating lateral movement.
Collect and contain (1 minute). If evidence confirms compromise: collect the investigation package, then isolate the device. If the alert involves a compromised user account, apply Contain user to prevent credential reuse on other endpoints.
Entity investigation (5-10 minutes). Pivot from the device to entity pages. Check the file hash across the tenant. Check the C2 IP: which other devices communicated with it? Check the user: which other devices did they log on to during the attack window? Each pivot either expands or narrows the incident scope.
Advanced Hunting (10-15 minutes). Write KQL queries against DeviceProcessEvents, DeviceNetworkEvents, and DeviceFileEvents to build the complete attack narrative. The timeline shows individual events; KQL aggregates them into patterns. A single timeline event shows one PowerShell connection to an external IP. A KQL query across DeviceNetworkEvents reveals 847 connections from that process to the same IP across 3 devices over 6 days, confirming automated C2 beaconing rather than manual operator access.
Document and escalate (5 minutes). Update the incident with findings: the attack chain, affected devices and users, containment actions taken, remaining investigation steps. If scope exceeds a single device, escalate to Tier 2 or the incident commander.
Security Operations Principle
Collect before you isolate. The investigation package captures live network connections, running processes, DNS cache, and active sessions. Isolation drops all connections immediately. Once isolated, volatile evidence is gone: C2 connections close, in-memory processes may terminate, network state resets. Collect first, isolate second, investigate while the package downloads.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.