Azure AD Connect for Red Teamers

With clients increasingly relying on cloud services from Azure, one of the technologies that has been my radar for a while is Azure AD. For those who have not had the opportunity to work with this, the concept is simple, by extending authentication beyond on-prem Active Directory, users can authenticate with their AD credentials against Microsoft services such as Azure, Office365, Sharepoint, and hundreds of third party services which support Azure AD.

If we review the available documentation, Microsoft show a number of ways in which Azure AD can be configured to integrate with existing Active Directory deployments. The first, and arguably the most interesting is Password Hash Synchronisation (PHS), which uploads user accounts and password hashes from Active Directory into Azure. The second method is Pass-through Authentication (PTA) which allows Azure to forwarded authentication requests onto on-prem AD rather than relying on uploading hashes. Finally we have Federated Authentication, which is the traditional ADFS deployment which we have seen numerous times.

Now of course some of these descriptions should get your spidey sense tingling, so in this post we will explore just how red teamers can leverage Azure AD (or more specifically, Azure AD Connect) to meet their objectives.

Before I continue I should point out that this post is not about exploiting some cool 0day. It is about raising awareness of some of the attacks possible if an attacker is able to reach a server running Azure AD Connect. If you are looking for tips on securing your Azure AD Connect deployment, Microsoft has done a brilliant job of documenting not only configuration and hardening recommendations, but also a lot about the internals of how Azure AD’s options work under the hood.

Setting up our lab

Before we start to play around with Azure AD, we need a lab to simulate our attacks. To create this, we will use:

1. A VM running Windows Server 2016
2. An Azure account with the Global administrator role assigned within Azure AD
3. Azure AD Connect

First you’ll need to set up an account in Azure AD with Global administrator privileges, which is easily done via the management portal:

Once we have an account created, we will need to install the Azure AD Connect application on a server with access to the domain. Azure AD Connect is the service installed within the Active Directory environment. It is responsible for syncing and communicating with Azure AD and is what the majority of this post will focus on.

To speed up the installation process within our lab we will use the “Express Settings” option during the Azure AD Connect installation which defaults to Password Hash Synchronisation:

With the installation of Azure AD Connect complete, you should get a notification like this:

And with that, let’s start digging into some of the internals, starting with PHS.

PHS… smells like DCSync

To begin our analysis of PHS, we should look at one of the assemblies responsible for handling the synchronisation of password hashes, Microsoft.Online.PasswordSynchronization.dll. This assembly can be found within the default installation path of Azure AD Sync C:\Program Files\Microsoft Azure AD Sync\Bin.

Hunting around the classes and methods exposed, there are a few interesting references:

As you are likely aware, DRS (Directory Replication Services) prefixes a number of API’s which facilitate the replication of objects between domain controllers. DRS is also used by another of our favourite tools to recover password hashes… Mimikatz.

So what we are actually seeing here is just how Azure AD Connect is able to retrieve data from Active Directory to forward it onto Azure AD. So what does this mean to us? Well as we know, to perform a DCSync via Mimikatz, an account must possess the “Replicating Directory Changes” permission within AD. Referring back to Active Directory, we can see that a new user is created during the installation of Azure AD Connect with the username MSOL_[HEX]. After quickly reviewing its permissions, we see what we would expect of an account tasked with replicating AD:

So how do we go about gaining access to this account? The first thing that we may consider is simply nabbing the token from the Azure AD Connect service or injecting into the service with Cobalt Strike… Well Microsoft have already thought of this, and the service responsible for DRS (Microsoft Azure AD Sync) actually runs as NT SERVICE\ADSync, so we’re going to have a work a bit harder to gain those DCSync privileges.

Now by default when deploying the connector a new database is created on the host using SQL Server’s LOCALDB. To view information on the running instance, we can use the installed SqlLocalDb.exe tool:

The database supports the Azure AD Sync service by storing metadata and configuration data for the service. Searching we can see a table named mms_management_agent which contains a number of fields including private_configuration_xml. The XML within this field holds details regarding the MSOL user:

As you will see however, the password is omitted from the XML returned. The encrypted password is actually stored within another field, encrypted_configuration. Looking through the handling of this encrypted data within the connector service, we see a number of references to an assembly of C:\Program Files\Microsoft Azure AD Sync\Binn\mcrypt.dll which is responsible for key management and the decryption of this data:

To decrypt the encrypted_configuration value I created a quick POC which will retrieve the keying material from the LocalDB instance before passing it to the mcrypt.dll assembly to decrypt: