Sysmon — System Monitor Event Log

Sysmon is the single most valuable telemetry source an investigator can find on a Windows endpoint — but only if someone installed it first. Unlike native event logs that record fragments of activity, a properly configured Sysmon deployment captures process creation with cryptographic hashes, parent-child relationships, full command lines, network connections, DLL loads, registry modifications, and DNS queries. When Sysmon is present, it transforms the endpoint from a forensic puzzle into a detailed operational timeline.

What Is Sysmon?

System Monitor (Sysmon) is a Windows system service and device driver from the Sysinternals suite, originally written by Mark Russinovich and Thomas Garnier. It installs as a persistent service that survives reboots and begins logging immediately after installation. Sysmon writes events to the Microsoft-Windows-Sysmon/Operational event log channel, using standard EVTX format that integrates with Windows Event Forwarding, SIEM platforms, and forensic tools.

The critical distinction between Sysmon and native Windows auditing is depth and context. The native Security log (Event ID 4688) records process creation but requires advanced audit policy configuration to include command-line arguments, and it never includes file hashes, parent process GUIDs, or network connection details. Sysmon Event ID 1 provides all of this in a single event — process name, full command line, SHA256 hash, parent process GUID, parent command line, user SID, logon GUID, and the integrity level of the process.

Sysmon operates through a kernel-mode driver (SysmonDrv.sys) that hooks into Windows kernel callbacks for process creation, thread creation, image loading, registry operations, and network activity. The driver filters events against the XML configuration policy before writing to the event log, which means the policy determines both what is logged and what is excluded. A poorly tuned policy produces noise; a well-tuned policy produces a forensic goldmine.

Location & Format

File Paths

Log Format

Sysmon events use the standard EVTX (Windows Event Log) binary XML format. Each event contains structured XML data with named fields that vary by Event ID. The log channel supports Windows Event Forwarding (WEF), Event Log subscriptions, and direct SIEM ingestion. Default maximum log size is 64 MB with circular overwrite, but this is configurable via wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:<bytes>.

Critical Event IDs

Sysmon generates 29 distinct event types (as of Sysmon 15.x). The following are the most forensically significant:

Additional Forensically Relevant Event IDs

What It Reveals

Sysmon answers investigative questions that no other single Windows artifact can address comprehensively:

• What exact binary ran, and what was its hash? — Event ID 1 provides SHA256/MD5/SHA1/IMPHASH for every executed process, enabling direct comparison against threat intelligence databases and malware repositories.
• What was the full command line? — Unlike native 4688 events (which require advanced audit configuration), Sysmon always logs full command lines including arguments, encoded payloads, and file paths.
• What was the parent process chain? — The ParentProcessGuid and ParentImage fields enable reconstruction of the complete process tree, from initial access through privilege escalation to lateral movement.
• Which process connected to which external IP? — Event ID 3 directly attributes network connections to specific executables, eliminating the guesswork required when correlating firewall logs with process execution.
• Which process loaded which DLL? — Event ID 7 reveals DLL side-loading, injection, and malicious module loading with hash verification and signature status.
• Was LSASS accessed for credential theft? — Event ID 10 captures every process that opened a handle to lsass.exe, including the specific access rights requested and the call stack.
• What DNS queries were made by which process? — Event ID 22 maps DNS resolution to specific executables, identifying C2 beacon domains, DGA patterns, and DNS tunneling per process.
• What files were created, and by which process? — Event ID 11 provides process-to-file attribution for staging, tool drops, and ransomware note creation.
• Were any registry persistence mechanisms installed? — Event IDs 12/13/14 track registry key creation, value modification, and deletion with full process attribution.
• Was process injection used? — Event ID 8 (CreateRemoteThread) and Event ID 25 (ProcessTampering) detect cross-process manipulation techniques used by advanced implants.

Forensic Use Cases

1. Cobalt Strike Beacon Reconstruction

An attacker delivers a Cobalt Strike stager via a phishing document. Sysmon Event ID 1 captures winword.exe spawning rundll32.exe with a suspicious command line. Event ID 3 shows rundll32.exe connecting to the team server IP on port 443. Event ID 8 records rundll32.exe creating a remote thread in svchost.exe (process migration). Event ID 10 shows the migrated beacon accessing lsass.exe for credential harvesting. Event ID 22 reveals DNS queries to the C2 domain. The entire attack chain — from initial execution through credential theft — is reconstructable from Sysmon alone.

2. DLL Side-Loading Detection

A legitimate signed application (Teams.exe) loads a malicious DLL from a non-standard path. Sysmon Event ID 7 logs the ImageLoaded path as C:\ProgramData\update\version.dll with Signed: false. The hash does not match any known legitimate module. By correlating with Event ID 1 (process creation) and Event ID 11 (file creation showing when the DLL was dropped), investigators can determine exactly when the malicious DLL was planted and which process delivered it.

3. Lateral Movement via PsExec

On the source host, Event ID 17 records the creation of a named pipe matching the PsExec pattern (\PSEXESVC-*). On the destination host, Event ID 1 captures PSEXESVC.exe spawning the attacker’s payload with the parent being services.exe. Event ID 3 shows the network connection between the two hosts on port 445/SMB. The combination of pipe creation, service execution, and network connection provides a complete lateral movement evidence chain.

4. Ransomware Process Tree Reconstruction

During a ransomware incident, the encryption binary has been deleted. Sysmon Event ID 1 preserves the full path, command line, SHA256 hash, and parent process chain. Event ID 11 records the creation of ransom notes (readme.txt in every directory). Event ID 13 captures registry modifications disabling Windows Defender (HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware = 1). Event ID 5 records when the ransomware process terminated. The hash from Event ID 1 can be submitted to VirusTotal for family attribution even though the binary no longer exists on disk.

5. DNS-Based C2 and Data Exfiltration

A process in C:\ProgramData generates high-frequency DNS queries to subdomains of a single parent domain with encoded data in the subdomain labels (e.g., aGVsbG8gd29ybGQ.evil-c2.com). Sysmon Event ID 22 maps every query to the specific process, providing both the DNS exfiltration channel and the responsible executable. Native Windows DNS Client logging records queries but does not attribute them to a process.

Configuration & the SwiftOnSecurity Baseline

Sysmon’s value is entirely dependent on its configuration. Without an XML policy, Sysmon uses default settings that log almost everything — creating massive noise that overwhelms both the event log and any downstream SIEM. The community standard baseline is the SwiftOnSecurity Sysmon configuration, a curated XML policy that enables high-value event types while excluding known-benign noise sources.

<!-- SwiftOnSecurity sysmon-config excerpt -->
<!-- https://github.com/SwiftOnSecurity/sysmon-config -->

<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms>
  <EventFiltering>

    <!-- Event ID 1: ProcessCreate - Log all, exclude known-benign -->
    <RuleGroup groupRelation="or">
      <ProcessCreate onmatch="exclude">
        <Image condition="is">C:\Windows\System32\backgroundTaskHost.exe</Image>
        <Image condition="is">C:\Windows\System32\SearchProtocolHost.exe</Image>
      </ProcessCreate>
    </RuleGroup>

    <!-- Event ID 10: ProcessAccess - Focus on LSASS -->
    <RuleGroup groupRelation="or">
      <ProcessAccess onmatch="include">
        <TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
      </ProcessAccess>
    </RuleGroup>

    <!-- Event ID 22: DNSQuery - Log all DNS, exclude noise -->
    <RuleGroup groupRelation="or">
      <DnsQuery onmatch="exclude">
        <QueryName condition="end with">.microsoft.com</QueryName>
        <QueryName condition="end with">.windowsupdate.com</QueryName>
      </DnsQuery>
    </RuleGroup>

  </EventFiltering>
</Sysmon>

:: Install Sysmon with configuration
sysmon64.exe -accepteula -i sysmonconfig-export.xml

:: Update configuration on running Sysmon
sysmon64.exe -c sysmonconfig-export.xml

:: Export current configuration
sysmon64.exe -c

:: Install with renamed binary and driver (evasion-resistant naming)
sysmon64.exe -i sysmonconfig.xml -d SysMon2Drv

Acquisition Methods

Live System Collection

:: Export Sysmon log using wevtutil
wevtutil epl Microsoft-Windows-Sysmon/Operational C:\Evidence\Sysmon.evtx

:: Using KAPE for Sysmon collection
kape.exe --tsource C: --tdest C:\Evidence --target Sysmon

:: Using PowerShell to export (alternative)
Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational |
    Export-Clixml C:\Evidence\Sysmon_Events.xml

:: Copy via VSS for locked file
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx C:\Evidence\

Forensic Image Extraction

# Mount forensic image read-only
mount -o ro,noexec,nodev /dev/sdb1 /mnt/evidence

# Copy Sysmon log
cp "/mnt/evidence/Windows/System32/winevt/Logs/Microsoft-Windows-Sysmon%4Operational.evtx" /analysis/sysmon/

# Also collect the SYSTEM hive for config recovery
cp /mnt/evidence/Windows/System32/config/SYSTEM /analysis/sysmon/

Parsing Tools & Analysis

Parsing with Chainsaw

# Hunt for Sigma detections in Sysmon log
chainsaw hunt /analysis/sysmon/Sysmon.evtx \
    --rules sigma/rules/ \
    --mapping mappings/sigma-event-logs-all.yml \
    --output /analysis/sysmon/chainsaw_results.csv

# Search for specific process by hash
chainsaw search /analysis/sysmon/Sysmon.evtx \
    -s "a1b2c3d4e5f6..." \
    --output /analysis/sysmon/hash_search.json

Analysis Script — LSASS Access Detection

# Identify processes that accessed LSASS (potential credential theft)

import pandas as pd

# Load EvtxECmd output for Sysmon Event ID 10
df = pd.read_csv('/analysis/sysmon/EvtxECmd_Output.csv')

# Filter for ProcessAccess events targeting LSASS
lsass = df[
    (df['EventId'] == 10) &
    (df['TargetImage'].str.contains('lsass.exe', case=False, na=False))
].copy()

# Flag high-privilege access patterns
suspicious_access = ['0x1010', '0x1FFFFF', '0x1F1FFF', '0x143A']
lsass['Suspicious'] = lsass['GrantedAccess'].isin(suspicious_access)

# Exclude known legitimate accessors
legit = ['svchost.exe', 'csrss.exe', 'MsMpEng.exe', 'lsm.exe']
alerts = lsass[
    (lsass['Suspicious']) &
    (~lsass['SourceImage'].str.lower().str.endswith(tuple(legit)))
]

print(f"Suspicious LSASS access events: {len(alerts)}")
print(alerts[['TimeCreated', 'SourceImage', 'GrantedAccess', 'CallTrace']].to_string())

Retention & Persistence

Anti-Forensics Resilience

Sysmon is a high-value target for adversaries because of the visibility it provides. Sophisticated threat actors actively attempt to disable, blind, or evade Sysmon. Understanding these techniques is critical for assessing evidence integrity.

MITRE ATT&CK Detection Mapping

Sysmon provides detection coverage across more MITRE ATT&CK techniques than any other single Windows telemetry source:

Related Artifacts & Cross-References

Corroborating Artifacts

References

1. Microsoft, “Sysmon — Sysinternals” — https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
2. SwiftOnSecurity, “sysmon-config — Sysmon Configuration File Template” — https://github.com/SwiftOnSecurity/sysmon-config
3. olafhartong, “sysmon-modular — Modular Sysmon Configuration” — https://github.com/olafhartong/sysmon-modular
4. WithSecure, “Chainsaw — EVTX Hunter” — https://github.com/WithSecureLabs/chainsaw
5. Eric Zimmerman, “EvtxECmd — EVTX Parser” — https://ericzimmerman.github.io/
6. SANS Institute, “Sysmon — The Best Free Windows Monitoring Tool” — https://www.sans.org/blog/
7. TrustedSec, “Sysmon Community Guide” — https://github.com/trustedsec/SysmonCommunityGuide
8. Yamato Security, “Hayabusa — Windows Event Log Analyzer” — https://github.com/Yamato-Security/hayabusa