Welcome BACK to my Blue Side adventures. For several years now, I have practiced setting up home lab environments for the sake of practicing penetration testing and red team methodologies. I bet I still have quite a collection of VulnHubs on a drive somewhere around here. But something that has been missing, is getting a better look at Blue Team habits. How much better can my offense be if I can get familiar with the defensive scheme?  For us college football fans, let’s call it sign stealing (LOOKING AT YOU, MICHIGAN!).

For those who happen to stumble here and are currently or soon to be looking to start breaking into cybersecurity, I feel like a project like this can help you tremendously.  When I’ve talked about “home lab” in past interviews, it was like, a Kali VM and a DVWA VM, Metasploitable, something like that.  You go in and talk about Wazuh SIEM with vulnerability scanning + Suricata IDS/IPS, red team / blue team whatever it is we about to do in this blog series, you’ll easily blow other candidates like me at the time away, with my weak Kali VM setup 😜.

In this month’s article, I go through integrating Wazuh, a free and open-source platform used for threat prevention, detection, and response, with our quad-Raspberry Pi setup discussed in previous blogs, plus adding 1 Windows target victim VM. I’ve also been playing around with Portainer a lot more, putting Dockge away for now. Portainer is said to be the most versatile container management software that simplifies your secure adoption of containers with remarkable speed. So far, as one who is attempting to containerize anything and everything, I think it’s been a great addition. Even though not required, I will include the installation steps below.

Thankfully, I was able to give myself a good amount of time to prepare this blog, as there are several new components for me to get familiar with.  I wanted to get all the agents up and running for a while to simulate a normal environment before starting to test evading and getting into my devilish red team ways. I was even able to get a bit of a diagram assembled. Yes, feel free to laugh at me for using the router graphic to represent my mini-PC haha.

The end goal:  To understand if I’m saying the name right, “Wa-zaa”, or “Wa-zoo?!” Ok, I’ve heard it pronounced both ways, but they say “Waz-aa” in their own video, so I’m rolling with that!

All jokes aside, there is a lot going on with this multi-part series, I want to ensure the end goal vision is obvious.  I want to set up Wazuh SIEM container (current version 4.7.4), and agents on a handful of hosts, learn a bit about how it works, try some things that require research, and eventually look at how to possibly bypass detection.  I start off here with just having an Ubuntu VM ready to go.

After getting the Ubuntu VM booted, I start by installing docker and docker compose:

sudo apt install docker.io docker-compose -y

I grab Portainer for some nice docker management:

sudo docker run -d -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Then I just visit 127.0.0.1:9000 to get to my Portainer page and set up an account.

Now I’m set to grab Wazuh docker container and begin setup:

git clone https://github.com/wazuh/wazuh-docker.git -b v4.7.4 && cd wazuh-docker

cd single-node && sudo docker-compose -f generate-indexer-certs.yml run --rm generator

sudo docker-compose up -d

After a short time, back in Portainer, we see Wazuh containers are up and running:

Slide over to the right, and see the exposed ports for the wazuh-dashboard:

443, so all I have to do is visit https://localhost and get redirected to the login page

The default username and password for the Wazuh dashboard are `admin` and `SecretPassword`.

Raspberry Pi agent deployment

As seen in previous posts, I have 4 Raspberry Pis, named after the kids on South Park. Within Wazuh, I follow the necessary steps to add agents to each of my Pis:

Add agent > DEB aarch64 > 192.168.0.249 > cartman

Add agent > DEB aarch64 > 192.168.0.249 > kenny

Add agent > DEB aarch64 > 192.168.0.249 > kyle

Add agent > DEB aarch64 > 192.168.0.249 > stan

After each step, Wazuh will generate the custom commands needed to run on each of my Raspberry Pis:

CARTMAN

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.4-1_arm64.deb && sudo WAZUH_MANAGER='192.168.0.249' WAZUH_AGENT_NAME='cartman-agent' dpkg -i ./wazuh-agent_4.7.4-1_arm64.deb

KENNY

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.4-1_arm64.deb && sudo WAZUH_MANAGER='192.168.0.249' WAZUH_AGENT_NAME='kenny-agent' dpkg -i ./wazuh-agent_4.7.4-1_arm64.deb

KYLE

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.4-1_arm64.deb && sudo WAZUH_MANAGER='192.168.0.249' WAZUH_AGENT_NAME='kyle-agent' dpkg -i ./wazuh-agent_4.7.4-1_arm64.deb

STAN

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.4-1_arm64.deb && sudo WAZUH_MANAGER='192.168.0.249' WAZUH_AGENT_NAME='stan-agent' dpkg -i ./wazuh-agent_4.7.4-1_arm64.deb

As instructed by Wazuh, the following command are required on each host to finish configuration:

sudo systemctl daemon-reload

sudo systemctl enable wazuh-agent

sudo systemctl start wazuh-agent

Windows agent deployment

While Wazuh does provide a PowerShell command for me to use on the Windows host, I’ve noticed other users opting to use the GUI Wazuh Agent Manager, so I figured I’d do the same. Download and run: https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.4-1.msi

All I needed here was the same Wazuh IP I used for the raspberry pi agents:

Back in Wazuh:

Enabling Vulnerability detection

I got really stuck here for a while.  I enabled this feature, and everything on the Raspberry Pis just worked.  However, the Windows 10 host did not.  Or it did, and I just did not understand what was happening. Here’s what happened, and how I was able to sort it out.  Here was the problem:

No matter what I did, I could not get any Windows findings to populate. First issue, I was editing Wazuh configurations within the dashboard GUI, and since this is a docker environment, those changes were not persistent. Every time the stack restarted; my changes were lost. Editing the “wazuh-docker/single-node/config/wazuh-cluster/wazuh_manager.conf” file allowed me to keep my changes even after restarting the environment.  The second issue, was to include “hotfixes”  in the Windows agent settings, outlined here:  https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/configuring-scans.html

Here is what I did to enable the vulnerability detector within “wazuh-docker/single-node/config/wazuh-cluster/wazuh_manager.conf”

Modify the vulnerability-detector setting to “yes”

Enable Ubuntu, Debian, Windows

Enabling the hotfixes setting within the Windows Wazuh agent (C:\Program Files (x86)\ossec-agent\ossec.conf)

Restarted the agent:

From here, I just gave it some time, came back in a few hours, and got results.

I tested this with an unpatched Windows 8.1 and got expected results:

So then, finally, I was able to apply the same steps to an unpatched Windows 10 VM and got the expected results.

Before patch: Found a CVE that says a KB is not installed.

I then applied all the updates that Windows had to provide at that time, and the resulting findings were tied to the vulnerable VLC I intentionally installed for testing:

So, to conclude this section, if you have a fully patched Windows OS, and no intentionally installed vulnerable software, you are likely to see zeros on this page! This does not mean that Wazuh is not working. I was even able to test by uninstalling Windows updates, scanning, then re-applying those Windows updates.

Finally, I have a working instance of Wazuh, and I’m ready to begin some real hands-on learning. I do want to start with some easier / script kiddie stuff, like using Hydra to brute force services, plain MSFVenom generated reverse shells ran on disk / memory, that kind of stuff. 

So, between the 4 Raspberry Pis, who to pick on?  Cartman, Kenny, Kyle, or Stan?? Kenny always gets picked on, right? So, I guess he’s used to it, and that’s who I’ll pick on. Now, I could just fire up a Kali instance, and run nmap / Hydra, but I’d like to contain as much of the Pi testing within the Pis as possible, so I am going to just install Hydra and perform the attacks from another pi, but who to run the attack from? I’m going to attack from my Stan pi, as he’s last on the list, and really has not been utilized yet.

sudo apt install hydra nmap

I’m also going to need some word lists, so I’m grabbing SecLists from GitHub, and shove them in /usr/share/wordlists directory I just created

sudo mkdir /usr/share/wordlists && cd /usr/share/wordlists

sudo git clone https://github.com/danielmiessler/SecLists

Nice.  I’m all set to set off some alarms. I start this experiment with 0 authentication failures, and filtering only on the last 30 mins:

Then, I kick-off a lengthy brute attack:

hydra -L /usr/share/wordlists/SecLists/Usernames/Names/malenames-usa-top1000.txt -P /usr/share/wordlists/SecLists/Passwords/Common-Credentials/10k-most-common.txt 192.168.0.251 ssh -f -s 22

Came back to it after a while, and to my surprise, there are no Authentication success or failures recorded on the dashboard.

Hm.  Seems I have ran into yet another mystery!

Without any concrete evidence, I suspected that the auth.log file within the pi would be the way Wazuh would capture these ssh login attempts and display them on to the dashboard, so this is where I started.  I went into the /var/log directory, and what do ya know, I do not even have an auth.log file! Did some quick digging, and I guess auth.log has not been a thing from Debian 8 onward….?

I’d love to know what would be best practice to get such a log over to Wazuh dashboard, but here is what I did, I installed rsyslog:

sudo apt install rsyslog

Which brought back auth.log. While my Hydra is still running, I keep an eye on the log:

tail -f /var/log/auth.log

Then, I just had to add a section in the Kenny raspberry pi ossec.conf file that pointed to the auth.log:

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

Restart the agent:

sudo service wazuh-agent restart

I can see the failed login attempts as they happen. Perfect, let’s check Wazuh dashboard:

How about that!  We can now start seeing our attack take place. Another small victory in my Wazuh-ventures!

I let Hydra hit SSH for a bit, then ran a few seconds hitting RDP for giggles. Next, dive in the dashboard and look around. First, I use the search bar to and query for “sshd”, significantly reducing the amount of findings to dig through. Scrolling down to the Security Alerts sections, we can start piecing things together:

Here is just a small piece of the several hundred results.

This seems to be a good spot to cut off the write up for now.  I feel like there’s a good amount accomplished here. As much as I wanted to dive into testing reverse shells this month, I ended up doing more testing to understand Wazuh. Not a bad trade off. I will, however, include below extra testing notes that may help others on this similar journey. See below >>>

Testing vulnerable software

I wanted to see how vulnerability DB integration worked, so naturally I jumped over to exploit-db and grabbed some apps. Below, I grab a few vulnerable applications, however neither Remote Mouse or PC Protect showed as a vulnerability in Wazuh Dashboard.

Remote Mouse (CVE-2021-35448)

https://www.exploit-db.com/exploits/50047

PC Protect (CVE-2018-17776)

https://www.exploit-db.com/exploits/45503

I couldn’t figure out why they would not appear on Wazuh, I had to do some research to find the following discussions.

https://github.com/wazuh/wazuh/issues/16727

https://www.reddit.com/r/Wazuh/comments/16ob1d9/microsoft_vulnerability_detection_not_workingor

I went ahead and ran Metasploit against this target and was unable to trigger reverse shell against Remote Mouse.  So, once a Windows PC is patched against a vulnerability, it will no longer appear in the Wazuh Dashboard. I was able to confirm Defender’s involvement by simply disabling real time protection and testing again.

Ok, so according to these, if I install VLC 3.0.8, I SHOULD get a finding within the Wazuh Dashboard.

VLC 3.0.8 (CVE-2023-47359)

https://nvd.nist.gov/vuln/detail/CVE-2023-47359

Ok fine so that worked lol.  But…. how come the other 2 known vulnerable software do not show up here as well?  I decided to copy over the cve.db from within the wazuh-manager container and see if I could find some answers.

sudo docker cp $(sudo docker ps | grep manager | awk '{print $1}'):/var/ossec/queue/vulnerabilities/cve.db .

Here, I’m using sqlite3 to navigate through the database, and verify the CVEs are indeed here.

sudo sqlite3 cve.db

.tables

.schema NVD_CVE

Below are some query examples to demonstrate how to extract desired details from this database:

SELECT * FROM NVD_CVE WHERE description LIKE '%VLC media player 3.0.8%';

SELECT * FROM NVD_CVE WHERE CVE_ID LIKE '%CVE-2021-35448%';

So the CVEs do exists here in the cve.db, however they just do not seem to appear on the Wazuh dashboard. 

Taking a snippit from Wazuh docs: https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html

“For Microsoft Windows systems and specific Microsoft products, the Vulnerability Detector has the hotfixes option in the syscollector settings on the Wazuh agent. Using this option enables the module to detect packages that the user has patched. When the Vulnerability Detector detects a patch, it uses the information provided by Microsoft to decide if the patch has resolved the CVEs. Then, it removes them from the list of vulnerabilities.”

Agent management

There were a few times after modifying Wazuh configuration file or an agent configuration file, that there were communication issues between the two.  Here a few areas in Wazuh that were help tracking down issues:

Management > Logs

Settings > Logs

On a few occasions, I needed to just straight up delete an agent, and start over. Below are the steps I took to get into the correct docker container, load up the manage agents tool, and delete the agent in question:

sudo docker exec -it $(sudo docker ps | grep manager | awk '{print $1}') bash

/var/ossec/bin/manage_agents

L

R

$AGENT_ID

YouTube resources

Hackersploit does a great job going through some initial Wazuh set up, was very helpful in getting things rolling after installation.