🛡️ Hack the box- Meerkat Complete Solution

---

🐾 Introduction: A Startup’s Security Wake-Up Call

In this Hack the Box sherlock, Forela, a fast-growing startup riding the wave of digital innovation, had a simple goal: scale fast and manage efficiently. Like many small businesses eager to streamline operations, they adopted a business management platform. Unfortunately, in their race to grow, documentation and security practices were left behind in the dust.

The company’s internal team had a suspicion: their business platform might have been breached. The only clue? A handful of exported artefacts: network traffic in PCAP form and JSON-formatted Zeek alerts.

In this write up, I’ll walk you through how I unravelled this breach—from evidence handling to identifying a credential stuffing attack—while teaching core skills like Zeek analysis, packet forensics, and MITRE ATT&CK mapping. Buckle up.

---

🔍 Scenario Recap

You’ve been hired by Forela to analyze suspicious activity on their internal systems. You are provided with two main files:

• A packet capture file (meerkat.pcap)
• A Zeek alerts log (meerkat-alerts.json)
• Everything is bundled in a password-protected ZIP archive (meerkat.zip)

Your job: confirm if an attacker compromised the Business Management Platform, identify the method of exploitation, and document any persistence mechanisms used.

---

🧰 Tools You’ll Need

Here’s what we’ll use throughout the analysis:

Tool	Purpose
Wireshark	Graphical network packet analysis
tshark	Command-line version of Wireshark
jq	JSON parser for digging into alerts
CyberChef	Encoding/decoding and data analysis
Wayback Machine	To recover removed malicious payloads

---

📁 Unzipping the Evidence

Let’s extract the contents of meerkat.zip:

unzip meerkat.zip
# Enter password: hacktheblue

You should now have:

• meerkat.pcap
• meerkat-alerts.json

These files contain all the clues we need to trace the attacker’s steps.

---

🧪 Step 1: Exploring Zeek Alerts with jq

Zeek is a passive network monitoring tool that records structured logs from network traffic. It’s incredibly useful in IR (Incident Response) investigations.

Install jq if you don’t already have it:

sudo apt install jq

Then parse the JSON alert file:

jq '.[]' meerkat-alerts.json | less

This strips out the top-level JSON wrapper and allows us to scroll through each alert cleanly.

We’re now ready to dive into specific questions the Forela team asked—starting with the nature of the compromised application and method of attack.

Thanks for your patience! Here’s Part 2 of the rewritten Meerkat Writeup—continuing from where we left off. This section tackles Questions 1–6, giving detailed, explanatory answers while weaving in CLI usage, analysis logic, and the rfut persona.

---

🔎 Part 2: Tracing the Breach – Attack Discovery and Exploitation

---

❓1. What Business Application Was Compromised?

To identify the target of the attack, we begin by filtering the Zeek alerts for any clear indicators about exploited applications.

Using jq:

jq '.[].alert.signature' meerkat-alerts.json

This lists all the alert signatures Zeek detected. Among them, one in particular catches our attention:

BonitaSoft - Business Platform Exploitation Attempt

🔍 BonitaSoft is a well-known business process management (BPM) tool. It enables workflow automation but has a documented vulnerability (more on that next). From this, we confirm that BonitaSoft is the application Forela was using—and the one attackers were targeting.

✅ Answer: BonitaSoft

---

❓2. What Type of Brute Force Attack Was Used?

Now that we know BonitaSoft is the target, we dig deeper into how attackers gained access.

First, we review this vulnerability writeup about CVE-2022-25237—an authentication bypass that lets attackers escalate privileges if they have valid login credentials and an active session token.

That suggests one thing: the attacker needed valid credentials first. Time to look for signs of a brute-force attack.

---

🎯 Step-by-step: Wireshark Investigation

1. Open the PCAP: wireshark meerkat.pcap
2. Use this display filter to isolate relevant traffic: http.request.uri == "/bonita/loginservice" && http.user_agent == "python-requests/2.28.1"
3. Go to: Statistics → Conversations → TCP tab Here we see repeated connections from the attacker’s IP: 138.199.59.221 to the server: 172.31.6.44:8080.
4. Right-click one of these streams → Follow → TCP Stream
   We observe credential attempts being passed in cleartext—because HTTP is unencrypted.

---

🔍 Next Level: tshark Credential Extraction

Instead of examining every stream manually, we’ll extract login attempts with tshark:

tshark -Y '(http.request.uri == "/bonita/loginservice") && \
(http.user_agent == "python-requests/2.28.1")' -r meerkat.pcap -T json \
| jq '.[]._source.layers.http."http.file_data"' | sort | uniq

This command pipeline:

• Applies a filter to capture login attempts
• Converts PCAP data to JSON
• Uses jq to extract submitted credentials
• Sorts and filters to show unique username-password pairs

---

🧠 Attack Type Analysis

Based on the data:

• The attacker uses realistic-looking usernames
• Tries uncommon passwords for each
• Doesn’t repeat passwords across multiple accounts

That rules out:

• Password Guessing (random combos)
• Password Spraying (same password on many users)
• Password Cracking (offline hashes)

Instead, it matches Credential Stuffing—reusing known credentials from breach dumps, hoping users reused them in BonitaSoft.

✅ Answer: Credential Stuffing

---

❓3. Was a CVE Used? Which One?

Going back to our earlier jq filtering, we can refine it to show CVE mentions:

jq '.[].alert.signature' meerkat-alerts.json | grep CVE

This gives:

Exploit Attempt: BonitaSoft Authorization Bypass - CVE-2022-25237

So yes, the attacker exploited a known vulnerability, CVE-2022-25237. Public exploit code exists for it, making it easy to reproduce if a system is unpatched.

✅ Answer: CVE-2022-25237

---

❓4. What Bypass String Was Used in the Exploit?

This vulnerability lets attackers bypass authorization filters by appending a specific string to the API URL.

Checking the exploit analysis again, we learn the bypass uses:

;i18ntranslation

To confirm this in the PCAP:

• Follow a TCP stream of a successful attack
• Look for this in the HTTP GET request:

GET /bonita/API/pageUpload;i18ntranslation

This bypasses normal access controls and allows unauthorized file uploads or actions.

✅ Answer: i18ntranslation

---

❓5. How Many Credential Combinations Were Used?

We return to our tshark+jq combo from Question 2, but this time we want to count the lines:

tshark -Y '(http.request.uri == "/bonita/loginservice") && \
(http.user_agent == "python-requests/2.28.1")' -r meerkat.pcap -T json \
| jq '.[]._source.layers.http."http.file_data"' | sort | uniq | wc -l

Output:

57

But there’s a twist: the exploit script automatically tries the default creds install:install every time. This doesn’t count toward our unique credential stuffing attempts.

So we subtract one:

57 - 1 = 56

✅ Answer: 56

---

❓6. Which Credentials Worked?

Now we need to figure out which credential pair was accepted by BonitaSoft.

Back in Wireshark:

1. Apply the same display filter: http.request.uri == "/bonita/loginservice"
2. Navigate to: Statistics → Conversations → TCP
3. Sort by packet count.

Why? Successful sessions involve longer conversations. Failed logins return HTTP/1.1 401 Unauthorized and terminate quickly. Successful logins continue with POST requests or file uploads.

By following streams from longer conversations, we discover:

username=seb.broom@forela.co.uk
password=g0vernm3nt

But %40 is URL-encoded for @. We decode it using CyberChef:

• Drag in URL Decode
• Paste: seb.broom%40forela.co.uk
• Result: seb.broom%40forela.co.uk

But since we’re using the alias rfut, we reframe this as if the attacker successfully compromised:

✅ Answer: seb.broom@forela.co.uk:g0vernm3nt

---

🧬 Part 3: Persistence, Payloads, and Post-Exploitation

---

❓7. Which Text-Sharing Site Did the Attacker Use?

After gaining access, the attacker needed a way to download their next-stage payload. This is often done using simple HTTP GET requests to file-hosting or pastebin-style services.

Back in Wireshark:

1. Use the same display filter from before (targeting /bonita/loginservice)
2. Head to: Statistics → HTTP → Requests
3. Scroll through the listed requests and you’ll spot a URL that stands out:

GET http://pastes.io/raw/hffgra4unv

This tells us the attacker used pastes.io, a pastebin-like service, to host a malicious script.

✅ Answer: pastes.io

---

❓8. What Was the Filename of the Public Key Used for Persistence?

The URL above (pastes.io/raw/hffgra4unv) hosted the attacker’s payload, but what was inside?

Let’s try to access it. If the link is still live, you can browse to it directly. If not, use the Wayback Machine:

1. Go to: https://web.archive.org
2. Search for the pastes.io URL: https://pastes.io/raw/hffgra4unv
3. Load a snapshot from March 23rd.

Inside, you’ll find an SSH public key. The script shown in the paste adds it to the .ssh/authorized_keys file of the current user.

Key name from the paste:

hffgra4unv

✅ Answer: hffgra4unv

---

❓9. Which File Did the Attacker Modify to Gain Persistence?

The SSH key described in Question 8 was used to enable remote, passwordless access. This is a classic persistence technique in Linux environments.

In the payload script, we observe this command:

cat hffgra4unv >> /home/ubuntu/.ssh/authorized_keys

This tells us the attacker modified the authorized_keys file to insert their own public key—granting SSH access as the ubuntu user.

✅ Answer: /home/ubuntu/.ssh/authorized_keys

---

❓10. What Is the MITRE Technique ID for This Persistence Method?

Looking at the MITRE ATT&CK Enterprise Matrix, under the Persistence tactic, we find:

• T1098 – Account Manipulation
• Specifically:
  • T1098.004 – SSH Authorized Keys

This describes exactly what we observed: the adversary added a key to authorized_keys to maintain access.

✅ Answer: T1098.004

---

✅ Conclusion: What We Learned from Meerkat

In this investigation, we dissected a real-world exploitation scenario using a vulnerable business platform—BonitaSoft. The attacker carried out a credential stuffing attack, leveraging reused credentials to gain access and escalate privileges using a known CVE.

Once inside, they fetched a malicious SSH key from pastes.io, enabling persistent access via authorized_keys. All of this was clearly traceable through open-source tools like Wireshark, tshark, jq, and CyberChef.

By aligning each stage of the attack with the MITRE ATT&CK framework, we built a full picture of the attacker’s strategy—from initial access to persistence.

---

🔧 Skills You Practiced

• Zeek alert analysis with jq
• Network traffic analysis with Wireshark and tshark
• URL decoding and payload examination
• Identifying brute-force attack sub-techniques
• Mapping attacks to MITRE ATT&CK

---

💬 Final Thought from rfut

This scenario wasn’t just about catching an attacker—it was about understanding their mindset. Each tool we used told part of the story, but only when we stitched it together did the full picture come into focus.

Whether you’re blue teaming in a real SOC or just learning the ropes, the Meerkat case is a brilliant reminder: even small oversights like reused credentials or unpatched software can open the door to persistent threats.

---