Guarding the Bridge: New Attack Vectors in Azure AD Connect

TL;DR

The article reveals new attack vectors in Azure AD Connect, focusing on the Password Hash Sync mechanism. These vectors allow attackers to intercept connector credentials via man-in-the-middle attacks or inject malicious code into the Password Hash Sync process, thereby extracting domain users’ NT hashes. In addition, the article advises mitigation methods that include Microsoft’s best practices, as well as additional guidelines to mitigate and detect these new attack vectors.

Overview

In today’s rapidly changing technological climate, many organizations have already embraced and deployed hybrid environments within their infrastructures. Organizations that have not yet adopted these environments are catching up quickly, as a hybrid approach helps to increase efficiency, reduce costs, and improve scalability. One of the features that forms an integral part of a hybrid environment is Azure AD, which is an Azure cloud feature that provides a solution for identity management in the Azure cloud – much like on-premises Active Directory.

This blog post summarizes the research that we recently conducted on Azure AD Connect in general, with a focus on the Password Hash Sync mechanism, which is enabled by default. Our research led us to the discovery of several attack vectors for extracting Connector credentials from the Azure AD Connect server, in addition to extracting domain users’ NT hashes.

The information in this article reflects the research and testing that we conducted in a lab environment. Before conducting any tests, make sure you understand the implications such activities might have on your environment.

Background and terms

One of Azure AD Connect’s roles is to integrate between on-premises AD and Azure AD, by syncing on-prem AD objects like groups and users with Azure AD.

In order to authenticate users, Azure AD hybrid identity supports three methods:

• Password Hash Synchronization (PHS) – Azure utilizes PHS to validate provided credentials and authenticate users, without the need for an additional Identity Provider (IdP). When PHS is enabled, the Azure AD Connect service uses the AD replication protocol to retrieve the password NT hash for every synced user. The hash is then re-hashed, using an additional algorithm, before it is synchronized to Azure AD. PHS is enabled by default, even if another authentication method is used, and serves as a backup solution in case the federated server goes offline.
• Federation – Azure does not store or synchronize AD users’ passwords; instead, Azure relies on another IdP for authenticating user credentials. If an authentication attempt is successful, the IdP provides the user with a SAML token that can be forwarded to Azure. An example of such an implementation is when using ADFS with Azure.
• Pass-through authentication (PTA) – The Pass-through agent is installed on-premises and maintains a constant outbound connection to Azure. When a user attempts to authenticate directly to Azure, Azure encrypts the password using a public key, and waits for validation from the PTA agent. The agent then retrieves the encrypted credentials, uses a private key to decrypt the credentials, and validates them against the domain controller. The authentication outcomes are then pushed back to Azure, using the outbound connection.

Before delving further into the attack vectors, we discovered, it is crucial to have a basic understanding of the Azure AD Connect tool, and the sync mechanism. To fully comprehend all aspects of this blog post, it is important to be familiar with the following key terminology:

• Sync engine: This service syncs objects, and is the primary component of Azure AD Connect. The sync engine is in charge of all operations that relate to the synchronization of identity data between Azure AD (AAD) and on-premises Active Directory (AD).
• Data source: The source of identity data (the AD).
• Sync DB: An SQL database instance (localDB or MSSQL), which stores the sync service’s information and settings.
• Connector space (CS): The table in the sync DB that stores the identity information of an object.
• Synced Object: A user or group that is synchronized from a data source to AAD.
• Connectors: The sync service connects to each data source (AD and AAD) to synchronize objects. The Connectors are set using dedicated accounts with specific permissions:
  • AD Connector user: The domain user running the sync process. By default, this account is prefixed with ‘MSOL_’, and its description contains the sync server’s hostname.
  • Azure AD Connector user: An Azure AD (AAD) account (not an Active Directory account) that synchronizes objects to Azure AD.
• ADSync service account: The Azure AD Connect service utilizes a virtual service account named NT SERVICE\ADSync to execute the service process (miiserver.exe).

In Azure AD, Connectors are used to connect to a data source (AD or AAD), where they push or pull data. The Connector contains several settings, including user credentials, which are used to access their respective data source.

During the Azure AD Connect installation, administrators are required to provide credentials for high-privileged accounts in both AD (Domain Admin) and AAD (Global Admin) environments. These users are used to apply configurations and create additional Connector users with the specific privileges required to perform their part in the sync functionality. These users are also called ‘AD Connector user’ and ‘AAD Connector user’:

• AD Connector: In the on-prem environment, an Active Directory user account is created with the prefix ‘MSOL_’. This user is created with the permissions that allow it to fulfil its role, including:
  • Replicating Directory Changes
  • Replicating Directory Changes All

You may know these permissions as the ones that allow you to perform Domain Replication (DCSync); this ability is essential to the AD Connector’s role in the Password Hash Sync process. When a password change is detected in an identity, the Connector user uses these permissions to ‘fetch’ the password hash of this account, and then ‘hands it over’ to the AAD Connector.

• AAD Connector: The account prefixed with ‘Sync_’ is the Connector User for the Azure AD, and it is added to the ‘Directory Synchronization Accounts’ hidden Azure role. This role has several significant privileges, which relate to identities in Azure, such as:
  • directory/servicePrincipals/create
  • directory/servicePrincipals/appRoleAssignedTo/update
  • directory/servicePrincipals/credentials/update

These and other permissions allow the AAD Connector user to perform its role in the sync process, which is to obtain the identity information delivered to it from the AD Connector via the AD Connect client, and update AAD with the identity information – effectively completing a successful sync.

Discovered vectors

We began by reviewing the known techniques to abuse the Azure AD Connect server functionality, most of which involve decrypting the encrypted configuration from the sync DB, yielding cleartext Connector credentials. However, once we understood the technical aspects of this service, we managed to come up with a few additional vectors.

Vector 1: obtain aad connector credentials via man-in-the-middle

The Azure AD Connect service pushes objects from on-prem Active Directory to the Azure Active Directory, meaning that the sync service must perform authentication against the Azure tenant with the credentials of the Azure AD Connector user. During our research, we discovered that the authentication request is sent over an encrypted HTTPS channel to a Microsoft login URL (https://login.microsoftonline.com), and uses the OAuth protocol.

To observe the request sent by the sync service in cleartext, we used a technique called ‘Secure Sockets Layer (SSL) inspection’, which requires a trusted certificate of the login.microsoftonline.com domain. There are two ways to obtain and use this trusted certificate: proxying the communication – which requires access to the server, or remotely by using the man-in-the-middle technique – with a little help from ADCS.

Proxy Azure AD connect communication

We created a root CA and used it to generate a certificate to the Microsoft login domain. Then, we installed our CA certificate as a Trusted Root Certificate on the Azure AD Connect server.

In order to redirect the outgoing traffic though our proxy, we changed the configuration for the .NET framework. This is configured by adding the following lines to the machine.config file, located in the ‘C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config’ folder:

We set our proxy to present the generated Microsoft login certificate, to decrypt the SSL communication. Then, we restarted the Azure AD Connect service in order to apply the proxy configuration. As a result, we can intercept the AAD Connector username and password in the request POST parameters.

Man-in-the-middle with help from adcs

Active Directory Certificate Services (ADCS) is Microsoft’s PKI implementation which provides a root CA that is trusted by all domain-joined machines. Using ADCS, we can avoid installing a new root CA certificate on the server.

Many organizations do not sufficiently restrict access to enrollment from certificate templates that allow server authentication – which is required for the use of SSL. In these cases, we can enroll an SSL certificate for Microsoft Login domain, which will be trusted by the AD Connect server.

By combining the ability to enroll a trusted certificate with DNS and ARP spoofing attacks, we can trick the server into treating our machine as the gateway. In this case, when the sync server attempts to access ‘login.microsoftonline.com’, it will be directed to our machine.

At this point, the sync server believes that it is accessing the ‘login.microsoftonline.com’ server, and because we presented a trusted certificate, the server submits the authentication request. The use of this certificate also enables us to encrypt and decrypt communication – including viewing cleartext credentials.

The result of the exploitation is that we obtained the AAD Connector cleartext password – which can be leveraged to perform lateral movement and privilege escalation in the cloud.

Demo

Vector 2: steal domain users’ nt hashes

Active Directory stores passwords in the form of MD4 hash values of users’ passwords. To synchronize a password to the cloud, Azure AD Connect extracts the password’s NT hash from a domain controller using the MS-DRSR protocol, adds a per-user salt, and re-hashes the value with the SHA-256 algorithm.

When a user authenticates to the cloud, the cloud backend performs the same hashing process on the password, and compares the hashes to determine whether the password provided is correct.

To get a better understanding of the Password Hash Sync mechanism, we analyzed the sync service libraries and identified the classes that handle the re-hash process. The CreatePasswordHash method of the PasswordHashGenerator class receives an object (ChangeObject) that contains user information and its NT hash. This method returns a PasswordHashData object, which contains the raw NT hash, and the salt + SHA-256 representation to sync.

The re-hashing process is handled by a method in the OrgIdHashGenerator class that receives a static configuration and an NT hash. The static configuration is set to add a 10-byte salt and perform 1,000 iterations of SHA256.

By attaching a debugger to the sync service and setting a breakpoint on the Generate method, we are able to validate that the input value is indeed the user’s NT hash.

Hook the password hash synchronization

As the Sync engine is implemented in .NET Framework, we divided the exploitation into three phases:

The first step was to create a simple DLL injector that will inject an unmanaged DLL (LoadCLR.dll) into the sync engine process. The injected DLL contains code that loads the .NET Framework Runtime, and uses it to execute the .NET Framework-managed DLL in the default AppDomain.

Next, we used Process Explorer to validate that the LoadCLR.dll was loaded to the process.

In the .NET Assemblies tab, we validated that the AzureADConnect_Abuse.dll was executed in the default AppDomain.

The managed DLL (AzureADConnect_Abuse.dll) contains code that hooks the CreatePasswordHash function we mentioned earlier, and appends instructions that will write any NT hash that the function processes into a file on disk.

To perform the hooking, we used an open-source library named Harmony, which provides the ability to alter .NET application code in runtime. Harmony implements several types of patches, each designed for a different use case. In order to write any NT hash into a file, we utilized a Transpiler patch.

After the injection, we simulated a user’s password change; the NT hash was written to the file on the server, proving that our patch works.

Force the synchronization of users’ passwords

At this point, we can inject code into the sync process and passively gather credentials as soon as they are changed. However, we want to be able to control this action, and force credentials to synchronize after our injection – or even trigger the sync for a specific user, such as an admin user.

The sync engine uses an SQL instance – also known as sync DB – to store the identity information of synced objects. During the Password Hash Synchronization, this data is used to determine whether the object needs to be synchronized.

In most implementations we have seen, the sync engine is configured with SQL LocalDB instance. The default configuration of the localDB database grants the local administrators group sysadmin rights, giving those users full control over it. This database contains the connector space, which contains a row for each AD object. Deleting rows from this table causes the next sync cycle to assume that the AD object is a new object, and to synchronize it to AAD.

As we did not want to delete information from the connector space, we looked for an alternative way to initiate an object sync. Examining the column names of the table revealed that the ‘is_password_hash_sync_retry’ column is populated with a Boolean value. Our assumption was that when this column is True, the sync engine tries to synchronize the password of this object on the next cycle.

In order to test that assumption, we created a PowerShell script that gets a username as input and changes the value of the ‘is_password_hash_sync_retry’ column in the connector space for this username.

We used the PowerShell script to force the sync of one user, which proved that our assumption was correct: the user was synchronized again, which resulted in us successfully obtaining the user’s password hash once the sync completed!

Understanding this behavior, we can manipulate the sync DB to trigger the sync server to re-sync any user (or users) we want, on demand. Following this forced re-sync, our process injection payload dumps the username and its hash to a file. Even if the user’s password is changed once again, access to the output file ensures that we automatically obtain the new password, as changing the password results in a sync.

Demo

Mitigations

When the Azure AD Connect server is implemented, it plays a critical role in organizations both because of its operational use, and the privileges that this service requires. Although security awareness of AD environments is constantly improving, some organizations neglect the Azure AD Connect server, and do not apply the necessary security measures, such as server hardening, network segregation, and access monitoring.

Azure AD Connect enables and utilizes password hash synchronization (PHS) by default, for the purposes of authentication. During our research, we discovered that even if PHS is explicitly disabled, the AD Connector account is still created with Replicating Directory Changes privileges, which according to Microsoft is an intended behavior.

Organizations should treat and classify the Azure AD Connect as a Tier 0 server according to Microsoft’s best practices for the Microsoft Enterprise Access Model. Additionally, to ensure robust security, consider adopting the following guidelines:

• Network Restrictions: Implement network segregation to restrict network access to the server reducing its attack surface. Additionally, monitor inbound and outbound traffic for potential MITM attacks, such as DNS-based attacks and ARP poisoning.
• Privileged Access Management: Implement privileged identity and access management solution to enforce secure administrative access to the AD Connect server. In addition, monitor the server for abnormal activities that include suspicious authentication attempts.
• Endpoint Detection and Response: Ensure that EPP solution is deployed on the server to detect and respond to common threats, and specifically the following activities:
      – Hosts file tempering to modify the resolution for http://login.microsoftonline.com domain.
      – Malicious PowerShell Usage including AADInternals.

Additionally, some of the techniques demonstrated here are not considered to be ‘malicious’ activity, such as enrollment of certificates from ADCS. As a result, to protect the Azure AD Connect server against such threats, it is highly recommended to restrict access to certificate templates that allow server authentication, and monitor the enrollment of templates to ensure that they are not requested for an external URL (e.g., http://login.microsoftonline.com). In addition, monitor the certificate store on the Azure AD Connect server to ensure that it contains only trusted Root CAs.

Wrapping up and conclusions

The techniques presented in this post demonstrate how an attacker can effectively create a backdoor for future attacks in an organization’s network without being detected. This is done by stealing hashes, and observing and receiving Connector accounts’ cleartext credentials. We also explored a rarely discussed vector: leveraging ADCS certificates that allow server authentication to perform man-in-the-middle attacks.

In our recent red team engagements, we used hooking and man-in-the-middle techniques to obtain credentials without our activities being detected, and while avoiding common security solutions.

In this post, we have demonstrated how it is possible to hook PHS functions to steal NT hashes of domain accounts on demand. This method can be further leveraged by an attacker to maintain persistence in an organization’s network, and to ensure that every future password change in the domain will be sent to the attacker. Attackers can also use hooking techniques to obtain the cleartext passwords of both the AD and AAD Connect-or accounts.

We have also shown how ADCS can be leveraged to perform SSL inspection via man-in-the-middle. In this post, we demonstrated specifically how to use ADCS to obtain the AAD Connector password; an attacker could also act as a man-in-the-middle and leverage attacks against SSL-encrypted channels in the network by exploiting misconfigurations in certificate templates that have Server Authentication.

To learn more about Sygnia’s Adversarial security services click here.

We hope you find this post useful in your investigations and testing of attack vectors. If you were impacted by attack or are seeking guidance on how to prevent attacks, please contact us at contact@sygnia.co or our 24-hour hotline +1-877-686-8680.

References

Microsoft Azure AD hybrid identity documentation:

• https://learn.microsoft.com/en-us/azure/active-directory/hybrid/

Extracting Connector credentials:

• https://aadinternals.com/aadinternals/
• https://blog.xpnsec.com/azuread-connect-for-redteam/
• https://dirkjanm.io/updating-adconnectdump-a-journey-into-dpapi/

dnSpy – .NET debugger:

• https://github.com/dnSpy/dnSpy

Execute managed code in unmanaged process:

• https://www.codeproject.com/Articles/607352/Injecting-NET-Assemblies-Into-Unmanaged-Processes

Patch .NET methods in runtime – Harmony:

• https://github.com/pardeike/Harmony

Microsoft Enterprise access model:

• https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model

This advisory and any information or recommendation contained herein has been prepared for general informational purposes and is not intended to be used as a substitute for professional consultation on facts and circumstances specific to any entity. While we have made attempts to ensure the information contained herein has been obtained from reliable sources and to perform rigorous analysis, this advisory is based on initial rapid study, and needs to be treated accordingly. Sygnia is not responsible for any errors or omissions, or for the results obtained from the use of this Advisory. This Advisory is provided on an as-is basis, and without warranties of any kind.