This project aims to showcase the setup and integration of Wazuh in a professional environment to enhance security operations. Here, I’ll guide you through the installation, agent management, alert configuration, integration with Microsoft Teams, and finally, testing with Atomic Red Team for validation.

Installation

To host our Wazuh server, we’ll use an AWS EC2 instance running Ubuntu 24.04. This setup is chosen for flexibility, scalability, and ease of maintenance in a cloud-based infrastructure.

Once our server is up-to-date we run the following command to install Wazuh:

1curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

This will take care of the setup and configuration of all core components. The process begins by checking system requirements and installing essential dependencies. Next, the script configures Wazuh’s security by generating certificates for the root, admin, indexer, Filebeat, and dashboard components, ensuring secure data handling across the ecosystem.

Once dependencies and configurations are set, the script sequentially installs and starts key Wazuh services: the Wazuh Indexer for data storage, the Wazuh Manager for threat detection, Filebeat for log forwarding, and the Wazuh Dashboard for monitoring. The dashboard is accessible at https://<wazuh-dashboard-ip>:443 with default login credentials provided at the end of the installation.

When we log in to our Wazuh dashboard for the first time, we should begin by setting up groups to make agent management easier.

To create agent groups from the Wazuh dashboard:

1. Navigate to Management > Groups and click the Add new group button.
2. Enter a name for the agent group and click on the Save new group button.

Now we’ll move on to deploying our agents.

Agent Deployment

To add a new agent we’ll click on the burger menu and go to Endpoints Summary, and click on Deploy new agent. Simply follow the wizard’s instructions to deploy an agent:

If you’re setting up a Wazuh agent on an AWS EC2 instance and experiencing connectivity issues, check your Security Group settings applied to your instance and ensure the Security Group attached to your Wazuh manager instance allows inbound traffic on these ports:

• 1514/TCP – Agent communication
• 1515/TCP – Agent registration
• 55000/TCP – API access

For my first agent I added an AWS Lightsail instance I want to keep track of. Now we can move onto further configurations, such as vulnerability and rootkit detection, file integrity monitoring, etc.

Vulnerability Detection

As of this publication date, Wazuh ships by default with the vulnerability dectection module toggled on, to confirm check the config file located at /var/ossec/etc/ossec.conf

 1<vulnerability-detection>
 2   <enabled>yes</enabled>
 3   <index-status>yes</index-status>
 4   <feed-update-interval>60m</feed-update-interval>
 5</vulnerability-detection>
 6
 7<indexer>
 8   <enabled>yes</enabled>
 9   <hosts>
10      <host>https://0.0.0.0:9200</host>
11   </hosts>
12   <ssl>
13      <certificate_authorities>
14         <ca>/etc/filebeat/certs/root-ca.pem</ca>
15      </certificate_authorities>
16      <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
17      <key>/etc/filebeat/certs/filebeat-key.pem</key>
18   </ssl>
19</indexer>

To check the vulnerabilities detected on our agents, go to Threat Intelligence > Vulnerability Detection.

Alerting

Configuring alerting in Wazuh involves setting up alert thresholds, forwarding alerts to external systems, and managing alert escalation and filtering.

Thresholds

Wazuh assigns a severity level (ranging from 0 to 16) to each event based on predefined rules. By default, Wazuh triggers alerts for events with a severity level of 3 or higher. You can adjust this threshold to control which alerts are generated.

To modify it, go to the ossec.conf file and locate the <alerts> section and adjust the <log_alert_level> value to the desired threshold.

For example, to set the minimum alert level to 5:

1<alerts>
2  <log_alert_level>5</log_alert_level>
3</alerts>

After making changes on the config file, restart the Wazuh manager to apply the new settings with:

1   sudo systemctl restart wazuh-manager

Filtering Alerts

To fine-tune your alerting system, implement alert filtering within Wazuh to suppress specific events, such as SSH brute-force attempts for non-existent users. Follow these steps:

1. Identify the Rule ID: Determine the rule ID associated with the alert you wish to suppress. You can find this ID in the alert logs or by reviewing the Wazuh ruleset.

   • For SSH brute-force attempts in Linux, you can find these events with rule.id:(5551 OR 5712). Other related rules are 5710, 5711, 5716, 5720, 5503, 5504.

   • For Windows logon failures you can find those events with rule.id:(60122 OR 60204).

2. Create a Local Rule to Override the Alert: By creating a local rule with a lower severity level, you can prevent the alert from being forwarded.

   • Navigate to the Wazuh manager’s rules directory, located at /var/ossec/etc/rules/local_rules.xml.

   • Add the following rule to suppress the specific alert:

     1<group name="sshd,">
     2  <rule id="100002" level="0">
     3    <if_sid>5716</if_sid>
     4    <description>Ignore SSH brute force alerts for non-existent users</description>
     5  </rule>
     6</group>

     This rule sets the alert level to 0 for the specified event, effectively suppressing it. For a more detailed example, check the ossec example file.

3. Restart the Wazuh Manager: Apply the changes by restarting the Wazuh manager:

   1sudo systemctl restart wazuh-manager

Forwarding Alerts

Wazuh can forward alerts to various external systems, such as syslog servers, email addresses, or collaboration platforms like Microsoft Teams.

• To forward alerts to a syslog server, add a <syslog_output> block in the ossec.conf file:

1<syslog_output>
2  <server>192.168.1.241</server>
3  <level>9</level>
4</syslog_output>

This configuration sends alerts with a severity level higher than 9 to the specified syslog server.

• To receive alerts via email, configure the email settings in the <global> section of ossec.conf:

 1<ossec_config>
 2  <global>
 3    <email_notification>yes</email_notification>
 4    <email_to>me@test.com</email_to>
 5    <smtp_server>mail.test.com</smtp_server>
 6    <email_from>wazuh@test.com</email_from>
 7  </global>
 8  <alerts>
 9    <email_alert_level>10</email_alert_level>
10  </alerts>
11</ossec_config>

This setup sends email alerts for events with a severity level of 10 or higher.

Teams Integration

To integrate Wazuh alerts with Microsoft Teams, we have several options, we can use Teams’ Incoming Webhook utility, Zapier, Make.com, or any other similar platform to send alerts to a Teams channel via a webhook. This involves creating a custom integration script and configuring it in ossec.conf.

I’ll be using this already configured integration with Teams, credits go to @redanthrax.

Once the integrations are setup on the Wazuh server simply configure it like this:

1<integration>
2  <name>custom-teams</name>
3  <level>3</level>
4  <hook_url>{WEBHOOK URL}</hook_url> 
5  <alert_format>json</alert_format> 
6</integration>

Now we’ll be receiving alerts on a Teams channel on every level 3 alert:

To further extend these alerts, we can implement a SOAR system to automate triaging, create escalation processes, develop playbooks and incident response. We could use another good open-source solution like Shuffle for this.

Testing and Validation

To validate our Wazuh implementation and ensure alerts are triggered correctly, we’ll use Atomic Red Team, a versatile and open-source framework that allows us to simulate real-world attack techniques mapped to the MITRE ATT&CK framework. Specifically, we’ll use the Invoke-Atomic PowerShell module, which can run Windows, MacOS and Linux, making it an ideal tool to test all our agents.

Setting up Atomic Red Team

Let’s do some tests on our ubuntu server. First we have to install PowerShell on linux with sudo snap install powershell --classic and then run pwsh. Once inside PowerShell we can proceed to install both the execution framework and the atomics folder, which contains the test definitions; the commands that the execution framework will execute.

1IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing);
2Install-AtomicRedTeam -getAtomics

We can now use the Invoke-AtomicTest function to perform controlled security tests. Below are examples of specific MITRE ATT&CK techniques that we can run to test our setup:

• Test for Ingress Tool Transfer (T1105): Simulates an attempt to transfer files from a remote source to an environment, which could be indicative of malware download or data exfiltration. This activity should trigger alerts if Wazuh is monitoring network activity and file movements appropriately.

  1Invoke-AtomicTest T1105

• Test for Credential Dumping (T1003): Runs a credential dumping simulation to check if Wazuh captures potential credential access events.

  1Invoke-AtomicTest T1003.008 # OS Credential Dumping: /etc/passwd and /etc/shadow

• Test for Scheduled Task Creation (T1053): Uses scheduled tasks to simulate persistence techniques and verify if Wazuh alerts on task creation.

  1Invoke-AtomicTest T1053.003 # Scheduled Task/Job: Cron

• Test for Command and Scripting Interpreter Execution (T1059): Simulates suspicious scripting activity that Wazuh should detect based on your threshold settings.

  1Invoke-AtomicTest T1059.004 # Command and Scripting Interpreter: Unix Shell

Verifying Alerts in Wazuh

After executing each test, we’ll navigate to the Wazuh dashboard to verify the alerts generated. We can see the events corresponding to each Atomic Red Team test under Threat Intelligence > MITRE ATT&CK. We can review the details to confirm that the alerts match the configured thresholds as intended.

By completing the implementation, configuration, and validation of Wazuh, we have created a robust and proactive SIEM setup capable of detecting, alerting, and responding to security events effectively. With integrations for seamless alerting, vulnerability monitoring, and extensive testing using Atomic Red Team, this Wazuh deployment strengthens our organization’s security posture. As threats evolve, this setup can be further customized to meet the dynamic needs of modern security operations, making it a valuable asset in our SOC’s toolkit. This project highlights the power of open-source solutions like Wazuh in building a resilient and adaptable cybersecurity environment.