Dumping NTHashes from Microsoft Entra ID

Summary

Microsoft Entra ID (formerly known as Azure Active Directory (Azure AD)^[1]) is a cloud-based identity and access management service. It does not store plaintext user passwords but instead uses an MD4 algorithm to calculate an NTHash from each password and re-hashes it 1,000 times to prevent recovery. While investigating a different Azure AD vulnerability in December 2022, Secureworks® Counter Threat Unit™ (CTU) researchers discovered that stored NTHashes could be recovered via the Microsoft Graph API and decrypted using a certificate stored on Azure AD Domain Services (Azure AD DS)^[2] domain controllers. Recovered NTHashes could be used in pass-the-hash attacks.

CTU™ researchers shared these findings with Microsoft on December 23, 2022. Microsoft confirmed the findings on January 27, 2023 but stated that it is expected behavior.

Azure AD passwords

When storing users' passwords, Azure AD uses the same hashing algorithm as password hash synchronization (PHS). PHS first obtains an NTHash that was created from the plaintext password via an MD4 algorithm. The NTHash and a random salt are then forwarded to the password-based key derivation function (PBKDF2), which iterates 1,000 times using the HMACSHA256 hashing algorithm. The resulting hash is non-reversible, so neither the original password nor the NTHash can be recovered.

Azure AD Domain Services

Azure AD DS allows running workloads in Azure that require Active Directory Domain Services (AD DS), without needing to deploy and manage domain controllers. When Azure AD DS is deployed, two domain controllers are deployed in the Azure subnet chosen by the organization. These domain controllers are managed by Microsoft. The organization can deploy additional domain controllers via replica sets, one per subnet (see Figure 1). Domain controllers are replicated via Microsoft's backbone network.

Figure 1. Azure AD DS topology. (Source: Secureworks)

After deploying Azure AD DS, Azure AD begins to store users' NTHashes. These hashes are then synchronized to Azure AD DS domain controllers. If organization is using hybrid identities, Azure AD Connect^[3] starts automatically synchronizing users' NTHashes from the on-premises Active Directory environment to Azure AD. The mechanism Azure AD DS used to synchronize users and NTHashes from Azure AD was unclear (see Figure 2).

Figure 2. User and NTHash synchronization. (Source: Secureworks)

In December 2022, CTU™ researchers discovered a vulnerability that allowed an attacker to compromise Azure AD DS domain controllers, obtain domain admin access, and dump NTHashes (see Figure 3). The domain admin access also enabled the researchers to study Azure AD DS implementation details.

Figure 3. Azure AD DS attack path. (Source: Secureworks)

Azure AD DS password synchronization

According to Microsoft documentation, Azure AD pushes encrypted NTHashes to Azure AD DS using an “internal synchronization mechanism over an encrypted HTTP session.” Moreover, Azure AD DS retrieves the decryption key from the Azure Key vault to decrypt the passwords. Microsoft also states that only Azure AD DS has access to the decryption keys.

When studying Azure AD DS domain controllers, CTU researchers determined that Azure AD DS synchronization is performed by the DCaaS AadSync Agent service (see Figure 4). DCaaS (domain controller as a service) is Azure AD DS's technical name.

Figure 4. Azure AD DS synchronization agent. (Source: Secureworks)

The DCaaS AadSync Agent uses the Microsoft Graph API to fetch users and NTHashes from Azure AD. The initial request to synchronize users includes all properties to be synced from Azure AD (see Figure 5). Two of the properties are not part of the MS Graph API user object schema: windowsLegacyCredentials and windowsSupplementalCredentials.

Figure 5. Initial MS Graph API request. (Source: Secureworks)

Subsequent requests were made every 30 seconds using the delta query (see Figure 6).

Figure 6. Subsequent MS Graph API requests. (Source: Secureworks)

The Azure AD DS synchronization agent uses the Azure AD Domain Services Sync application for syncing (see Figure 7). This application is installed during Azure AD DS deployment. Only this application can read the windowsLegacyCredentials and windowsSupplementalCredentials properties.

Figure 7. Synchronization application name and ID. (Source: Secureworks)

The application was configured to use a DCaaS Sync Engine certificate for authentication (see Figure 8). The corresponding certificate was saved in the local machine Personal store on Azure AD DS domain controllers (see Figure 9).

Figure 8. Synchronization application authentication certificate defined in the Azure portal. (Source: Secureworks)

Figure 9. Synchronization application certificate on the domain controllers. (Source: Secureworks)

The DCaaS Password Hash Encryption certificate used to decrypt credential blobs was also saved in the certificate store on domain controllers (see Figure 10). Therefore, the certificates were not stored in the Azure Key vault as the documentation stated.

Figure 10. Password hash decryption certificate on the domain controllers. (Source: Secureworks)

When Azure AD Connect synchronizes passwords after Azure AD DS deployment, the synchronization request includes WindowsLegacyCredentials and WindowsSupplementalCredentials (see Figure 11, lines 34 and 35). Both attributes contain Base64-encoded credential blobs.

Figure 11. Azure AD Connect password hash synchronization request. (Source: Secureworks)

Azure AD Connect uses the GetADAuthInfo function to generate credential blobs. The function is located in the ADAuthInfoGenerator.dll file (see Figure 12).

Figure 12. Location of the ADAuthInfoGenerator.dll file. (Source: Secureworks)

Figure 13 shows the GetADAuthInfo function encrypting the password blob on line 77 by calling the Encrypt function and generating the credentials blob on line 90 by calling the WriteADAuthInfo function.

Figure 13. GetADAuthInfo function. (Source: Secureworks)

Examination of the Encrypt function reveals the encryption details (see Figure 14, lines 216 - 223). The resulting byte array is reversed on line 224 of the function.

Figure 14. Encrypt function. (Source: Secureworks)

The WriteADAuthInfo function contains details about the synchronized blob (see Figure 15, lines 22 - 29).

Figure 15. WriteADAuthInfo function. (Source: Secureworks)

Figure 16 describes the structure of the credentials blob.

Figure 16. Encryption blob structure. (Source: Secureworks)

The password blob encrypted with the Encrypt function is the unicodePwd attribute from the on-premises Active Directory environment. Figure 17 describes the password blob's structure.

Figure 17. Password blob structure. (Source: Secureworks)

Dumping NTHashes from Azure AD

Domain administrators have full access to domain controllers, so both the synchronization application certificate and the password hash decryption certificate could be exported and used remotely to dump NTHashes from Azure AD. Figure 18 shows an updated Azure AD DS attack graph that includes this attack path.

Figure 18. Azure AD DS attack graph. (Source: Secureworks)

Azure AD DS renews certificates regularly, so an attacker would need persistent access to Azure AD DS domain controllers. However, because the Azure AD Domain Services Sync application is deployed directly in an organization's Azure AD tenant, administrators with the Global Administrator or Cloud Application Administrator role can add new application credentials. As a result, they can access users' credentials without needing a DCaaS Sync Engine certificate.

When a new user is created or when a user changes their password, NTHashes stored in Azure AD are encrypted using the current DCaaS Password Hash Encryption certificate. As a result, Azure AD may have NTHashes encrypted with multiple certificates at any given time. To decrypt all passwords, attackers would need to have access to all certificates used to encrypt the passwords.

Communication with Microsoft

On December 23, 2022, CTU researchers notified the Microsoft Security Response Center (MSRC) that certain administrators can gain access to legacy credential attributes by adding extra credentials to Azure AD Domain Services Sync. The MSRC responded on January 27, 2023:

This is [..] considered by-design, except when an attacker has the cert to decrypt. Since the cert part is being addressed with [..] case [..] we will be closing this one out.

This is considered by design due to the fact that both Cloud Application Administrator and Global Administrator roles are highly privileged within AAD. And yes, they do have permissions to modify our application as outlined in the case. Also, per our current documentation, a Cloud Application Administrator can be used to elevate privileges and impersonate an app identity.

Conclusion

When an organization is using Azure AD DS, Azure AD stores users' legacy credentials, including NTHashes. The purpose of this storage is to enable synchronization of these credentials to Azure AD DS domain controllers. The credentials are encrypted with a regularly updated certificate available from the Azure AD DS domain controller certificate store. Only a specific Azure AD Domain Services Sync application has access to credentials stored in Azure AD. Administrators with Global Administrator or Cloud Application Administrator roles can add new application credentials, enabling them to retrieve encrypted legacy credentials without access to Azure AD DS domain controllers. Legacy credentials are stored on Azure AD until the user's password is reset, and they are encrypted using the certificates available on the Azure AD DS domain controllers. Decryption requires access to these certificates.

Organizations using Azure AD DS should regularly monitor Azure AD audit log for suspicious events. These events include the addition of new certificates or secrets to the Azure AD Domain Services Sync application. On October 27, 2023, Microsoft announced that Microsoft Graph activity logs are available for public preview. These logs enable detection of ongoing dumps of NTHashes. Organizations should contact Microsoft support immediately if they detect any indication of compromise.

Appendix — KQL queries

The results of the following queries could indicate a future NTHash dump.

• Identify the creation of an Azure AD DS service principal:

	AuditLogs
	| where Category == "ApplicationManagement"
	| where OperationName == "Add service principal"
	| where TargetResources[0].displayName == "Azure AD Domain Services Sync"
	| where InitiatedBy.app.displayName == "Domain Controller Services"
	

• Identify the creation of an Azure AD DS Sync application:

	AuditLogs
	| where Category == "ApplicationManagement"
	| where OperationName == "Add application"
	| where TargetResources[0].displayName == "Azure AD Domain Services Sync"
	| where InitiatedBy.app.displayName == "Domain Controller Services"
	

The following KQL query identifies the addition of extra credentials to an Azure AD DS Sync app, which indicates a future NTHash dump as there is no legitimate use case to update credentials:

	AuditLogs
	| where Category == "ApplicationManagement"
	| where OperationName contains "Certificates and secrets management"
	| where TargetResources[0].displayName == "Azure AD Domain Services Sync"
	| where InitiatedBy.app.displayName != "Domain Controller Services"
	

The following KQL query can identify an ongoing NTHash dump from MicrosoftGraphActivityLogs (when publicly available):

	let AADDS_appId = AADServicePrincipalSignInLogs
	| where TimeGenerated > now() - 10m
	| where ServicePrincipalName == "Azure AD Domain Services Sync"
	| distinct AppId;
	

	MicrosoftGraphActivityLogs
	| where RequestMethod == 'GET'
	| where AppId == AADDS_appId
	| where RequestUri !contains '/users/microsoft.graph.delta()?$deltatoken'