3.8 Collection Playbook for Endpoint Incidents

Process tree reconstruction

The process tree tells the story of how the attacker reached execution. Starting from the alert's process ID, the query walks up the parent chain and down the child chain to reconstruct the complete ancestry.

let AlertProcessId = "{AlertProcessId}";
let AlertDeviceId = "{AlertDeviceId}";
DeviceProcessEvents
| where DeviceId == AlertDeviceId
| where TimeGenerated > ago(24h)
| where ProcessId == AlertProcessId
    or InitiatingProcessId == AlertProcessId
    or InitiatingProcessParentId == AlertProcessId
| project TimeGenerated, FileName, ProcessCommandLine,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    ProcessId, InitiatingProcessId, AccountName
| order by TimeGenerated asc

The tree reveals the attack chain: explorer.exe → outlook.exe → cmd.exe → powershell.exe -enc [base64] → certutil.exe -urlcache → payload.exe. The investigator reads the process ancestry and understands the initial access vector (email attachment), the execution method (encoded PowerShell), and the payload delivery mechanism (certutil download).

The process tree is the single most valuable piece of endpoint evidence because it answers the "how did the attacker get here" question. The tree also reveals evasion techniques. A process tree where winword.exe spawns powershell.exe is a classic macro execution, straightforward to trace. A tree where svchost.exe spawns rundll32.exe which spawns cmd.exe is a service-based execution that may indicate persistence already established from a prior compromise. The playbook includes the SHA256 field for every executable in the tree, enabling the investigator to check file reputation through VT or MDE's file profile without re-accessing the endpoint.

The query walks three levels: the alert process itself, its children (one level down), and its grandchildren (two levels down). For deeply nested attack chains (more than three levels), the investigator uses the collected data as a starting point and queries deeper manually. Three levels catches the majority of attack patterns, initial execution, intermediate staging, and payload delivery.

Lateral movement indicators

The lateral movement query captures connections from the affected device to other internal hosts on management ports.

DeviceNetworkEvents
| where DeviceId == "{AlertDeviceId}"
| where TimeGenerated > ago(24h)
| where RemotePort in (445, 5985, 5986, 3389, 135)
| where RemoteIPType == "Private"
| project TimeGenerated, RemoteIP, RemotePort,
    Protocol = case(RemotePort == 445, "SMB",
                    RemotePort in (5985,5986), "WinRM",
                    RemotePort == 3389, "RDP",
                    RemotePort == 135, "WMI", "Other"),
    InitiatingProcessFileName, InitiatingProcessCommandLine
| summarize ConnectionCount = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by RemoteIP, Protocol

Each destination is a candidate for proactive containment. SMB connections to the file server indicate file access or potential ransomware staging. WinRM connections to the domain controller indicate remote command execution against the most sensitive host. RDP connections suggest interactive sessions where the attacker can operate a GUI. Each lateral movement target identified here triggers cascading collection (see below).

The port-to-protocol mapping in the query (case statement) translates raw port numbers into human-readable protocol names for the evidence output. The investigator reads "3 WinRM connections to SRV-NGE-DC01" rather than "3 connections to 10.0.1.5 on port 5985." The InitiatingProcessFileName column reveals which tool the attacker used for lateral movement — PsExec.exe for PsExec, powershell.exe for WinRM, mstsc.exe for RDP, or custom tooling. The initiating process is the lateral movement indicator; the destination port is the lateral movement vector.

A false-positive consideration: IT administrators at NE routinely connect to servers via WinRM and RDP for legitimate management. The playbook cross-references the initiating process with the alert timeline, connections from the compromised device during the compromise window are flagged, while connections from the same device hours before the alert (normal admin activity) are included as context but not flagged.

Credential access detection

The credential access query catches the most common dumping techniques. LSASS credential dumping is the highest-priority finding because it turns a single-device compromise into a multi-account compromise.

The query covers five dumping vectors. Direct LSASS process access (the attacker's tool opens the LSASS process and reads its memory). Mimikatz execution (identified by command-line patterns like sekurlsa::logonPasswords or the Mimikatz binary hash). Procdump LSASS dumping (procdump.exe -ma lsass.exe: a legitimate Microsoft tool used offensively). The comsvcs.dll MiniDump technique (rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump [LSASS_PID]: a living-off-the-land technique that uses a native Windows DLL to dump LSASS without dropping a third-party tool). And ntdsutil/vssadmin targeting the AD database (NTDS.dit extraction for offline credential cracking). Each technique produces distinct telemetry in DeviceProcessEvents.

DeviceProcessEvents
| where DeviceId == "{AlertDeviceId}"
| where TimeGenerated > ago(24h)
| where (FileName =~ "lsass.exe" and ActionType == "ProcessAccessed")
    or ProcessCommandLine has_any ("sekurlsa", "mimikatz", "kerberos::list",
        "ntdsutil", "vssadmin", "shadow", "SAM", "NTDS.dit")
    or (FileName =~ "procdump.exe" and ProcessCommandLine has "lsass")
    or (FileName =~ "rundll32.exe" and ProcessCommandLine has "comsvcs.dll")
| project TimeGenerated, FileName, ProcessCommandLine,
    InitiatingProcessFileName, AccountName, SHA256
| order by TimeGenerated desc

This catches: LSASS memory access (direct credential dumping), Mimikatz execution, ntdsutil and vssadmin usage (AD database extraction), and the comsvcs.dll MiniDump technique (a living-off-the-land alternative to procdump). Each finding is a critical indicator, if the attacker dumped credentials, the incident scope expands to every account whose credentials were on the compromised device.

Scope expansion, identifying all compromised accounts

When the credential access query confirms LSASS dumping, the incident scope expands beyond the initial account to every account whose credentials were in memory.

DeviceLogonEvents
| where DeviceId == "{AlertDeviceId}"
| where TimeGenerated > ago(7d)
| where LogonType in ("Interactive", "RemoteInteractive", "CachedInteractive")
| where ActionType == "LogonSuccess"
| summarize LastLogon = max(TimeGenerated),
    LogonCount = count()
    by AccountName, AccountDomain
| order by LastLogon desc

Every account that successfully authenticated on the device in the last 7 days had cached credentials in LSASS memory. A single workstation typically has 1 to 3 accounts (primary user, IT admin who logged in for support, possibly a service account). A domain controller may have 50 or more. The scope expansion list directly drives the password rotation workload.

The 7-day window is a trade-off. LSASS caches credentials for accounts that have logged on interactively or via RDP. Restarting the device clears the cache. If the device was restarted 3 days ago, only accounts that logged on in the past 3 days are at risk. The playbook uses 7 days as a conservative window, it may include accounts no longer cached, but missing a compromised account is worse than rotating an extra password. The investigator reviews the list and uses the LastLogon timestamp to assess which accounts are most likely to have been in memory at the time of the dump.

The playbook automatically adds the tag "credential-dump-detected" to the incident and flags all cached accounts as requiring password rotation. If any cached account is a service account or an admin account with privileged access, the playbook escalates the incident severity: a credential dump that includes a Domain Admin's cached credentials is a different incident than one that includes only a standard user.

Persistence scanning

The persistence scan checks specific registry paths, scheduled tasks, WMI subscriptions, and startup folder modifications. Registry persistence targets include Run and RunOnce keys (both HKLM and HKCU), service registration under CurrentControlSet\Services, Winlogon Shell and Userinit overrides, and ShellServiceObjects. Scheduled task creation is captured from DeviceProcessEvents where schtasks.exe runs with /create. WMI subscriptions are detected from registry events touching ROOT\subscription. Startup folder drops are captured from DeviceFileEvents.

All results are filtered to items created during the compromise window. The timestamp filtering is critical: a device may have hundreds of legitimate registry entries, scheduled tasks, and startup items. Showing all of them buries the attacker's additions in noise. By filtering to the compromise window (from the alert's earliest event to present), the persistence scan surfaces only the items created during or after the attack.

The formatted output shows each persistence mechanism with the creating process: the investigator traces the complete chain: "payload.exe created a scheduled task at 14:31 which runs payload.exe at every boot." This chain matters because removing the scheduled task without removing the payload file (or vice versa) results in incomplete remediation. The persistence evidence gives the remediation team the full removal checklist: which mechanisms, which files, which registry keys.

Defense evasion detection

Sophisticated attackers tamper with security controls on the compromised endpoint. The collection includes queries that detect Defender exclusions added by the attacker (excluding their payload directory from scanning), real-time protection disabled via registry, and AMSI tampering. Each finding indicates the attacker is actively evading detection, which means other evidence sources (Defender alerts, AMSI logs) may be incomplete.

The Defender exclusion query checks DeviceRegistryEvents for modifications to the HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths key. Attackers commonly add C:\Users\Public\ or their specific payload directory. The real-time protection query checks for registry modifications to DisableRealtimeMonitoring. AMSI tampering is detected from DeviceProcessEvents where the process command line includes amsi.dll combined with memory manipulation patterns.

The evidence package flags defense evasion findings prominently so the investigator knows to treat the telemetry as potentially incomplete. If the attacker disabled real-time protection at 14:29 and the first alert fired at 14:30, the one-minute gap between evasion and detection means some attacker activity during that window may not have generated Defender alerts. The investigator switches to process-based evidence (DeviceProcessEvents) which logs regardless of Defender's real-time protection status.

Cloud-to-endpoint evidence correlation

For incidents that span both cloud and endpoint (AiTM leading to endpoint pivot), the collection playbook correlates evidence across domains by timestamp and user. The cloud evidence shows AiTM sign-in, mailbox access, and file downloads. The endpoint evidence shows payload execution, credential dumping, and lateral movement. The overlap in timestamps, cloud access and endpoint activity happening simultaneously, confirms the attacker is operating in both environments. The evidence package presents a combined timeline showing interleaved cloud and endpoint actions.