Modern attackers work hard to avoid detection. They use trusted tools, legitimate accounts, and built-in Windows utilities to blend into normal activity. Traditional antivirus software and automated detection rules can identify many threats, but they cannot detect every attack. Security teams must also search for attacker behavior that does not generate an alert.
This process is called threat hunting.
Threat hunting is a proactive security activity. Instead of waiting for an alert, analysts develop a hypothesis about attacker behavior and search for evidence across available telemetry. The quality of the hunt depends on the quality of the available data.
For Windows environments, few telemetry sources provide more value than Microsoft Sysmon.
What Is Sysmon?
Sysmon, short for System Monitor, is a free utility from Microsoft Sysinternals. It installs as a Windows service and records detailed system activity in the Microsoft-Windows-Sysmon/Operational event log.
Unlike Windows Security logs, Sysmon focuses on endpoint activity that is valuable during investigations. It records detailed information about processes, files, network connections, registry changes, and other operating system events.
Sysmon does not prevent attacks. It improves visibility. This visibility allows analysts to reconstruct attacker activity and understand what occurred on a system.
Why Sysmon Matters
Threat hunting depends on context. An analyst needs to know not only that a process executed, but also how it executed, who started it, what command-line arguments it used, and what it did next.
Sysmon provides this context.
For example, Sysmon can record:
– Process creation and parent-child process relationships.
– Full command-line arguments.
– Network connections initiated by a process.
– Registry modifications.
– File creation and deletion.
– Process injection activity.
– DNS queries.
– Driver loading.
– DLL loading.
This information allows analysts to build a timeline of attacker activity instead of investigating isolated events.
The Most Important Sysmon Events
Sysmon records many event types. Some events provide more value during threat hunting than others.
Event ID 1 – Process Creation
Process creation is the foundation of most endpoint investigations.
This event records:
– Executable name.
– Full command line.
– Parent process.
– User account.
– Process identifier.
– File hashes.
Many attack techniques begin with process execution. Examples include malicious PowerShell commands, Living-off-the-Land Binaries (LOLBins), and custom malware.
A threat hunter should understand normal process execution before searching for abnormal behavior.
Event ID 3 – Network Connections
This event records outbound network connections.
It identifies:
– Destination IP address.
– Destination port.
– Network protocol.
– Initiating process.
Attackers eventually need to communicate with another system. Reviewing unexpected network connections often reveals command-and-control traffic, malware downloads, or data exfiltration.
Event ID 10 – Process Access
Credential theft frequently requires one process to access another process.
Event ID 10 records these interactions.
One common example is access to LSASS, which stores authentication information in memory.
Legitimate software can access LSASS, including security products and backup software. Analysts should investigate the source process before reaching a conclusion.
Event ID 13 – Registry Value Set
Attackers often create persistence by modifying the Windows Registry.
This event records registry value modifications and helps identify:
– Startup entries.
– Service configuration changes.
– Security setting modifications.
– Persistence mechanisms.
Registry activity becomes much more valuable when correlated with process creation events.
Event ID 22 – DNS Query
Most malware performs DNS lookups before establishing network communication.
DNS telemetry can reveal:
– Rare domains.
– Dynamic DNS providers.
– Algorithmically generated domains.
– Suspicious subdomain patterns.
A single DNS query does not confirm malicious activity. It provides additional context that supports an investigation.
Threat Hunting with Sysmon
Threat hunting begins with a hypothesis.
For example, an analyst might believe an attacker used PowerShell to execute a malicious script.
The investigation begins by reviewing PowerShell process creation events. The analyst examines the command line, parent process, execution time, and user account. If the process connects to an external IP address, the investigation expands to include network telemetry. If the process modifies the registry, the analyst reviews registry events. Each event builds a more complete picture of system activity.
This approach differs from alert-driven investigations.
Instead of reacting to a detection, the analyst follows evidence until the activity is understood.
Focus on Behavior
Many threat hunters search for indicators of compromise, such as file hashes or IP addresses. These indicators are useful, but they have limitations. Attackers can replace a file or change an IP address in minutes.
Behavior is much harder to change.
An attacker still needs to execute code, establish persistence, communicate with external systems, and achieve their objectives.
For this reason, experienced threat hunters focus on behavior rather than individual indicators.
Questions such as these often produce better results:
– Which Office applications started PowerShell?
– Which administrative tools connected to the Internet?
– Which unsigned executables launched from temporary folders?
– Which processes accessed LSASS?
– Which systems communicated with a destination that no other device contacted?
Behavior-based hunting remains effective even when attackers change their infrastructure.
Build a Strong Sysmon Configuration
A default Sysmon configuration records a large amount of data. This data can quickly become difficult to manage.
Most organizations begin with a community-maintained configuration and adjust it to match their environment.
A good configuration balances visibility with performance.
Too many exclusions reduce visibility. Too few exclusions create unnecessary noise.
Review the configuration regularly. New attacker techniques require new telemetry.
Correlate Multiple Data Sources
Sysmon should not operate alone.
Combine Sysmon telemetry with:
– Windows Security logs.
– Endpoint detection and response platforms.
– Identity logs.
– Firewall logs.
– DNS logs.
– Proxy logs.
– Cloud audit logs.
Correlation improves confidence and reduces false positives.
An isolated event may appear suspicious. Multiple data sources often reveal the complete story.
Best Practices
Use these practices when threat hunting with Sysmon:
– Deploy a consistent configuration across all Windows systems.
– Record full command-line arguments whenever possible.
– Collect file hashes to support investigations.
– Hunt for attacker behavior instead of individual indicators.
– Validate findings with multiple data sources.
– Document each hunt, even when no malicious activity is found.
– Convert successful hunts into new detection rules.
– Review and update the Sysmon configuration as attacker techniques change.
Conclusion
Sysmon is one of the most valuable telemetry sources for Windows threat hunting. It provides detailed endpoint visibility that standard Windows logging does not provide. This visibility allows analysts to identify suspicious behavior, investigate complex attacks, and improve detection coverage.
Threat hunting is not about finding alerts. It is about finding activity that should have generated an alert but did not. Sysmon provides the data needed to perform that work effectively.
A well-configured Sysmon deployment, combined with a structured threat hunting process, gives security teams better visibility into their environment and increases their ability to detect sophisticated attackers before they achieve their objectives.
Killian Sherer 