---
# System prepended metadata

title: '**CCF Lab 4 - SIEM Deployment for Threats Detection**'

---

:::success
# **CCF Lab 4 - SIEM Deployment for Threats Detection**
## **Gideon Emmanuel Oki**
:::
## Task 1 - Wazuh deployment.
:::info
Install Wazuh SIEM solution in any way (deployment scenario) that you prefer. Consider a possible lab environment:

- Wazuh server (could be as a part of Elastic stack).
- Wazuh agents (workers under monitoring, at least one node, but more is better).
- Attacker host (not mandatory, but much better to have).

It's up to you where to create the lab environment and its nodes (locally or in the cloud). But make sure that if you are going to simulate an any attacks/threats or exploit vulnerabilities, your **attacker host and workers are in isolate network**. Thus, it's recommended do not perform any illegal actions it the cloud. **This is in your area of responsibility, be very careful and attentive!**
*`Bonus: prepare a different agents: Windows and Linux based.`*
:::

For this lab I opted to setup a server with 2 agent machines and an attacker machine. I will also have the interfaces of the devices in NAT and connected to the SNE Lab network. The entire lab would be done locally.
:::warning
![](https://i.imgur.com/ZuZuLJu.png)
Machines for the lab.
:::

**Server:** CentOS 7, `192.168.25.149/24`.
**Agent1:** Linux Mint, `192.168.25.150/24`.
**Agent2:** Windows 10, `192.168.25.1/24` || `10.1.1.10/24`. This is my base OS.
**Attacker:** Kali-Linux, `192.168.25.153/24`.

:::warning
![](https://i.imgur.com/OXtYVFv.png)
Wazuh Server.

---
![](https://i.imgur.com/9eWzxdh.png)
Agent1.

---
![](https://i.imgur.com/2t8ZaFp.png)
Agent2.

---
![](https://i.imgur.com/sdrT7DL.png)
Attacker.
:::
With the details above, I decided to install the Wazuh Server components (Wazuh Indexer, Wazuh Server and Wazuh Dashboard) using the quick start option instead of installing the components individually I settled for the convenience script (Quickstart option using Wazuh Installation Assistant).

On the Wazuh Server I then ran the command: 
`curl -sO https://packages.wazuh.com/4.4/wazuh-install.sh && sudo bash ./wazuh-install.sh -a`

:::warning
![](https://i.imgur.com/YbXXUTv.png)
Installation completed.
:::
I then accessed the web browser and used the server ip address to get in.

:::warning
![](https://i.imgur.com/rourjH7.png)
landing page.
:::

Next I went on to add the individual agents to the server via the web interface.

:::warning
![](https://i.imgur.com/Q4a2IpS.png)
adding agent1 on the server.

---
![](https://i.imgur.com/A6IiEDj.png)
on agent1.

---
![](https://i.imgur.com/pp29YPZ.png)
adding agent2 on the server

---
![](https://i.imgur.com/ttQHmb7.png)
on agent2.
:::

Past experiences have taught me that some servers might require that the firewall be toyed with.
But after some troubleshooting I got the two agents in position as they should.

:::warning
![](https://i.imgur.com/GPlz8J3.png)
agent1 and agent2 on the dashboard.
:::


## Task 2 - Configure the SIEM.
:::info
Once Wazuh is installed, make familiar with its features and manager interface (it's not mandatory to describe in the report). Then configure agents ossec rules to work with a various Wazuh security processing possibilities. Rules types and amount depends on how many different Wazuh features you are going to try in the next task.
:::

I navigated through the different sections and tried to get familiar with the different offerings.
:::warning
![](https://i.imgur.com/XNqP88Z.png)
modules window.
:::

For the next task I will be going for File Integrity Monitoring (FIM), Detecting a Shellshock attack and Intrusion Detection/ Detecting a brute-force attack. I will be demonstrating these concepts in the next section.

I should also mention here that i will be focusing my demonstrations on the agent1 in particular.

:::warning
![](https://i.imgur.com/tQqXywi.png)
`/var/ossec/etc/ossec.conf` showing some entries on agent1.
:::

some rules were also defined in `/var/ossec/ruleset/rules` a custom-rules file was created and the following entries were registered.

```
<group name="local,syslog,sshd">
  <rule id="100105" level="8">
    <if_sid>5700</if_sid>
    <match>sshd.*Failed password for|sshd.*Invalid user</match>
    <description>Multiple failed SSH login attempts</description>
  </rule>
</group>
```
but I opted for using the ossec.conf file to implement the PoCs.

## Task 3 - Play with SIEM in action.
:::info

Wazuh provides a numerous possibilities for Security Operations Center (SOC) implementation such as:
- Log Data Analysis.
- Cloud Security.
- Container Security.
- File Integrity Monitoring.
- Intrusion Detection.
- Security Audit and Analytics.
- Vulnerability Detection.
- Policy Auditing.
- Monitoring Logons.
- Incident Response.
- ...

By simulating attacks and security threats or exploiting vulnerabilities on agents, try out as many of the above Wazuh features in action as possible. The number of features is limited only by your capabilities, resources and time. Nevertheless, try to test at least two different Wazuh features.

Regarding how to check the operability of your SIEM system and get security incidents. In fact, it is absolutely your freedom to choose which methods and techniques to use for this. First of all, they are related to the functionality of Wazuh that you plan to test. Consequently, the choice of methods and tools for emulating security threats on agents is really wide, so here we just give a some motley sketch of examples:
- [testmynids](http://testmynids.org/).
- [https://testmyids.com](https://testmyids.com/)
- [hydra brute force](https://www.kali.org/tools/hydra/)
- [Atomic Red Team tests library](https://github.com/redcanaryco/atomic-red-team).
- [Caldera](https://github.com/mitre/caldera).
- [DVWA](https://github.com/digininja/DVWA#linux-packages).
- [Nikto web scanner](https://www.kali.org/tools/nikto/).
- [Detection guides on Wazuh official blog](https://wazuh.com/blog/).
- ...

At the end, also learn Wazuh Incident Response features, generate Wazuh security reports and analyze its content.
:::
For the Proof of Concept for the chosen features:

### FIM.

First I accessed the client machine `agent1`.
I then created a directory where I will be demonstrating my test. `/home/wazuhagent1/Downloads/FIM-directory/`. I then made some changes to the `/var/ossec/etc/ossec.conf` 

:::warning
![](https://i.imgur.com/iwUofyw.png)
monitoring in place for the file/directory.
:::

Afterwards I issued the command: `systemctl restart wazuh-agent.service`.

next I used the command `touch home/wazuhagent1/Downloads/FIM-directory/FIMtest.txt` to create a file in the monitored directory. I repeated the same operation creating a second file and then deleting it subsequently to see if it would be recorded on the manager.

:::warning
![](https://i.imgur.com/oL7xfBN.png)
From homeage, I selected Integrity Monitoring.

---
![](https://i.imgur.com/2GQ1cow.png)
Event Tab showing active monitoring.
:::

Given Linux treats everything as a file I opted to monitor a directory which is considered a file in linux but this can also be done for a particular file or a single text file for example...

:::warning
![](https://i.imgur.com/rdXrmhd.png)
creating the FIMtest file for the PoC

---
![](https://i.imgur.com/P2ZA13y.png)
ossec entries to ensure wazuh monitored the file for any possible changes after saving the file `systemctl restart wazuh-agent.service` was ran..

---
![](https://i.imgur.com/z1RQ7EK.png)
entires in the monitored file. 

---
![](https://i.imgur.com/DVJ0UvO.png)
the changes to the file is flagged at the 

---
![](https://i.imgur.com/puBnYxn.png)
digging into the event even further.

---
![](https://i.imgur.com/3fJxbfm.png)
other interesting things including the apparent changes to the file.
:::

### Detecting a Shellshock Attack.
On the agent1 machine, I will be installing a webserver and try to attack the webserver with a shellshock attack.

First, I installed the webserver using: `sudo apt install nginx`.

Next I enabled it through the firewall using: `sudo ufw allow 'Nginx Full'`.

:::warning
![](https://i.imgur.com/eN9bUoz.png)
checking the staus of the installed webserver.

---
![](https://i.imgur.com/54bNvW9.png)
webserver accessible from the attacker machine.
:::

I then made some entries in /var/ossec/etc/ossec.conf
```
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/nginx/access.log</location>
  </localfile>
```
Afterwards I restarted the wazuh agent.

I then went to the attacker machine to attempt the shellshock attack.
`sudo curl -H "User-Agent: () { :; }; /bin/cat /etc/passwd" 192.168.25.150` command was used.

:::warning
![](https://i.imgur.com/mT8yiBO.png)
the event is captured on the dashboard.

---
![](https://i.imgur.com/mosfaZc.png)
looking into the attack further.
:::

### Detecting Brute-Force.

For this, I opted to try a bruteforce attack from the attacker machine to the agent1 machine and see if the manager could flag this activity.

First I downloaded two sample of files from this [project](https://github.com/danielmiessler/SecLists/tree/master/Passwords). 

I will also use hydra on the attacker machine to carry out this attack.

:::warning
![](https://i.imgur.com/z64kVfT.png)
actively bruteforcing the agent1.

---
![](https://i.imgur.com/S3aC5hu.png)
From the hompage i selected Security Events.

---
![](https://i.imgur.com/Yu6BDM0.png)
Inspected the logs and selected bruteforce and then clicked on events.

---
![](https://i.imgur.com/X0P3txn.png)
closer inspection of the entries in the logs.
:::
:::warning
![](https://i.imgur.com/rX1eObm.png)
generating report to be analyzed.
:::

:::success
**REFERENCES**

- [Wazuh Documentation](https://documentation.wazuh.com/current/index.html).
- [File Integrity Monitoring](https://documentation.wazuh.com/current/proof-of-concept-guide/poc-file-integrity-monitoring.html).
- [Detecting BruteForce](https://documentation.wazuh.com/current/proof-of-concept-guide/detect-brute-force-attack.html).
:::