Introduction to Wazuh: Setting up and Detecting Malware

Summary

This guide will walk you through the initial installation of Wazuh, including the setup process on various operating systems, and provide instructions for integrating essential tools like Sysmon for enhanced logging and monitoring. We will download and deploy the Wazuh .ova. As always, you can use the hypervisor of your choice; however, the walk-through is targeted to Virtual Box users.

Lab Setup

Download the Wazuh .ova file and import it to you hypervisor. You can download it from this link.

https://packages.wazuh.com/4.x/vm/wazuh-4.7.4.ova

Download Mimikatz to your Windows VM using Power Shell. Be sure to change the user from dafga in the -OutFile path.

Invoke-WebRequest -Uri https://github.com/ParrotSec/mimikatz/archive/refs/heads/master.zip -OutFile C:/Users/dafga/Downloads/mimikatz.zip

Download and Deploy Wazuh OVA

Wazuh provides a pre-built virtual machine image in Open Virtual Appliance (OVA) format. This can be directly imported to Virtual Box or other OVA compatible virtualization systems

Import and access the virtual machine

1. Import the OVA to the virtualization platform.

In this case it throws an error because the VM has already been imported and is present. Otherwise the .ova will be successfully imported.

2. If you’re using Virtual Box, set the VMSVGA graphic controller. Setting another graphic controller freezes the VM window.
- 2.1. Select the imported VM.
- 2.2. Click Settings > Display
- 2.3. In Graphic controller, select the VMSVGA option.

3. Start the machine.
4. Access the virtual machine using the following user and password.

user: wazuh-user
password: wazuh

You can use the virtualization platform or access it via SSH. It is easiest to access via SSH using Putty so that copy/paste functions properly.

SSH root user login has been deactivated; nevertheless, the wazuh-user retains sudo privileges. Root privilege escalation can be achieved by executing the following command:

Access the Wazuh dashboard

Shortly after starting the VM, the Wazuh dashboard can be accessed from the web interface by using the following credentials:

URL: https://<wazuh_server_ip>
user: admin
password: admin

To obtain the <wazuh_server_ip>, execute the following command in the VM:

After navigating to the ip address the Wazuh wizard login page should be accessible:

Upon logging in, the primary dashboard becomes visible.

Configuring a Static IP Address

Assigning a static IP address to your server is crucial for maintaining consistent network communication. Relying on DHCP can result in the server receiving a different IP address, potentially disrupting connectivity with other hosts. This is particularly important for the Wazuh server, as its configuration and agents rely on a consistent IP address to transmit logs effectively.

You can configure a static IP address using a few straightforward commands. Although it is recommended to set the static IP address prior to configuring Wazuh, it can still be done afterward, provided the virtual machine retains the same IP address that was originally assigned during the Wazuh configuration.

It is not necessary to change the IP address from the one initially assigned. The first step is to verify the current IP address and the associated netmask.

ifconfig

As seen below the command gives the IP address as well as the netmask.

The default gateway could be discovered by using the command shown below

ip r

As shown below, the IP address can be made static by using the following command:

sudo ifconfig eth0 192.168.1.171 netmask 255.255.255.0

Set the default gateway using the following command:

sudo route add default gw 192.168.1.1 eth0

Add agents to Wazuh:

Initially there will be no agents added so there will be a prompt asking for a new agent to be added right on the main page.

In this case it could be seen that there are two agents so the fore-mentioned prompt cannot be seen.

Next an operating system on which the agent will be installed has to be chosen.
In this case it will be windows
After that the wazuh server’s ip address should be provided.
Rest of the settings below are optional.

Don’t forget to run the command above on the agent in order to install it.

After that this window could be closed.

The Power Shell script should be pasted on the VM that you want to install the agent.
(Presumably it is a windows machine)

Then start the service on the system the agent was installed with the following command:

The newly connected and active agent should be present on the Wazuh dashboard

Configure Wazuh to Monitor Sysmon Logs

Before going directly to configuring Sysmon to be able to work with Wazuh make sure it is already installed and configured on the agent/s.

Here is a link on how to do this:

Using Wazuh to monitor Sysmon events | Wazuh

1. Modify Wazuh configuration to read Sysmon logs from the Windows hosts.
   On the Windows VM, open a text editor (such as Notepad++ or Notepad) with Administrator privileges. Edit the C:\Program Files (x86)\ossec-agent\ossec.conf file and incorporate the following entries:

<localfile>
    <location>System</location>
    <log_format>eventchannel</log_format>
  </localfile>
 
  <localfile>
    <location>active-response\active-responses.log</location>
    <log_format>syslog</log_format>
  </localfile>


  <localfile>
      <location>Microsoft-Windows-Sysmon/Operational</location>
      <log_format>eventchannel</log_format>
  </localfile>

2. Restart the service:

NET STOP WazuhSvc
NET START WazuhSvc

Configuring Wazuh Server for Sysmon Events

1. Enable SSH access for the root user on the Windows VM:

• In the Wazuh VM, edit the SSH configuration file:

sudo nano /etc/ssh/sshd_config

• Change ##PermitRootLogin no to PermitRootLogin yes

• Save and exit
• Restart the SSH service

sudo service sshd restart

Test the configuration by creating rules to detect suspicious activity related to the mimikatz.exe process. Mimikatz is a well-known tool used for extracting Windows credentials, making it a critical target for monitoring.

Write the security rules:

• Edit the Wazuh rules file:

sudo nano /var/ossec/etc/rules/local_rules.xml

<group name="windows, sysmon, sysmon_process-anomalies,">
   <rule id="100000" level="12">
     <if_group>sysmon_event1</if_group>
     <field name="win.eventdata.image">mimikatz.exe</field>
     <description>Sysmon - Suspicious Process - mimikatz.exe</description>
   </rule>
   <rule id="100001" level="12">
     <if_group>sysmon_event8</if_group>
     <field name="win.eventdata.sourceImage">mimikatz.exe</field>
     <description>Sysmon - Suspicious Process mimikatz.exe created a remote thread</description>
   </rule>
   <rule id="100002" level="12">
     <if_group>sysmon_event_10</if_group>
     <field name="win.eventdata.sourceImage">mimikatz.exe</field>
     <description>Sysmon - Suspicious Process mimikatz.exe accessed $(win.eventdata.targetImage)</description>
   </rule>
</group>

sudo service wazuh-manager restart

Test Wazuh with Mimikatz

Extract the previously downloaded Mimikatz .zip file.

Open Power Shell as administrator and navigate to the extracted Mimikatz folder.

Run the following commands:

.\mimikatz.exe

.\mimikatz.exe: This command executes the Mimikatz executable file. The .\ at the beginning indicates that the file is located in the current directory.

privilege::debug

privilege::debug: This command instructs Mimikatz to enable debug privileges. These privileges grant powerful permissions, allowing the user to interact directly with system processes and memory, potentially bypassing security mechanisms.

log mimikatz.log

log mimikatz.log: This command enables logging, directing the output of Mimikatz commands to a file named mimikatz.log. This can be useful for later analysis or auditing purposes.

sekurlsa::logonpasswords

sekurlsa::logonpasswords: This command directs Mimikatz to retrieve and display plaintext passwords from the Windows Security Account Manager (SAM) database, which stores user account information, including passwords. The sekurlsa module in Mimikatz is specifically designed for handling credentials.

As demonstrated above, Mimikatz successfully retrieved the NTLM hash for the user dafga. This information is also logged in the mimikatz.log file.

On the Wazuh dashboard, navigate to “Security information management → Security events → Level 12 or above alerts” and you will be able to see alerts related to the Mimikatz activities.

Due to previous tests, numerous alerts are visible here. The only critical alert to focus on is the one related to mimikatz.exe.

This demonstrates that Sysmon logs are successfully being imported into Wazuh.

Malware Detection with Wazuh

With the successful configuration of Wazuh, we will now explore its advanced capabilities for detecting malware. Wazuh’s strength in malware detection is supported by a comprehensive suite of features, including log analysis, intrusion detection, and threat intelligence integration. Additionally, Wazuh provides real-time alerting, event correlation, and supports custom scripts for automated responses.

Wazuh employs various strategies to enhance its malware detection capabilities:

• Threat Detection Rules and File Integrity Monitoring (FIM): File Integrity Monitoring is a crucial security measure that identifies unauthorized changes to files and directories. Wazuh uses predefined threat detection rules to continuously monitor critical file modifications. This proactive approach helps in detecting suspicious activities, events, and patterns that could indicate malware infections or security breaches. FIM is integral to Wazuh’s malware detection strategy, overseeing file and directory changes to identify any unauthorized or unexpected alterations that may signal malware activity.
• Rootkit Behavior Detection: Wazuh utilizes its rootcheck function to identify anomalies indicative of rootkits — stealthy malware that hides its presence on compromised systems. By employing behavior-based detection techniques, Wazuh can detect activities associated with rootkits, such as unauthorized privilege escalation or attempts to obscure files or processes. Detection triggers alerts for further investigation and response.
• VirusTotal Integration: Wazuh enhances its malware detection capabilities through integration with VirusTotal, a web-based service that scans files and URLs for potential threats using multiple antivirus engines and threat intelligence sources. Suspicious files or URLs encountered by Wazuh are automatically submitted for analysis by VirusTotal. The results, which aggregate findings from various antivirus engines, are incorporated into Wazuh’s alerting system, increasing confidence in alerts flagged as malicious by multiple engines.
• YARA Integration: Wazuh leverages YARA, an open-source tool for identifying and categorizing malware based on binary patterns, to detect malware samples. YARA allows security professionals to create custom rules tailored to specific malware strains or behaviors not covered by standard Wazuh rules. These custom signatures can be seamlessly integrated into Wazuh’s ruleset, providing comprehensive monitoring of the environment for emerging threats.

Wazuh server setup for malware detection

To configure the Wazuh server with a CDB list containing malware hashes and establish the necessary rules for alerting when a file with a matching hash is detected, follow these steps:

1. Create a file in the CDB list: CDB lists are stored in the /ossec/etc/lists directory on the Wazuh server. To add a new CDB list for malware hashes, create a file named malware-hashes using the following command:

sudo nano /var/ossec/etc/lists/malware-hashes

2. Add malware hashes: Enter the known malware hashes into the CDB list using the key:value format, where the key represents the actual malware hash and the value denotes the name or keyword associated with it. Various sources provide malware hash lists suitable for the CDB list. One widely recognized source is the list published by Nextron Systems, available for download on their official GitHub page here. For testing purposes, we will create our own CDB list using the file hash for Mimikatz.zip.

Enter the following hash in the format shown below.

85061FB539F0E118805729C0D9EFA99E:mimikatz

3. Change permissions on the file malware-hashes.

sudo chmod 777 /var/ossec/etc/lists/malware-hashes

4. Add the CDB list under the default ruleset: To include the CDB list in the default ruleset, specify its location in the <ruleset> block of the Wazuh manager configuration file, located at /var/ossec/etc/ossec.conf. Open the configuration file and insert the following line:

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

<list>etc/lists/malware-hashes</list>

5. Write a rule to compare hashes: Create a custom rule in the Wazuh server’s /var/ossec/etc/rules/local_rules.xml file. This rule will trigger when Wazuh detects a match between the MD5 hash of a recently created or updated file and a malware hash listed in the CDB. When an event indicates the presence of a newly created or modified file, rules 554 and 550 will be activated:

sudo nano /var/ossec/etc/rules/local_rules.xml

<group name="malware,">
  <rule id="110002" level="13">
    <if_sid>554, 550</if_sid>
    <list field="md5" lookup="match_key">etc/lists/malware-hashes</list>
    <description>Known Malware File Hash is detected: $(file)</description>
    <mitre>
      <id>T1204.002</id>
    </mitre>
  </rule>
</group>

6. Restart the manager: To apply the changes, restart the Wazuh manager using the following command:

sudo systemctl restart wazuh-manager

We have successfully created a CDB list containing malware hashes and configured security rules for comparing these hashes against files on the Wazuh agent. Next, we will proceed to configure a Windows endpoint to monitor file changes and enable it to utilize the CDB list for hash comparisons.

Configure the Windows VM

On the Windows VM, use a text editor (notepad++ or notepad) and edit the C:\\Program Files (x86)\\ossec-agent\\ossec.conf file and add the following entries to track file changes in the Downloads folder. this as well

<!-- Directory Monitoring. -->
 <directories check_all="yes" realtime="yes">C:/Users/m122/Downloads</directories>

The following settings are configured:

• check_all="yes": This option ensures that Wazuh monitors every aspect of the file, including its size, permissions, owner, last modification date, inode, and hash sums.
• realtime="yes": This enables real-time monitoring, allowing Wazuh to trigger alerts immediately upon detecting changes.

After making these changes, restart the Wazuh service to apply them.

NET STOP WazuhSvc
NET START WazuhSvc

Testing

You can test the file modification rules by downloading Mimikatz to the Downloads folder using the following PowerShell command:

Invoke-WebRequest -Uri https://github.com/ParrotSec/mimikatz/archive/refs/heads/master.zip -OutFile C:/Users/m122/Downloads/mimikatz.zip

Check the alerts.

As seen below an alert was created when mimikatz.exe was downloaded to the Downloads folder.

Further testing can be conducted by deleting Mimikatz.exe from the Downloads folder and then reviewing the alerts to ensure that changes are detected.