How to Install and Configure Sysmon: Step-by-Step Sysmon Tutorial

Prerequisites and Expected Outcomes

This sysmon tutorial walks you through installing, configuring, and verifying Microsoft Sysinternals System Monitor on a Windows endpoint. When you complete this guide, you will have an active Sysmon service running as a protected boot-start driver. It will log enriched endpoint events directly to the Windows event log, ready for analysis in Windows Event Viewer or export to a security information and event management platform.

Before starting, you need an administrative account on a physical or virtual machine running Windows 10, Windows 11, or Windows Server. You also need access to an elevated command prompt or administrative PowerShell console. If you are building detection engineering skills in an isolated testing environment such as a SOC detection home lab, this tutorial provides the foundational telemetry layer you need to observe malicious activities safely.

Understanding Core Sysmon Telemetry and Event IDs

Standard Windows Security event logs provide baseline auditing, but they often lack critical context such as full command lines or file hashes. While security analysts rely on essential Windows security event IDs for basic auditing, Sysmon provides a deeper layer of host visibility. According to the Microsoft Sysinternals Sysmon documentation, Sysmon logs activity to a dedicated channel located at Applications and Services Logs/Microsoft/Windows/Sysmon/Operational, recording all event timestamps in UTC standard time.

Event ID 1 records process creation events. Unlike standard process auditing, Sysmon Event ID 1 includes the complete command line for both the child process and the parent process. It records process file hashes using algorithms such as SHA256, MD5, SHA1, or IMPHASH. Crucially, it records a ProcessGUID. Because the operating system repeatedly reuses numeric Process IDs, the ProcessGUID provides a unique identifier across the lifetime of the operating system, allowing analysts to trace execution trees reliably.

Event ID 2 tracks changes to file creation times, which helps analysts identify timestomping attempts where attackers backdate files to blend into system directories. Event ID 3 logs TCP and UDP network connections, attributing remote IP addresses, ports, and hostnames directly to the responsible ProcessGUID. Event ID 4 logs changes to the state of the Sysmon service itself, alerting analysts if an unauthorized actor or service issue halts monitoring.

Designing a Balanced Sysmon XML Configuration

Sysmon operates using an XML configuration schema that specifies which events to log, which hashing algorithms to run, and which filters to apply. An unfiltered Sysmon installation logs an overwhelming volume of events, rapidly filling local event log buffers and exhausting SIEM ingestion budgets. By applying schema-compliant XML rules, detection engineers can selectively include suspicious patterns while excluding known, high-volume legitimate background processes.

A typical configuration begins with the Sysmon root tag, specifying the schema version. The HashAlgorithms tag defines which cryptographic hashes Sysmon calculates during file and process events; SHA256 and IMPHASH are common choices. Within the EventFiltering tag, individual rules target specific Event IDs. The onmatch attribute dictates whether the rule behaves as an allowlist (include) or a denylist (exclude) per the official schema described in the Microsoft Sysinternals Sysmon documentation.

Tuning requires a balance between visibility and noise. For example, when monitoring for adversary execution techniques documented in the MITRE ATT&CK framework, you want detailed visibility into script interpreters such as PowerShell or Windows Command Shell. If you investigate scenarios like suspicious encoded PowerShell execution, capturing the full command line and parent process information is critical.

<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms>
  <CheckRevocation />
  <EventFiltering>
    <RuleGroup name="ProcessCreation" groupRelation="or">
      <ProcessCreate onmatch="exclude">
        <Image condition="is">C:\Windows\System32\audiodg.exe</Image>
      </ProcessCreate>
    </RuleGroup>
    <RuleGroup name="NetworkConnections" groupRelation="or">
      <NetworkConnect onmatch="include">
        <Image condition="is">powershell.exe</Image>
        <Image condition="is">cmd.exe</Image>
      </NetworkConnect>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Installing and Managing the Sysmon Service

Sysmon uses a straightforward command-line interface for deployment, updates, and maintenance. To install Sysmon for the first time, you run the 64-bit executable sysmon64.exe with administrative privileges. The -i flag instructs the installer to install the device driver and system service, while the -accepteula switch suppresses the interactive license prompt, making the command suitable for automated deployment scripts.

The installer does not require a system reboot. Sysmon installs as a boot-start driver, allowing it to capture telemetry early during subsequent system start cycles before user-space processes initialize. If you already have Sysmon installed and want to update its filtering logic without stopping the driver, use the -c parameter followed by the path to the updated XML configuration file. The -c parameter updates the configuration of an installed Sysmon driver without requiring a service restart. To view the running configuration at any time, execute sysmon64.exe -c without additional arguments.

Sysmon includes maintenance commands to view its supported schema and remove the service. Running sysmon64.exe -s prints the configuration schema supported by that binary version, which helps you verify valid XML tags and filter attributes. When decommissioning a system or resetting a test host, running sysmon64.exe -u uninstalls both the service and the driver cleanly without requiring a restart.

:: Install Sysmon with a custom configuration file
sysmon64.exe -accepteula -i C:\Tools\Sysmon\sysmonconfig.xml

:: Update configuration on a running Sysmon installation without restarting
sysmon64.exe -c C:\Tools\Sysmon\sysmonconfig.xml

:: Dump the currently active configuration
sysmon64.exe -c

:: Uninstall the Sysmon service and device driver
sysmon64.exe -u

Verifying Telemetry and Troubleshooting Issues

Once Sysmon is installed, you must verify that the driver is functioning and writing events to the operational log. Open Windows Event Viewer, expand Applications and Services Logs, navigate to Microsoft, then Windows, and locate Sysmon/Operational. You should immediately observe Event ID 4, indicating that the Sysmon service state changed to started, followed by Event ID 1 entries as the operating system launches background processes.

To test event generation intentionally, launch a command prompt and run a standard reconnaissance command, or initiate an outbound web request using PowerShell. Refresh the Event Viewer console and inspect the most recent Event ID 1 entry. Confirm that the ParentCommandLine, CommandLine, Hashes, and ProcessGuid fields are populated accurately according to the rules defined in your configuration file.

If no events appear in the operational log, begin troubleshooting by verifying the service status. Run sc.exe query sysmon64 from an elevated command prompt to verify that the service state is RUNNING. If the service is stopped, check the System event log for service launch errors. If the service is running but events are missing, run sysmon64.exe -c to ensure your XML exclude rules are not inadvertently dropping legitimate test processes.

Integrating Sysmon into Detection Engineering Workflows

Sysmon is a telemetry source, not an automated alert engine. In an enterprise security operations center or detection engineering pipeline, Sysmon events are forwarded to a centralized SIEM or data lake using Windows Event Forwarding or dedicated log collection agents. Once centralized, detection engineers write search queries that correlate Sysmon fields across multiple endpoints.

The unique ProcessGUID field makes root cause analysis straightforward. When an analyst identifies a suspicious network connection under Event ID 3, they search for the matching ProcessGUID under Event ID 1 to pinpoint the exact binary, command-line arguments, parent process, and file hash responsible for the traffic. This level of detail eliminates the ambiguity often encountered when investigating shared process names like svchost.exe or rundll32.exe.

When engineering detection rules, focus on high-fidelity indicators such as unusual parent-child process relationships, script engines executing out of temporary directories, or non-browser binaries establishing external network connections. Tuning your Sysmon XML to capture these patterns provides the foundation for resilient host-based threat hunting.