System Monitor (Sysmon)

Sysmon (System Monitor) is a free Windows system service from Microsoft's Sysinternals suite that logs detailed system activity to the Windows Event Log. It captures information that the standard Windows Security log does not, including process creation with full command-line arguments, network connections with source and destination details, file creation timestamps, driver and DLL loading, and changes to file creation times (a technique attackers use to cover their tracks). Sysmon runs as a Windows service and device driver, surviving reboots, and its events are written to a dedicated event log channel. It is widely used in threat detection because it provides the telemetry needed to reconstruct attack timelines.

Sysmon logs over 25 event types, each identified by an Event ID. The most security-relevant are: Event ID 1 (process creation with command line, hashes, and parent process), Event ID 3 (network connections with source/destination IP and port), Event ID 7 (image loaded, for detecting malicious DLLs), Event ID 8 (CreateRemoteThread, used in code injection), Event ID 10 (process access, catches credential dumping tools accessing LSASS), Event ID 11 (file create), Event ID 13 (registry value set), and Event ID 22 (DNS query). Each event includes a timestamp, the process GUID for correlation, and the user account. This level of detail is what separates Sysmon from the default Windows event logs.

Download Sysmon from the Microsoft Sysinternals website and deploy it using your existing management tools. The most common methods are Group Policy (using a startup script that runs `sysmon64.exe -accepteula -i config.xml`), SCCM/Intune task sequences, or a PowerShell remoting script. You need an XML configuration file that defines which events to capture and which to exclude. Start with a community configuration like SwiftOnSecurity's sysmon-config (available on GitHub), which provides well-tuned defaults that balance visibility with log volume. Deploy to a test group first, monitor log volume for 48 hours, then roll out organization-wide. Sysmon requires local administrator privileges to install.

Configure your log forwarder (Windows Event Forwarding, NXLog, Winlogbeat, or the Blumira agent) to ship the Sysmon event log channel (Microsoft-Windows-Sysmon/Operational) to your SIEM. Once ingested, the SIEM applies detection rules against Sysmon events. For example, Event ID 1 with a command line containing "mimikatz" or "sekurlsa" triggers a credential theft alert. Event ID 3 showing PowerShell making outbound connections to uncommon ports can indicate command-and-control activity. Blumira ingests Sysmon logs and includes pre-built detection rules tuned to Sysmon event types, so you get detection value without writing custom queries. The 24/7 SecOps team triages Sysmon-based alerts and provides response guidance.

Start with SwiftOnSecurity's sysmon-config from GitHub, which is the most widely used community configuration and is regularly updated. It excludes known-noisy processes to keep log volume manageable while capturing the events most useful for threat detection. Key tuning decisions: always log Event IDs 1, 3, 7, 8, 10, 11, 13, and 22. Exclude trusted software updaters and system processes that generate high-volume, low-value events. Add exclusions for your specific environment (backup agents, monitoring tools, deployment software) only after reviewing what they generate. Olaf Hartong's sysmon-modular project on GitHub provides a modular approach where you can enable or disable detection categories independently. Review and update your configuration quarterly as new attack techniques emerge.

Sysmon's performance impact is minimal on modern hardware when properly configured. With a well-tuned configuration (like SwiftOnSecurity's defaults), CPU overhead is typically under 1% and memory usage is 10 to 20 MB per system. The main resource consideration is disk I/O from writing events to the local event log and network bandwidth for forwarding logs to your SIEM. A busy workstation might generate 5,000 to 50,000 Sysmon events per day depending on the configuration. Poorly tuned configurations that capture every file creation or network connection on a busy server can generate millions of events per day. That is why starting with a proven community configuration and excluding noisy, low-value processes is critical. The performance cost is negligible compared to the visibility gained.

Sysmon adds the most value when you have a SIEM or log management platform to analyze its output. Deploying Sysmon without a centralized log collection system means the events sit in local Windows Event Logs where nobody reviews them, which provides no security benefit. Sysmon is also less useful in environments that are entirely cloud-based with no Windows endpoints to monitor. If your organization runs macOS or Linux exclusively, Sysmon does not apply. For Windows environments that already run an EDR agent with comparable telemetry (process creation, network connections, file activity), evaluate whether Sysmon adds incremental visibility before deploying it and adding to your log volume.