HTB: Monteverde

–[ intro ]

This is Monteverde! It was a pretty cool box, and it demonstrates how cloud-tools can go wrong – on Windows!

Monteverde

–[ recon ]

Let’s start enumerating! Nmap shows quite a few open ports:

nmap results

So we see quite a few ports open that are telling of a domain controller:

• 88 – kerberos
• 53 – DNS
• 3269 – LDAP
• 5985 – WinRM

Let’s see what we can enumerate!

–[ user ]

I used enum4linux as a start, and then used the usernames I found with smb_login with USER_AS_PASS set to true, to see if there was any lazy account setup:

SMB user login

And it turns out that my theory worked! I got some working credentials. Time to enumerate shares:

SMB shares

There’s one share that looks very interesting: users$. I mounted it and had a look:

Share contents

There’s an interesting file called azure.xml, and it contains a password! It was in mhope‘s directory, so let’s see if those credentials work:

User shell!

User has fallen 🙂

–[ root ]

I was stuck here for a whole. Let’s see what processes are running:

Running processes

The process Microsoft.Identity.AadConnect.Health.AadSync.Host, as I haven’t seen it before. I searched for it, and it turns out that it part of what Microsoft calls ADConnect

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.

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect

Huh, so it looks like it merges AD on prem with AD on the cloud, and in particular, it synchronises password hashes:

Password hash synchronization is one of the sign-in methods used to accomplish hybrid identity. Azure AD Connect synchronizes a hash, of the hash, of a users password from an on-premises Active Directory instance to a cloud-based Azure AD instance.

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs

Huh, this looks interesting. I also found that the sqlservr process is running! I found that I can use the PowerShell Invoke-Sqlcmd commandlet to perform queries, but I had no SQL credentials.

Fortunately, Invoke-Sqlcmd allows us to use SSPI via the -ConnectionString parameter. SSPI allows us to authenticate to SQL using Windows authentication (i.e. our windows user account), instead of a SQL user (which I don’t have).

I logged into the database and poked around, first listing the databases:

Databases

ADSync looks quite interesting! It must be related to the running process I found earlier. I got all of the tables and started going through them:

Tables in ADSync

I looked at all the records in these tables, and mms_management_agent looked the most promissing:

Contents of mms_management_agent

So I searched google for a while, and this blog post came up from XPN where he has a PoC for decrypting these passwords. I had to slightly modify the PoC to change the login options to use SSPI, and:

Dumping admin’s password

Let’s try to WinRM in as an administrator:

Administrator shell

Administrator achieved 🙂

–[ recap ]

I really enjoyed this box, especially the root part – even though I found it very frustrating I learnt a few things! I am constantly amazed at how powerful PowerShell is!

So what could have been done better on this box?

• Weak passwords: There was an account that had the username as a password. Pretty easy to guess!
• Passwords in files: mhope had his password stored in a file in plaintext, and this was exposed via SMB.
• AzureAD PHS: I am not exactly sure what went wrong here, but I’m pretty sure this is a misconfiguration.