Monteverde

Completed on 14 Jan 2020.

Overview

This Hack The Box machine is built on Windows operating system and revolves around Active Directory, LDAP, and misconfigurations. The surprise of this machine was seeing Azure involved; quite interesting.

Some great resources around this are below:

Resources:

  1. Active Directory Kill Chain Attack & Defense

  2. Azure AD Connect for Red Teamers

  3. Azure Active Directory Pass-through Authentication security deep dive

Initial Enumeration: Footprinting and Scanning

First of, we need to identify how to reach the system. In other words, we need to identify what are the services available from this machine.

Let's start by adding this machine's IP address to the hosts file and create an alias:

My go-to tools in this phase, which are typically used by many to start enumerating, are:

masscan: very nice port scanning tool that allows finding open ports quickly. To me this is a tool to narrow down the scope of the enumeration so we can focus on open ports only when using nmap.

Here, I am designating the interface to use when communicating to the HTB machine (-e) which will be the HTB VPN interface, along with -p to designate the port range to target but I will target ALL TCP and UDP Ports, and the transmission rate of packets per second (--rate).

Similar to this, you could also run something like this:

nmap -p- --min-rate=1000 -T4

nmap: I think most people in the information technology and security space know what nmap does. It is a very versatile Port scanning tool which also allows you to use scripts to further target the services found. Just like anything, it can be a useful tool while it can also be damaging if the user is not careful.

What I typically start with when using nmap is:

MASSCAN

Now, we can use the output saved in the log file to store the ports in a variable and make ours lives easier:

By doing this, we can simply call this variable when performing our port scan.

NMAP

As you can see from the open ports found, we have the following which are very important:

Some of these ports are typical of Active Directory environments, but not all can be targeted.

For instance, TCP 445 would reveal more information if some conditions were applicable for the port scan to access it, the fact that no other information was returned means that it shouldn't be our first attempt.

MSRPC and Netbios can return some information, but we won't target them directly. LDAP on the other hand, return domain related information or basically the domain FQDN, which means it could be possible to target through a null session.

Below, I will provide a truncated output as it is too massive to provide, along with the the syntax to use.

LDAPSEARCH

To get a more friendly enumeration, let's use enum4linux through a null session using MEGABANK as the Netbios domain name:

ENUM4LINUX

Thanks to enum4linux, we got now a lot of valuable information that is not just related to the users, but critical group membership. Some of these users and groups are related to Azure.

Along with the Azure Directory Sync group and others, we have a MS SQL related group. Let gather a list of users and test for potential user and password combinations.

Now, we can try using the lazy password approach, including usernames as passwords, and perform password spraying.

CRACKMAPEXEC

Looks like the approach was correct even though the first attempt failed.

As it turns out, the service account SABatchJobs was used as its own password when created; the lazy administrator approach.

Let's try and validate the access this account has:

This last attempt basically tell us we can go through each of the shares we have read access with SABatchJobs.

Another way could've been by using smbmap:

Exploitation and Gaining Access

At this point, we can try accessing these shares:

IMPACKET-SMBCLIENT

Let's try this with evil-winrm and user mhope as this is the only normal user with admin rights per the information returned by enum4linux.

EVIL-WINRM

We have found the user flag. At this point, we can try to escalate our privileges.

Privilege Escalation

After enumerating services, groups and accounts, there was a possibility this domain controller could have ADSync tasks to the assigned Azure Tenant, along with the Azure files found under mhope that are related to the AzureRM Context and TokenCache.dat.

This information points us to try and exploit AzureAD Connect and ADSync to extract the administrator account password.

Remember to verify the Execution Policy in PowerShell before running any script. Since we are in a PowerShell session through WinRM, we can leverage its commands or functions.

To verify the Execution Policy:

Get-ExecutionPolicy -List

To change it for the current user:

Set-ExecutionPolicy Bypass -Scope CurrentUser

Changing this without specifying the scope will failed if the user does not have Administrator privileges.

Following the blog Azure AD Connect for RedTeamers provided in the overview section, lead us to a few failed attempts:

Basically the SQL connection did not work. After digging a little, the syntax on the connection was not good due to the SQL version. We had to tweak the connection from:

$client = new-object System.Data.SqlClient.SqlConnection -ArgumentList "Data Source=(localdb). \ADSync;Initial Catalog=ADSync"

To the following:

$server = 127.0.0.1; $db = "ADSync"; $client = new-object System.Data.SqlClient.SqlConnection -ArgumentList "Server = $server; Database = $db; Initial Catalog=$db; Integrated Security = True;"

Now, our second attempt after updating the uploaded script:

We got the Administrator credentials used to configure Azure AD Connect, so now we need to login as the Administrator using impacket-smbclient again.

And we have found the root flag!

Different Approach

This section was added on April 17, 2022 while reviewing my notes versus the approach I would have taken if I worked on this box now.

Another way to finish this box would've been by accessing the system through either impacket-smbexec or evil-winrm:

Closing Statements:

As demonstrated by Adam Chester in his blog, there is always a risk with new technologies and even worse when best practices are not followed. At every deployment, evaluate each potential risk and do not rush it.

In this scenario, Adam Chester's POC is able to retrieve the credentials used to configure and run Azure AD Connect, we had the ability to retrieve the credentials for an account capable of performing a DCSync. But, this would not be achieved if the server running the Azure AD Connect service was configured properly and no others associated to misconfigurations.

PreviousResoluteNextSauna

Last updated

Was this helpful?