Deploying and Validating a Wazuh SIEM with Atomic Red Team

Akindele Fasuba — Tue, 28 Jul 2026 15:44:26 +0000

1.1 Teaser Overview

Security monitoring is only effective when the right telemetry is collected and meaningful alerts are generated. In this project, I deployed and enhanced an open-source Wazuh SIEM environment by enabling additional Windows Defender Operational log collection and validating the configuration using Atomic Red Team techniques mapped to the MITRE ATT&CK framework. I performed experiments covering Scheduled Task Persistence (T1053.005) and Ingress Tool Transfer (T1105) to evaluate how well the SIEM detected simulated attacker behavior. While the Atomic Red Team techniques executed successfully, only some activities generated corresponding Wazuh detections, highlighting opportunities to improve the default detection rules. This blog documents my implementation process, the experiments I performed, the results I observed, and the lessons I learned while improving endpoint visibility.

1.2 Introducing Yourself to the Cyber Community

Hello! My name is Akindele Fasuba, and I am currently developing my cybersecurity skills with a focus on blue-team operations, SIEM engineering, and threat detection. I enjoy learning by working through realistic lab environments that simulate real-world security operations. This project gave me valuable experience deploying a SIEM, collecting Windows event logs, and validating detections using Atomic Red Team. My goal is to continue developing practical blue-team skills and share what I learn with others who are beginning their own cybersecurity journey. I hope this write-up provides useful insight into deploying, testing, and improving a SIEM environment.

2.1 Deployment Environment

This project was completed using the TripleTen CloudShare lab environment, which included a Wazuh manager, an Active Directory domain controller (AD01), an Observer Linux server, and an Atomic Red Team workstation. The Wazuh manager collected and analyzed security telemetry from the Windows endpoint, while Atomic Red Team simulated attacker techniques based on the MITRE ATT&CK framework. This environment provided a realistic platform for validating Windows event collection and SIEM detections.

2.2 SIEM Modification

To improve endpoint visibility, I modified the Wazuh agent configuration on AD01 to collect events from the Microsoft-Windows-Windows Defender/Operational event log in addition to the default Windows event channels. This required editing the ossec.conf configuration file to add the Defender Operational log as an additional event source before restarting the Wazuh agent service.

After restarting the service, I confirmed that Windows Defender Operational events were successfully forwarded to the Wazuh manager and appeared in the Threat Hunting interface. Adding this telemetry expanded endpoint visibility and provided additional security context for the Atomic Red Team simulations.

2.3 Environment Validation

Before executing the Atomic Red Team techniques, I verified that the deployment was operating correctly by confirming that:

The Wazuh agent was connected and reporting to the Wazuh manager.
Windows Defender Operational events were successfully collected.
AD01 events appeared in the Wazuh Threat Hunting dashboard.
The environment was ready to receive alerts generated during the simulated attack scenarios.

Completing these validation steps established a reliable baseline, ensuring that any alerts or missing detections observed during the experiments reflected the effectiveness of the SIEM configuration rather than deployment issues.

Experiment #1

The first experiment focused on MITRE ATT&CK T1053.005 – Scheduled Task/Job: Scheduled Task. The objective was to validate whether Wazuh could detect persistence techniques involving the creation of scheduled tasks on a Windows endpoint. I executed the Atomic Red Team test using PowerShell with the command Invoke-AtomicTest T1053.005, which created several scheduled tasks designed to simulate an attacker establishing persistence on a Windows system.

During the test, Windows successfully created the scheduled tasks and Wazuh collected the resulting security events from the domain controller. The generated telemetry demonstrated that the SIEM successfully received Windows Event Log data and recorded activity associated with scheduled task creation. This confirmed that the Defender Operational logging modification and Windows event collection were functioning correctly.

This experiment demonstrated how attackers can establish persistence through scheduled tasks while also confirming that the SIEM was capable of collecting and presenting relevant evidence for further investigation. It also reinforced the importance of validating detections after making configuration changes rather than assuming monitoring was working as expected.

Experiment #2

The second experiment tested MITRE ATT&CK T1105 – Ingress Tool Transfer. The goal was to simulate an attacker downloading tools onto a compromised system and determine whether Wazuh generated alerts for the activity. I executed the Atomic Red Team test using Invoke-AtomicTest T1105, which performed several download techniques using native Windows utilities.

The Atomic Red Team framework successfully executed multiple download methods, including PowerShell, BITS, CertUtil.exe, and SCP-based transfers. While the activity completed successfully, Wazuh did not generate alerts specifically mapped to technique T1105. Instead, supporting events such as file creation and command execution were recorded, demonstrating that telemetry was present even though a dedicated detection rule was not triggered.

This experiment highlighted an important lesson in defensive operations: the absence of an alert does not necessarily mean the activity was invisible. Analysts should review multiple data sources and understand the limitations of default detection rules when evaluating SIEM coverage.

Experiment #3

One of the most valuable learning experiences during this project occurred while validating the SIEM configuration rather than during an attack simulation. After completing the Atomic Red Team tests, I initially expected Wazuh to generate alerts that explicitly referenced the MITRE ATT&CK technique IDs. Instead, I observed different rule IDs or no matching alerts for some techniques, which led me to believe the configuration might be incorrect.

After reviewing the collected logs more carefully, I discovered that Wazuh successfully collected telemetry, but the default detection rules did not always map directly to every Atomic Red Team technique. Some attacks generated supporting events, such as file creation or command execution, instead of technique-specific alerts. This reinforced the importance of validating both telemetry collection and detection coverage rather than relying solely on alert names.

This experience improved my understanding of SIEM tuning and threat hunting by demonstrating that effective security monitoring often requires manual investigation alongside automated detections to fully understand attacker activity.

4.1 Summary of Experimental Findings

The experiments demonstrated that the Wazuh SIEM was successfully configured to collect and analyze Windows security telemetry after enabling Microsoft Defender Operational logging. The Scheduled Task Persistence experiment confirmed that Windows event data was successfully collected and could be used to investigate persistence techniques. The Ingress Tool Transfer experiment highlighted that not every Atomic Red Team technique generated a dedicated Wazuh alert by default, even when the underlying telemetry was available. Together, these experiments reinforced the importance of validating both data collection and detection capabilities when deploying a SIEM. They also demonstrated that effective threat hunting often requires analysts to correlate multiple sources of evidence rather than relying solely on predefined alerts or a single detection rule.

4.2 Advice on Avoiding Mistakes

One of the most important lessons from this project is to verify each configuration step before moving on to the next task. Small configuration errors or incorrect assumptions can make troubleshooting much more difficult later in the deployment process. It is also important to understand that the absence of a SIEM alert does not necessarily indicate that no malicious activity occurred. Analysts should review raw event logs, confirm that telemetry is being collected correctly, and validate detection coverage using multiple testing techniques. Taking a methodical approach to configuration, testing, and verification will produce more reliable results and build greater confidence in the effectiveness of the monitoring environment.

5.1 The Coolest Thing I Learned

The most interesting lesson from this project was realizing that successfully deploying a SIEM is only the beginning of effective security monitoring. Collecting telemetry is important, but understanding how to interpret the data and recognize gaps in detection coverage is equally valuable. Running Atomic Red Team tests demonstrated that not every simulated attack produced an obvious alert, which reinforced the importance of threat hunting, log analysis, and validating detections instead of relying solely on automated alerts. This project gave me a much deeper appreciation for the work performed by blue-team analysts every day.

5.2 One Piece of Advice

My biggest piece of advice is to take a methodical approach throughout the entire deployment process. Verify every configuration change, test each modification before continuing, and document your observations as you work. When something does not behave as expected, resist the urge to assume the configuration is wrong. Instead, investigate the available telemetry, review the logs carefully, and use the results to understand what actually happened. That approach will save time and strengthen your troubleshooting skills.

5.3 My Favorite Resource

My favorite resource during this project was the Atomic Red Team framework. It provided realistic adversary simulations that made it possible to validate the SIEM configuration in a safe and repeatable way. The framework also helped me better understand how specific MITRE ATT&CK techniques appear in system logs and how those activities are translated into detections within Wazuh. Using Atomic Red Team transformed the project from simply configuring a SIEM into performing practical defensive security testing.

5.4 Thank You (Gratitudes!)

I would like to thank the TripleTen instructors and reviewers for providing clear guidance throughout this project and encouraging a hands-on approach to learning. I also appreciate the developers and contributors behind the Wazuh and Atomic Red Team projects for creating outstanding open-source tools that make practical cybersecurity training accessible. Their work made it possible to gain valuable experience with SIEM deployment, threat detection, and defensive security operations in a realistic lab environment. Their contributions helped transform this project from a configuration exercise into a meaningful hands-on learning experience.

References

1. Atomic Red Team

Title: Atomic Red Team

Author: Red Canary

Affiliation: Red Canary

Date Published: n.d.

URL: https://atomicredteam.io/

Why it was useful: This framework was used to simulate realistic adversary techniques in a controlled environment. It allowed me to validate the SIEM configuration and observe how different attack techniques appeared in Wazuh.

2. MITRE ATT&CK Enterprise Matrix

Title: MITRE ATT&CK Enterprise Matrix

Author: MITRE Corporation

Affiliation: MITRE Corporation

Date Published: n.d.

URL: https://attack.mitre.org/

Why it was useful: MITRE ATT&CK provided the standardized technique IDs and descriptions used throughout the experiments. It helped me understand the tactics and techniques being simulated and how they relate to real-world threats.

3. Wazuh Documentation

Title: Wazuh Documentation

Author: Wazuh

Affiliation: Wazuh Inc.

Date Published: n.d.

URL: https://documentation.wazuh.com/

Why it was useful: The documentation provided configuration guidance for log collection and SIEM management. It was an important reference for verifying settings and understanding Wazuh's detection capabilities.

4. Microsoft Learn

Title: Microsoft Defender Documentation

Author: Microsoft

Affiliation: Microsoft Corporation

Date Published: n.d.

URL: https://learn.microsoft.com/windows/security/

Why it was useful: Microsoft Learn explained the Windows Defender Operational log and related security features. It helped me understand the event data collected by Wazuh during the experiments.

5. TripleTen Course Materials

Title: Sprint 10 – Deploy a SIEM Project Materials

Author: TripleTen

Affiliation: TripleTen

Date Published: n.d.
Why it was useful: The course materials provided the lab environment, step-by-step guidance, and project objectives. They served as the foundation for configuring the SIEM and documenting the deployment process.

DEV Community: Akindele Fasuba