Security Tools: Wazuh
In the last HomeLab post, I built out a Wazzuh SIEM and tried to see if I could start seeing emulated attacks. Unfortunately, I could not capture the correct information to see the attacks happening. After the post, I tried several other attack emulations with Invoke-AtomicRedTeam. I had even set up a new SIEM and Server on a standalone environment to ensure the firewall or network wasn’t causing issues. With nothing working, I decided to go back to the basics and read the Manual. Thankfully, with that, I understand more about why I could not view the attacks and how to utilize Wazzuh. I will go over the basics of how to use Wazzuh and how to configure a few things.
Let’s start at the beginning, logging into Wazzuh. After getting the VM running and connecting to the IP it will give us a loading screen as it makes sure everything gets configured.
After that we can go ahead and get signed in the default credentials are username: admin password: admin. You will be unable to change the password from the web GUI.
To do that we must SSH into the VM.
Now that we are connected to the Wazuh VM we have to run the following commands in order to get the password changed.
curl -so wazuh-passwords-tool.sh https://packages.wazuh.com/4.8/wazuh-passwords-tool.sh
*Note that you will need to make sure you get the right version number in the URL. Since I am running the 4.8 version that is the version I will target
sudo bash wazuh-passwords-tool.sh -u admin -p Secr3tP4ssw*rd
Now, with the password changed we need to restart the services in order for it to pull the new admin password.
Restart the following services with the “systemctl restart” command. Then using the “systemctl status” to ensure the service is in an active (running) state.
Wazuh-indexer
Wazuh-manager
Wazuh-dashboard
Filebeat
Now the password has been reset you can log in to the Web GUI. It may take a few minutes for the Web GUI to come back up after the restarts.
Dashboard
Now that we are in the Wazuh GUI it starts us off with a few options.
Get Matthew Smith’s stories in your inbox
Join Medium for free to get updates from this writer.
As you can see here the home page gives a lot of options to choose from. We can either look at the agents attached or see the alerts that have come through.
Adding Agents
First lets start off by adding a computer to Wazuh. We’ll first got to endpoints, you can do so by clicking wither active or disconnected in the Agents Summary.
Then scroll down until you see Agents. In that section there should be a button to Deploy new agent.
Once you click the button you should see a page like this.
Since I am using a windows machine right now I will of course select the windows button.
Then it will ask for the FQDN or IP address of the Wazuh server. This is not the local machines IP or name
Then as an additional option it will ask to name the device. This doesn’t matter too much it is only how Wazuh will display the device. Below it is another optional addition, if you wanted you could create different groups and have different machines assigned to them for organizational purposes.
Once that is done it will give you a command to run. For windows this needs to be run in an Admin powershell window.
Then to start the agent and get it active under Wazuh it will have you restart the Wazuh service.
Now we can see the agent is active in our Agent Dashboard!
Agent Dashboard
Clicking on the agent allows you to drill down into a better view of the computer.
As you can see it gives a lot of information right off the bat. Let’s quickly break it down. At the top you will see the basic info like name, IP, status, etc. Then below that it shows the MITRE ATT&CK, this box shows any alerts that the SIEM has correlated with certain attack tactics in the MITRE framework. Clicking on the different tactics will show MITRE’s tactic number.
If you click on the tactic it will show you the exact events that it is correlating.
Next box is the Compliance section. This is an amazing section that shows us our compliancy with specific regulations.
And if you drill down it will tell you what exactly it compliant with and if there are any hits for non compliance.
The next two sections are FIM or File Integrity Monitoring and SCA or Security Configuration Assessment. I will be getting into both of these more in the next section so I’ll keep it brief. FIM will show you if there are any alerts for the file integrity. This will need to be set up in order to start getting alerts. Then SCA compares the OS to its CIS Benchmark and will give a scoring. Right now since the server I am using has just been turned on and nothing has been done to it I have a pretty okay score.
You can dive even deeper by clicking More.. up top.
Secure Configuration Assessments
Now we let’s get into the SCA section. By clicking on the scan it will show you a breakdown of the results. As you can see a majority of the configurations from the benchmark aren’t applicable.
But if you click on a failed test it tells a description and the reason for the configuration, as well as how to remediate it.
Security Events
Now by using the Threat Hunting option we can see what is going on with the device.
This shows us the total amount of events, if there are any high-level events or any authentication failures and successes. On the bottom, it also shows the top alerts.
By going to the events tab you can see the different events and get more information on each one.
File Integrity Monitoring
Now let’s get into something I find really cool: File Integrity Monitoring. By going to the said option on the agent dashboard, this will tell us if any files or registry keys have been modified. This can be key if you have it set to monitor the places most attacks may modify or store things.
But when first going to it you won’t be able to see anything.
But if you go to inventory you will see it has already scanned your system.
In order to make a new rule or alert we will have to go to the agent configuration file. This will be on the host machine, for windows this will be under C:\ProgramFile(x86)\ossec-agent. Go to the ossec.conf file and open it with the notepad.
Once you open it up it’s going to show a lot of text and probably be a bit confusing if you have never worked with a configuration file before. Don’t worry we’re going to a very specific part of the file. Using CTRL+F find the file integrity monitoring section.
Here you can see the default files to its monitors and the frequency of the scans.
Now under the 32-bit programs (it doesn’t really matter where it is placed in all honesty) add a new line and insert the following bit. Make sure the spacing lines up with the others or you will break things.
<directories realtime=“yes” report_changes=“yes” check_all=“yes”>C:\Users\*\Desktop</directories>
After you save make sure to restart the Wazuh service. Once the service is back up and running now we can test it out by adding a file to the desktop and modifying it.
Now on the events tab it will show the change. We can now see that a file was created, the deleted means it was renamed, and the checksum was changed meaning that the file has been modified.
Now the same thing can be done to monitor certain registry keys. Under the same section you can scroll down a little further and you will see the registry section. To add a new path to monitor you will have to do much the same as with the files. The entry will look like:
<windows_registry>(Registry Path)</windows_registry>
Setting up Sysmon logs
Now that we have a good grasp of Wazuh, we can start adding extras to it. One of the things I like to add is Sysmon. Sysmon helps log a lot of detailed information, a lot more than the default logs. But it first must be installed and deployed.
First step is to download from https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon and extract it.
Then download the sysmonconfig-export.xml from https://github.com/SwiftOnSecurity/sysmon-config and place it inside the sysmon folder.
Then run the following command as an admin in powershell:
C:\(file path)\sysmon/Sysmon.exe -accepteula -i sysconfig-export.xml
Now that sysmon is installed we’ll need to make sure the logs get sent to Wazuh. Going back to the configuration file we will add an entry to point the sysmon logs to Wazuh.
As you can see, getting this setup wasn’t too difficult, and it can add a lot of value to your monitoring capabilities. I hope this overview was both helpful and practical, providing insight into Wazuh’s potential.
However, this is just the beginning. There’s still much to learn — configuring alerts, optimizing dashboards, and fine-tuning the system for maximum efficiency. I’m excited to continue exploring Wazuh’s full capabilities, and I hope you’ll stick around for future updates as I dive deeper into this powerful SIEM solution.
