Artifact Analysis: Sysmon (System Monitor)

Note

Executive Summary: System Monitor (Sysmon) is a free, elite telemetry sensor from the Microsoft Sysinternals suite. Installed as a system service and device driver, it continuously monitors and logs system activity to the Windows Event Log. By bridging the massive visibility gaps left by native Windows logging, Sysmon effectively transforms a standard operating system into an EDR-like endpoint, making it an indispensable tool for Threat Hunting and deep forensic investigations.

1. Technical Philosophy and Architecture

Sysmon is not a protection tool; it does not block or quarantine malicious activity. It is purely a high-fidelity sensor. Its core philosophy is to “make the invisible visible” by logging attributes that native Windows auditing ignores, such as process hashes, exact network destinations, and precise parent-child process tracking.

The power of Sysmon lies in its XML Configuration File. This file dictates exactly what the driver should log and, more importantly, what it should exclude. Without a finely tuned configuration, Sysmon will rapidly overwhelm the event log and the centralized SIEM with “noise.”

Once installed (sysmon.exe -i config.xml), the telemetry is written to a dedicated event channel: Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.

2. Critical Event IDs for DFIR

Sysmon generates dozens of event types, but DFIR analysts primarily focus on the following core events to reconstruct the attack kill chain.

Event ID 1: Process Creation

A heavily steroid-injected version of the nativeEvent 4688. It records the command line, the parent process, and crucially:

• Hashes: MD5, SHA1, SHA256, or IMPHASH of the executable.
• OriginalFileName: Extracted from the PE header, this defeats basic renaming techniques (e.g., an attacker renaming mimikatz.exe to svchost.exe).
• ProcessGuid: A unique identifier that permanently links this process to all its subsequent actions.

Event ID 3: Network Connection

This event binds a specific network connection to the exact process that initiated it—a feature notoriously absent from standard Windows logs. It records the Source/Destination IPs, ports, and the resolved Destination Hostname, making it invaluable for detecting C2 (Command & Control) beacons.

Event ID 8 & 10: Advanced Memory Operations

• Event ID 8 (CreateRemoteThread): Detects when a process injects code into another process. This is the primary indicator of Process Injection, Process Hollowing, and advanced evasion techniques.
• Event ID 10 (ProcessAccess): Detects when a process opens a handle to another process. Filtering this event for access to lsass.exe is the industry standard for detecting OS Credential Dumping (e.g., Mimikatz, Procdump).

Event ID 11 & 22: File and DNS Activity

• Event ID 11 (File Create): Tracks files dropped onto the disk, essential for catching stage-two malware payloads or temporary archives created during Insider Threat Exfiltration.
• Event ID 22 (DNS Query): Records every DNS resolution attempt and ties it to the requesting process.

3. The Power of ProcessGuid Correlation

The most revolutionary feature of Sysmon for Incident Responders is the ProcessGuid.

In standard Windows logging, Process IDs (PIDs) are recycled rapidly by the OS, leading to timeline confusion. Sysmon generates a globally unique identifier (ProcessGuid) for every process upon creation (Event ID 1).

Analysts can use this single GUID to trace a complete, unambiguous execution chain:

1. Event 1: Process is created (GUID: A1B2…).
2. Event 22: Process A1B2 queries malicious-domain.com.
3. Event 3: Process A1B2 connects to 198.51.100.45:443.
4. Event 11: Process A1B2 drops payload.exe into C:\Users\Public\.

4. Threat Hunting Queries

When Sysmon telemetry is ingested into a SIEM, analysts can deploy highly targeted behavioral hunting queries.

KQL (LSASS Credential Dumping)

hunt_sysmon_lsass_access.kql

// Detect suspicious access to lsass.exe (Event ID 10)
DeviceEvents
| where ActionType == "SysmonProcessAccess"
| where FileName == "lsass.exe"
// Exclude known legitimate processes accessing LSASS
| where InitiatingProcessFileName !in~ ("svchost.exe", "csrss.exe", "taskmgr.exe", "msmpeng.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, AccessMask

Splunk (Suspicious DNS)

hunt_sysmon_dns_c2.spl

# Detect non-browser processes making DNS queries (Event ID 22)
index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22
| search NOT Image IN ("*\\chrome.exe", "*\\firefox.exe", "*\\msedge.exe", "*\\iexplore.exe", "*\\system32\\svchost.exe")
| table _time, host, Image, QueryName, QueryStatus
| sort - _time

5. Deployment and Configurations

The quality of an investigation depends entirely on the quality of the Sysmon XML configuration. Using the default configuration provides minimal value. DFIR teams rely on community-driven baselines tailored to map to the MITRE ATT&CK framework.

Olaf Hartong's Sysmon-Modular

The current industry standard. A highly modular, easily maintainable configuration mapped directly to MITRE ATT&CK techniques, offering superior signal-to-noise ratios.

SwiftOnSecurity Configuration

The legacy standard. A solid, foundational baseline configuration that filters out immense amounts of generic Windows noise, perfect for smaller deployments.

---

References & Further Reading

• Microsoft Sysinternals: Sysmon Documentation
• Olaf Hartong: Sysmon-Modular GitHub Repository
• SwiftOnSecurity: Sysmon-Config GitHub Repository
• Related Artifact: Event ID 4688 & Process Lineage