# HTB Monteverde Walkthrough

## Scanning

Let’s first run a port scan to enumerate the open ports on the target machine 10.10.10.160, and since Windows DCs usually have interesting services running on ports higher then 3000 let’s directly add the -p- option:

The services that we find are typical of Windows DCs and some of them could be easly exploited to collect juicy informations such as DNS, SMB over NetBIOS, LDAP and WinRM (identified by nmap as Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)).

### Technical Details

Most of the previous protocols are well known but I’d like to say something more about the port 5985 which is the canonical one used by Windows Remote Management 2. Let’s read what it is on the Microsoft Windows Dev Center [1][2][3]:

After some research, I’ve found that inside the WinRM’s functions core there are explicit references to the possibility to execute shell commands using this protocol, so it could be a great path to have access to the machine!

And looking around the web, I’ve discovered an easy-to-use Ruby script that provides shell functionality via WinRM (and something more) called Evil-WinRM.

## Enumeration

My first attempt to gather information is to try a DNS Zone Transfer, but it reveals itself to be unsecessful.

Interacting with SMB protocol using enum4linux tool and exploiting NULL Session misconfiguration a lot of useful information pop up (let me shorten it, highlighting the most important ones):

## User Shell

### SMB Information Gathering

As you can see, We gather nine usernames, the local and domaing groups and memberships together with the domain password policy. The first thing that comes to mind is to try to get access to SMB Shared Folders explointing a weak password policy that makes possibile to use the usernames as passwords.
In order to do so, I write a simple Bash script that uses smbclient to test the login attempts:

But since We know that the minimum password length is seven, let’s filter a little bit the the script’s input:

At this point, enumerating the Shared Folders which the SABatchJobs has access to, we find some with read-only permissions:

None of them contains something useful apart from \\\\monteverde.htb\\users$\mhope that has a azure.xml file in which we find some credentials in clear-text: Let’s try if the password 4n0therD4y@n0th3r$ provides a new valid access, maybe having write permissions on Shared Folders! I duplicate the previous Bash script and modify it a little bit to test this password for all the known usernames:

The user that matches the given credentials (mhope) has got the same permissions of the previous one:

### WinRM

It’s time to attack the WinRM service and the only way that seems to be viable is to try the found credentials against it, and in fact it works! mhope lets us obtain a remote user shell via Evil-WinRM:

## Privilege Escalation

Looking around we discover two important information:

• mhope account belongs to the Azure Admins group (in reality we already knew it from SMB enumeration btw);
• an ADsync service is running on the target machine, together with a MSSQLSERVER instance.

Why should this be interesting? After a lot of research, I’ve found an amazing blog post by @XPN that deeply explains how to exploit Azure AD and local Active Directory misconfigurations during a red team.
Particularly interesting for us is the Password Hash Synchronisation (PHS) process which uploads user accounts and password hashes from Active Directory into Azure, letting the users to authenticate with their local AD credentials against Microsoft services such as Office365, Sharepoint and so on.
In short, using an “express” ADSync configuration, the hashes that has to be sent to the Azure AD are stored inside a local Microsoft SQL Server table. Having enough permissions on the DBMS instance, it is possible to retrive them, to crack them and to finally obtain them in clear-text. I highly recommend to read the article that is linked above to fully understand this process!

In order to confirm my theory, I look for a local database named ADSync that contains the main columns used during the hash decryption process, and here you are:

It’s time to use the PoC that the author put in his article that exploits PHS misconfiguration and decrypts the Administrator password using the algorithm obtained reversing the C:\Program Files\Microsoft Azure AD Sync\Binn\mcrypt.dll library, which is responsible for key management and the decryption of this data. But since the code doesn’t work for some unpredictable reason I need to modify it (I’m really bad at coding in PowerShell…) and this is my final result:

It’s time to run a SimpleHTTPServer instance, to upload this script via Invoke-WebRequest and to execute it to finally get the desired password:

Last of all, let’s connect to the Administrator account using d0m@in4dminyeah! password and WinRM protocol to read the root flag: