2.5 Device Investigation: Timelines, Forensics, and Evidence Collection

Device Investigation: Timelines, Forensics, and Evidence Collection

Introduction

Module 1.4 introduced the device page, the device timeline, and the basic investigation workflow. This subsection goes deeper — into the forensic detail that turns a surface-level alert triage into a thorough investigation that can withstand scrutiny in an incident report, a legal proceeding, or a post-incident review.

The depth matters because adversaries operate in layers. The alert shows you the most obvious indicator — the process that triggered a detection rule. But the attacker’s full activity on the device spans multiple processes, registry modifications, scheduled tasks, network connections, and file operations that do not individually trigger alerts. Reconstructing the complete attacker narrative requires systematic timeline analysis, forensic artifact interpretation, and Advanced Hunting queries that surface evidence the portal view does not highlight.

This subsection teaches you to perform deep timeline analysis using advanced filters and search, interpret forensic artifacts that reveal attacker techniques beyond the initial alert (process injection, DLL sideloading, living-off-the-land binaries), extract maximum value from the investigation package, and write Advanced Hunting queries that reconstruct multi-stage device compromise narratives. These skills are used in every investigation module from Module 11 onward.

Deep timeline analysis

The device timeline in Module 1.4 was presented as a chronological event list. In practice, a production device generates thousands of events per hour — process creation, network connections, file writes, registry modifications, logon events, and service configuration changes. Finding the attacker’s activity within this volume requires systematic filtering, not scrolling.

Time window isolation. Before examining individual events, narrow the timeline to the relevant window. If the alert fired at 09:14, set the timeline to 08:45-10:00 — 30 minutes before (to capture initial access or setup activity) and 45 minutes after (to capture post-compromise actions). Dragging across the mini-timeline at the top sets this window. Everything outside this window is irrelevant for the current investigation and creates visual noise that slows your analysis.

Data type filtering. The timeline shows Events and Techniques by default. For initial investigation, filter to Events only — techniques are MITRE ATT&CK annotations that overlay on events, and they can be distracting during the first pass. After you understand the event sequence, enable Techniques to see the ATT&CK context.

Event type filtering. For each investigation phase, focus on one event type at a time. During initial triage: process events (what executed). During scope assessment: network events (where did the malware connect). During persistence analysis: registry events and file events (what did the attacker change to survive reboot). During lateral movement analysis: logon events (who else logged on, from where).

Search within timeline. The timeline search bar accepts free-text queries against event details. Search for specific file names (mimikatz), IP addresses (203.0.113), command-line fragments (-enc, downloadstring, invoke-expression), or registry paths (CurrentVersion\Run). This is faster than scrolling through thousands of events looking for a specific indicator.

Flagging events. As you identify relevant events during timeline analysis, flag each one using the flag icon. After completing your analysis, filter to “Flagged events only” to see your curated investigation timeline — the specific events that tell the attack story, extracted from thousands of irrelevant background events. This flagged timeline is what you reference when writing the incident report (Module 14).

Interpreting forensic artifacts

Beyond the obvious indicators (malicious process execution, C2 connections), the device timeline contains forensic artifacts that reveal sophisticated attacker techniques. Recognizing these artifacts separates a junior analyst who closes the alert from a senior analyst who understands the complete compromise.

Process injection evidence. When an attacker injects code into a legitimate process (to hide malicious activity inside a trusted process like svchost.exe or explorer.exe), the timeline shows specific indicators: a process opening another process with suspicious access rights (typically PROCESS_VM_WRITE or PROCESS_CREATE_THREAD), followed by memory allocation in the target process, followed by the target process exhibiting new behaviors (network connections it does not normally make, child processes it does not normally spawn). In Advanced Hunting, look for DeviceEvents with ActionType values related to process access and memory manipulation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Detect potential process injection: suspicious cross-process access
DeviceEvents
| where Timestamp > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where ActionType in ("OpenProcessApiCall", "CreateRemoteThreadApiCall",
    "QueueUserApcRemoteApiCall", "SetThreadContextRemoteApiCall")
| project Timestamp, ActionType,
    SourceProcess = InitiatingProcessFileName,
    TargetProcess = FileName,
    SourcePID = InitiatingProcessId,
    TargetPID = ProcessId,
    AccountName
| order by Timestamp asc

DLL sideloading. Attackers place a malicious DLL in the same directory as a legitimate application that loads DLLs from its working directory rather than the system path. The legitimate application loads the malicious DLL, and the malicious code executes within the context of a trusted, signed process. In the timeline, look for DeviceImageLoadEvents where a signed application loads a DLL from an unusual path (temp directories, user profile, downloads folder rather than Program Files or System32).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Detect DLL sideloading: signed processes loading DLLs from unusual paths
DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where InitiatingProcessVersionInfoCompanyName has "Microsoft"
    or InitiatingProcessVersionInfoCompanyName has "Google"
    or InitiatingProcessVersionInfoCompanyName has "Adobe"
| where not(FolderPath startswith "C:\\Windows\\")
    and not(FolderPath startswith "C:\\Program Files")
| where not(FileName in~ ("ntdll.dll", "kernel32.dll", "kernelbase.dll"))
| project Timestamp, InitiatingProcessFileName,
    DLLName = FileName, DLLPath = FolderPath,
    SHA256, InitiatingProcessVersionInfoCompanyName
| order by Timestamp desc

Living-off-the-land binaries (LOLBins). Attackers abuse legitimate Windows system tools to perform malicious actions without dropping custom malware. Common LOLBins include certutil.exe (downloading payloads via -urlcache), bitsadmin.exe (downloading via BITS transfer jobs), mshta.exe (executing HTML applications containing scripts), regsvr32.exe (executing DLLs via COM scriptlet registration), and rundll32.exe (executing arbitrary DLL functions). The timeline shows these as normal system processes — the malicious intent is revealed only by examining their command-line arguments.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Detect LOLBin abuse: legitimate tools with suspicious command lines
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("certutil.exe", "bitsadmin.exe", "mshta.exe",
    "regsvr32.exe", "rundll32.exe", "wmic.exe", "cmstp.exe",
    "msxsl.exe", "installutil.exe")
| where ProcessCommandLine has_any ("http://", "https://", "-urlcache",
    "/transfer", "scrobj.dll", "javascript:", "vbscript:",
    "/i:http", "-decode", "scriptlet")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
    AccountName, InitiatingProcessFileName
| order by Timestamp desc

Persistence mechanisms. After gaining initial access, attackers establish persistence to survive reboots and credential changes. The most common persistence mechanisms visible in the device timeline include registry Run key modifications (DeviceRegistryEvents with key paths containing CurrentVersion\Run), scheduled task creation (DeviceEvents with ActionType ScheduledTaskCreated), new service installation (DeviceEvents with ActionType ServiceInstalled), and startup folder file drops (DeviceFileEvents with paths containing Start Menu\Programs\Startup).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

// Comprehensive persistence detection on a specific device
let targetDevice = "DESKTOP-NGE042";
let investigationWindow = 48h;
union
    // Registry Run keys
    (DeviceRegistryEvents
        | where Timestamp > ago(investigationWindow)
        | where DeviceName =~ targetDevice
        | where RegistryKey has_any ("CurrentVersion\\Run",
            "CurrentVersion\\RunOnce", "Winlogon\\Shell")
        | where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
        | project Timestamp, Type = "Registry",
            Detail = strcat(RegistryKey, " → ", RegistryValueData),
            Actor = InitiatingProcessFileName),
    // Scheduled tasks
    (DeviceEvents
        | where Timestamp > ago(investigationWindow)
        | where DeviceName =~ targetDevice
        | where ActionType == "ScheduledTaskCreated"
        | project Timestamp, Type = "ScheduledTask",
            Detail = tostring(AdditionalFields),
            Actor = InitiatingProcessFileName),
    // New services
    (DeviceEvents
        | where Timestamp > ago(investigationWindow)
        | where DeviceName =~ targetDevice
        | where ActionType == "ServiceInstalled"
        | project Timestamp, Type = "Service",
            Detail = tostring(AdditionalFields),
            Actor = InitiatingProcessFileName),
    // Startup folder drops
    (DeviceFileEvents
        | where Timestamp > ago(investigationWindow)
        | where DeviceName =~ targetDevice
        | where FolderPath has "Start Menu\\Programs\\Startup"
        | where ActionType == "FileCreated"
        | project Timestamp, Type = "StartupFolder",
            Detail = strcat(FileName, " in ", FolderPath),
            Actor = InitiatingProcessFileName)
| order by Timestamp asc

This query produces a comprehensive persistence audit for a single device. In a real investigation, finding any result from this query after the initial compromise timestamp confirms the attacker established persistence — and every persistence mechanism must be removed during eradication (subsection 2.6 response actions and Module 11’s eradication phase).

Investigation package deep dive

Module 1.4 introduced the investigation package at a summary level. Here is what each folder in the extracted package contains and how to analyze it for forensic evidence.

Autoruns folder contains a comprehensive listing of all auto-start extensibility points (ASEPs). This is generated by Microsoft’s Autoruns methodology — the same logic used by the Sysinternals Autoruns tool. Compare this against a known-good baseline for the device’s OS build and installed applications. Any entry that does not appear in the baseline is either a legitimate recent installation or attacker-added persistence. Entries pointing to temp directories, user profiles, or recently created executables are high-priority investigation targets.

CollectionSummary.txt documents exactly which commands the agent ran to collect the package, the timestamps, and any errors. This is your chain-of-custody record — it proves when the data was collected and that the collection process completed successfully. Include a reference to this file in your incident report evidence section.

InstalledPrograms lists every application registered with Windows Installer, including version numbers and install dates. Look for remote access tools (AnyDesk, TeamViewer, ScreenConnect, ngrok) that should not be present in your environment, hacking tools (Mimikatz, Rubeus, Cobalt Strike, BloodHound/SharpHound), and recently installed applications (install date within the investigation window) that were not part of the standard build.

NetworkConnections captures all active TCP and UDP connections at the time of collection, with the owning process ID. Cross-reference PIDs against the RunningProcesses file to identify which processes had active connections. Look for connections to public IP addresses on non-standard ports (4444, 8080, 8443, 9090), connections from processes that should not have network access (notepad.exe, calc.exe, explorer.exe connecting to external IPs), and multiple connections to the same external IP from different processes (indicating a C2 channel shared across multiple injected processes).

RunningProcesses captures every process running at collection time with PID, parent PID, command line, memory usage, and start time. Look for processes started near the compromise timestamp, processes with suspiciously long or encoded command lines, multiple instances of system processes that normally have only one instance (two lsass.exe processes indicate injection or impersonation), and processes running from temp directories or user profiles.

ScheduledTasks lists all scheduled tasks with their triggers, actions, last run time, and next run time. Attacker-created tasks often have generic names (update, sync, maintenance), run at regular intervals (every 15 minutes, every hour), and execute from unusual paths. The distinction between a legitimate scheduled task and an attacker-created one is the creation date — tasks created within the investigation window that were not part of a known deployment are investigation targets.

SecurityEventLog contains the extracted Windows Security event log. Import this into an event log viewer or parse it with tools like EvtxEcmd for detailed analysis. Key events include 4624 (logon — shows who logged on, from where, using which logon type), 4625 (failed logon — brute force evidence), 4672 (special privilege assigned — shows which logons received admin access), 4688 (process creation — if command-line logging is enabled, shows every process with its full command line), and 4720 (user account created — attacker creating backdoor accounts).

Advanced investigation queries

Beyond the queries above, these patterns are essential for deep device investigation.

Complete process tree reconstruction shows every process launched on a device in parent-child relationship format, allowing you to trace the complete execution chain from initial access through post-compromise activity.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Reconstruct the full process tree for a device during the investigation window
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where Timestamp between (datetime(2026-03-18 09:00) .. datetime(2026-03-18 10:00))
| project Timestamp,
    ProcessId,
    ParentId = InitiatingProcessId,
    Process = FileName,
    Parent = InitiatingProcessFileName,
    Grandparent = InitiatingProcessParentFileName,
    CommandLine = ProcessCommandLine,
    Account = AccountName
| order by Timestamp asc

Network connection timeline shows every outbound connection from the device during the investigation window, revealing C2 channels, data exfiltration, and lateral movement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// All outbound connections from the device during the investigation window
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where Timestamp between (datetime(2026-03-18 09:00) .. datetime(2026-03-18 10:00))
| where RemoteIPType == "Public"
| summarize ConnectionCount = count(),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    Processes = make_set(InitiatingProcessFileName, 5)
    by RemoteIP, RemotePort
| order by ConnectionCount desc

File drop analysis identifies every file written to disk during the investigation window, revealing dropped payloads, tools, and exfiltrated data staged for transfer.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Files created on the device during the investigation window
DeviceFileEvents
| where Timestamp > ago(24h)
| where DeviceName == "DESKTOP-NGE042"
| where ActionType == "FileCreated"
| where Timestamp between (datetime(2026-03-18 09:00) .. datetime(2026-03-18 10:00))
| where not(FolderPath startswith "C:\\Windows\\Temp\\")
    and not(FolderPath has "\\AppData\\Local\\Temp\\")
| project Timestamp, FileName, FolderPath, SHA256,
    CreatedBy = InitiatingProcessFileName
| order by Timestamp asc

The deep investigation workflow

For complex incidents that go beyond single-alert triage (Module 1.4’s workflow), follow this expanded investigation methodology:

Phase 1 — Alert context (5 minutes). Read the alert, understand the detection logic, check the MITRE ATT&CK mapping. What technique was detected? What stage of the kill chain does it represent?

Phase 2 — Process tree analysis (10 minutes). Trace the full process chain from the alerted process to the root process. Identify the initial access vector (what launched the first suspicious process) and the post-compromise chain (what the suspicious process launched).

Phase 3 — Timeline deep dive (15-20 minutes). Isolate the time window. Filter by event types systematically: processes first (what executed), then network (where it connected), then files (what it dropped), then registry (what it modified for persistence), then logons (who else accessed the device). Flag every relevant event.

Phase 4 — Forensic artifact analysis (10-15 minutes). Run the persistence detection query, the LOLBin detection query, and the process injection query. Check for DLL sideloading. These queries surface attacker techniques that may not have triggered individual alerts but are visible in the telemetry.

Phase 5 — Investigation package (5-10 minutes). If you collected the package (and you should — subsection 2.6 covers the collection sequence), review the autoruns, installed programs, and network connections for evidence that supports or extends your timeline analysis.

Phase 6 — Entity pivoting (10-15 minutes). From the device investigation, pivot to other entities. Check the file hash: is the dropped malware on other devices? Check the C2 IP: which other devices communicated with it? Check the user account: where else did it authenticate? Each pivot either expands or narrows the incident scope.

Phase 7 — Documentation (5 minutes). Update the incident with your findings. Document the complete attack chain, all affected artifacts (processes, files, registry keys, network connections), and the evidence that supports each finding. This documentation enables the next analyst to continue the investigation and forms the basis of the incident report (Module 14).

Knowledge check