Deployment
Deploying Wazuh onto Active Directory
Heavy Resources
The DC VM, Client1, and the Wazuh server will be using 10-12 vCPU, 12 GB of RAM, and 110 GB of storage. I will make a separate document that covers Wazuh using Linode so that the lab environment isn’t too resource-heavy.
If you have 20+ Logical Processors and 32 GB of RAM, this lab can be easily done without Linode.
Lab Brief Summary
This lab will cover the deployment of a Wazuh Server onto Active Directory. It will guide you through adding agents to Wazuh, using the CIS Benchmark tool to ensure compliance, and configuring the File Integrity monitor to detect integrity violations on user desktops. Additionally, the configuration of the vulnerability module will be covered at the end.
Now, to get started with this lab, we need to get the Wazuh OVA.
We can obtain it either by searching for “wazuh ova” on Google (or your preferred browser) and clicking the first result, as shown below, or by following the link provided above.
Once there, click on the “virtual appliance (OVA)” link as shown below.
Save the OVA file in a location that you can easily recall. Then, open VirtualBox and go to the “File” menu at the top left corner. From there, select “Import Appliance”.
Click on the little folder with the green arrow to browse to the location where you saved the OVA file and select “Open”.
In the application settings, leave everything as default, then click “Finish”. After importing the OVA, ensure that the Wazuh VirtualBox is selected, then click “Settings” at the top.
Inside the newly popped-up settings window, click on display on the left-hand side, and change the Graphics Controller to “VMSVGA” as shown in the picture below. The official documentation states that we have to change the graphics controller settings to VMSVGA, or else the Virtual Machine may start crashing.
The recommended configuration for 1-25 agents/clients is 4 vCPU, 8 GB of RAM, and 50GB of storage. I will be using the 4 processors and the 50 GB of storage, but bump down the RAM to 4 GB (4096). Depending on your setup, you can do the same, or you may be able to bump down the processors to 2 instead of 4. You can change these settings under the “System” tab.
Then go to the “Network” tab and make sure that the network adapter is on the “Internal Network” with the name “intnet”.
After that, go to “General” and put the shared clipboard and Drag’n’Drop to “Bidirectional.”
At this point, make sure the DC virtual machine is “on” so the Wazuh server can obtain an IP address.
I used the domain admin account, which was in the “a-XXXXX” format, to log in.
Once the DC VM is on and running, start up the Wazuh Server VM.
It might take a bit for it to start up. Once you see the screen shown below, then you’re all set. Log in using the credentials shown.
You can do a “sudo -i” to change to the root account.
We’ll need to know the IP Address to access the Wazuh website.
It’ll be very easy to tell if you have an IP, as logs will appear in the console indicating that the time is being synced. But you can check by running an “IP a” command on the Wazuh Server, or by checking on the Domain Controller in “Server Manager” -> “Tools” -> “DHCP”, then look for “Address leases”.
The IP addresses seem to match up.
I also started the Client1 Machine and logged in using the same account as on the DC machine.
Once logged in, open Microsoft Edge (or Chrome, or any browser of your choosing), then navigate to “https://<WazuhIP>,” as shown below.
The user and pass for this page are “admin:admin”. Once everything has finished loading, you’ll be greeted by the dashboard.
Adding Agents
Adding Agents to the Wazuh server
Let’s add the DC and Client 1 machines as agents so that we can explore Wazuhs functionalities. Click on Add agent.
Inside the new agent menu, click on Windows, Windows 7+, and the last option should be auto-selected. Then, for step 4, since the Wazuh server is on the internal network, we can use its IP address.
For step 5, I named the agent “Client1-VC” and clicked on the default group.
While keeping the page open, search for PowerShell in the bottom-left corner and run it as an administrator. Click Yes if it asks whether you want PowerShell to make changes to the system.
For step 6, click the PowerShell command to copy it, then paste it into the PowerShell window. It will say that the service has started successfully once done running.
We can head back to the dashboard and reload the page to confirm that the agent is active. Which seems like it is.
Compliance Support
Wazuh can be used to support compliance
This section will provide a quick overview of the agent dashboard and explain how the CIS Benchmark tool can help organizations become compliant with industry standards and laws.
We can then click on the “1” below either the total or active agents.
Scroll down and click on the actual agent.
This dashboard is now for the Client1 machine.
On the left-hand side, it shows which top tactics were identified and can be used against the machine.
On the right, it shows us the number of recommendations we can make to help with compliance with specific laws and standards.
At the very bottom, there is the File Integrity monitor, which reports to us whether a specific file was created, modified, or deleted in specific locations.
Below the FIM is an Event count.
And even further down, we can see that the client1 machine was tested against a CIS benchmark. And we seem to have failed it miserably, at 32%.
We can click on the benchmark for more information.
We will see which checks we have failed and which we have passed. By clicking on an entry, we can see which compliance it is tied to, why we should care, how to fix it, and what it checks to confirm it.
It’s very important for organizations to be compliant. Not doing so can put them at risk of hefty fines, loss of reputation and trust, and even prison time.
I also made the domain controller into an agent. The CIS benchmark test returned a 72% Score on the first assessment.
I messed around for a bit and remediated 10 failures. Managing to bring the score up to 90%. It was a lot of group policy changes. Going through the remediations is great practice and a learning opportunity. Client1 has 260+ failures, and I plan on going through those on my own time.
File integrity
Monitors for any changes made to specified locations
Let’s take a look at file integrity. But first, let’s go over how and where to configure Wazuhs configuration file for the FIM.
Open client1’s “File Explorer”, click on “This PC”, then double click on “Local Disk”.
Then double click “Program Files (x86)”
After that, double-click on “ossec-agent”. Click “continue” if the permissions pop-up appears.
Scroll down until you find “ossec.conf”, then right-click and open it with “Notepad”.
Once inside the Notepad, do a “Ctrl+F” and search for “syscheck”. It will take you to the file integrity monitoring section. Here we can add what directories and files we want to monitor.
Below is the line that I added to monitor the desktop of the “a-vcoil” account. Make sure you put your username. After that, just save the file.
Once saved, open up “PowerShell” with administrator privileges and run the command “restart-service -name wazuh”.
I already had a “superSecret” note on my desktop before doing the changes. But you can make one and change the file.
The integrity monitor will show you any changes made to files and if any files were deleted.
If you click on an event, it will show you the changes made and additional information. As shown below, here are the changes I made to the super secret file.
Vulnerabilities Module
Vulnerability Scanner in Wazuh
In this section, we will cover how to enable the vulnerability module in Wazuh.
By default, the Vulnerability Module is off.
Inside the Wazuh Server, vim into “/var/ossec/etc/shared/default/agent.conf”, and add in the code shown below. Save and quit the file.
After adding that, vim into “/var/ossec/etc/ossec.conf” and you may have to scroll down until you notice “vulnerability detector”. Once found, change the “no” between the “enabled” tags to “yes”. Save and quit the file.
Ensure that in the “/etc/resolv.conf” file, the nameserver is set to the internal DNS IP. Which will be the Domain Controller IP.
This will allow Wazuh to pull the databases from NVD and MSU.
After making those changes and ensuring the nameserver is correct. Do a “Systemctl restart wazuh-manager” to restart the Wazuh service.
After a bit of time, you’ll be able to navigate to the vulnerability module and see it reporting on the vulnerabilities found.
If you need to do additional troubleshooting because it’s not updating. This command helped me a lot. “cat /var/ossec/logs/ossec.log | grep -i -E “vulnerability.”
If you’re interested in the critical vulnerabilities, click the number below. So in this case, the red 22. This will filter for only the critical vulnerabilities.
Scroll down, and you will see them.
For me, they sadly didn’t provide the remediations straight away, unlike with the CIS benchmark tool, but it does give you references. These references usually provide remediation or other ways to fix the vulnerability.
They do give you the condition, and usually when you see the “KBXXXXXX”. It just means to update the system.
This concludes the Wazuh Lab.