Sysmon Setup and Tuning for Threat Hunters

I once inherited a Sysmon deployment that logged everything at default settings across 3,000 endpoints. Event ID 3 alone—network connections—was generating something like 40 million events a day. Nobody was hunting through that. Nobody could. The SIEM was choking, the analysts had given up looking at it, and the whole deployment existed purely so someone could check a compliance box. That’s the trap with Sysmon: install it wrong and you’ve built an expensive log firehose nobody uses. Configure it well and it’s the single highest-value data source you’ll have for endpoint hunting, full stop.

Sysmon isn’t a detection tool by itself. It’s a telemetry generator. The value comes entirely from what you configure it to log and how well you filter the noise before it hits your SIEM ingestion pipeline.

Start from a real config, not the Microsoft defaults

Running Sysmon with no config file, or the bare-bones one Microsoft ships, gets you almost nothing useful. Process creation logs command lines but skips hashing. Network connection logging is off by default. You need a proper XML configuration, and at this point there’s no reason to write one from scratch—start from SwiftOnSecurity’s config or Olaf Hartong’s more hunt-oriented one and modify from there. Both are maintained, both encode years of tuning work from people who’ve actually dealt with the noise problem.

What actually matters in your config: enable hashing (SHA256 at minimum, ImpHash if you can afford the CPU cost) on process creation, turn on network connection logging but exclude your known-noisy internal ranges, and make sure you’re capturing parent process command lines, not just the child. Say your config currently only logs the process that ran, not what launched it—you’ll catch a malicious PowerShell execution but have no idea it came from a Word macro. That parent-child chain is often the entire story.

Filtering is where the real engineering happens

The include/exclude rule logic in Sysmon config is deceptively simple to write and genuinely hard to get right. Exclude too aggressively and you blind yourself to techniques that hide inside legitimate-looking processes—svchost.exe making unusual network connections is a classic example you don’t want to filter out just because svchost.exe is “normal.” Exclude too little and you’re back to the 40-million-events-a-day problem.

My general approach: filter based on destination for network events (exclude your internal DNS servers, your patch management infrastructure, known-good broadcast/multicast noise), but don’t filter based on source process name for anything that could plausibly be abused. LOLBins like rundll32.exe, regsvr32.exe, and mshta.exe get logged in full regardless of how often they show up, because when they do show up maliciously, that’s exactly the hunt lead you need.

Event ID 1 and Event ID 3 deserve the most tuning attention

These two event types—process creation and network connection—generate the highest volume and the highest hunt value simultaneously, which makes them worth spending 80% of your tuning effort on. For process creation, focus your filtering on eliminating known-benign repetitive processes (antivirus scan child processes, patch scanners that fire every few minutes) rather than filtering by parent path, which attackers can spoof or live inside of anyway.

For network connections, a realistic tuning target for a 2,000-host environment might bring you from tens of millions of raw events down to a few hundred thousand a day that are actually worth indexing for search—still a lot of data, but searchable and hunt-ready instead of an undifferentiated firehose.

Don’t forget the operational side: rotation, resource use, and tamper protection

Sysmon writes to its own event log channel (Microsoft-Windows-Sysmon/Operational), and if you don’t size that log file appropriately, you’ll lose events to rotation before your log shipper ever picks them up. On a busy server, a default 1MB or even 64MB log size gets overwritten in minutes. Bump it to at least 500MB-1GB depending on your shipping interval, and verify your forwarding agent is actually keeping pace—I’ve seen environments where Splunk’s universal forwarder was configured with a polling interval too slow to keep up with burst activity, silently dropping events during exactly the kind of high-activity period you’d want visibility into.

Also worth doing: enable Sysmon’s own tamper protection features and monitor for attempts to stop or unload the Sysmon driver itself (Event ID 255, or watching for sc.exe / net.exe stop commands targeting the Sysmon service). An attacker disabling your telemetry source is itself a detection opportunity, and a fairly loud one if you’re watching for it.

Getting the deployment scope right

Rolling Sysmon out everywhere at once, with one config, on day one is how most tuning nightmares start. Start with a pilot group—maybe your SOC’s own workstations and a handful of servers—run the config for two weeks, review what’s actually flooding your index, and iterate before wider rollout. Different host roles genuinely need different tuning: a domain controller’s normal network connection profile looks nothing like a developer workstation’s, and treating them identically in one config means one of the two groups gets either drowned in noise or under-monitored.