A Sysmon baseline that actually catches things in 2026

Look, most of the Sysmon configs I inherit fall into one of two buckets. Either it’s the schema default, which logs process creation and not much that helps, or it’s a four-thousand-line config someone copied from a blog in 2019 and never tuned, throwing so much volume at the SIEM that nobody reads it. Both of them fail the same way: when something actually happens, the telemetry that would have caught it either wasn’t collected or was buried under noise nobody triages.

This is the config I’d stand up first on a Windows fleet in 2026, event type by event type, with what each one actually catches and where the FPs come from. I’m running these notes against MDE on Win11 23H2 with Sysmon 15, because the specifics matter and “the test box” tells you nothing.

Process creation (EID 1) is the floor, not the coverage

Everyone collects EID 1. It’s the floor. Command line, hashes, parent process, and the parent is usually where the signal is. A w3wp.exe spawning cmd.exe is worth more than any single command line, because the ancestry is what’s abnormal, not the child. If you collect one thing, it’s this, and you tune it on the parent-child pairs your environment never legitimately produces.

But EID 1 alone is a door camera pointed at the front door. It tells you a process started. It doesn’t tell you what that process reached for, and most of the interesting behavior in 2026 is in the reaching.

Image load (EID 7): expensive, worth it if you scope it

EID 7 logs every DLL load, which is why people turn it off. Unscoped it’s the single loudest event Sysmon produces. Scoped, it’s how you catch unsigned or unusual modules loading into processes that should only ever load Microsoft-signed code. The catch here is DLL sideloading and injection that never shows up as a new process. I don’t collect all image loads. I collect unsigned image loads into a short list of processes that have no business loading third-party code, and I let the rest go.

(Yes, that means you miss the signed-but-malicious case. This catches most of it, not all. That’s the trade for a config anyone will actually keep enabled.)

ProcessAccess (EID 10): the LSASS rule that earns its keep

If I could only add one event to a default config, it’s EID 10 scoped to lsass.exe. Credential theft has to touch LSASS memory, and EID 10 shows you the process that opened a handle to it and the access mask it asked for. A handle request with 0x1010 or 0x1410 into LSASS from something that isn’t a known security product is about as close to a definition of the attack as endpoint telemetry gets.

The FPs are real and they’re worth knowing before you ship the rule: your EDR touches LSASS, some Windows components do, and a couple of legitimate admin tools do. You tune those out by process, once, and then the rule is quiet until it isn’t. Mine fired twice in six months. Both times it mattered.

Named pipes (EID 17 and 18): the lateral-movement and C2 signal

Named pipe creation and connection are underrated. A lot of C2 frameworks and post-exploitation tooling use named pipes for their default inter-process comms and for SMB-based lateral movement, and the pipe names are often a giveaway. You don’t block on a name, because names change, but a workstation creating a pipe pattern you only ever see from tooling is a hunt lead. This pairs directly with the endpoint side of the lateral movement detections I wrote up last month, which lean on the same “one box reaching for another in a way it never normally does” idea.

DNS (EID 22): keep it, scope it hard

EID 22 gives you process-attributed DNS, which network logs can’t. That attribution is the value: not “someone resolved this domain” but “this specific process resolved it.” It’s loud, so you scope it, usually to processes that have no business making DNS queries at all (why is notepad.exe resolving anything?) rather than trying to log the whole fleet’s browsing. Beaconing to a fresh domain from an unexpected process is the catch.

The registry and file events, briefly

EID 12, 13, and 14 (registry) earn their place scoped to autorun and persistence keys, not collected wholesale. EID 11 (file create) is worth it for a short list of staging directories and for dropped executables in user-writable paths. EID 15 (FileCreateStreamHash) catches alternate-data-stream tricks that still work more often than they should. None of these belong in the config as blanket collection. All of them belong scoped to the behavior you’re actually hunting.

What I’d turn on first, in order

If you’re standing this up on Monday and you have a noise budget to spend, here’s the order I’d spend it in:

• EID 1 with parent-child tuning. The floor.
• EID 10 scoped to LSASS. The highest signal-per-event you will collect.
• EID 17 and 18 for named pipes. Cheap, and it covers lateral movement and C2 that EID 1 misses.
• EID 7 for unsigned loads into a scoped process list. Expensive, so it goes last, but it’s the DLL-sideloading catch nothing else gives you.
• EID 22 for DNS from a short list of should-never-resolve processes.

The mistake I made for years was treating the config as a collection problem when it’s a triage problem. Every event you collect is an event someone has to be able to reason about at 3am when it fires. A config tuned to five things your analysts understand beats a config tuned to fifty they’ll mute by Friday. The upstream reference for what each event actually contains is still the Sysinternals Sysmon documentation, and the community starting point most people fork is the SwiftOnSecurity config which you then cut down rather than add to. Map the whole thing back to MITRE ATT&CK so you know what you’re not covering, and revisit it every quarter, because the config that caught things in 2024 has blind spots now.

Collect less. Tune harder. Read what fires.