Sysmon Advanced Configuration for Threat Detection: SwiftOnSecurity Config, Event ID Coverage, and SIEM Integration
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Sysmon deployed without a configuration file is Sysmon deployed wrong. The default installation with no config file enables only Event ID 1 (ProcessCreate) and Event ID 255 (errors) and applies no exclusion filters, generating a process creation event for every process on the endpoint including Windows Update, antivirus signature updates, and browser tab processes. A busy Windows workstation with no Sysmon config generates 1,000-5,000 Event ID 1 events per day, the vast majority of which are known-good software. The SIEM sees a flood of process creation events, ingest costs skyrocket, and the signal-to-noise ratio makes threat detection rules impractical.
The configuration file transforms Sysmon from a data generator into a precision threat detection tool. SwiftOnSecurity's sysmon-config enables 15+ event types, applies hundreds of exclusion filters for known-good software, and is the most widely deployed Sysmon configuration in enterprise environments for good reason: it is maintained against current threat intelligence, commented clearly enough to understand every rule, and calibrated to balance detection coverage against event volume in real enterprise workload environments. Starting with SwiftOnSecurity and tuning from there is the fastest path to operational Sysmon deployment with meaningful SIEM coverage.
Configuration selection and deployment: SwiftOnSecurity as the baseline
The SwiftOnSecurity sysmon-config XML file is not a starting template — it is a production-ready configuration that can be deployed as-is to most enterprise Windows environments. Understanding its structure (event type blocks, include/exclude rule logic, condition types) is essential for tuning it to your specific environment, but the initial deployment should use the file as-is to establish a baseline before customization. The olaf-hartong sysmon-modular framework builds on the same community knowledge but restructures it for automated deployment pipelines that manage per-event configuration files independently.
Deploy SwiftOnSecurity's sysmon-config as the baseline and track all local modifications in version control
Download the current sysmon-config from github.com/SwiftOnSecurity/sysmon-config and deploy it as-is to a pilot group of 20-50 endpoints using the Group Policy startup script method. After 30 days, review the Sysmon event volume by Event ID in the SIEM and identify which event types are generating disproportionate volume relative to their detection value. For each environment-specific high-volume event type (a custom application that generates frequent network connections, a build system that creates many child processes), add targeted exclusion rules to the configuration XML. Store the modified sysmon-config.xml in a version-controlled repository with commit messages documenting why each local modification was made (which application, which behavior, confirmed false positive). This tracking ensures that future upgrades to the upstream SwiftOnSecurity config can be merged without losing local customizations and provides an audit trail if a modification is questioned during an incident investigation.
Configure Sysmon hash algorithms to include SHA256 and IMPHASH for threat intelligence matching
Configure the Sysmon hash setting in the configuration XML to capture both SHA256 and IMPHASH for every file tracked by Sysmon: <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms> in the Sysmon configuration root element. SHA256 hashes enable exact file match against threat intelligence IOC feeds — any known-malicious binary hash will match. IMPHASH (Import Hash) is computed from a PE file's import table and remains consistent across malware family variants even when the file is recompiled to produce a different SHA256 hash. IMPHASH matching in the SIEM enables malware family detection that survives hash obfuscation. Connect the SIEM Sysmon Event ID 1 and Event ID 7 (ImageLoad) hash fields to threat intelligence feeds (MISP, OpenCTI, commercial TI platforms) for automated IOC alerting whenever a process or loaded DLL matches a known-malicious hash or IMPHASH. This integration provides automatic detection of known malware without requiring explicit detection rules for each malware family.
SIEM integration: building detection rules from Sysmon telemetry
Sysmon events in the SIEM are the raw material; detection rules are what transform them into security alerts. The most effective Sysmon-based detection rules use process lineage (parent-child process chains) and behavioral context (network connections from processes that should not make them, LSASS access from non-AV processes) rather than single-event signature matching. Process lineage rules are harder to evade because attackers cannot change the Windows kernel's recording of which process spawned which — changing the child process name or hash does not change the fact that cmd.exe was spawned by Word.exe.
Build process lineage detection rules for the 10 highest-value parent-child process anomalies
The following parent-child process combinations are high-fidelity threat indicators that should be implemented as SIEM detection rules against Sysmon Event ID 1: Office applications (winword.exe, excel.exe, powerpnt.exe, outlook.exe) spawning cmd.exe, powershell.exe, wscript.exe, or mshta.exe indicates malicious macro execution; browsers (chrome.exe, firefox.exe, msedge.exe) spawning cmd.exe or powershell.exe indicates a browser exploit; lsass.exe spawning any child process (lsass should not spawn children) indicates LSASS memory manipulation; svchost.exe spawning cmd.exe or powershell.exe with unusual command-line arguments indicates service-based lateral movement; and werfault.exe spawning child processes other than known Windows error reporting processes indicates exploitation of the Windows Error Reporting process. In Splunk, these rules are written as searches joining on the ProcessId/ParentProcessId fields from Sysmon Event ID 1; in Elastic, use the EQL sequence syntax to match parent-child pairs within a 1-second window.
Configure recurring Sysmon coverage validation to verify that critical event IDs are flowing to the SIEM from all endpoints
Establish a recurring Sysmon coverage check that validates all critical event IDs are flowing from the expected number of endpoints by running a SIEM query that counts unique source hosts per event ID over the past 7 days. Compare the unique host count for Sysmon Event ID 1 against the total managed endpoint count from your asset inventory — a significant gap indicates Sysmon is not deployed on some endpoints, the WEF collector is missing events from specific network segments, or Sysmon has been stopped or uninstalled on some hosts. For endpoints showing Event ID 1 but not Event ID 3 (NetworkConnect), the configuration file may not have NetworkConnect enabled on those endpoints, or the Sysmon version may be outdated and not support the event type. Run this validation as a scheduled SIEM search with an alert that fires if any critical event ID is received from fewer than 95% of expected endpoints, indicating a coverage gap that leaves detection blind spots.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Sysmon's value as a threat detection tool is entirely determined by the quality of its configuration and its integration with the SIEM. Start with the SwiftOnSecurity sysmon-config as the baseline — deploy it as-is, run for 30 days, then tune environment-specific exclusions while tracking modifications in version control. Enable SHA256 and IMPHASH hashing for threat intelligence feed matching. Deploy via Group Policy startup scripts with a WEF collector for centralized log aggregation before SIEM forwarding. Build detection rules that use process lineage (parent-child chains in Event ID 1) rather than single-event signature matching for rules that are harder to evade. Monitor Event ID 10 ProcessAccess for LSASS credential dumping with an allowlist of legitimate EDR and AV processes. Validate coverage on a recurring schedule by checking that all critical event IDs are flowing from the expected endpoint population. A well-configured Sysmon deployment with these practices provides Windows endpoint telemetry comparable to commercial EDR platforms for threat detection use cases.
Frequently asked questions
Which Sysmon configuration should I use: SwiftOnSecurity, olaf-hartong, or custom?
Choose between Sysmon configurations based on your team's operational maturity and deployment scale. The SwiftOnSecurity sysmon-config (github.com/SwiftOnSecurity/sysmon-config) is the right starting point for most environments: it is a battle-tested single XML file with sensible defaults that balances detection coverage against log volume, actively maintained, and extensively commented so each rule is understandable. Deploy it as-is and run it for 30 days before customizing. The olaf-hartong sysmon-modular config is better for teams with automation infrastructure (Ansible, DSC, SCCM) that need to maintain per-event configuration files separately, deploy different Sysmon configs to different endpoint tiers (servers vs. workstations), or track changes to individual event type configurations in version control. Custom configurations are appropriate when the community configs generate too many false positives or insufficient coverage for your specific environment after several months of tuning. Start with SwiftOnSecurity, document every deviation from it, and transition to sysmon-modular if the organization has the automation infrastructure to manage the per-file deployment workflow.
How do I configure Sysmon to detect process injection and LSASS credential dumping?
Configure Sysmon Event ID 10 (ProcessAccess) for LSASS credential dumping detection and Event ID 8 (CreateRemoteThread) for process injection detection. For LSASS access detection, add a ProcessAccess rule that includes all access events targeting lsass.exe: <ProcessAccess onmatch='include'><TargetImage condition='is'>C:\Windows\System32\lsass.exe</TargetImage></ProcessAccess>. The resulting Event ID 10 events include the SourceImage (the process trying to access LSASS), GrantedAccess rights (0x1010 and 0x1410 are the read-memory rights used by Mimikatz and similar tools), and CallTrace. Alert in the SIEM on Event ID 10 where TargetImage contains lsass.exe AND SourceImage does not match your EDR or antivirus process allowlist. For process injection, enable Event ID 8 with CreateRemoteThread include rules and alert when the SourceImage is a non-system process injecting into a system process (svchost.exe, explorer.exe, winlogon.exe). These two event types together cover the most common credential theft and process hollowing techniques used by post-exploitation frameworks.
How do I manage Sysmon event log volume to avoid SIEM ingest cost overruns?
Manage Sysmon event log volume by applying exclusion filters for known-good processes before enabling broad include rules, tuning the most expensive event types (NetworkConnect and DnsQuery), and reviewing the log volume contribution by event ID regularly. In the Sysmon configuration XML, exclusion rules are applied before inclusion rules, so adding <Image condition='is'>C:\Program Files\Google\Chrome\Application\chrome.exe</Image> in a NetworkConnect exclude block removes all Chrome network connections from the event stream before the include rules fire. For DnsQuery events (Event ID 22), exclude DNS queries to known-good internal resolvers and CDN domains rather than trying to include only suspicious queries — the known-good exclusion list approach is more maintainable. Use Windows Event Forwarding with a subscription that filters Sysmon events by Event ID before forwarding to the SIEM, so the forwarding layer drops low-value event types (like Event ID 5 ProcessTerminate) rather than forwarding them to the SIEM and paying ingest cost before filtering. Check the Sysmon event count per Event ID on a regular basis in the SIEM: if any single Event ID accounts for more than 40% of Sysmon ingest volume, investigate whether the exclusion filters for that event type are working correctly.
How do I deploy Sysmon via Group Policy across a Windows domain?
Deploy Sysmon via Group Policy by distributing the Sysmon binary and configuration file through a Group Policy startup script. Copy sysmon.exe and your configuration XML to a SYSVOL share accessible by all domain computers: \\domain.com\SYSVOL\domain.com\scripts\sysmon. Create a Computer Configuration > Windows Settings > Scripts (Startup/Shutdown) > Startup script that runs: if not defined as a service, install; if defined, update config. The startup script checks whether Sysmon is installed using sc query sysmon64, and if not, runs \\domain.com\SYSVOL\domain.com\scripts\sysmon\sysmon.exe -accepteula -i \\domain.com\SYSVOL\domain.com\scripts\sysmon\sysmonconfig.xml. If Sysmon is already installed, the script runs sysmon.exe -c \\domain.com\SYSVOL\domain.com\scripts\sysmon\sysmonconfig.xml to update the configuration without reinstalling. The startup script runs as SYSTEM at boot, giving it sufficient privileges for Sysmon installation. Test the GPO on a pilot OU of 10-20 endpoints first, verify Sysmon events appear in the Event Viewer at Microsoft-Windows-Sysmon/Operational, and then expand the GPO scope to all endpoints.
Which Sysmon event IDs provide the highest threat detection value and which are low value?
The highest threat detection value Sysmon event IDs by use case: Event ID 1 (ProcessCreate) is essential for nearly every threat detection use case — process chain analysis, suspicious parent-child process relationships, command-line argument analysis for LOLBin abuse, and malware process identification. Event ID 3 (NetworkConnect) is essential for C2 communication detection and lateral movement via network connections. Event ID 7 (ImageLoad) is valuable for detecting DLL hijacking and process hollowing when combined with known-good DLL allowlists. Event ID 10 (ProcessAccess) is essential for LSASS credential dumping detection. Event ID 22 (DnsQuery) is valuable for detecting DNS-based C2 communication. Lower-value event IDs for most environments: Event ID 2 (FileCreationTimeChanged) is used by attackers to timestomp evidence but generates high volume from backup software and file sync tools, making it noisy without granular exclusions. Event ID 5 (ProcessTerminate) rarely contributes to detection rules and generates high volume. Event ID 17/18 (PipeEvent) is valuable for detecting named pipe exploitation (PetitPotam, PrintNightmare) but requires detailed named pipe allowlisting to avoid noise. Enable the high-value event IDs first, verify they are providing signal in the SIEM before adding the noisier event types.
How do I use Sysmon Event ID 1 ProcessCreate for detecting living-off-the-land binary abuse?
Detect LOLBin (Living Off the Land Binary) abuse using Sysmon Event ID 1 by building detection rules around the specific process lineage and command-line patterns that indicate malicious use of legitimate Windows binaries. Write SIEM detection rules for these high-value LOLBin patterns: certutil.exe with -urlcache and -split in the command line indicates downloading content to disk using the certificate utility (used by many malware droppers); mshta.exe spawned by anything other than explorer.exe or the user's browser indicates a malicious HTML Application execution; wscript.exe or cscript.exe spawned by Outlook.exe or a browser process indicates a malicious script attachment executed via email; regsvr32.exe /s /n /u /i: pattern with a URL indicates a Squiblydoo attack; powershell.exe with -EncodedCommand or -enc in combination with -WindowStyle Hidden indicates obfuscated PowerShell execution; and any process spawned by wmiprvse.exe indicates WMI-based lateral movement or persistence. In the SIEM, correlate ProcessCreate events with parent process (ParentImage and ParentCommandLine fields from Sysmon Event ID 1) to build process chain detection rules rather than relying on the child process alone.
How do I integrate Sysmon logs with a SIEM for threat detection at scale?
Integrate Sysmon logs with SIEM platforms using Windows Event Forwarding (WEF) for cost-effective log collection at scale. Configure a WEF collector server with a WinRM listener and create an Event Log subscription that collects Microsoft-Windows-Sysmon/Operational events from all domain-joined endpoints using source-initiated subscriptions (endpoints push to the collector rather than the collector pulling from each endpoint). On the endpoints, configure the Windows Remote Management service and set the subscription URL via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager. The WEF collector aggregates Sysmon events from all endpoints before forwarding to the SIEM, reducing the number of SIEM data sources from thousands of endpoints to one collector. For SIEM-specific parsing, install the Splunk Add-on for Microsoft Sysmon (SA-Sysmon), Elastic's Windows integration with Sysmon event parsing, or the Microsoft Sentinel Sysmon solution which includes workbooks, hunting queries, and analytics rules pre-built for Sysmon event IDs. After integration, validate that all Sysmon event IDs are being parsed correctly by the SIEM by running a query for a recent Sysmon Event ID 1 and verifying that the Image, CommandLine, ParentImage, and Hashes fields are extracted and searchable.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.