root@thehacksparrow:~/writeups$ SYSTEM ONLINE
· log in sign up
← back to HackTheBox writeups
root@sparrow:~/writeups$ cat delivery.md
// writeups

Delivery

9 Jan 2021 · 11 min read
writeupshacktheboxlinuxEasyretiredvip
Delivery - maquina de Hack The Box

Executive summary — Delivery is an Easy Linux box that isn't solved with a technical exploit but by chaining logic flaws: osTicket is used as an indirect mailbox (<ticketID>@delivery.htb) to bypass Mattermost's email verification and get in; inside, an internal channel leaks maildeliverer's SSH credentials and the hint that root's password is a variation of «PleaseSubscribe!». A Mattermost configuration file exposes its database credentials, which we use to dump root's bcrypt hash; with the hint in hand we apply hashcat rules instead of brute force to crack the password, which turns out to be reused as the system's root password. An osTicket → Mattermost → SSH → MySQL → hashcat rules → root path.

PlatformHack The Box
Operating systemLinux
DifficultyEasy
StatusRetired
Target IP10.129.23.103

Attack map

[80] delivery.htb  +  [helpdesk] osTicket  +  [8065] Mattermost
   │  osTicket (guest): open a ticket → «<ticketID>@delivery.htb» mailbox
   │  Check Ticket Status trusts email+ID → an unvalidated mail viewer
   │  register on Mattermost with that email → read the confirmation in the ticket
   ▼
[Mattermost]  internal channel leaks: maildeliverer SSH creds + hint «root ~ PleaseSubscribe!»
   ▼
[SSH]  maildeliverer : Youve_G0t_Mail!  (user.txt)
   │  /opt/mattermost/config/config.json → mmuser:Crack_The_MM_Admin_PW
   │  MySQL → Users table → «root» bcrypt hash
   ▼
[hashcat]  base «PleaseSubscribe!» + best64 rules → PleaseSubscribe!21
   ▼
[ROOT]  su - (password reuse) → root.txt

1. Reconnaissance

We start by mapping the attack surface with two nmap passes: a fast sweep across every TCP port, then a second one with scripts and version detection against the ports found.

nmap -p- --min-rate 10000 10.129.23.103
nmap -p22,80,8065 -sC -sV 10.129.23.103
22/tcp    open  ssh
80/tcp    open  http
8065/tcp  open  http  (Mattermost)

Hypothesis: a public web port (80) plus a secondary application (8065) plus open SSH is a very typical pattern for an easy box: the entry point is the web app, and the end goal is reusable credentials for the system.

2. The main site and the vhosts

The site on port 80 doesn't have much functionality, but it mentions a helpdesk and warns that accessing Mattermost requires an email on the @delivery.htb domain. It also references delivery.htb and helpdesk.delivery.htb, which we add to /etc/hosts:

echo "10.129.23.103 delivery.htb helpdesk.delivery.htb" | sudo tee -a /etc/hosts

Why: many applications serve different content depending on the Host header or a specific subdomain; without resolving those names locally we'd lose entire routes. The @delivery.htb email requirement already hints at the key restriction: we don't control that domain… or so it seems.

3. The helpdesk: osTicket as an indirect mailbox

helpdesk.delivery.htb is an osTicket instance with a very specific logic: anyone can open a ticket as a guest with any email address, then check its status via Check Ticket Status by entering just email + ticket number. We open a ticket with an arbitrary email (e.g. test@test.com) and note the ticket number it's given.

The logic flaw: osTicket trusts that whoever knows the email and the ticket number is the legitimate owner, without ever validating that email. In a real system, if a ticket contains sensitive messages sent by email, you'd want strong guarantees that the user actually controls that address — here there are none, turning the helpdesk into an abusable mail viewer.

And here's the piece that ties everything together: when you open a ticket, osTicket also assigns you an email address on its own domain, <ticketID>@delivery.htb. Mail arriving at that address can be read from the ticket itself. Without ever controlling delivery.htb, we've still obtained a valid mailbox on it.

4. Practical bypass: registering on Mattermost

At http://delivery.htb:8065 we register on Mattermost using exactly that <ticketID>@delivery.htb address. Mattermost requires email verification and sends a confirmation email… which, being an internal email on that domain, lands right in our own osTicket ticket. We read it via Check Ticket Status, click the verification link, and the account is now active.

The lesson: we didn't need to break Mattermost's verification directly; it was enough to find another system (the helpdesk) that received and exposed those emails for us. Systems that talk to each other —helpdesk + email + chat— amplify each other's risk.

5. Inside Mattermost: leaked credentials

Once authenticated, we join the team and browse the available channels. In one internal channel, a privileged user has left credentials and a very specific hint about root's password:

maildeliverer : Youve_G0t_Mail!
# note: root's password is a variation of PleaseSubscribe!

The box changes phase here: up to now we were exploiting web logic; from here on it's credential reuse and lateral movement. PleaseSubscribe! isn't root's password yet, but it's a very strong semantic hint for the escalation.

6. Initial access over SSH

Port 22 was open from the initial recon; with leaked credentials and SSH active, testing for credential reuse is one of the first mandatory moves:

ssh maildeliverer@10.129.23.103
# password: Youve_G0t_Mail!
cat ~/user.txt

Initial access confirmed. Time for local enumeration.

7. Local enumeration: Mattermost's configuration

We know Mattermost runs on the box itself, so we check its configuration for database credentials or application secrets:

cd /opt/mattermost/config
cat config.json | grep -i sql
mmuser : Crack_The_MM_Admin_PW

Why it matters: there's no CVE or exotic SUID involved —it's a very common operational mistake: an application's configuration file, readable by an already-compromised user, contains the credentials for its own database.

8. The database and root's hash

With those credentials we log into MySQL/MariaDB and go straight to the users table, the natural place to look for usernames, hashes, emails and roles:

mysql -u mmuser -pCrack_The_MM_Admin_PW mattermost
show tables;
select Username,Password from Users;
root  $2a$10$......................................  (bcrypt)

Not the operating system's root yet, but a bcrypt hash tied to a «root» account inside Mattermost. On an easy box this usually leads to cracking the hash and testing password reuse —the right path here.

9. Targeted cracking with hashcat rules

Cracking a bcrypt hash blindly is expensive, but we already have the hint from the Mattermost channel: the password is a variation of PleaseSubscribe!. Instead of a huge wordlist, we use that single word as a base and apply mutation rules (best64):

echo "PleaseSubscribe!" > password.txt
hashcat -m 3200 hash.txt password.txt --user -r /usr/share/hashcat/rules/best64.rule
PleaseSubscribe!21

Why it works: hashcat rules generate thousands of variants of a base word (case, numeric suffixes, l33t…). With a password hint we're no longer attacking blindly: we apply a semantic base plus targeted mutations, far more efficient than brute force even against bcrypt. The --user flag tells hashcat the hash file follows the username:hash format.

10. Privilege escalation — password reuse

With the cracked password in hand, we test whether it also works for the operating system's root user:

su -
# password: PleaseSubscribe!21
cat /root/root.txt

Why it works: pure credential reuse. There's no complex local vulnerability involved: a password meant for an application account (Mattermost) turned out to also be the Linux root user's password.

Vulnerability summary

PhaseComponentVulnerabilityImpact
BypassosTicketCheck Ticket Status trusts email + ID without validating ownership → abusable mail viewerControlled @delivery.htb mailbox
BypassosTicket + MattermostMattermost's confirmation email is readable from the ticket → email verification bypassedActive Mattermost account
FootholdMattermost channelPlaintext SSH credentials leaked + root password hintSSH as maildeliverer
Local enumerationMattermost's config.jsonDatabase credentials in a readable configuration fileMySQL access (mmuser)
PrivEscMattermost DB + hashcatRoot's bcrypt hash + weak password pattern crackable with targeted rulesRoot (password reuse)

Lessons learned

  • Web enumeration is king: the entry point wasn't SSH or an unusual port, it was understanding the relationship between services (helpdesk ↔ email ↔ chat).
  • Logic flaws are just as dangerous as technical ones: no RCE was needed in osTicket, just abuse of its ticket logic and the missing email validation.
  • Interconnected systems amplify risk: helpdesk + email + internal chat formed a chain that none of the three, on its own, would have allowed.
  • Don't trust «email + ID» as proof of ownership: require real verification of the email, not just knowledge of it.
  • Configuration files are gold: if an attacker can read config.json, they'll likely walk away with database credentials, API keys, or tokens.
  • Hints matter, and pattern-based passwords fall: «PleaseSubscribe!» looked like an innocent phrase in a chat, but it was the semantic base that made cracking trivial with hashcat rules, even against bcrypt.
  • Password reuse kills: an application account's password doubling as the system's root password is a very realistic, very common failure.