Sysmon Configuration for SOC Teams: Which Event IDs to Enable and Why

Windows Security Event Log and Sysmon are complementary, not competitive. The Security Event Log captures authentication, authorization, and audit events. Sysmon captures process execution, network connections, file writes, registry modifications, driver loads, and inter-process activity at a level of detail that native logging does not provide without significant Group Policy configuration and third-party parsing.

The most important gap Sysmon closes is process creation with full command line (Event ID 1). While Event ID 4688 can be configured to capture command-line arguments, it requires specific audit policy settings that are often not enabled by default in older Windows environments, and it does not capture the parent process image hash, the current directory, or the LogonGUID that ties the process to a user session. Sysmon Event ID 1 captures all of these in a single structured record.

The second major gap is network connection logging per process (Event ID 3). Windows Firewall logging and NetFlow capture traffic at the network layer, but neither correlates a specific outbound connection to the exact process that initiated it, with the process hash and parent process context included. For detecting command-and-control beaconing or data exfiltration, this per-process network telemetry is essential.

Sysmon also captures events that have no native Windows equivalent: raw disk access (Event ID 9), named pipe creation and connection (Event IDs 17 and 18), and process tampering (Event ID 25). These cover techniques used in credential theft and defense evasion that would otherwise be invisible to a Windows-native logging stack.

Not every Sysmon event ID belongs in every environment. The right configuration depends on your SIEM ingestion budget, your endpoint count, and the threat actors and techniques you are prioritizing. The following breakdown covers the event IDs that matter most for detection and the tradeoffs of each.

Event ID 1: Process Create. Enable in all environments. This is the highest-value single event ID in Sysmon and contributes detection coverage for more MITRE ATT&CK techniques than any other. Tune by excluding process paths that generate high-frequency benign events: endpoint agents, antivirus processes, and system processes that spawn child processes continuously. Do not suppress broadly; tune the filter rules to exclude specific known-good parent-child relationships.

Event ID 3: Network Connection. Enable with tuning. Without exclusions, this will generate massive volume from browsers, update services, and endpoint agents. Focus filters on excluding destination ports and process paths associated with known-good update traffic. Keep coverage for unusual ports and unusual source processes.

Event ID 7: Image Loaded. Enable only on high-value targets such as domain controllers, PAWs, and sensitive servers. On general endpoints this generates enormous volume. If SIEM cost is a constraint, consider limiting ID 7 to a subset of critical assets.

Event IDs 8 and 10: CreateRemoteThread and ProcessAccess. Enable both. These cover process injection techniques central to most post-exploitation frameworks. Tune to exclude known-good injection patterns from endpoint security products, which routinely use these mechanisms for legitimate monitoring.

Event ID 11: FileCreate. Enable with heavy tuning. Target specific directories used for initial access and persistence: user temp directories, startup folders, and browser download paths. Logging all file creation events is impractical and will generate high volume.

Event IDs 12, 13, and 14: RegistryEvent. Enable with targeted path coverage. Log modifications to Run keys, service registry paths, COM object registrations, and AppInit paths. Logging all registry activity is not viable; a targeted key list is the correct approach.

Event ID 15: FileCreateStreamHash. Enable. This captures Alternate Data Stream creation, which is used by some downloaders to store payloads in ADS. Volume is low in most environments.

Event ID 22: DNSEvent. Enable in environments where DNS-based C2 is a priority threat. Volume can be high in environments with frequent DNS queries from monitoring agents. Tune to exclude known-good resolver traffic.

Event ID 25: ProcessTampering. Enable. This was added in Sysmon 13 to detect process image replacement and hollowing. Volume is low and the signal is almost always meaningful.

Two community Sysmon configurations dominate practitioner discussion: the SwiftOnSecurity config and the Olaf Hartong sysmon-modular project. Both are legitimate starting points and both have meaningful tradeoffs.

The SwiftOnSecurity config is a single XML file designed for immediate deployment. It is conservative by design: it enables a broad set of event IDs with extensive exclusion filters for common benign processes. The goal is a config that works out of the box in most enterprise environments with minimal initial noise. The tradeoff is that the exclusion lists may be too broad for some environments and are not easily decomposed into per-technique modules. For teams new to Sysmon, this is the recommended starting point.

The Olaf Hartong sysmon-modular project takes a different approach. Instead of a single monolithic config, it provides individual XML modules organized by MITRE ATT&CK technique. Teams can compose a custom config by selecting only the modules relevant to their detection priorities. This approach is more powerful and more maintainable at scale, but requires more initial effort to assemble and test. For mature SOC teams with an established detection engineering practice, sysmon-modular is the better long-term foundation.

Florian Roth's fork of the SwiftOnSecurity config adds additional detection logic for specific threat actor techniques and is worth reviewing as a supplementary reference when tuning for targeted threats.

The critical mistake practitioners make is deploying any community config without validating it against their specific environment. Run the chosen config in a test environment for one week, measure the alert volume per event ID, and identify the top noise sources before rolling out to production. No community config will be right for your environment without some degree of local tuning.

Sysmon is free to run on endpoints, but the data it generates is not free to ingest. Most commercial SIEM platforms charge by data volume, and an untuned Sysmon deployment on a large endpoint fleet can meaningfully increase monthly costs. Understanding which event IDs drive the most volume allows teams to make deliberate tradeoffs between coverage and cost.

Event ID 1 is high value and moderate volume in a well-tuned deployment. It should always be prioritized even in budget-constrained environments. Event ID 3 is the primary cost driver in most deployments because every network connection from every process generates a record. On endpoints with active browsers and update clients, this can produce thousands of records per hour per host. Aggressive tuning of known-good network traffic is essential.

Event ID 7 (Image Load) is the most expensive event ID in high-activity environments. On a developer workstation or build server, DLL loads occur at very high frequency. This event ID should be considered optional for general endpoints and reserved for high-value targets where the coverage is worth the cost.

A practical approach for cost management: calculate the per-event-ID volume in your test deployment, multiply by your endpoint count, and then multiply by your SIEM's per-GB rate to get a monthly cost estimate per event ID. This number makes the coverage-versus-cost tradeoff concrete and defensible when presenting a Sysmon deployment plan to leadership.

Deploying Sysmon without validating that your detection rules fire is the equivalent of installing a camera without checking that it records. Coverage validation should be part of every Sysmon deployment and every significant config change.

Use Atomic Red Team to run technique-specific tests that correspond to the event IDs you have enabled. For Event ID 1, test with T1059 (Command and Scripting Interpreter) variations. For Event IDs 8 and 10, test with T1055 (Process Injection) atomics. For Event ID 22, test with T1071.004 (DNS) C2 simulation. After each test, confirm that the relevant Sysmon event was logged to the endpoint event log and forwarded to your SIEM.

Keep a coverage matrix that maps each enabled event ID to the MITRE ATT&CK techniques it is intended to cover, the test used to validate it, and the date of last validation. This matrix serves as the authoritative record of what your Sysmon deployment actually detects, not just what it is configured to collect. When you tune a config, update the matrix. When a technique is escalated as a priority threat, check the matrix to confirm you have coverage before the next adversary simulation cycle.