← 02 — Articles

Sysmon without drowning

Endpoint7 min read

The Windows Security log tells you that a process started. With the right audit policy, it also tells you the command line. It does not tell you the parent’s command line, the file hash, which process opened a connection to which address, or that something wrote itself into a Run key. System Monitor (Sysmon) from Sysinternals does, and it is free.

It also logs DLL loads, every DNS query and every file write if you let it. A Sysmon deployment fails in one of two ways: a configuration so broad that the SIEM bill doubles and analysts stop reading, or one so cautious that it adds nothing. This article describes a baseline in between, the reasoning for each event type, and how to measure what it costs on your machines before rolling it out. The configuration is sysmon-baseline.xml.

What you need before you start

  • Sysmon, version 13 or later. The baseline uses schema 4.50, which newer versions accept. sysmon64.exe -s prints the schema your version supports.
  • A way to deploy it: a software distribution tool, a Group Policy startup script or your EDR’s script runner. Sysmon is one executable and one XML file.
  • A collector for Microsoft-Windows-Sysmon/Operational. Most SIEM agents read it with a few lines of configuration; check that yours parses the event fields, not just the message text.
  • Three to five test machines that look like the fleet: a workstation, a busy server, a domain controller if you plan to cover them.

The principle: include the noisy, exclude the rare

Sysmon filters each event type separately, with onmatch="include" (log only what matches) or onmatch="exclude" (log everything except what matches). An empty include logs nothing; an empty exclude logs everything. The baseline uses that deliberately:

  • Log everything for event types that are rare and valuable: process creation, driver loads, remote threads, WMI subscriptions, process tampering.
  • Log only an include list for event types that are frequent: network connections, file creation, registry changes, LSASS access.
  • Log nothing for event types whose cost is rarely worth it as a default: image loads, DNS queries, file deletes with archiving, clipboard, named pipes.

Anything you do not list explicitly is not logged. That is the main difference from configurations that try to capture everything and then exclude noise: here, every event in the SIEM is there because someone decided it should be.

Event types, one by one

Process creation (event 1): everything

Event 1 is the reason to run Sysmon. Compared with 4688, it adds the parent command line, the file hashes (SHA256 and IMPHASH in this baseline), the process GUID that links events together, the integrity level and the current directory. The baseline logs every process start. The only exclusions you should add are high-frequency, known-good parents you have actually seen in your data, by full path.

Network connections (event 3): an include list

Logging every connection from every process is the fastest way to drown. The baseline logs connections from the binaries that commonly appear in living-off-the-land activity — powershell.exe, pwsh.exe, rundll32.exe, regsvr32.exe, mshta.exe, certutil.exe, bitsadmin.exe, wscript.exe, cscript.exe, msbuild.exe, installutil.exe — and connections to the remote-administration ports 22, 3389, 5985 and 5986 from any process.

That is a detection-oriented list, not a network log. If you need to know everything a host talked to, a firewall or a network sensor is the better source.

Driver loads (event 6): everything not signed by Microsoft Windows

Drivers signed as Microsoft Windows with a valid signature are excluded. Everything else — third-party drivers, unsigned or invalid signatures — is logged. On a stable fleet that is a short list, which makes a new entry worth a look.

Remote threads, raw disk reads, tampering, WMI (events 8, 9, 25, 19–21): everything

CreateRemoteThread (8), raw disk reads (9), process tampering (25) and WMI event subscriptions (19–21) are rare on most machines and map to specific techniques: injection, reading locked files such as the AD database, process hollowing, WMI persistence. Expect a handful of legitimate sources — security products for 8, backup tools for 9 — and exclude them by full path after you have seen them.

LSASS access (event 10): include LSASS only

Process access to lsass.exe is how many credential theft tools start. It is also something your EDR, antivirus and some management agents do constantly. The baseline logs only access to LSASS and leaves an ADAPT block for excluding your security products. Expect to tune this one on day one.

File creation (event 11): persistence locations

Only the Startup folders, the scheduled task folders (C:\Windows\System32\Tasks\, C:\Windows\Tasks\), and .exe or .ps1 files written anywhere under C:\Users\. Software updaters write executables to user profiles too, so the last rule will need exclusions.

Registry (events 12–14): autostart and services

Changes under the Run and RunOnce keys (both native and WOW6432Node), Winlogon, Image File Execution Options, and the ImagePath value of any service. These are a small part of the registry and a large part of Windows persistence.

What is off, and when to turn it on

  • Image loads (7): extremely high volume. Enable for specific DLLs only when a detection needs it.
  • DNS queries (22): valuable, and large. If your DNS servers already log queries centrally, you do not need it on endpoints. If they do not, consider enabling it with an exclude list for your own domains and major update services.
  • File delete with archiving (23): copies deleted files to an archive folder — useful for forensics, expensive in disk space.
  • Clipboard (24): can capture passwords and personal data. Leave off unless you have a specific reason and a retention policy for it.
  • Named pipes (17, 18): useful for some lateral movement detections, noisy by default. Enable with an include list when you write those detections.

Measuring the cost before rollout

Install on the test machines, let them run through a normal working day, and count:

Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Name, Count

The top two or three event IDs will be most of the volume. For each, look at the top processes behind them and decide: exclude, keep, or narrow the include list. Then check the size of the log itself; the Sysmon channel has its own maximum size, which you can read with wevtutil gl Microsoft-Windows-Sysmon/Operational and change with wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:<bytes>.

Multiply the per-machine numbers by the number of machines of each type, and record the result in your log source inventory.

Testing that the configuration works

  1. Load it: sysmon64.exe -accepteula -i sysmon-baseline.xml on a test machine, or sysmon64.exe -c sysmon-baseline.xml to update an existing install. sysmon64.exe -c with no file prints the active configuration.
  2. Process creation: run cmd.exe /c echo ew-sysmon-test and look for event 1 with that command line.
  3. Network: from PowerShell, connect to a machine in your network that accepts Remote Desktop: Test-NetConnection -ComputerName SRV-APP01 -Port 3389. Expect event 3 from powershell.exe, matched by both the image and the port rule.
  4. Registry: create and delete a value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run with reg add and reg delete. Expect event 13 for the value set and event 12 for the delete.
  5. Find them centrally, not only in Event Viewer.

Limitations

  • Sysmon records what happens; it does not block anything and it is not an EDR. An attacker with administrator rights can unload it or change the configuration. Sysmon event 16 records configuration changes, and a silent-source alert catches a stopped service.
  • Include lists only catch what they list. A binary that is not in the event 3 list makes connections that this baseline will not see.
  • We have not measured this configuration’s volume on your fleet. The section above is how to do that; the numbers depend on your software, users and servers.
  • This baseline is our own and intentionally small. Larger community configurations exist and are worth reading for ideas; compare them by what they include, not by how many lines they have.

Adapting this to your environment

  • ADAPT the exclusions in every block marked ADAPT: your EDR, antivirus, backup and monitoring agents, by full path.
  • ADAPT the event 3 list: add binaries your detections care about, remove ones your software uses legitimately all day.
  • ADAPT per role: domain controllers and servers may justify DNS logging or a broader file creation list; workstations rarely need either.
  • Keep the configuration in version control and increase the date in its header with every change, so you can tell which version a machine runs.

The configuration is sysmon-baseline.xml (MIT). If something here is wrong, write to hello@entropywatch.dev and we will correct it in the open.