I've been conducting a series of methodical evaluations of SIEM platforms for complex threat hunting scenarios, specifically focusing on the technical workflow of correlating disparate data sources. This post details a procedural walkthrough using LogRhythm's AI Engine and Data Indexer to perform a cross-source investigation, moving from a network alert to endpoint process verification. The core challenge in such hunts is the temporal and contextual linkage of events across different log schemas and collection mechanisms.
The scenario begins with a Network Monitor alert on a suspected beaconing pattern from an internal IP (`10.10.5.22`) to a known malicious external IP. The initial step is to validate the alert and pivot to endpoint data for host-based context.
**Step 1: Initial Network Investigation**
First, I query the Network Monitor logs using LogRhythm's Search interface to get the full context of the alert. A typical query would filter on the destination IP and protocol.
```sql
-- Simplified representation of the search filter applied in the UI
source:"NetMon-Logs"
AND dst_ip:"93.184.216.34"
AND src_ip:"10.10.5.22"
AND protocol:"TCP"
AND timestamp LAST 24 HOURS
```
This returns the raw log entries, confirming the periodic connections every 300 seconds. The key fields to note are the source IP (`10.10.5.22`) and, crucially, the source port (e.g., `49122`) from the most recent connection attempt.
**Step 2: Pivoting to Endpoint Data**
The objective is to identify the process on host `10.10.5.22` that initiated the connection using the source port. This requires correlating network flow data with Windows Security Event Logs (Event ID 5156) or Sysmon logs (Event ID 3), which LogRhythm can ingest via its agents. The correlation hinges on matching the port number and a precise timestamp window.
In the Log Search, I construct a composite query targeting the endpoint data for that specific host:
```sql
source:"WinEventLog-Security" OR source:"Sysmon-Logs"
AND host_ip:"10.10.5.22"
AND (event_id:"5156" OR event_id:"3")
AND timestamp WITHIN 2 MINUTES OF
```
The critical step is manually reviewing the returned process creation events or network connection events around that time, looking for a matching source port number in the event's `SourcePort` or `Initiated` field. This often reveals the process image path (e.g., `C:UsersPublicsvchosts.exe`) and the Process ID.
**Step 3: Process Tree Analysis and Enrichment**
Once the malicious process is identified, the next phase involves building a process tree. Using the discovered Process ID (PID) as a pivot point, I search backward in time for its parent process (typically via Sysmon Event ID 1 or Windows Event ID 4688). This is where LogRhythm's Data Indexer proves valuable, as it normalizes these fields across different log source types, allowing for a unified search on `parent_pid` or `process_guid`.
* Query for parent process: `host_ip:"10.10.5.22" AND child_pid:"" AND event_id:"1"`
* Query for any other child processes spawned: `host_ip:"10.10.5.22" AND parent_pid:""`
Finally, all related entities (IPs, hashes, file paths) are extracted and investigated using LogRhythm's embedded threat intelligence tools (like File Analysis and Entity Explorer) to confirm maliciousness. The entire investigation path, from network alert to malicious process tree, can then be documented as a custom AI Engine rule template for automated detection in the future.
The primary pitfalls observed in this workflow involve timestamp synchronization across log sources and the necessity for detailed, process-level logging (Sysmon) to be configured on endpoints. Without Sysmon or equivalent, the pivot from network flow to specific process is often impossible, reducing the hunt to host-level containment only.