7.5 The Device Investigation Page

75 minutes · Module 7

The Device Investigation Page

By the end of this subsection, you will be able to read a device timeline, identify malicious process chains, and use the device page for investigation alongside KQL.

The device page in Defender XDR is the single-device investigation interface. It combines the device timeline (every process, network connection, file event, and registry change), device properties, security recommendations, and response actions in one view.

The device timeline

The timeline is a chronological view of everything that happened on the device. It is the most detailed investigation data source for endpoint activity — more granular than the aggregated tables in Advanced Hunting.

Event types in the timeline:

Event typeWhat it showsInvestigation value
Process creationParent → child process chain, command line argumentsThe #1 investigation signal. Malware execution chains are visible here.
Network connectionsDestination IP/domain, port, process that initiatedC2 communication, data exfiltration, lateral movement
File eventsFile creation, modification, deletion with path and hashMalware dropping payloads, evidence tampering
Registry eventsKey creation, modification, deletionPersistence mechanisms (Run keys, services, scheduled tasks)
Logon eventsLocal and remote logon with source IP and accountLateral movement via RDP, PSExec, WMI
Alert eventsAlerts raised on this device with severityCorrelated view of what Defender detected

Reading a malicious process chain

The most critical skill for device investigation is reading the process tree — the parent-child relationship between processes.

Normal process chain: explorer.exe → outlook.exe → winword.exe (user opens Outlook, opens a Word attachment). This is a legitimate chain.

Malicious process chain: winword.exe → cmd.exe → powershell.exe → mimikatz.exe This means: Word executed a macro that launched cmd, which launched PowerShell, which launched Mimikatz (credential dumping). Each step is a red flag:

  • Word spawning cmd.exe = macro execution (ASR rule target)
  • cmd spawning PowerShell = script execution (common malware delivery)
  • PowerShell spawning mimikatz = credential theft (immediate containment)
1
2
3
4
5
6
7
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where InitiatingProcessParentFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe")
| project TimeGenerated, InitiatingProcessParentFileName,
    InitiatingProcessFileName, FileName, ProcessCommandLine
| sort by TimeGenerated asc
Expected Output — Malicious Office Macro Chain
TimeGrandParentParentChildCommandLine
09:14winword.execmd.exepowershell.exepowershell -enc aQBl...
09:14cmd.exepowershell.exemimikatz.exemimikatz "privilege::debug" "sekurlsa::logonpasswords"
What to look for: Office application (winword.exe) spawning cmd.exe is the macro execution indicator. The -enc flag on PowerShell means Base64-encoded command (attackers hide payload content this way). Mimikatz with sekurlsa::logonpasswords dumps all credentials from LSASS memory. This is a complete initial access → execution → credential theft chain. Containment is immediate: isolate the device, revoke the user's sessions.

What to check on every device investigation

When you open a device page during an incident, check these five things in order:

  1. Alert timeline — what triggered the investigation? Read the alert details first.
  2. Process tree for the alert — click the alert to see the process chain. Read parent → child → grandchild.
  3. Network connections from suspicious processes — did the malicious process connect to an external IP? That is likely C2.
  4. File events — did the process create or modify files? Look for new executables, scripts, or persistence mechanisms.
  5. Logon events — did a new account log on around the time of the alert? That could be lateral movement from another compromised device.

Network connection analysis from the timeline

After identifying a suspicious process, the next step is checking its network connections. C2 communication is the confirmation that the process is not just suspicious but actively communicating with the attacker.

1
2
3
4
5
6
7
8
9
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe", "mshta.exe", "wscript.exe")
| where RemoteIPType == "Public"
| project TimeGenerated, InitiatingProcessFileName,
    RemoteUrl, RemoteIP, RemotePort,
    InitiatingProcessCommandLine
| sort by TimeGenerated desc
Expected Output
TimeProcessRemoteUrlRemoteIPPort
09:15powershell.exec2-server.malicious-domain.com203.0.113.99443
09:14powershell.exec2-server.malicious-domain.com203.0.113.99443
What to look for: PowerShell making outbound HTTPS connections to an unknown domain is the C2 confirmation. Port 443 is used because it blends with normal HTTPS traffic and passes through most firewalls. The domain and IP become custom indicators (subsection 7.4) for fleet-wide blocking. Check threat intelligence for the domain — recently registered domains with randomized names are almost certainly attacker infrastructure.

File event analysis — what did the process drop?

1
2
3
4
5
6
7
8
DeviceFileEvents
| where TimeGenerated > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where InitiatingProcessFileName =~ "powershell.exe"
| where ActionType == "FileCreated"
| project TimeGenerated, FileName, FolderPath, SHA256, FileSize,
    InitiatingProcessCommandLine
| sort by TimeGenerated desc
Expected Output
TimeFileNameFolderPathSHA256
09:15svchost-update.exeC:\Users\j.morrison\AppData\Local\Tempa3f8b2c1d4...
What to look for: A file named "svchost-update.exe" in a Temp folder is a classic disguise — it mimics a legitimate Windows process name. The SHA256 hash is your file indicator for fleet-wide detection. Check the hash against VirusTotal. If it is malware, create a file hash indicator (subsection 7.4) to block it on every device.

Try it yourself

Write a KQL query that finds all process creation events on a specific device where the parent process is powershell.exe and the child process makes a network connection within 60 seconds. This pattern detects PowerShell downloading and executing payloads.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
let targetDevice = "DESKTOP-NGE042";
let psProcesses =
    DeviceProcessEvents
    | where TimeGenerated > ago(24h)
    | where DeviceName == targetDevice
    | where InitiatingProcessFileName =~ "powershell.exe"
    | project PSTime = TimeGenerated, ProcessId, FileName, ProcessCommandLine;
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where DeviceName == targetDevice
| join kind=inner psProcesses on $left.InitiatingProcessId == $right.ProcessId
| where TimeGenerated between (PSTime .. (PSTime + 1m))
| project TimeGenerated, FileName, RemoteUrl, RemoteIP, ProcessCommandLine

This joins process creation with network events from the same process within a 60-second window. Any PowerShell process that makes a network connection shortly after spawning is worth investigating — it may be downloading a payload.

Check your understanding

1. You see winword.exe → cmd.exe → powershell.exe -enc [base64] in the device timeline. What is the correct interpretation?

A Word macro executed a command that launched an encoded PowerShell payload. This is the textbook macro-based malware delivery chain. The -enc flag hides the actual command in Base64 encoding. Decode the Base64 to see what the payload does, then containment: isolate the device and revoke the user's sessions.
Normal Office behavior
A Windows update process

2. What is the first thing to check when the process tree shows a network connection from a suspicious process?

The destination IP and domain — this is likely C2 (command and control). Check it against threat intelligence. If the IP is in a known-malicious range or the domain was recently registered, this confirms the malware is communicating with the attacker. Create a custom indicator to block it fleet-wide.
The file hash
The user who was logged in