What Can Sysmon Actually See? My First Dive into SIEM Detection with Sysmon and Wazuh

colin monroe — Wed, 09 Sep 2026 21:10:29 +0000

1. Introduction

I wanted to answer a pretty simple question: what can Sysmon actually see? The answer, as I quickly learned, was basically, “a lot more than I expected.” My plan sounded simple enough: tune Sysmon on a Windows endpoint, generate some suspicious-looking activity, and then follow the evidence into Wazuh. Easy, right? Well... not exactly. Along the way, I learned that collecting logs is only half the battle. You also have to figure out what you're looking for, where you're supposed to look for it, and whether the logs are actually missing or you just ran your test on the wrong computer. Spoiler alert: I managed to do that last one. I'm still fairly new to cybersecurity, which is part of what made this project interesting. Before starting, I understood the basic idea behind Sysmon and SIEMs, but I had never really followed an event from the command line, into an endpoint log, and finally into a SIEM alert. That investigative side of cybersecurity is what keeps pulling me in. It feels a little like being a detective: create some activity, hunt down the evidence, and figure out what the logs are trying to tell you. Sometimes the mystery is suspicious activity. Sometimes the mystery is just, “Why is my event not showing up?” This project gave me a much better understanding of Sysmon and Wazuh, but it also taught me something I wasn't expecting: troubleshooting your own mistakes can sometimes teach you more than when everything works perfectly the first time.

2. Setup

For my modification, I decided to tune the existing Sysmon configuration on the Windows server ad01. Sysmon was already installed and collecting security telemetry, so instead of installing another tool, I wanted to understand how changing the configuration could affect what Sysmon records.

I started by confirming that Sysmon was running and checking its current configuration. The Sysmon executable was located at:

C:\Windows\Sysmon64.exe

The configuration file I worked with was:

C:\Users\Administrator\Downloads\sysmonconfig-export.xml

Before changing anything, I created a backup of the configuration. I also used the following command to review the active Sysmon configuration:

C:\Windows\Sysmon64.exe -c

While reviewing sysmonconfig-export.xml, I noticed that the ProcessCreate section used an exclusion-based configuration:

<ProcessCreate onmatch="exclude">

One of the exclusions caught my attention:

<Image condition="is">C:\Windows\system32\conhost.exe</Image>

Because conhost.exe was being excluded, I decided to remove that exclusion to see whether I could increase the process telemetry available to me. I documented my change directly in the XML file with the following comment:

A Result I Wasn't Expecting

This modification also gave me my first troubleshooting lesson. Before making the change, I ran:

cmd.exe /c "echo Sysmon pre-modification test"

Sysmon recorded the cmd.exe Process Create event, but I did not find a new conhost.exe event. I expected that removing the exclusion and repeating the test would cause conhost.exe telemetry to appear.

After modifying the configuration, I ran another test:

cmd.exe /c "echo Sysmon post-modification test"

I could still see the cmd.exe activity, but there was no new conhost.exe Process Create event. I checked the running processes and confirmed that several instances of conhost.exe already existed, but searching the recent Sysmon Event ID 1 records still did not produce the new event I expected.

This taught me to be more careful about how I interpret logging results. Sysmon Event ID 1 records process creation, so changing an exclusion does not retroactively create Process Create events for processes that were already running. My test also did not prove that a fresh conhost.exe process had been created. Instead of immediately assuming Sysmon was broken, I learned to check the configuration, process state, time range, and activity that actually occurred before reaching a conclusion.

3. Experiment Time!

Experiment #1: T1082 – System Information Discovery

For my first experiment, I tested MITRE ATT&CK T1082 – System Information Discovery. I wanted to see what Sysmon would record when Windows commands were used to gather information about the system.

I reviewed the Atomic Red Team T1082 test, which included commands such as:

systeminfo

and:

reg query HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum

After generating the activity on ad01, I searched the Sysmon Operational log. Sysmon Event ID 1 recorded Process Create events for systeminfo.exe and reg.exe. The events included information such as the command line, parent process, and user that executed the commands.

Finding the same activity in Wazuh was more difficult than I expected. My first searches for systeminfo.exe and reg.exe did not return the results I was looking for. This showed me that seeing an event locally in Sysmon does not always mean it will be easy to find in the SIEM with a simple search.

Experiment #2: T1057 – Process Discovery

For my second experiment, I tested MITRE ATT&CK T1057 – Process Discovery.

I selected an Atomic Red Team test that searches the Windows process list for lsass.exe. The test uses: tasklist | findstr lsass ### The Case of the Missing Logs This experiment gave me one of those troubleshooting moments that is funny after you figure it out. I ran the Atomic Red Team test, opened the Sysmon logs on ad01, and started searching. Nothing. So I widened the time range. Still nothing. I changed my searches. Nothing. For a minute, I was convinced something was wrong with the logging. Then I ran one extremely advanced cybersecurity command: hostname Mystery solved.

I had executed the Atomic Red Team test on student-host-windows and was searching for the evidence on ad01. Sysmon wasn't broken. Wazuh wasn't broken. I was just looking at the wrong computer. That mistake ended up teaching me one of the most useful lessons from the entire project: before diving into complicated troubleshooting, check the simple stuff first. Because Atomic Red Team was not installed directly on ad01, I reproduced the approved test command on the monitored endpoint: cmd.exe /c "tasklist | findstr lsass"

The command successfully located the running lsass.exe process. Sysmon Event ID 1 recorded Process Create events for both tasklist.exe and findstr.exe. The events also showed cmd.exe as the parent process and contained the command-line information from the experiment. I then searched Wazuh. Searching for tasklist and findstr alone did not initially return the event, so I used: data.win.system.providerName:"Microsoft-Windows-Sysmon" along with the agent.name: ad01 filter. This allowed me to locate the corresponding Wazuh telemetry. The event details showed findstr.exe, the command findstr lsass, and the parent command containing tasklist | findstr lsass. In the end, I found exactly what I was looking for—I just had to make sure I was looking on the right computer first.

Experiment #3: T1083 – File and Directory Discovery

For my third experiment, I tested MITRE ATT&CK T1083 – File and Directory Discovery. I reviewed Atomic Red Team test T1083-1, which uses Windows dir and tree commands to discover files and directories.

The commands searched several locations on the system and redirected the results to:

%temp%\T1083Test1.txt

When I generated the activity on ad01, I received a File Not Found message. At first, I thought the experiment might have failed. Instead of assuming it had failed completely, I checked for the output file.

T1083Test1.txt had actually been created and contained file and directory information collected from the Windows system. This showed that the command sequence still produced substantial discovery output even though part of it returned an error.

I then searched the Sysmon Operational log. Sysmon Event ID 1 recorded Process Create events for cmd.exe and tree.com. The cmd.exe event contained the discovery commands and the reference to T1083Test1.txt, while the tree.com event showed the tree /F command.

Finally, I searched Wazuh using:

data.win.system.providerName:"Microsoft-Windows-Sysmon"

with the agent.name: ad01 filter.

I found the corresponding telemetry in Wazuh. The document details showed C:\Windows\System32\cmd.exe and the command line containing the dir commands and T1083Test1.txt. PowerShell was also recorded as the parent process.

This was my favorite experiment because I was able to follow the activity from the command I executed, to Sysmon Event ID 1 on the endpoint, and finally into Wazuh. Seeing that entire path helped me understand how endpoint logging and a SIEM work together.

4. Conclusion

4.1 Summary of Experimental Findings

My three experiments helped me understand what Sysmon can capture and how that information can appear in Wazuh. In Experiment 1, T1082 System Information Discovery generated Sysmon Event ID 1 events for systeminfo.exe and reg.exe. Experiment 2, T1057 Process Discovery, generated Process Create events for tasklist.exe and findstr.exe, and I was also able to locate the activity in Wazuh. In Experiment 3, T1083 File and Directory Discovery generated events for cmd.exe and tree.com, including the command line used to enumerate files and directories. I was able to follow this activity from the command executed on ad01, to Sysmon, and finally into Wazuh.

Overall, these experiments showed me that Sysmon provides much more than just the name of a process. Information such as command lines, parent processes, users, and hashes can provide useful context when investigating activity.

4.2 Advice on Avoiding Mistakes

The biggest lesson I learned was to verify the basics before assuming something is broken. During my setup modification, I expected removing the conhost.exe exclusion to produce new telemetry, but my test did not prove that a new conhost.exe process had actually been created.

I made a similar mistake during Experiment 2 when I ran the Atomic Red Team test on student-host-windows but searched for the results on ad01. Running hostname helped me discover what had happened.

My advice is to verify the hostname, command, timestamp, Event ID, and search filters before troubleshooting the entire logging system. Also, if a command produces an error, check the actual results before assuming the whole experiment failed. Taking a few minutes to verify these details can save a lot of troubleshooting time.

5. Final Thoughts

5.1 The Coolest Thing I Learned

The coolest thing I learned during this project was how I could follow one action through different layers of security monitoring. Before this project, I understood the basic idea that Sysmon collects Windows activity and a SIEM collects logs, but actually seeing that happen made it much easier to understand.

My favorite example was the T1083 File and Directory Discovery experiment. I executed the discovery activity on ad01, found the Process Create activity in Sysmon Event ID 1, and then found the same command-line information inside Wazuh. Seeing cmd.exe, its parent process, and the discovery command show up in the SIEM made the whole process feel less abstract.

I also learned that logs provide much more context than I originally realized. Details like command lines, parent processes, users, timestamps, and hashes can help tell the story of what happened on a system.

5.2 One Piece of Advice

My biggest piece of advice to someone new to this type of project is to document everything as you go and always verify the basics before assuming something is broken.

I learned this the hard way when I ran an Atomic Red Team test on student-host-windows but searched for the activity on ad01. I spent time changing searches and increasing the time range before realizing I was simply looking at the wrong computer.

Commands like hostname might seem basic, but they can save a lot of troubleshooting time. I would also recommend recording the exact command you ran, the time you ran it, the endpoint, the expected Event ID, and the search filters you used. Those details make it much easier to work backward when something does not appear where you expect it.

5.3 My Favorite Resource

My favorite external resource during this project was Red Canary's Atomic Red Team. I discovered it through the project material while looking for ways to generate activity that I could investigate with Sysmon and Wazuh.

Atomic Red Team was especially useful because its tests are mapped to MITRE ATT&CK techniques. Instead of randomly running commands and hoping something interesting appeared in the logs, I could choose a specific technique, review what the test would do, generate the activity, and then investigate the results.

I used Atomic Red Team while working with T1082 System Information Discovery, T1057 Process Discovery, and T1083 File and Directory Discovery. It gave my experiments a clear purpose and helped connect what I was seeing in Sysmon and Wazuh with techniques used in cybersecurity. I can see myself using this resource again as I continue learning detection and security monitoring.

5.4 Thank You (Gratitudes)!

I want to thank Mark Russinovich and Thomas Garnier for their work on Sysmon and its documentation. Sysmon was at the center of this project, and the documentation helped me understand what the different events contained and how process activity could be investigated.

I also want to thank Carrie Roberts and the Atomic Red Team community for their work maintaining Atomic Red Team and its learning resources. Atomic Red Team gave me a practical way to generate activity instead of only reading about MITRE ATT&CK techniques. Being able to run a test and then search for the evidence made these concepts much easier for me to understand.

Projects and documentation like these are especially helpful for someone new to cybersecurity because they make it possible to learn by actually experimenting instead of only reading theory.

6. References

1. Sysmon v15.21

Authors: Mark Russinovich and Thomas Garnier

Affiliation: Microsoft Sysinternals

Published: June 17, 2026

Resource: Sysmon - Sysinternals | Microsoft Learn

This resource helped me understand how Sysmon monitors Windows activity and what information is recorded by different Sysmon Event IDs. I used it during my configuration modification and when investigating Process Create events during my experiments.

2. Atomic Red Team

Author/Organization: Red Canary

Affiliation: Red Canary

Published: No publication date listed

Resource: Atomic Red Team

Atomic Red Team was one of the most useful resources in my project because it provides reproducible tests mapped to MITRE ATT&CK techniques. I used its tests as the basis for generating T1082, T1057, and T1083 discovery activity that I could investigate with Sysmon and Wazuh.

3. T1082 – System Information Discovery

Author/Organization: MITRE ATT&CK

Affiliation: The MITRE Corporation

Last Modified: May 12, 2026

Resource: T1082 – System Information Discovery

This resource helped me understand what System Information Discovery means and why an attacker may collect operating system and hardware information. I used T1082 as the basis for my first experiment involving systeminfo and registry queries.

4. T1057 – Process Discovery

Author/Organization: MITRE ATT&CK

Affiliation: The MITRE Corporation

Last Modified: May 12, 2026

Resource: T1057 – Process Discovery

This resource helped me understand how attackers can discover processes running on a system. I used T1057 for my second experiment, where I generated tasklist and findstr activity and investigated the resulting telemetry in Sysmon and Wazuh.

5. T1083 – File and Directory Discovery

Author/Organization: MITRE ATT&CK

Affiliation: The MITRE Corporation

Last Modified: May 12, 2026

Resource: T1083 – File and Directory Discovery

This resource helped me understand how file and directory enumeration fits into the Discovery tactic. I used T1083 for my third experiment, where dir and tree commands generated activity that I investigated locally with Sysmon and then in Wazuh.

DEV Community: colin monroe