Table of Contents
- Recon and Enumeration
- Getting User
- Privilege Escalation
Simple Password --> Plaintext password in SMB Share --> Azure AD Connect Exploit
Recon and Enumeration
As always, we start with a
masscan, followed by a detailed
Given we have kerberos, ldap, and SMB, we were confident this machine was a domain controller. The domain name was
megabank.local0 (Similar to the domain in Resolute, another box by egre55). We added that domain name to our /etc/hosts file per usual.
We gathered usernames and group memberships by running
We put all the usernames into a file for future use. We also notice there is a group called “Azure Administrators”. Azure is Microsoft’s cloud platform and will likely be part of some CVE during this box.
Lazy Admins (Initial Foothold)
We spent the next two days looking for passwords. We tried AS-REP Roasting, anonymous SMB login, etc. Nothing seemed to be working. Multiple hints on the HTB Forums mentioned the password was easy to find due to laziness. I rarely brute force logins on boxes, so I thought about what kind of passwords I would set if I was a lazy admin. It finally hit me. Use the username as the password. One less thing to remember :)
rpcclient to test each username password combination, where the password was the username. I did not use
evil-winrm for this, since it was likely that only a few users were part of the Remote Administrators Group (and could login remotely).
Turns out our hunch was correct, and we found the username and password for
SABatchJobs (password was also “SABatchJobs”).
Since we were not able to login remotely (via
evil-winrm) with SABatchJobs, we needed to find another way in. With valid credentials, I decided to check Samba again (using
So we see there are shares available, but do not see our permissions on them. Using
Looks like we can read both azure_uploads and users$. I started with users$ since it seemed more interesting.
Following an answer on Stack Overflow, I mounted the users$ share on my local machine.
mount -t cifs //10.10.10.172/users$ -o username=SABatchJobs,password=SABatchJobs,vers=2.0 /mnt/monte
Navigating through the share, we find an Azure Config file in user
mhope's home directory. Not suprisingly, it contains a plaintext password for
Using this username and password combination, we can now use
evil-winrm to login remotely and get the user hash.
We can see
mhope is a member of the Azure Admins, which might be helpful later.
It was clear to me that Azure Active Directory was the key to the privilge escalation portion of this box. I googled “Azure AD exploits” and was greeted with many articles. Most important were the ones by VBScrub (a fellow HTB member) and Dirk-jan. Both contained information and links to an exploit called “Azure AD Connect Database Exploit”.
The cliffnotes version of it (according to VBScrub):
- When connected to a domain, Azure AD has a syncing tool (called Azure AD Connect)
- This syncing tool syncs hashes, users, groups, etc
- For this sync to occur, Azure AD Connect must have access to a privileged account on the domain
- The credentials for this user are stored insecurely on the domain, and can be read/decrypted with “ease”
VBScrub made this much too easy for us. He layed out a guide on how to run a script he created (based loosely on Dirk-jan’s original script). Upload his script to the box, make sure you are in the correct directory, and run it.
- Downloaded VBScrub’s script AdDecrypt.exe and mcrypt.dll
- Uploaded both to the domain controller
- Changed directory into
C:\Program Files\Microsoft Azure AD Sync\Bin
- Ran the program using the full SQL Server command*
How did we know to use full SQL Server instead of a local one?
enum4linux alerted us there was a SQL Server running on the domain controller. Even if we did not know, we could have tried both options of the payload. Running the program, we get the password for the Administrator. We can then login with psexec, and grab the root hash.
- Username was password for SABatchJobs
Fix: Never use a username as a password for the same user
- Password for mhope was stored in plaintext in an Azure Configuration File
Fix: Do not store credentials in plain text, or restrict the users$ samba share
- Abused Azure AD Connect to get Administrator password
Fix: Microsoft patched this specific vulnerability, but other similar ones still exist. Check out the articles in the references section for more details
I think I am finally starting to get a decent process down to attack windows boxes. I learned a few more techniques I can add to this process, that I think will make future Windows boxes even easier. Thanks to
egre55 for another good one and for
VBScrub for a fantastic article. Onto the next one…
As always, if you have any questions or feedback, please contact me on HTB! I am always looking to improve my writing to make it as clear and concise as possible (while remaining somewhat beginner friendly). Happy Hacking!
- Microsoft Azure: https://azure.microsoft.com/en-us/
- Moutning SMB Shares Stack Overflow Post: https://unix.stackexchange.com/questions/99065/how-to-mount-a-windows-samba-windows-share-under-linux
- VBScrub Azure AD Connect Exploit Article: https://vbscrub.video.blog/2020/01/14/azure-ad-connect-database-exploit-priv-esc/
- Dirk-jan’s AD Connect Exploit Article: https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/