Learn what Sysmon is, how to install and configure it, and how to forward logs to SIEM tools like Splunk, ELK, and Wazuh. This complete Sysmon guide covers event IDs, tuning configs, and best practices for Windows security monitoring.

What is Sysmon?

Sysmon (System Monitor) is a Windows system service and kernel driver developed by Microsoft as part of the Sysinternals Suite (a collection of advanced system utilities).

It is not included by default in Windows — you have to download it from Microsoft’s Sysinternals site. https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

Once installed, Sysmon runs as a persistent background service, continuously monitoring the system and recording detailed, high-value security and operational events into the Windows Event Log. Sysmon does not need to be re-run manually every time you reboot. It starts automatically with Windows, ensuring continuous monitoring. Even if the computer is restarted, Sysmon keeps its logs so security teams can see the full history of what happened.

Accessing Sysmon Logs:

The logs are stored in the Windows Event Log under Applications and Services Logs ➝ Microsoft ➝ Windows ➝ Sysmon ➝  Operational.

What does “Sysmon is a Windows system service and kernel-mode driver” mean?

  • System Service:
    • Sysmon installs as a Windows service that runs in the background.
    • Services start automatically with Windows and don’t require a logged-in user.
    • This means Sysmon is always active, monitoring from the moment the system boots.
  • Kernel-Mode Driver:
    • The driver component integrates deeply into the Windows kernel.
    • This allows Sysmon to observe low-level system activity (like process creation, file writes, registry modifications, or network connections) that might not be visible to user-mode applications.
    • Because it runs at the kernel level, it’s harder for malware to hide from it.

What Sysmon Records (Event IDs):

Complete list of Sysmon event IDs and their descriptions can be found here: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

Sysmon produces rich event logs, with each event having its own Event ID. Some key ones include:

  • Process and Executable Monitoring
    • Event ID 1: Process creation (with full command line, hashes, parent process, integrity level)
    • Event ID 5: Process termination
    • Event ID 7: Image loaded (DLLs and drivers)
  • Network Activity
    • Event ID 3: Network connection (source/destination IP, ports, protocol, process)
    • Event ID 22: DNS query logs
  • File and Registry Monitoring
    • Event ID 11: File creation (including hashes)
    • Event ID 13: Registry value set
    • Event ID 14: Registry key and value rename
  • System & Miscellaneous
    • Event ID 6: Driver load
    • Event ID 12: Registry object added/deleted
    • Event ID 15: File stream creation
    • Event ID 21: WMI event (useful for detecting persistence techniques)

Real SOC Use Cases:

When SOC teams actually put Sysmon to work, it’s less about generating pretty dashboards and more about catching the weird little things that slip past default Windows logging. The tool gives analysts just enough detail to connect events that—on their own—look harmless, but together may suggest something’s off. A few common scenarios:

PowerShell abuse (Event ID 1 & 3)

Attackers love PowerShell because it’s already trusted on Windows systems. By watching process creation logs (ID 1) alongside network connections (ID 3), analysts can spot oddball scripts that suddenly start reaching out to the internet. One red flag I’ve seen is PowerShell quietly spawning a process to fetch a payload from an IP that’s never been touched before.

Persistence via registry changes (Event ID 13 & 14)

Malware that wants to stick around often tampers with Run or RunOnce keys. Sysmon logs those registry modifications in detail, so a tuned rule set can highlight when a new autorun entry shows up unexpectedly. It’s not perfect—some admin tools legitimately touch those keys—but it narrows the haystack.

Credential dumping (Event ID 10 + LSASS access)

If something suddenly tries to access LSASS, you should probably pay attention. Sysmon’s process access events (ID 10) correlated with known attack tools like Mimikatz give SOC analysts an early heads-up that credentials may be under attack. Of course, false positives do happen—legit software sometimes pokes LSASS too—but the context often tells the story.

Lateral movement (Event ID 3 + 22)

Unusual RDP or SMB sessions, paired with DNS lookups for never-before-seen hosts, can be a strong hint that someone’s moving sideways across the network. Sysmon surfaces both the network connections and the DNS queries, which means analysts can piece together activity that would otherwise look like routine traffic.

Sysmon Tuning Tips (SOC edition):

Out of the box, Sysmon is noisy—so noisy it can bury your SIEM under millions of events a day. Most SOC teams end up spending more time tuning than deploying. A few common approaches (and some caveats) stand out:

  • Exclude the obvious → Skip security tools, patch agents, backup software. No one needs endless Defender logs.

  • Hash smart, not everything → Focus on .exe, .dll, .ps1, .js. Full-file hashing sounds good but wastes cycles.

  • Watch the sketchy dirs → AppData, Temp, Startup. That’s where attackers love to hide.

  • Modular configs → Start with SwiftOnSecurity’s base, then add Olaf Hartong’s modules for registry, WMI, network.

Without tuning, Sysmon is just noise. With tuning, it’s one of the best free visibility tools you’ll ever deploy.

Sysmon vs Windows Event Viewer:

When it comes to monitoring Windows activity, a lot of admins still turn to Event Viewer. It does the job for routine auditing or troubleshooting, but it wasn’t really built with modern threat detection in mind. Event Viewer is fine for auditing or troubleshooting — it logs app, security, and system events. But for threat hunting, it often falls short.

  • Detail matters: Event Viewer might say “process created.” Sysmon adds hashes, command-line args, parent–child process chains, and even network metadata. That’s what lets you catch things like PowerShell quietly spawning cmd.exe.

  • Correlation counts: Attacks unfold as a series of small steps. Sysmon gives the context to connect them — persistence tweaks, odd registry changes, strange outbound traffic.

  • Consistency helps: Windows event IDs vary by version. Sysmon’s are stable, which makes writing rules across machines far easier.

  • Built for security ops: Sysmon logs plug neatly into SIEMs (Splunk, ELK, Sentinel), powering alerts and detections. Event Viewer isn’t designed for that.

Event Viewer still has its place — quick checks, compliance audits. But for defenders trying to spot the weird stuff before it becomes a breach, Sysmon is usually the better tool.

 

Sysmon Installation & Configuration:

Step 1. Prepare a Configuration File (before install)

Why: If you install Sysmon straight out of the box with raw switches like -h -l -n, you’ll quickly realize it logs everything. A config (sysmonconfig.xml) tells Sysmon exactly what to log and what to ignore.

Step 2. Download Sysmon

  • Download the official Sysmon from Microsoft.
  • Extract it into C:\Tools\Sysmon.
  • Use sysmon64.exe if you’re on a 64-bit machine.

💡 Tip: Keep Sysmon binaries in a version-controlled repo or central share for easy redeployment.

Step 3. Install Sysmon with Config

Keep the sysmonconfig.xml in the C:\Tools\Sysmon

Run in Command Prompt (Run as Administrator):

cd C:\Tools\Sysmon

sysmon64.exe -accepteula -i sysmonconfig.xml

What happens:

  • Installs Sysmon as a persistent service.
  • Immediately starts logging per your XML config.
  • Survives reboots automatically.

💡 Tip: Always use the config on first install. Don’t rely on command-line switches unless you’re just testing.

Command Explanation: sysmon64.exe -accepteula -i sysmonconfig.xml

  • -accepteula
    Automatically accepts the Sysinternals license so you aren’t prompted.
  • -i
    Installs Sysmon as a persistent service and driver.
  • sysmonconfig.xml
    Argument to the -i switch. This is the configuration file Sysmon loads during install.
    (Defines what events to log, what to filter, and what hashing algorithms to use.)

Other Switches You Can Use (Optional):

  • -h md5,sha256,imphash → Enable hashing of executables with MD5, SHA256, and imphash.
  • -l → Log DLL loads (Event ID 7).
  • -n → Log network connections (Event ID 3).

Step 4. Verify Installation

  • Check service status:
sc query sysmon64

Check logs in Event Viewer:
Applications and Services Logs → Microsoft → Windows → Sysmon → Operational

At this point, Sysmon is fully installed and running.
It will persist across reboots and continuously collect logs based on your configuration.

Sysmon Maintenance & Future Updates

The following steps are not required for initial installation. They cover tuning, updating, and managing Sysmon after it’s already installed.

Updating Sysmon Config (No Reinstall Needed)

If you need to refine logging later:

sysmon64.exe -c updatedconfig.xml
  • Replaces current config live.
  • No service restart or reinstall required.
  • Old logs remain intact.

💡 Tip: Keep configs in Git and document changes — helps track tuning decisions and revert mistakes.

Updating Sysmon.exe with a Fresh Download

Here’s the safe workflow:

  1. Delete or move the old folder (e.g., C:\Tools\Sysmon).
  2. Download the new Sysmon zip from Microsoft.
  3. Extract it into a newly created folder, e.g.: C:\Tools\Sysmon
  4. Copy the sysmonconfig.xml in the C:\Tools\Sysmon
  5. Open an elevated command prompt in that folder.
  6. Run the update:
sysmon64.exe -u

sysmon64.exe -accepteula -i sysmonconfig.xml

This ensures you’re using the fresh binary directly from the new folder.

Sysmon Uninstall (If Needed)

sysmon64.exe -u
  • Removes the Sysmon service and driver.
  • Does not delete old logs — they remain in Event Viewer until cleared.

💡 Tip: Before uninstalling in production, export logs for retention (forensics, compliance).

What happens if you delete C:\Tools\Sysmon?

Once installed, Sysmon copies its driver and service files into C:\Windows\System32 and registers itself as a service. It doesn’t run from the tools folder. So if you delete C:\Tools\Sysmon, Sysmon keeps running just fine. The only catch: you’ll need the executable again later if you want to update or change configs.

 

Forwarding Sysmon Logs to SIEM:

Sysmon logs are most valuable when centralized. Forward logs from endpoints to your SIEM:

  • Wazuh, Splunk, Elastic/ELK, Sentinel, QRadar, etc.
  • Collect from Microsoft-Windows-Sysmon/Operational.

When you install Sysmon, it creates its own log channel called Microsoft-Windows-Sysmon/Operational, where Sysmon writes all its events such as process creation, network connections, and file changes. A Windows Event Log channel is a logical container (or stream) within the Windows Event Log system where events from a specific source are recorded.

Open PowerShell as admin and run Get-WinEvent -ListLog *sysmon* — you’ll see Microsoft-Windows-Sysmon/Operational, the channel name to use in automation and SIEM tools.

Sysmon Log Forwarding to Wazuh:

In your ossec.conf (Wazuh agent side), add:

<localfile>
  <log_format>eventchannel</log_format>
  <location>Microsoft-Windows-Sysmon/Operational</location>
</localfile>

 

Check that events reach the Wazuh Manager:

  • On the Wazuh server side, search in your Wazuh dashboard for events with:
  • data.win.system.providerName: “Microsoft-Windows-Sysmon”

Best Practices for SOC Teams:

  • Start with a baseline config, then tune for your environment.
  • Use Sysmon events + MITRE ATT&CK mapping for detection rules.
  • Avoid logging “everything” → prevents SIEM overload.
  • Pair with Windows native logs for full coverage.

Troubleshooting & FAQs:

  • Q: Does Sysmon replace an EDR in a SOC?
    No. Sysmon only produces detailed telemetry. Most SOCs use it alongside an EDR and SIEM for context in investigations.
  • Q: How does Sysmon help with threat hunting?
    By logging key signals (process creation, registry edits, DNS queries). For example, pairing Event ID 1 (process create) with Event ID 3 (network) can reveal a malicious PowerShell script calling out to an unknown IP.
  • Q: Can I forward Sysmon logs to Wazuh or a SIEM?
    Yes. Point Wazuh at the Microsoft-Windows-Sysmon/Operational channel (via <localfile> in ossec.conf). Sysmon logs can also be forwarded to SIEMs like Splunk, ELK, Sentinel, or QRadar for correlation across endpoints.
  • Q: What’s the best Sysmon config for SOC teams?
    There’s no universal config. Most SOCs start with SwiftOnSecurity or Olaf Hartong’s configs, then tune for their environment by excluding noisy processes and monitoring high-risk directories.
  • Q: Isn’t Sysmon too noisy for SIEM ingestion?
    It can be if installed without a config. Tuning solves this: exclude trusted processes, hash only executables/scripts, and focus on attacker-friendly paths like AppData or Temp.
  • Q: Does Sysmon integrate with MITRE ATT&CK?
    Yes. Wazuh and other SIEMs map Sysmon events to ATT&CK techniques (persistence, credential dumping, defense evasion), giving SOC teams detection coverage out of the box.
  • Q: Can Sysmon detect lateral movement?
    On its own, no. But in a SIEM, correlating Event ID 3 (network) and Event ID 22 (DNS) across hosts can reveal RDP/SMB lateral movement.
  • Q: How do I check if Sysmon is running and logging?
    Run: sc query sysmon64
    If the state shows RUNNING, it’s active. Confirm logs in Event Viewer: Microsoft-Windows-Sysmon/Operational.
  • Q: Do I need to restart Sysmon after a reboot?
    No. Sysmon registers as a persistent Windows service and starts automatically with the OS.
  • Q: How do I uninstall Sysmon safely?
    Run: sysmon64.exe -u
    This removes the service and driver but leaves logs in Event Viewer until cleared. Export logs first for retention.

 

Conclusion:

Sysmon might look like “just more logs,” but tuned properly it’s one of the most powerful free tools for Windows visibility. Paired with a SIEM like Splunk, ELK, Wazuh, or Sentinel, it helps SOC analysts catch persistence tricks, malware behavior, and lateral movement that native logs almost always miss. The catch? Without good configs and ATT&CK mapping, it’s just noise. With them, it becomes a cornerstone of threat hunting and DFIR.