2. Take part of the Red v Blue team event

Introduction

On the 22th of November on the Monday morning the Red v. Blue event officially began. Of course, prior to the event starting I already did some preperation according to the assignment. I held an interview with a teacher that was supervising the excercise to become more familiar with the context of the assignment.

The goal

The goal was to simply have red-teamers test out applications made by security engineers; and have the blue team monitor the applications and use a SoC in tangent.

Preperation

For this assignment we created a duplicate of our development environment (on vSphere); in case a critical bug was found we didn’t want to have to quarantine and rebuild the environment. So we duplicated some servers in preperation. For our group assignment (which is a blue team training): we have also set up research into security operation centers. In which we concluded that Wazuh was the best suited for our use case (cyber security trainees). We decided to use this SoC for the red v. blue team event.

VPN

Instead of spawning countless machines in the network our application was running on, I decided on the morning on the event to implement a VPN and distribute it among the red team participans - granting them direct access. I shared this VPN also with the blue team, who could access the SoC.

Event

Prior to the event, I signed myself up as a SoC-manager (which was one of the blue team roles). Along with myself, I had two other students that participated in the blue team; since we had a 3-man SoC I assigned both of the other students to be T1 + T2 analysts. During the event, we performed triage and took note of interesting incidents; which in a real life situation would be communicated to the real customer.

Incidents

When the event started, lots of scanning, enumerating and, fuzzing was performed by the red-teamers, despite being explicitly told to be subtle they went all out and the decrease in performance became quickly noticeable.

Blue-team actions

Due to this, I immediately began taking notes as to what actions we needed to perform to ensure smooth operation:

1. Remove false positives from appearing on the dashboard

2. Reboot the machine and add more RAM + CPU on vSphere

3. Filter enumeration, scanning & fuzzing tools

Most of the filtering could be done if the advesary was outside of the network, and an IPS/IDS solution was implemented - this thought occured to me before the event but I reckoned it wouldn’t be any fun at all to the redteamers.

T1 / T2 incidents + triage

I delegated interesting looking alerts to the other students in the blue-team, down below you will see examples of those incidents.

Incident #1:

Request on : http://172.16.1.17/static/js/server-status

Action: T2 Analyst will look further into possibilities

Result: (by Maxim van Esch)

Triage

Apache version info is shown when performing a GET request on a non-existing page (returns 404).

SoC-manager(me): // Is it possible to hide the version info and how? //

Result: Yes it is possible to hide version info on error pages (https://drujoopress.wordpress.com/2013/12/19/how-to-remove-apache-version-and-os-identity-from-errors-pages/)

Open the Apache config file (/etc/apache2/apache2.conf) and modify the following settings:

ServerSignature Off -> This makes sure the server signature will not be send when a request is being performed

ServerTokens Prod -> this tells Apache to return only Apache as product in the server response header on every page request, It suppresses the OS, major and minor version info.

After running these command you need to restart the Apache/Httpd service to apply the changes.

Incident #2:

Request on : SSH login attempts

T2 analyst will write a short report and make an advise for the ‘ customer ‘

Somebody tried to login as user root using SSH. However the used password was incorrect. Also, the same attacker (with IP 172.16.1.35) tried to login using SSH wiht a non-existing user.

To be able to use SSH, port 22 needs to be open/forwarded. When opening/forwarding ports theres always a risk. A solution for this would be to close port 22 and only allow users to access the network/services through a trusted VPN connection. VPN connection profiles (.ovpn) files can be generated by the system admin and handed over (locally) to machines which are trusted within the internal network. This way only the port for setting up VPN connections (1194 for OpenVPN) needs to be open/forwarded. This is also a risk, but much smaller compared to the SSH port (22)

Since in this case the advesary had direct connection to the network, this solution while effective if that isn’t the case – couldn’t be implemented due to the context of the assignment

Incident 3#

OWASP: Common web attacks

T2 Analyst(Max Eggens) will review the inputs, create a list and forward it to the ‘ customer ‘

Attack type: GET request to obtain page’s content

Methods

Process Injection: inject code into processes in order to evade process-based defenses as well as possibly elevate privileges.

Process injection is a method of executing arbitrary code in the address space of a separate live process.

Running code in the context of another process may allow access to the process’s memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process., File and Directory Discovery, Exploit Public-Facing Application

Notes:

Injecting “GET /_mem_bin HTTP/1.1” to reveal webpage content

Received error 404 : Attack failed

Conclusion

We had to remove a lot of false/positives from appearing on the dashboard to make sense of what was going on. It is possible to do this natively within Wazuh, so for example only Suricata alerts appear (most of these alerts came from ossec)

Statistics

Eventually when Wazuh had received up to 800 thousand alerts, it stopped logging new alerts; the disk-space ran full. We tried resolving this during the event, but failed in doing so.

When I did some research later on, I discovered it was possible to add a new disk to a vSphere machine (since we couldn’t extend the original 20gb) – and tried using a weird LVM setup to mitigate the issue but couldn’t get it to work. When looking at it, again, later, I discovered (with the help of a teacher who was testing on his account) that checkpoints prevents vSphere from extending the original disk. So we ran a clone of this machine, removed all of the checkpoints and then we extended the disk. With a simple command, the disk was extended:

cfdisk -> extend sda1 -> save