From Setup to Signal: Building My First Wazuh SIEM with Sysmon and Atomic Red Team

Introduction

Setting up a SIEM sounds simple until you have to prove that it is actually seeing what you think it is seeing. For this project, I added Wazuh and Sysmon monitoring to an Atomic Red Team workstation, then used safe attack simulations to trace activity from the Windows endpoint into the SIEM.

Two of my experiments produced clear, matching evidence in Sysmon and Wazuh. A third showed something equally useful: Sysmon recorded the activity locally, but I could not find a matching Wazuh alert. That gap taught me that installing a logging tool is only the beginning. Detection coverage has to be tested, not assumed.

My name is Christopher Bontempi, and I am transitioning into cybersecurity because I enjoy problem-solving, continuous learning, and figuring out how systems fit together. This is my first contribution to the cybersecurity community. I hope it helps another beginner see how a collection of logs can become a useful story about what happened on a system.

Setup

Adding ART Workstation to Wazuh

I chose ART Workstation for this project because it already had Atomic Red Team installed. That gave me a safe Windows endpoint where I could generate controlled activity without changing the Active Directory server.

From the Wazuh dashboard on Blue-Team Workstation, I generated a Windows agent deployment for the Wazuh manager at 10.170.0.99. I named the agent ARTWorkstation and assigned it to the default and Windows_Servers groups.

On ART Workstation, I ran Wazuh’s generated installer command from an elevated PowerShell window, then started the service:

NET START WazuhSvc

Wazuh showed ARTWorkstation as active with agent ID 008 and IP address 10.160.0.100. At that point, I knew the endpoint could communicate with the SIEM, but I still needed useful Windows telemetry to validate the rest of the project.

Installing Sysmon and forwarding its logs

Next, I downloaded Sysmon and Neo23x0’s sysmonconfig-export.xml baseline configuration. I installed Sysmon64 from an elevated PowerShell window with:

& "$env:USERPROFILE\Downloads\Sysmon\Sysmon64.exe" -accepteula -i "$env:USERPROFILE\Downloads\sysmonconfig-export.xml"

Sysmon confirmed that the XML configuration was valid and started successfully. I then edited the Wazuh agent configuration file at C:\Program Files (x86)\ossec-agent\ossec.conf so it would collect Sysmon’s Operational event channel:

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

After saving the change, I restarted the Wazuh service:

Restart-Service -Name wazuh

A small mistake that improved my workflow

To make sure the new logging path really worked, I ran the harmless hostname command. Event Viewer showed a Sysmon Event ID 1 Process Creation event with the command line, UTC timestamp, and ProcessGuid.

At first, I searched Wazuh Discover for HOSTNAME.EXE and got no useful results. I briefly thought the forwarding had failed. The event was actually there—I found it by filtering for agent.name: ARTWorkstation and data.win.system.eventID: 1, then matching the timestamp and ProcessGuid to the local Sysmon record.

That was a useful early lesson for me: SIEM investigations work much better when I use structured fields instead of relying only on free-text searches. It also reminded me to account for Sysmon’s UTC timestamps when comparing them with the local time shown elsewhere in the lab.

Experiment Time!

Experiment 1: Creating a scheduled task with Atomic Red Team

For my first experiment, I used Atomic Red Team technique T1053.005 — Scheduled Task/Job: Scheduled Task, Test #2. This test creates a one-time scheduled task named spawn that runs cmd.exe.

Before running the test, I reviewed its details, checked that the prerequisites were met, and recorded my start time. Then I ran:

Invoke-AtomicTest T1053.005 -TestNumbers 2

The test created the task successfully. Sysmon recorded the activity locally as Event ID 1, a Process Creation event. The important command line was:

SCHTASKS /Create /SC ONCE /TN spawn /TR C:\windows\system32\cmd.exe /ST 20:10

The local Sysmon record showed:

• UtcTime: 2026-07-31 04:39:36.462

• ProcessGuid: {37a7a3ca-2708-6a6c-3127-000000006800}

On Blue-Team Workstation, I used Wazuh Discover to filter for agent.name: ARTWorkstation and Sysmon Event ID 1. I found the corresponding event with the same scheduled-task command and ProcessGuid.

Wazuh created an alert, but it classified the behavior as T1059.003 — Windows Command Shell instead of the more specific scheduled-task technique. That result still mattered: the evidence was present, even though the MITRE mapping did not exactly match the Atomic Red Team technique I ran.

Finally, I cleaned up the test:

Invoke-AtomicTest T1053.005 -TestNumbers 2 -Cleanup

I verified cleanup by running:

schtasks /Query /TN spawn

The message saying the task could not be found confirmed that the spawn task had been removed.

Experiment 2: Adding a Registry Run key with Atomic Red Team

For my second experiment, I used T1547.001 — Registry Run Keys / Startup Folder, Test #1. This technique simulates persistence by adding a Registry value that Windows would execute at the next user logon.

Before running the test, I checked the prerequisites and confirmed that the Atomic Red Team value was not already present in the current user’s Run key. I then ran the test with Calculator as the harmless executable:

Invoke-AtomicTest T1547.001 -TestNumbers 1 -InputArgs @{command_to_execute = 'C:\Windows\System32\calc.exe'}

The test completed successfully. I verified that the Registry value existed with:

reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Atomic Red Team"

The query showed that Atomic Red Team pointed to C:\Windows\System32\calc.exe.

On ART Workstation, Sysmon recorded a Registry value set event, Event ID 13. The important evidence was:

• UtcTime: 2026-08-01 01:56:15.211

• ProcessGuid: {37a7a3ca-523f-6a6d-2128-000000006800}

• TargetObject: HKU\...\CurrentVersion\Run\Atomic Red Team

• Details: C:\Windows\System32\calc.exe

In Wazuh Discover, I found one matching alert. Wazuh correctly mapped it to T1547.001 and described it as a Registry entry that would be executed on the next logon being modified by reg.exe.

This was the clearest end-to-end detection in the project: the local event, the Wazuh alert, and the ATT&CK mapping all described the same persistence behavior.

I cleaned up the test with:

Invoke-AtomicTest T1547.001 -TestNumbers 1 -Cleanup

A second Registry query returned an error saying the value could not be found, confirming that the persistence artifact had been removed.

Experiment 3: Creating a Startup-folder shortcut with Atomic Red Team

For my final experiment, I stayed with T1547.001 — Registry Run Keys / Startup Folder, but used Test #7: Add Executable Shortcut Link to User Startup Folder. This test creates a harmless shortcut named calc_exe.lnk in the current user’s Startup folder and points it to Calculator.

Before starting, I checked that the shortcut did not already exist. I then ran:

Invoke-AtomicTest T1547.001 -TestNumbers 7

The test completed successfully, and a follow-up check confirmed that calc_exe.lnk existed in the Startup folder.

Sysmon recorded the shortcut creation locally as Event ID 11, File Create. The key evidence was:

• UtcTime: 2026-08-01 02:26:01.491

• TargetFilename: C:\Users\administrator.MEGAQUAGGAAD01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\calc_exe.lnk

• CreationUtcTime: 2026-08-01 02:26:01.491

This experiment taught me an important lesson about the difference between logging and alerting. I expected to find a matching Wazuh alert after seeing the local Sysmon Event ID 11. I filtered Wazuh Discover for ARTWorkstation and Event ID 11, then searched for calc_exe.lnk and the full path. I found other Event ID 11 activity, but not a matching Wazuh alert tied to the shortcut I created.

The test itself did not fail. Sysmon captured the shortcut locally, which proved the behavior happened. Instead, the result exposed a visibility gap: this Wazuh environment did not create a matching alert for that specific Startup-folder persistence behavior.

I cleaned up the shortcut with:

Invoke-AtomicTest T1547.001 -TestNumbers 7 -Cleanup

A final Test-Path check returned False, confirming that calc_exe.lnk had been removed.

Conclusion

This project showed that the new ART Workstation monitoring pipeline was working, but its detection coverage was uneven. The scheduled-task experiment generated a clear Sysmon process-creation event and a matching Wazuh alert, although Wazuh classified it as Windows Command Shell instead of Scheduled Task. The Registry Run-key experiment produced the strongest result: Sysmon and Wazuh both captured the persistence change, and Wazuh correctly mapped it to T1547.001.

The Startup-folder shortcut experiment showed the other side of the story. Sysmon recorded the exact file creation locally, but Wazuh did not create a matching alert. Together, these results showed me that telemetry collection, event parsing, and alerting all need to be tested instead of assumed.

My biggest advice is to treat each test like a small investigation, not just a command you run and forget. Record the start and end time, endpoint name, expected command, and Sysmon Event ID before searching in the SIEM. My initial free-text search for HOSTNAME.EXE made me think logging had failed. Using structured fields—such as agent.name, event ID, timestamp, and ProcessGuid—showed that the event was there. It is also important to remember that Sysmon timestamps are in UTC, while the lab interface and Wazuh can display another time zone. Finally, always run cleanup and verify that the task, Registry value, or shortcut is gone.

Final Thoughts

The coolest thing I learned was that a detection is not just a log entry. It is a chain: an action happens on an endpoint, a log source records it, the SIEM receives and parses it, and a rule decides whether to create an alert.

My three experiments made that chain visible. The Registry Run-key test made it all the way through: the local Sysmon event, the Wazuh alert, and the ATT&CK mapping all matched. The Startup-folder shortcut did not. Sysmon saw the activity, but Wazuh did not give me a matching alert. That difference helped me understand why detection engineering matters. Visibility is not something I can assume just because a tool is installed—it is something I need to test, question, and improve.

My advice to another new analyst is to start with one harmless behavior and prove every part of the evidence trail before moving to something more complicated. Write down what you expect to run, which endpoint will run it, which Sysmon Event ID you expect, and what you expect Wazuh to show. Then compare the local event with the SIEM result. That turns a confusing wall of logs into a focused investigation. You do not have to understand every field at first; start with the fields that connect the activity to the host, time, process, and command.

My favorite external resource was Florian Roth’s Neo23x0 sysmon-config repository on GitHub. I found it while looking for a practical Sysmon baseline for this lab. The configuration gave me a useful starting point instead of forcing me to enable everything and drown in noise. Its comments helped me understand why certain process, Registry, and file events were worth recording. It made Sysmon feel less like a mysterious fire hose of data and more like a tool I could tune with a purpose.

I want to thank Mark Russinovich and Florian Roth for making this project possible. Russinovich’s work on Sysmon gave me the endpoint telemetry I used to trace process, Registry, and file activity locally. Roth’s Sysmon configuration gave me a thoughtful baseline rather than forcing me to guess which events to collect. Their public work turned this from an installation exercise into a real lesson about evidence and detection coverage. I am also grateful to the Atomic Red Team contributors at Red Canary for providing safe, repeatable tests that made these controlled experiments possible.

References

1. Wazuh. (n.d.). Deploying Wazuh agents on Windows endpoints. Wazuh Documentation. https://documentation.wazuh.com/current/installation-guide/wazuh-agent/wazuh-agent-package-windows.html
   
   I used this documentation to deploy and start the Wazuh agent on ART Workstation, then verify that it connected to the Wazuh manager.

2. Wazuh. (n.d.). Configuring log collection for different operating systems. Wazuh Documentation. https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/configuration.html
   
   This reference guided my configuration of Wazuh to collect the Microsoft-Windows-Sysmon/Operational event channel.

3. Microsoft Sysinternals. (n.d.). Sysmon. Microsoft. https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
   
   I used this page to download Sysmon and understand the Event IDs used during the project, including Event IDs 1, 11, and 13.

4. Roth, Florian. (n.d.). sysmon-config. GitHub. https://github.com/Neo23x0/sysmon-config
   
   I used Neo23x0’s baseline XML configuration on ART Workstation. Its comments and filtering approach helped me focus on useful Windows telemetry without enabling every possible event.

5. Red Canary. (n.d.). Atomic Red Team. GitHub. https://github.com/redcanaryco/atomic-red-team
   
   Atomic Red Team provided the safe, repeatable tests I used to create the scheduled-task, Registry Run-key, and Startup-folder shortcut behaviors in this project.