Fuse Process, File, Network, Registry, and Identity Evidence
Build a time-aligned behavior timeline that distinguishes process creation from the files, connections, persistence, and account effects that follow.
In this lesson, you will learn to:
- Join endpoint events with identifiers appropriate to their scope.
- Determine which observed effects materially change incident severity and scope.
Fuse Process, File, Network, Registry, and Identity Evidence
Provides a correlation workflow using process GUIDs, file hashes, destination data, registry and service changes, logon sessions, and collection-quality checks.
Correlate through explicit keys and bounded time
Start with the process creation record and create a narrow UTC window while retaining original times. Link network connections by Process GUID where the source provides it, or by host, PID, and process lifetime with care. Link file creation by process identifier, path, hash, and time. Add registry changes, service or scheduled-task creation, module loads, DNS queries, authentication sessions, user activity, and security-control alerts. Record the join key and source for every relationship.
Do not force unrelated telemetry into the chain because it shares a host. High-volume endpoints create many simultaneous processes. A DNS query five seconds later may belong to another process unless the sensor attributes it. A file hash can connect an artifact across hosts, while a path alone may identify several different files over time. Network addresses can represent shared services. Use process, user or Logon ID, destination hostname, TLS or proxy metadata, and application context to strengthen joins. Mark inferred relationships and uncertainty separately from direct provider links.
Use effects to distinguish execution from impact
Severity changes with effects. A suspicious command blocked before execution differs from a process that wrote and launched a payload. Execution that established persistence, accessed credentials, altered security controls, connected externally, or touched sensitive data requires wider scope. Search for the same hash, command template, parent-child pattern, user, destination, and persistence mechanism on relevant peers. Apply stop rules so a common system binary does not expand the case to the entire fleet without behavior-specific evidence.
Check telemetry quality before declaring no impact: was network event collection enabled, were file events filtered, did the endpoint disconnect, and did the time window cover delayed activity? Absence of one data source can be offset by proxy, firewall, EDR, application, or identity evidence, but the limitation remains. Build a chronological story with the first supported execution, each confirmed effect, containment time, and latest observed activity. The story should allow a responder to see where execution ended and incident impact began.
Resources
- Microsoft Sysmon field-reading and tuning guidance — Use the official workflow for grouping process, command-line, file, registry, network, and DNS fields while tuning high-volume endpoint telemetry.