Deploying Wazuh on Active Directory Environment

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 the Active Directory. It will walk through adding agents into Wazuh, Using the CIS Benchmark tool and going over on how to use it to support compliance. As well as configuring the File Integrity monitor to pick up on integrity violations on User Desktop. At the end, the configuration of the vulnerability module will also be covered.

To get the Wazuh OVA download we can google “wazuh ova” or just head to the link above. 

Once there, just click on the link as shown below.

Save the OVA in a spot you can remember. Open up Virtual Box and navigate to “file” in the top left corner. Then click on “Import Appliance”.

Browse to the location where you saved the OVA file and click “Open”.

In the application settings, keep everything default then click “Finish”. Once done importing the OVA, make sure that the Wazuh Virtual box is highlighted and click on “Settings” at the top.

Inside settings, click on display, and change the graphic controller to VMSVGA. The official Documentation brings up that we have to change the graphic controller settings to VMSVGA or else the Virtual Machine will start freezing on us.

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). Dependiong 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 navigate to the “Network” tab and make sure that it’s on the “Internal Network” with the name “intnet”.

Lastly, navigate to General and put the shared clipboard and Drag’n’Drop to “Bidirectional.”

At this point, make sure that the DC virtual machine is on so that the Wazuh server can get an IP address.

I used the domain admin account to log in, which was in the “a-XXXXX” format.

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 below then you’re all set. Log in using the credentials shown.

You can do a “sudo -i” to go to the root account.

We’ll need to know the IP Address to access the Wazuh website.

It’ll be very easy to know if you have an IP, as the logs will pop up on the console that the time is being synced up. But you can check by running an “IP a” command on the Wazuh Server or checking on the Domain Controller, inside of the server manager -> Tools ->DHCP then look for Address leases.

Seems to match up. 

I also started up the Client1 Machine and logged in using the same account from the DC machine.

Once logged in, open up Microsoft Edge (or Chrome, or just any browser of your choosing) then navigate to “https://<WazuhIP>” just as seen below.

The user and pass for this page is “admin:admin”. Once everything is done loading, you’ll be greeted with the dashboard.

Adding Agents

Adding Agents onto 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 of 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 in the internal network we can just do the IP address.

For step 5 I named the agent “Client1-VC” and clicked on the default group.

While keeping the page open, search up PowerShell at the bottom left and run it as administrator. Click on yes if it asks if you want powershell to make changes to the system.

For step 6, click on the PowerShell command to copy it and paste it on 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 do a quick glance over of the agent dashboard and go over how teh CIS Benchmark tool can help support organiczations to 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.

Now this dashboard is for the Client1 machine. 

On the left-hand side, it lets us know what top tactics were found and can be used against the machine.

On the right it shows us if we are compliant or not with specific laws and standards.

At the very bottom, there is the File Integrity monitor which reports to us if a specific file was made, changed, or deleted on specific locations.

Below the FIM is an Event count.

And even further down we can see that the client1 machine was tested with a CIS benchmark test. And we seem to have failed it miserably with a 32%.

We can click on the benchmark for more information.

We will see the checks we have failed and passed. By clicking on a check we can see what compliances it is tied to, the reason 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 being compliant can put them at risk of being fined a hefty amount, loss of reputation and trust, and prison time can also get involved.

I also made the domain controller into an agent. The CIS benchmark test came back with a 72% Score. 

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 changing. 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 on any changes done to specified locations

Let’s take a look at file integrity. But first.. lets go over on how and where to configure where Wazuh monitors for integirty violations.

Open client1’s File explorer, click on “This PC”, then double click on Local Disk.

Then 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 be monitored.

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 do some changes on the file.

The integrity monitor will show you any changes done 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 seen below, we can see the changes I made to the super secret file.

Vulnerabilities Module

Vulnerability Scanner in wazuh

In this section we will go over on how to enable the vulnerability module inside of Wazuh.

By default the Vulnerabily Module is off.

Inside of 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” inbetween the “enabled” tags to “yes”. Save and quit the file.

Ensure that in “/etc/resolv.conf” file the nameserver is set to the internal DNS IP. Which is 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 will see it reporting back on found vulnerabilities.

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 intesrested in teh critical vulnerabilities, you can click on the number below it. So in this case, the red 22. This will filter for only the critical.

Scroll down and you will see them.

For me, they sadly didn’t give out the remediations straight out like with the CIS benchmark tool, but it does give you references. These references usually give you the 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.