Did You Know: Sysmon Logs Only What Its Configuration Asks For, and a Default Install Skips Network Connections

AUSTIN - Installing Microsoft's System Monitor on an endpoint does not mean the endpoint reports everything Sysmon can see. Microsoft's documentation for Sysmon v15.22 describes a Windows service and boot-start driver that writes to the Applications and Services Logs/Microsoft/Windows/Sysmon/Operational event log, and it lists event types numbered 1 through 29, from process creation to executable file detection, plus an error event. Which of those events reach the log depends on the configuration file. Microsoft's own example of an install with default settings, sysmon -accepteula -i with no configuration file, is described as process images hashed with SHA1 and no network monitoring.

Several event types are off unless someone turns them on. Microsoft says the network connection event, Event ID 3, is disabled by default. It says the image loaded event, Event ID 7, is disabled by default and needs to be configured, and warns that monitoring all image loads will generate a significant amount of logging. For the process access event, Event ID 10, Microsoft says it enables detection of hacking tools that read the memory of the Local Security Authority process, lsass.exe, to steal credentials, but that enabling it can generate significant amounts of logging and generally should be done with filters that remove expected accesses.

The configuration also decides how much of each enabled event survives. Each event type has its own filter tag under the EventFiltering node. Microsoft says an onmatch value of include logs only matched events, exclude logs everything except matches, and exclude matches take precedence when both are set for the same event. Rules on the same field behave as OR conditions and rules on different fields behave as AND conditions. That makes exclusions a coverage decision as well as a noise decision: the header of one popular community configuration warns that legitimate processes are routinely used by threats and tells users not to blindly exclude them.

That configuration is SwiftOnSecurity's sysmon-config, which bills itself as a Sysmon configuration file for everybody to fork. Its header lists source version 74, dated July 8, 2021, and says it requires Sysmon version 13 or higher. In the file, the sections for image loads (Event ID 7), raw disk reads (Event ID 9) and process access (Event ID 10) use an include filter with no rules, and the file notes that this means nothing in those sections will be logged; its comments say these events can cause high system load. The project's README says users will need to install and observe the results in their own environment before deploying widely, and that the configuration does not track authentication and other Windows events that are also vital for incident investigation. Olaf Hartong's sysmon-modular, which the SwiftOnSecurity README points to for a more exhaustive approach, says every configuration is a starting point to be reviewed and tuned for applications, endpoint roles, detection needs and logging budget. One of its profiles, built to complement Microsoft Defender for Endpoint, does not enable every Sysmon event.

For a SOC, the Sysmon configuration belongs in the detection inventory alongside the rules that read its events. Microsoft says running sysmon -c with no other argument dumps the configuration currently loaded on the host, and that Event ID 16 logs changes to the Sysmon configuration, such as updated filtering rules. Before concluding that a host never opened a network connection or never touched LSASS, confirm that its configuration was collecting Event ID 3 or Event ID 10 for that process at that time. A missing Sysmon event can mean the activity did not happen, or that the configuration never asked Sysmon to record it.