Sysmon Deployment and Configuration: How to Build Endpoint Visibility Without a Commercial EDR

Sysmon with no config logs almost nothing useful. Sysmon with a default-all config generates 50 to 200 MB per endpoint per day and is impossible to work with in most SIEMs. The configuration file is what makes Sysmon useful. Two community configs are the standard starting points: SwiftOnSecurity sysmon-config (github.com/SwiftOnSecurity/sysmon-config) and olaf hartong's sysmon-modular (github.com/olafhartong/sysmon-modular). SwiftOnSecurity is a single-file config maintained for operational environments -- it includes reasonable include rules for common attack techniques and exclude rules to suppress noisy legitimate processes. It is the right starting point for most organizations. Sysmon-modular is a modular framework where you compose the config from individual module files -- more flexibility, more maintenance, better for mature security programs that want precise control. Download and review the config before deployment: look at the exclusion rules to confirm they match your environment. The default configs exclude common security products and system processes; verify those match what is actually installed. Do not deploy sysmon-config without reading it. Some exclusions that suppress noise in one environment will suppress genuine attacker activity in another.

Single-host install: copy Sysmon64.exe and your config file (sysmonconfig.xml) to the target, then run Sysmon64.exe -accepteula -i sysmonconfig.xml. Sysmon installs as a service and driver. Verify with: sc query sysmon64. Enterprise deployment via GPO: create a network share accessible to all endpoints. Place Sysmon64.exe and sysmonconfig.xml there. Create a scheduled task via GPO (User Configuration > Preferences > Control Panel Settings > Scheduled Tasks) that runs on startup: Sysmon64.exe -accepteula -i \share\sysmon\sysmonconfig.xml. Add a second scheduled task that runs the update command: Sysmon64.exe -c \share\sysmon\sysmonconfig.xml. This lets you push config updates without reinstalling the binary. Configuration updates are live: running Sysmon64.exe -c newconfig.xml replaces the active config within seconds without stopping the service. Use this for incremental tuning without service restarts. For SCCM/Intune deployment: package Sysmon64.exe and config as an application with the install command above, and a detection rule that checks for the Sysmon64 service running.

Sysmon event IDs are not all equal. Event ID 1 (Process Create) is the most valuable for detection: it includes the full command line, parent process, user, and SHA256 hash. Alert on: cmd.exe or powershell.exe spawned by Office applications (parent: winword.exe, excel.exe, outlook.exe); PowerShell with encoded commands (-enc or -encodedcommand); mshta.exe, wscript.exe, or cscript.exe execution; processes spawned from temp directories or user AppData. Event ID 3 (Network Connection) is noisy but useful: filter on outbound connections from processes that should not make network connections (lsass.exe, svchost with non-standard command lines, Office applications connecting to non-Microsoft IPs). Event ID 7 (Image Loaded) logs DLL loads -- useful for detecting DLL hijacking and injection but high volume; use selectively. Event ID 8 (CreateRemoteThread) is almost always suspicious outside of known injection-based AV products -- alert on this broadly. Event ID 10 (ProcessAccess) specifically for lsass.exe access: this is your primary Mimikatz indicator. Any process accessing lsass.exe with PROCESS_VM_READ rights (access mask 0x1010 or 0x1038) should be investigated. Event ID 11 (File Create) for executable drops in temp and user-writable directories. Event ID 22 (DNS Query) for detecting C2 beaconing via DNS -- high-frequency DNS queries to rare domains from internal hosts. Event IDs 17 and 18 (Pipe Created/Connected) are valuable for detecting lateral movement tools that use named pipes (Cobalt Strike, PsExec, Impacket).

After initial deployment, expect high log volume from a few noisy sources. The most common noise sources: antivirus software accessing many files (add process excludes for your AV binary); backup agents making network connections (add network connection excludes for known backup server IPs); software update agents spawning child processes (add excludes for known update executables); browser processes making DNS queries (add DNS query excludes for browsers by process name). Tuning process: query your SIEM for the highest-volume event ID and process combinations over 24 hours. For each high-volume entry, decide: is this process ever relevant to an alert? If not, add an exclude rule. If it is relevant in some contexts, add a more specific exclude (e.g., exclude network connections from chrome.exe to known CDN IP ranges while keeping alerts for chrome.exe connecting to RFC1918 addresses). Test every exclude rule: does the final config still catch the behaviors you care about? Use a test VM to manually trigger each attack simulation (encoded PowerShell, lsass access, DLL injection) and confirm event generation after adding excludes.

Sysmon writes to Microsoft-Windows-Sysmon/Operational. Forward this channel via your existing log collection method. Windows Event Forwarding (WEF): add the Sysmon channel to your WEF subscription. Winlogbeat (Elastic): add the Sysmon channel to the winlogbeat.yml event_logs list. Splunk UF: add the Sysmon channel to the inputs.conf monitor stanza. Log volume planning: a well-tuned config generates 5 to 20 MB per endpoint per day. One thousand endpoints produce 5 to 20 GB per day of Sysmon data. Factor this into your SIEM ingestion budget before deployment. Hash algorithm: the default hash is SHA1. Add MD5 and SHA256 in the config HashAlgorithms element for cross-referencing with threat intel: HashAlgorithms value of MD5,SHA256,IMPHASH. IMPHASH (import hash) is valuable for detecting renamed malware variants that share the same code -- it hashes the import table rather than the file content. VirusTotal accepts IMPHASH lookups. DNS event forwarding: Event ID 22 is high volume even after tuning. Consider forwarding it only for non-browser processes, or storing it at cold tier in your SIEM for forensic queries rather than real-time alerting.