Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article describes how to review Sysmon events after configuration, interpret common event patterns, and tune filtering rules to balance visibility and event volume.
Prerequisites
To make sure you are set up to utilise sysmon, ensure the following is true:
Sysmon is enabled and configured on the device. For more information about installing Sysmon, see Enable and configure Sysmon.
Sysmon events are visible locally in Event Viewer or forwarded to a centralized log platform.
You understand which Sysmon event types are enabled in your configuration.
Reading Sysmon events locally
Sysmon writes events to the Windows Event Log. To view Sysmon logs, follow the steps:
Select the Start button, type Event viewer, and open Event viewer from the best match list.
In Event Viewer, go to Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.
Select an event and view its details.
Each event includes structured fields such as:
Event ID and name (for example, Process Create)
Process and parent process information
Command line
File paths
Network addresses and ports
Hashes and identifiers
Interpreting common Sysmon event types
Understanding the intent of each event type helps distinguish expected behavior from suspicious activity. The following lists the common Sysmon event types.
| Type | Indication | Look for |
|---|---|---|
| Process create | Indicates a process had started | Unusual parent-child relationships |
| Unexpected command-line arguments | ||
| Script engines or administrative tools running in non-administrative contexts | ||
| Network create | Indicates an outbound or inbound network connection initiated by a process. | Rare destination IP addresses or ports |
| Network activity from processes that typically do not communicate externally | ||
| Repeated connections to the same destination | ||
| File create | Indicates that a file was created or overwritten | Executables written to user-writable locations |
| Files created shortly after suspicious process execution | ||
| Image create | Indicates a dynamic link library (DLL) or executable image was loaded | Unsigned or unexpected modules |
| Rare DLL's loaded into commonly abused processes | ||
| Registry events | Indicate registry key or value changes | Modifications to autorun or persistence-related keys |
| Modifications to autorun or persistence-related keys | ||
| Changes occurring shortly after process creation events Sysmon configurations should be tuned over time to reduce noise while preserving useful signal |
Tune Sysmon configuration
Sysmon configurations should be tuned over time to reduce noise while preserving useful signal.
Identify high-volume events
Start by determining which Sysmon event types generate the most data in your environment. Use your log aggregation platform to summarize event counts by Event ID over a representative time period (for example, one to two weeks). Summarizing as such quickly reveals whether events such as ProcessCreate, NetworkConnect, ImageLoad, or FileCreate are contributing disproportionately to overall telemetry volume. High-volume events are not inherently problematic, but they are the primary candidates for tuning.
Review event counts by event type
Once high-volume event types are identified, analyze trends over time. Look for patterns such as spikes during system startup, user logon, software updates, or development workflows. Break down counts by host role (for example, developer workstation vs. domain controller) to understand whether certain systems naturally produce more telemetry. This helps avoid over-tuning based on activity that is expected only on specific device classes.
Identify processes or paths that generate excessive events
Within a high-volume event type, group and sort by relevant fields such as Image, CommandLine, TargetFilename, DestinationPort, or RegistryKey. Doing so typically reveals a few processes, file paths, or services responsible for most events. For example, a security agent may repeatedly access processes, or a development tool may generate frequent file creation events. Focus on identifying consistent, repeatable sources of noise rather than rare outliers.
Determine whether the activity is expected
Evaluate whether the identified behavior is legitimate and required for normal operations. Consult system owners or application teams if necessary. If the activity is expected and low-risk, consider adding narrowly scoped exclusion rules targeting the specific process, path, or condition responsible. Avoid disabling entire event categories or using overly broad string matches, as doing so can remove important investigative context. After applying changes, compare telemetry volumes before and after tuning to validate the impact and confirm that meaningful signals remain visible.
Apply include and exclude rules
Use filtering rules to focus on high-value activity.
Examples:
Exclude known benign processes from Network Connect events.
Include only specific file paths for File Create events.
Exclude common system DLLs from Image Load events.
Tip
Start with broader logging and gradually add exclusions rather than aggressively filtering early.