Shoppy

January 18, 2026

Driver

Created by	Page	Difficulty	OS
lockscan	Hack The Box	Easy	Linux

Enumeration

I began with a full TCP port scan, followed by a service and version detection scan on the discovered open ports

  nmap -p- --open -vvv --min-rate 3000 -Pn -sS 10.10.11.180 -oG scan
  /opt/extractports scan
  nmap -p22,80,9093 -Pn -sCV 10.10.11.180 -oN ports

I performed virtual host enumeration using ffuf

  ffuf -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt -u http://shoppy.htb/ -H 'Host: FUZZ.shoppy.htb' 

This revealed the virtual host mattermost.shoppy.htb, which I also added to /etc/hosts

I enumerated directories and endpoints on the main web application:
```
  feroxbuster --url http://shoppy.htb/
```
This revealed the endpoint /login.php
When testing the login form, submitting a single quote (') caused a server-side error, suggesting possible injection vulnerabilities

Initial NoSQL injection attempts using standard form data were unsuccessful. I then changed the Content-Type to application/json and sent a JSON-formatted request:
```
  {
      "username":"admin",
      "password":"admin"
  }
```
Although authentication failed, the application accepted the request format.
By injecting malformed NoSQL payloads, I triggered error messages that leaked a filesystem path: /home/jaeger, confirming the existence of a system user named jaeger.
I continued testing NoSQL injection payloads and successfully bypassed authentication using the following payload in the username field (with any password):
```
  admin' || 'a'=='a
```
After authentication, the application displayed a product list and a user search feature.
Searching for users revealed that:
- The admin user existed, but its MD5 hash could not be cracked.
- By abusing the same NoSQL injection logic, I was able to enumerate all users.
This revealed a user named josh along with an MD5 password hash.

I cracked the hash using Hashcat:

  hashcat -m 0 6ebXXXXXXXXXXX995 /usr/share/wordlist/rockyou.txt

This recovered the plaintext password for the user josh.
mattermost.shoppy.htb
To identify the Mattermost version, I accessed the following endpoint:
```
  http://mattermost.shoppy.htb/api/v4/config/client?format=old
```
This confirmed the version as Mattermost 7.1.2.
Using Josh’s credentials, I logged into the Mattermost instance. While reviewing the available channels, I found sensitive credentials for the user jaeger posted in the Deploy machine channel.
Since jaeger was a valid system user, I attempted SSH authentication:
```
  ssh jaeger@10.10.11.180
```
This granted shell access and allowed me to retrieve the user flag.

I checked which commands jaeger could execute with elevated privileges:
```
  sudo -l
```
The user was allowed to execute /home/deploy/password-manager as the user deploy without a password.

I copied the binary for offline analysis by encoding it in Base64:
```
  cat /home/deploy/password-manager | base64 -w 0
```
After reconstructing the binary locally, I analyzed it using Ghidra.
The main() function revealed that the program prompts for a password. If the password equals “Sample”, it prints the contents of /home/deploy/creds.txt.

I executed the binary as the deploy user:

  sudo -u deploy /home/deploy/password-manager

By providing the correct password, the program disclosed credentials for the deploy user.
I then authenticated via SSH
```
  ssh deploy@10.10.11.180
```

I checked group memberships and found that deploy belongs to the docker group.
This allows mounting the host filesystem into a container. I ran the following command:
```
  docker run -v /:/mnt -it alpine
```
This mounted the root filesystem under /mnt, allowing unrestricted access to system files. From there, I accessed the root directory and retrieved the final flag.