In my previous post, I explored Wazuh without an agent, just to get a feel for how things work. Now, it’s time to level up and deploy the Wazuh agent on an Ubuntu VM to start monitoring system activities properly. This guide will walk through the setup process step by step.

🛠 Prerequisites

Before we begin, make sure:
✅ You have a Wazuh Manager running.
✅ You have sudo privileges on the Ubuntu VM.

Step 1: Install the Wazuh Agent

First, access the Wazuh Dashboard using https://WAZUH-MANAGER-IP, make sure you remember the login credentials. On the Homepage, click the Deploy Agent button and follow the instructions.

You need to choose correct package according to the agent’s OS. In my case, I am using Ubuntu so I choose DEB amd64.

There are several things that you need to configure such as agent name and server IP. Then, copy and run the command in the agent VM.

Step 2: Configure the Agent

Edit the Wazuh agent config file:

  sudo nano /var/ossec/etc/ossec.conf

Look for the section and update the <address> field to point to your Wazuh Manager’s IP:

  <client>
    <server>
      <address>YOUR_WAZUH_MANAGER_IP</address>
      <port>1514</port>
    </server>
  </client>

The Wazuh agent communicates with the manager using port 1514 (TCP). Make sure the firewall on Wazuh Manager isn’t blocking it:

  sudo ufw allow 1514/tcp

Step 3: Enable and Start the Agent

Now, enable and start the Wazuh agent:

  sudo systemctl daemon-reload
  sudo systemctl enable wazuh-agent
  sudo systemctl start wazuh-agent

Check if it’s running:

  sudo systemctl status wazuh-agent

If you see “active (running)”, then you’re good to go! 🎉

Step 4: Verify Connection on Wazuh Manager

Go to your Wazuh Manager and check if the agent is connected:

If the agent appears in the list, everything is working fine. If not, you might need to check firewall settings or restart the Wazuh Manager.

  sudo systemctl restart wazuh-manager

Exploring Agents Functionalities

Now it is the time to explore what Wazuh Agent has to offer. Straight off, one of the features that attracts my attention is the Regulatory Compliance dashboard. Since my internship will be mainly on GRC, it’s great if I can see how a SIEM can integrate to track compliance.

1. Regulatory Compliance

The compliance feature in the Wazuh agent helps ensure that your system follows security best practices, regulatory standards, and internal policies. It continuously monitors configurations, permissions, and security settings to detect any non-compliance issues.

There are several standards that you can refer to and there are many well-known security standards like PCI-DSS, NIST, and GDPR. For example, I get an alert from PCI-DSS Requirement 10.6.1 that requires me to review security logs from devices such as firewall, IDP, IPS etc on a regular basis.

2. Vulnerability Detection

This feature helps identify security weaknesses in your system by scanning for known vulnerabilities (CVEs) and ensuring that your system is up-to-date with patches.

From the dashboard, you see the vulnerabilities according to their severity levels. There is also lists of CVEs related to the agent which can help us to patch the vulnerabilities.

For example, CVE-2024-26458, CVE-2024-26461, CVE-2024-26462 related to Kerberos 5 1.21.2 that contains a memory leak vulnerability.

References:

• https://ubuntu.com/security/CVE-2024-26458
• https://ubuntu.com/security/CVE-2024-26461
• https://ubuntu.com/security/CVE-2024-26462

3. File Monitoring

Wazuh also can tracks changes of file attributes such as modifications, creations, deletions and access times in critical files and directories on a system. This allows security teams to identify unauthorized changes, which could indicate malicious activity or system compromise. Wazuh compares the current state of monitored files with a baseline and will generates alerts whenever changes occur.

1. Edit the Wazuh Agent Configuration

On your Ubuntu agent, open the configuration file:

  sudo nano /var/ossec/etc/ossec.conf

Find the section (or add it if missing), and define which directories to monitor:

  <syscheck>
    <!-- Scan system binaries and config files -->
    <directories check_all="yes" report_changes="yes" realtime="yes">/etc</directories>
    <directories check_all="yes" report_changes="yes" realtime="yes">/var/www/html</directories>
    <directories check_all="yes" report_changes="yes" realtime="yes">/home/<user></directories>
  
    <!-- Frequency of checks (in seconds) -->
    <frequency>3600</frequency>
  
    <!-- Alert when file changes -->
    <alert_new_files>yes</alert_new_files>
    <auto_ignore>no</auto_ignore>
  </syscheck>

Apply the changes by restarting the agent:

  sudo systemctl restart wazuh-agent

1. Test File Integrity Monitoring

Try creating, modifying, and deleting a file in a monitored directory:

  sudo touch /home/<user>/test.txt
  echo "Test" | sudo tee -a /home/<user>/test.txt
  sudo rm /home/<user>/test.txt

I also tried modifying /etc/passwd, and Wazuh successfully detected the changes. It also shows the difference between the original and modified file.

For the compliance part, I look up to alert by PCI-DSS Requirement 11.5 which mentions about deploying file integrity monitoring to detect any malicious file changes.

4. Detecting Suspicious Binaries

Wazuh provides malware detection capabilities to identify suspicious binaries such as trojan on an endpoint. A Trojan is a type of malware that disguises itself as a legitimate program to trick users into running it. Once executed, a Trojan can perform malicious actions such as stealing data, opening backdoors, or allowing attackers to gain unauthorized access to a system.

Wazuh helps detect legitimate system binaries (usually at /usr/bin/) that have been modified to execute malicious code while still appearing normal. This allows security teams to identify and mitigate potential compromises.

Configuration

By default, the Wazuh Rootcheck module is enabled in the Wazuh agent’s configuration. To confirm this, check the <rootcheck> section in /var/ossec/etc/ossec.conf on the agent and ensure it includes the following configuration:

<rootcheck>
    <disabled>no</disabled>
    <check_files>yes</check_files>

    <!-- Enable Trojan detection -->
    <check_trojans>yes</check_trojans>

    <check_dev>yes</check_dev>
    <check_sys>yes</check_sys>
    <check_pids>yes</check_pids>
    <check_ports>yes</check_ports>
    <check_if>yes</check_if>

    <!-- Scan frequency: every 12 hours -->
    <frequency>43200</frequency>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
    <skip_nfs>yes</skip_nfs>
</rootcheck>

If we look at /var/ossec/etc/shared/rootkit_trojans.txt, we can see several commands that become signature of trojans to do malicious activities when being executed.

# Common binaries and public trojan entries
ls          !bash|^/bin/sh|dev/[^clu]|\.tmp/lsfile|duarawkz|/prof|/security|file\.h!
env         !bash|^/bin/sh|file\.h|proc\.h|/dev/|^/bin/.*sh!
echo        !bash|^/bin/sh|file\.h|proc\.h|/dev/[^cl]|^/bin/.*sh!
chown       !bash|^/bin/sh|file\.h|proc\.h|/dev/[^cl]|^/bin/.*sh!
chmod       !bash|^/bin/sh|file\.h|proc\.h|/dev/[^cl]|^/bin/.*sh!
chgrp       !bash|^/bin/sh|file\.h|proc\.h|/dev/[^cl]|^/bin/.*sh!
cat         !bash|^/bin/sh|file\.h|proc\.h|/dev/[^cl]|^/bin/.*sh!
bash        !proc\.h|/dev/[0-9]|/dev/[hijkz]!

On the other hand, /var/ossec/etc/shared/rootkit_files.txt contains a list of known trojan-related files that Wazuh Rootcheck scans for on monitored endpoints. This list helps detect the presence of malicious files commonly associated with rootkits.

# Bash door
tmp/mcliZokhb           ! Bash door ::/rootkits/bashdoor.php
tmp/mclzaKmfa           ! Bash door ::/rootkits/bashdoor.php

# adore Worm
dev/.shit/red.tgz       ! Adore Worm ::/rootkits/adorew.php
usr/lib/libt            ! Adore Worm ::/rootkits/adorew.php
usr/bin/adore           ! Adore Worm ::/rootkits/adorew.php
*/klogd.o               ! Adore Worm ::/rootkits/adorew.php
*/red.tar               ! Adore Worm ::/rootkits/adorew.php

Simulating a Suspicious Binary Attack

1. First, create a backup of an existing system binary before modifying it:

   sudo cp -p /usr/bin/w /usr/bin/w.copy
   

2. Replace the legitimate binary with a malicious script that performs unauthorized actions:

   sudo tee /usr/bin/w << EOF
   #!/bin/bash
   echo "\$(date) - This is an evil script" > /tmp/trojan_created_file
   echo "Test for /usr/bin/w trojaned file" >> /tmp/trojan_created_file
   # Running the original binary
   /usr/bin/w.copy
   EOF
   

   This script logs a fake message and then executes the original binary to maintain normal functionality, making it harder to detect.

3. The Rootcheck scan runs every 12 hours by default, but you can force a scan immediately by restarting the Wazuh agent:

   sudo systemctl restart wazuh-agent
   

4. Once the scan completes, Wazuh detects the modified binary and generates an alert. Navigate to the Threat Hunting module in the Wazuh dashboard.

You can also use the search filter to monitor specific alert:

location:rootcheck AND rule.id:510 AND data.title:Trojaned version of file detected.

🎯 Conclusion

That’s it! Ubuntu VM is now running the Wazuh agent and sending logs to the manager. In the next post, I’ll explore how to do some integrations with third-party API such as VirusTotal for active response and maybe Discord for alert notifications. Stay tuned!