1. Introduction
What happens when you run a security test, but your SIEM shows no results? During my first SIEM deployment project, I learned that finding the answer takes more than searching for an alert. I configured Microsoft Defender log collection, tested antivirus detection, simulated suspicious activity with Atomic Red Team, and compared it with normal Windows activity. Along the way, I ran into problems, investigated missing evidence, and learned how to connect endpoint logs to what I saw in Wazuh.
One of my biggest takeaways was that a successful test does not always produce the alert I expect. I also discovered how useful it is to compare local endpoint logs with SIEM results. Sometimes the most interesting finding is not an alert—it is figuring out why an alert did not appear.
Hi, I’m Inam Kayani, a cybersecurity student building my hands-on skills through security labs and projects. I decided to enter cybersecurity because it was really interesting to me. This is my first contribution to the cybersecurity community, and I hope my experience is useful to another beginner who is learning how to investigate logs and troubleshoot a SIEM.
2. Setup: Adding Microsoft Defender Logs to Wazuh
For my SIEM modification, I decided to collect Microsoft Defender Operational logs from the Windows endpoint ad01. I wanted Wazuh to receive antivirus-related events so I could investigate detections from a central location.
I opened the Wazuh agent configuration file on ad01:
C:\Program Files (x86)\ossec-agent\ossec.conf
Inside the existing <ossec_config> section, I added this configuration:
<localfile>
<location>Microsoft-Windows-Windows Defender/Operational</location>
<log_format>eventchannel</log_format>
</localfile>
The location identifies the Windows event channel I wanted to collect, and eventchannel tells the Wazuh agent how to read it. After saving the file, I restarted the Wazuh Windows Agent service so the change would take effect.
Next, I opened Wazuh Discover on the Blue Team Workstation and searched the wazuh-alerts-* index using this query:
agent.name:"ad01" AND data.win.system.channel:"Microsoft-Windows-Windows Defender/Operational"
I found Microsoft Defender Event ID 1150, which reported that the endpoint protection client was running in a healthy state. This confirmed that Defender Operational events from ad01 were reaching Wazuh.
My setup mistake and how I fixed it
My aha moment during setup was realizing that saving a configuration file does not automatically mean the SIEM is collecting the logs I want. After adding the Microsoft Defender Operational channel to ossec.conf, I restarted the Wazuh agent and searched Discover for Defender events from ad01. When I found Event ID 1150 reporting that the endpoint protection client was running in a healthy state, I had proof that the new log source was reaching Wazuh. I learned that every configuration change needs to be tested with actual evidence, not just assumed to be working.
With Defender logs available in Wazuh, I was ready to test what happened when the endpoint detected a suspicious file.
3. Experiment Time!
Experiment 1: Testing Microsoft Defender with EICAR
For my first experiment, I wanted to see whether a Microsoft Defender detection on ad01 would appear in Wazuh. I used the EICAR anti-malware test file, which is designed to test antivirus detection without using real malware.
My first attempt with the text-file version did not produce the detection I expected. I then tried the ZIP version, and the browser displayed a “Virus detected” message.
I searched the Microsoft Defender Operational events from ad01 in Wazuh and found events associated with the test file. The events reported a Severe threat classification and a Quarantine action. The recorded file path pointed to the Administrator’s Downloads folder.
This experiment demonstrated the value of the modification I had made during setup. I could investigate Defender detection details in Wazuh instead of relying only on what appeared in the browser or Windows Security interface.
Experiment 2: Simulating Regsvr32 Activity with Atomic Red Team
For my second experiment, I used Atomic Red Team to run T1218.010 Test 3, which simulates execution using the Windows utility regsvr32.exe. My goal was to investigate the resulting process activity in Sysmon and Wazuh.
My first attempt ran on the ART Workstation instead of the target endpoint, ad01. The test returned exit code 0, but I could not find the expected activity when I searched Wazuh for ad01. I realized that a successful command does not prove I ran the test on the machine I intended to investigate.
I created a PowerShell remote session to ad01 and checked the test prerequisites. This revealed another problem: the required AllTheThingsx86.dll file was missing from the endpoint. The automatic prerequisite installation also failed with an access-denied error.
To solve the problem, I copied the DLL from the ART Workstation into the required Atomic Red Team folder on ad01. I ran the prerequisite check again and confirmed that the prerequisites were met. I then executed the test through the remote session, and it returned exit code 0.
In Event Viewer on ad01, Sysmon recorded Event ID 1 (Process Create) for C:\Windows\SysWOW64\regsvr32.exe at approximately 1:08:48 AM EDT on September 24, 2026. The event included the command line referencing the Atomic Red Team DLL.
I found the matching event in Wazuh at approximately 1:08:49 AM EDT. Wazuh generated a level 3 alert with rule ID 92032 and the description “Suspicious Windows cmd shell execution.”
One detail surprised me: the alert was mapped to MITRE ATT&CK techniques T1087 and T1059.003, not the T1218.010 technique I had tested. This taught me to inspect the actual event evidence—including the process image, command line, and parent process—instead of assuming an alert’s title or ATT&CK mapping tells the whole story.
After saving my evidence, I ran the Atomic Red Team cleanup command, which completed successfully.
Experiment 3: Comparing Normal Notepad Activity with Suspicious Activity
For my third experiment, I wanted to compare normal Windows activity with the Regsvr32 test from Experiment 2. On ad01, I opened Notepad and typed a short test message.
I searched Wazuh Discover for Notepad activity from ad01, but the search returned 0 hits in the wazuh-alerts-* index. Rather than assuming the activity had not been recorded, I checked the local Sysmon Operational log in Event Viewer.
I found Event ID 1 for C:\Windows\System32\notepad.exe at 1:56:42 AM EDT on September 24, 2026. This confirmed that Sysmon had recorded the Notepad process creation.
Both the Notepad and Regsvr32 activities produced process creation evidence, but their details were different. Notepad was an ordinary application launch. The Regsvr32 test involved a Windows utility executing a DLL from an Atomic Red Team temporary folder.
The most important lesson from this experiment was that a locally recorded event and a Wazuh alert are not the same thing. My Wazuh search did not confirm a Notepad alert, but the local Sysmon event confirmed that the activity occurred and was logged.
4. Conclusion
My three experiments helped me understand how endpoint logs support security investigations. In Experiment 1, Microsoft Defender detected the EICAR test file, and I found the detection and quarantine details in Wazuh. This demonstrated that the Defender log collection modification was working.
In Experiment 2, I successfully ran the Regsvr32 test on ad01. Sysmon recorded the process creation event, and Wazuh generated an alert. In Experiment 3, Sysmon recorded normal Notepad activity, but my Wazuh alerts search returned zero hits.
Together, these findings showed me that collecting an event, generating an alert, and interpreting the activity are different parts of an investigation. I learned to compare evidence across tools rather than relying on a single search result.
My advice for avoiding the mistakes I made during Experiment 2 is to confirm the target machine, check prerequisites, and record the test time before running a simulation. When a SIEM search returns no results, checking the original endpoint log can help determine whether the activity was recorded locally.
My advice to another beginner is to never assume a configuration change worked just because the file was saved. Restart the Wazuh agent, then search for an actual event from the new log source to verify that the SIEM is receiving it.
5. Final Thoughts
5.1 The coolest thing I learned
The coolest thing I learned was how to connect activity on a Windows endpoint to evidence collected by a SIEM. During the Regsvr32 experiment, I found the process creation event in local Sysmon and then located the matching event in Wazuh. Seeing the process name, command line, and timestamps helped me understand how analysts investigate suspicious activity.
5.2 One piece of advice
My advice to another beginner is to check the basics before troubleshooting something complicated. Make sure the test is running on the correct machine, verify its prerequisites, and save the command output. If you cannot find an alert in Wazuh, check the original endpoint logs before assuming the test failed.
5.3 My favorite external resource
My favorite external resource was the Atomic Red Team GitHub repository. It provided a structured way to run a test based on a MITRE ATT&CK technique. Its prerequisite checks and cleanup commands were especially useful when I encountered problems during my Regsvr32 experiment.
5.4 Thank You
I want to thank Triple ten.
I also want to thank all the instructors who always help me.
6. References
1. Wazuh — Log Data Collection Configuration
Title: Log Data Collection Configuration
Author: Wazuh documentation team
Affiliation: Wazuh
https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/configuration.html
This resource helped me understand how to configure the Wazuh agent to collect Microsoft Defender Operational events from a Windows endpoint.
2. Microsoft — Sysmon
Title: Sysmon
Affiliation: Microsoft
URL: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
This resource helped me understand Sysmon process creation events and the endpoint evidence I investigated during Experiments 2 and 3.
3. Red Canary — Atomic Red Team
Title: Atomic Red Team
Author: Red Canary and project contributors
Affiliation: Red Canary
URL: https://github.com/redcanaryco/atomic-red-team
This resource provided the test framework I used for my Regsvr32 experiment, including prerequisite checks and cleanup commands.
4. MITRE ATT&CK — Regsvr32
Title: Regsvr32 (T1218.010)
Author: MITRE ATT&CK
Affiliation: MITRE
URL: https://attack.mitre.org/techniques/T1218/010/
This resource helped me understand the technique simulated in Experiment 2 and compare it with the activity recorded by Sysmon and Wazuh.
5. EICAR — Download Anti-Malware Testfile
Title: Download Anti-Malware Testfile
Author: EICAR
Affiliation: European Institute for Computer Antivirus Research
URL: https://www.eicar.org/download-anti-malware-testfile/
This resource provided the safe test file I used to trigger Microsoft Defender and investigate the resulting events in Wazuh.
Top comments (0)