Monteverde just retired on Hackthebox, it’s a medium difficulty Windows box. It’s was a very interesting webless box. Still being a bit new to the Windows environment the foothold was not that easy to find for me but once you do enough recon it get pretty straightforward real life scenarios to arrive to root. I would recommend it if you are confortable on easy box and want to level up to a medium one.
Tl;Dr: To get the user flag you had to enumerate users using RPC service, using password spraying you find that user use its own username as password allowing to connect to its SMB folder. In this folder we found an Azure configuration file containing credentials for user mhope. Then using WinRM protocol we can connect to mhope account and grab the flag. To get the root flag you had to exploit an “Azure Active Directory Connect Database” privilege escalation exploit in order to retrieve administrator credentials and get the flag.
Alright! Let’s get into the details now!
First thing first, let’s add the box IP to the hosts file:
Let’s start with the classic nmap scan to see which ports are open on the box:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
[hg8@archbook ~]$ $ nmap -Pn -n -A -T5 -p1-65535 10.10.10.172 Nmap scan report for 10.10.10.172 PORT STATE SERVICE VERSION 53/tcp open domain? 88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-05-26 19:25:41Z) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: MEGABANK.LOCAL0., Site: Default-First-Site-Name) 445/tcp open microsoft-ds? 464/tcp open kpasswd5? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open tcpwrapped 3269/tcp open tcpwrapped 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) 9389/tcp open mc-nmf .NET Message Framing
Nmap done: 1 IP address (1 host up) scanned in 374.92 seconds
As often on Windows machines we do have a lot of ports open. It’s one of the first box I see without any web server running nor SSH open. It’s going to be fun :)
Enum4Linux
From the nmap result and being one of my first Windows based box I was really unsure where to start off so I decided to give a try to enum4linux.
Enum4linux is a tool for enumerating information from Windows and Samba systems.
It is written in Perl and is basically a wrapper around the Samba tools smbclient, rpclient, net and nmblookup.
========================== | Target Information | ========================== Target ........... 10.10.10.172 RID Range ........ 500-550,1000-1050 Username ......... '' Password ......... '' Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
=========================================== | Getting domain SID for 10.10.10.172 | =========================================== Domain Name: MEGABANK Domain Sid: S-1-5-21-391775091-850290835-3566037492 [+] Host is part of a domain (not a workgroup)
============================= | Users on 10.10.10.172 | =============================
============================== | Groups on 10.10.10.172 | ==============================
[+] Getting domain group memberships: Group 'Domain Users' (RID: 513) has member: MEGABANK\Administrator Group 'Domain Users' (RID: 513) has member: MEGABANK\krbtgt Group 'Domain Users' (RID: 513) has member: MEGABANK\AAD_987d7f2f57d2 Group 'Domain Users' (RID: 513) has member: MEGABANK\mhope Group 'Domain Users' (RID: 513) has member: MEGABANK\SABatchJobs Group 'Domain Users' (RID: 513) has member: MEGABANK\svc-ata Group 'Domain Users' (RID: 513) has member: MEGABANK\svc-bexec Group 'Domain Users' (RID: 513) has member: MEGABANK\svc-netapp Group 'Domain Users' (RID: 513) has member: MEGABANK\dgalanos Group 'Domain Users' (RID: 513) has member: MEGABANK\roleary Group 'Domain Users' (RID: 513) has member: MEGABANK\smorgan Group 'Azure Admins' (RID: 2601) has member: MEGABANK\Administrator Group 'Azure Admins' (RID: 2601) has member: MEGABANK\AAD_987d7f2f57d2 Group 'Azure Admins' (RID: 2601) has member: MEGABANK\mhope Group 'HelpDesk' (RID: 2611) has member: MEGABANK\roleary Group 'Domain Guests' (RID: 514) has member: MEGABANK\Guest Group 'Trading' (RID: 2610) has member: MEGABANK\dgalanos Group 'Operations' (RID: 2609) has member: MEGABANK\smorgan Group 'Group Policy Creator Owners' (RID: 520) has member: MEGABANK\Administrator
enum4linux complete
The full result of Enum4Linux is very complete so I removed the informations we don’t need.
One thing that catch the eye is that Password Complexity is set to disabled. Since we have a list of user we can maybe find one account using a weak password by brute-force.
Brute-force user accounts
Since the SMB port 445 is open we can use it to try bruteforcing account passwords. To do so I will use crackmapexec.
After having no luck with the classical rockyou.txt password list I decided to take a different approach. One common weak password strategy is the reuse of username as password, either when setting up a default account or out of user laziness. Maybe one of the users did so ?
Now that we have SABatchJobs credentials let’s see if we can find anything in its SMB shared folder:
1 2 3 4 5 6 7 8 9 10 11 12
[hg8@archbook ~]$ smbclient -U 'SABatchJobs' //10.10.10.172/users$ Enter MYGROUP\SABatchJobs's password: Try "help" to get a list of possible commands. smb: \> ls . D 0 Fri Jan 3 14:12:48 2020 .. D 0 Fri Jan 3 14:12:48 2020 dgalanos D 0 Fri Jan 3 14:12:30 2020 mhope D 0 Fri Jan 3 14:41:18 2020 roleary D 0 Fri Jan 3 14:10:30 2020 smorgan D 0 Fri Jan 3 14:10:24 2020 524031 blocks of size 4096. 519955 blocks available
We have a few users folder. mhope one contains what’s look like an interesting configuration file named azure.xml:
We got lucky there is a password in it. Is that mhope account password ?
SSH is not open but WinRM port 5985 is, so we should be able to get a shell from there. As a reminder:
WinRM (Windows Remote Management) is the Microsoft implementation of WS-Management Protocol. A standard SOAP based protocol that allows hardware and operating systems from different vendors to interoperate. Microsoft included it in their Operating Systems in order to make life easier to system administrators.
Group Name Type SID =========================================== ================ ============================================ [...] MEGABANK\Azure Admins Group S-1-5-21-391775091-850290835-3566037492-2601
[...]
One of the most noteworthy information is that mhope belongs to Azure Admins group. Which makes sense after finding the azure.xml config file earlier.
Let’s dig a bit more to see if we can find more informations related to Azure.
While looking around at running services we stumble upon a service named Azure AD Connect Health Sync:
Azure AD Connect is the Microsoft tool designed to meet and accomplish your hybrid identity goals. It provides the following features:
Password hash synchronization - A sign-in method that synchronizes a hash of a users on-premises AD password with Azure AD.
Pass-through authentication - A sign-in method that allows users to use the same password on-premises and in the cloud, but doesn’t require the additional infrastructure of a federated environment.
Federation integration - Federation is an optional part of Azure AD Connect and can be used to configure a hybrid environment using an on-premises AD FS infrastructure. It also provides AD FS management capabilities such as certificate renewal and additional AD FS server deployments.
Synchronization - Responsible for creating users, groups, and other objects. As well as, making sure identity information for your on-premises users and groups is matching the cloud. This synchronization also includes password hashes.
Health Monitoring - Azure AD Connect Health can provide robust monitoring and provide a central location in the Azure portal to view this activity.
The Password hash synchronization and Pass-through authentication might be interesting to escalate our privileges. It may me worth digging a bit this service.
Its possible to just run some simple .NET or Powershell code on the server where Azure AD Connect is installed and instantly get plain text credentials for whatever AD account it is set to use!
Basically when deploying a new ADSync connector, the credentials gets stored in a local SQL Database. Then, when credentials need to be retrieved, they get decrypted using mcrypt.dll library located in C:\Program Files\Microsoft Azure AD Sync\Bin\.
Indeed while looking at open connection on the box we can see port 1434 (Microsoft SQL Server) listening on localhost: