Hack The Box – Sherlock – Meerkat

Background:

Sherlock Scenario

As a fast-growing startup, Forela has been utilizing 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 have a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.

Files Downloaded

Meekrat.zip
SHA256:
a76867ade304c8081e2023cbf2977c65e8c146180b2e0ff760e4059d042c2a5a

Zip Password: 
hacktheblue

Contents:
Meerkat.pcap
SHA256:
aa3838dbd634f9798d1e9505d243a4fee1d340d6e25e2f0c9648dd64e2178dbf

Meerkat-alerts.json
SHA256:
012aa4e8aae5d500c001510d6e65567eb0cdbfffe2dab9a119b66f7770c222be

Step 0:

Install jq for command line viewing of JSON

Test:

Looks good, json is parsed nicely now.

Install sublime text and the JsFormat plugin

Download

wget -qO - https://download.sublimetext.com/sublimehq-pub.gpg | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/sublimehq-archive.gpg > /dev/null

Select stable channel 

echo "deb https://download.sublimetext.com/ apt/stable/" | sudo tee /etc/apt/sources.list.d/sublime-text.list

Install

Task 1

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

Scrolling through the JSON in sublime, it’s clear we will need to parse / carve a lot of this data to figure out what alerts are beneficial. Sure, we might get lucky but scrolling through 10,000+ lines does not seem very efficient. SO we will head over to our terminal and carve out some data using jq.

Jq documentation: https://jqlang.github.io/jq/manual/

cat meerkat-alerts.json | jq ‘[.[] | {alert: .alert.signature}] | sort | unique’ 

This is essentially just a giant for loop stating that for each item in the JSON array (.), get the alert signature ({alert: .alert.signature}) and then sort (sort) the items and filter out any duplicates (unique).

We could change out main query {alert: .alert.signature} to any item / sub item and the alert: can be anything

But now we have a smaller array with the alerts that were triggered.

Here we can see a couple of EXPLOIT detections for Bonitasoft and some associated CVEs

*********t

We are technically done with this but we should do some research on what this CVE is

https://nvd.nist.gov/vuln/detail/CVE-2022-25237

https://rhinosecuritylabs.com/application-security/cve-2022-25237-bonitasoft-authorization-bypass/

This is also interesting, this is likely scanning or brute force activity.

Task 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?

Let’s dive into the python requests we saw earlier and test out theory.

cat meerkat-alerts.json | jq ‘[.[] | select(.alert.signature | strings | test(“python”;”i”))]’

Here we are again looping through our entire JSON array but now instead of creating an array with just the alert name and de-duping them, we are looking for every alert with the string python (test(“python”,”i”)), and pulling back the alert details. The “i” in this case is simply stating this is a case insensitive search.

Here we can see some potentially useful information, the source/destination IP, ports, and the action. 

If we look at all the source IPs, we can get a sense of if this is a single IP or if it is spread out.

We will do this just like we did before, pipe the results and filter down to dest_ip and again for src_ip

So here we can see 2 IPs with python talking to a single IP

Suspicious IPs:

• 138[.]199.59.221
• 156[.]146.62.213

Targeted IPs:

• 172[.]31.6.44

Let’s move over to our pcap and see if we have any valuable data for these IPs, starting with 138.xxx

Right off the bat I can see posts to bonita loginservice

Diving into this packet, we can see a couple different usernames and password being tried, and the user agent of python-requests/2.28.1

We see a successful login from the seb.broom account and then a file upload

I realized I was diving a little too deep too quickly and not answering the main question here, what was the attack?

I took a step back and looked at the traffic with a python user agent:

Here we see a lot of attempts, primarily coming from 156.xxx, but later coming from the 138.xxx address we were looking at earlier

A lot of these login attempts are for the install account, but the unique logins all seem to have different passwords

This looks to me like the attacker is trying credentials that they already have, not just random passwords from a wordlist.

This is likely credential stuffing

Task 3

Does the vulnerability exploited have a CVE assigned – and if so, which one?

We accidentally answered this earlier, CVE-2022-25237

Task 4

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

We can check for the API URI by filtering down to packets where the http request URI contains API. Here we can see a couple different packets, coming from both the 156.xxx address and the 138.xxx address. We can also see what looks to me like command injection or possible c2 with api posts calling cmd=whoami and cmd=cat/etc/passwd.

If we look at the Request URI Path Segments for these posts, we can see all of them seem to have i18ntranslation. We can also see this same IOC in the CVE Documentation

Task 5

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

There is probably a way to do this by looking at the alerts but in my mind I am thinking what if the alert missed something or didn’t trigger, so I did this in wireshark with some filters.

((((http.user_agent contains “python” ) && (http.request.method == “POST”)) && (http.request.full_uri == “http://forela.co.uk:8080/bonita/loginservice”))) && !(urlencoded-form.value == “install”)

This will show me all the login attempts that were not for the generic “install” account.

We get a total of 59 packets

We then need to dedupe this list.

To make this a little easier, I made the username field a column using the “Apply As Column” option in wireshark. 

I then saved the packet dissections as a csv so I can easily work with them

So we have 58 deduped results, one of these is the column header, the other is the install account. If we take these two out, we have 56 results.

**

Task 6

Which username and password combination was successful?

We accidentally found this earlier, but we will pretend we didn’t.

Let’s look at all the HTTP traffic from our server

(ip.src == 172.31.6.44) && (_ws.col.protocol == “HTTP”)

Now, we can see a lot of 401 responses, so those are the failed attempts. Let’s filter those out.

((ip.src == 172.31.6.44) && (_ws.col.protocol == “HTTP”)) && (http.response.code != 401)

We are left with a couple 302 and then some 200 responses.

Let’s follow the http stream of the 200 response

Here we see the failed install:install credentials (indicated by the 401 response) and then a successful authentication for seb.broom%40forela.co.uk

If we fix the encoding for this we get the username and password.

This is pretty obvious but for reference:

https://www.w3schools.com/tags/ref_urlencode.ASP

seb.broom@forela.co.uk:g0vernm3nt

Task 7

If any, which text sharing site did the attacker utilize?

When I was first poking around in the alerts I noticed a .io url by looking for URLs with regex

We can then take this hit and search for the http traffic and see if it seems to line up with the attack

We could have also found this by looking at the GET requests made earlier

Pastes[.]io

Task 8

Please provide the filename of the public key used by the attacker to gain persistence on our host.

I tried looking into the url itself but it appeared to have been taken down.

I tried looking for a way to find the response in the pcap but I came up short.

Luckily, I was able to find an archived copy of the site using archive.org and was able to see the script downloaded. 

The same went with the second file curled

Filename:hffgra4unv 

Task 9

Can you confirm the file modified by the attacker to gain persistence?

This is evident in the bash script we see, the attacker is editing the authorized_keys file

/home/ubuntu/.ssh/authorized_keys

Task 10

Can you confirm the MITRE technique ID of this type of persistence mechanism?

Some super quick Googling here

T1098.004

And we are done with this Sherlock!