Sysmon: The Endpoint Telemetry Goldmine

The Visibility Problem

In Lesson 2.1, you learned that Windows Event Logs are the most important log source in most enterprise SOCs. In Lab 1.2, you mapped APT29's 15 techniques to the ATT&CK framework and discovered that 7 were red gaps — techniques Wazuh couldn't detect with default log sources.

Let's revisit those gaps:

The common thread: Windows Security Event Logs don't tell you which process connects to which network endpoint, which DLLs a process loads, which process accessed LSASS memory, or what files a process creates. Native Windows logging tells you "someone logged in" and "a process was created" — but not the deep behavioral telemetry needed to detect modern attacks.

Sysmon fills that gap.

Industry Reality: According to multiple DFIR surveys, Sysmon is deployed in over 70% of enterprise environments that take endpoint detection seriously. It's free, maintained by Microsoft (Sysinternals), and is the single most impactful improvement you can make to Windows endpoint visibility. If your SOC doesn't have Sysmon, you're missing most of the attack chain.

Click to enlarge

What Is Sysmon?

System Monitor (Sysmon) is a free Windows system service and device driver from Microsoft's Sysinternals suite. Once installed, it:

1. Monitors system activity at a deeper level than native Windows logging
2. Logs events to the Windows Event Log under Microsoft-Windows-Sysmon/Operational
3. Persists across reboots — once installed, it survives restarts and most tampering attempts
4. Is configurable — you control exactly what gets logged through an XML configuration file

Sysmon doesn't block anything. It doesn't prevent attacks. It records what happened at a granularity that native Windows logging cannot match. It's a telescope, not a shield — and in the SOC, seeing the attack clearly is the first step to stopping it.

Sysmon vs. Native Windows Logging

The Essential Sysmon Event IDs

Sysmon generates 29 event types (Event IDs 1-29). In practice, SOC analysts spend 95% of their time with 8 key Event IDs. Here are the ones that close the detection gaps from Lab 1.2:

Click to enlarge

Event ID 1: Process Creation

The single most valuable Sysmon event. Logs every new process with unprecedented detail.

ATT&CK Coverage: T1059 (Command and Scripting), T1204 (User Execution), T1036 (Masquerading)

Event ID 3: Network Connection

Logs network connections per process — which executable connected to which remote IP and port.

ATT&CK Coverage: T1071 (Application Layer Protocol), T1041 (Exfiltration Over C2), T1105 (Ingress Tool Transfer)

This directly closes the Lab 1.2 gaps for T1071.001 (Web Protocols C2), T1105 (Ingress Tool Transfer), and T1041 (Exfiltration Over C2). Without Sysmon, you can't see which process is talking to the C2 server — you only see network traffic at the firewall level without process attribution.

Event ID 7: Image Loaded (DLL Loading)

Logs every DLL loaded by a process — critical for detecting DLL injection and DLL side-loading.

ATT&CK Coverage: T1055.001 (DLL Injection), T1574 (DLL Side-Loading)

This closes the Lab 1.2 gap for T1055.001 (DLL Injection). In the APT29 scenario, the attacker injected code into svchost.exe via DLL injection. With Sysmon Event ID 7, you would see svchost.exe loading an unsigned DLL from an unusual path — a clear detection opportunity that native Windows logging completely misses.

Event ID 8: CreateRemoteThread

Logs when a process creates a thread in another process — a direct indicator of code injection.

ATT&CK Coverage: T1055 (Process Injection — all sub-techniques)

Event ID 10: Process Access

Logs when a process opens a handle to another process — the key detection for credential dumping.

ATT&CK Coverage: T1003.001 (LSASS Memory Dump)

This closes the Lab 1.2 gap for T1003.001. In the APT29 scenario, the attacker used Mimikatz to dump LSASS memory. With Sysmon Event ID 10, you would see an unusual process (the renamed Mimikatz binary) accessing lsass.exe with memory read permissions — regardless of what the tool is named.

Event ID 11: File Created

Logs file creation events — which process created which file.

ATT&CK Coverage: T1105 (Ingress Tool Transfer), T1560.001 (Archive Collected Data)

Event ID 13: Registry Value Set

Logs registry modifications — critical for detecting persistence mechanisms.

ATT&CK Coverage: T1547.001 (Registry Run Keys), T1112 (Modify Registry)

Event ID 22: DNS Query

Logs DNS queries per process — the per-process DNS visibility that no other Windows log source provides.

ATT&CK Coverage: T1071.004 (DNS C2), T1568 (Dynamic Resolution)

Sysmon + Wazuh Integration

Sysmon generates events into the Windows Event Log. Wazuh's Windows agent can read these events and forward them to the Wazuh manager for processing. The integration requires two things:

1. Sysmon Configuration

Sysmon's behavior is controlled by an XML configuration file. The community-standard configuration is SwiftOnSecurity's sysmon-config — a well-maintained, production-ready configuration that balances visibility with noise reduction.

Key configuration decisions:

• Which Event IDs to enable — Event IDs 1, 3, 7, 10, 11, 13, 22 are essential
• Exclusion filters — Suppress known-good processes to reduce noise (e.g., Windows Update, antivirus)
• Hash algorithms — MD5 + SHA256 for maximum threat intel compatibility

2. Wazuh Agent Configuration

The Wazuh agent needs to be configured to read the Sysmon channel:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Once configured, Sysmon events flow through the standard Wazuh pipeline: Agent → Manager → Decoder → Rules → Dashboard. Wazuh includes built-in decoders and rules for Sysmon events, so detection starts working immediately.

Closing the Lab 1.2 Gaps: Before and After

Let's revisit the APT29 detection coverage from Lab 1.2 and see how Sysmon changes the picture:

Result: From 3 Green / 5 Yellow / 7 Red → 7 Green / 5 Yellow / 3 Red

Sysmon alone closes 4 gaps completely and partially addresses 3 more. Combined with the existing Wazuh detection (Lesson 2.1-2.5), you now have meaningful coverage across the majority of the APT29 kill chain.

Click to enlarge

Real-World Detection Patterns with Sysmon

Here are five high-value detection patterns that Sysmon enables, each mapped to attack techniques you studied in Module 1:

Pattern 1: Macro Execution Chain

Event ID 1: ParentImage = WINWORD.EXE → Image = cmd.exe → powershell.exe

Detects: T1566.001 (Spearphishing) → T1059.001 (PowerShell)

Pattern 2: Credential Dumping

Event ID 10: SourceImage = unknown.exe → TargetImage = lsass.exe, GrantedAccess = 0x1010

Detects: T1003.001 (LSASS Memory Dump)

Pattern 3: C2 Beaconing

Event ID 3: Image = svchost.exe → DestinationIp = external_ip, repeated every 4 hours

Detects: T1071.001 (Web Protocols C2)

Pattern 4: Persistence via Registry

Event ID 13: TargetObject = HKLM\Software\Microsoft\Windows\CurrentVersion\Run, Image = powershell.exe

Detects: T1547.001 (Registry Run Keys)

Pattern 5: Renamed Binary Detection

Event ID 1: Image = C:\Temp\svchost.exe, OriginalFileName = mimikatz.exe

Detects: T1036 (Masquerading) — binary renamed to look like a legitimate Windows process

Sysmon Limitations

Sysmon is powerful but not perfect. Understanding its limitations prevents overconfidence: