This post describes an abuse of hard matching synchronization in Azure AD Connect that can lead to Azure AD account takeover. These findings build on the research that Semperis published in August, which described abuse of soft matching (also known as SMTP matching).
This SyncJacking vulnerability means that an attacker with certain privileges can abuse hard matching synchronization in Azure AD Connect to completely take over any synchronized Azure AD account—including Active Global Administrator.
These findings were promptly reported to the Microsoft Security Response Center (MSRC), which updated hardening guidelines to provide more specific mitigations against hard matching abuse. While MSRC rapidly responded and updated the hardening guidelines, further testing shows that the attack can succeed even after these mitigations are implemented. Therefore, we strongly advise extra mitigation to combat abuse and potential Azure AD account takeover.
Azure AD Connect and hard matching
As explained in “SMTP Matching Abuse in Azure AD,” Azure AD Connect is a Microsoft application that supports hybrid identity by synchronizing on-prem AD objects with Azure AD objects. Azure AD Connect features include password hash synchronization, pass-through authentication, federation integration (with ADFS), and synchronization (with Azure AD Connect Sync).
The hard matching Azure AD account takeover discussed here abuses the password hash synchronization and general synchronization features of Azure AD Connect.
To achieve integrity between the on-prem environment and Azure AD tenants in hybrid identity implementations, Azure AD Connect matches user objects between AD Azure AD. A source anchor attribute, chosen during initial Azure AD Connect setup and synchronization, uniquely identifies each of these user objects between AD and Azure AD. Azure AD Connect uses this attribute to match user objects between Azure AD and AD using one of two techniques:
Soft (SMTP) matching
If you let Azure manage the source anchor, Azure AD Connect looks for one of two possible sourceAnchor attributes:
Azure AD Connect version 1.1.486.0 or older looks for the objectGUID
Azure AD Connect version 1.1.524.0 or newer looks for the mS-DS-ConsistencyGuid
If the mS-DS-ConsistencyGuid attribute is unpopulated, Azure AD Connect writes the user’s objectGUID to that attribute. The corresponding value on the Azure AD object is ImmutableID (the base64-encoded objectGUID). Figure 1 shows an example of hard matching: getting the ImmutableID of an Azure AD object from the on-prem AD user’s objectGUID.
This mechanism is the object of the abuse discussed in this post.
Password hash synchronization
Password hash synchronization, an authentication method that is enabled by default in Azure AD hybrid identity environments, synchronizes the user’s on-prem AD password hash to Azure AD every two minutes. This synchronization enables use of the same password to log in to both AD and Azure AD. (For a detailed explanation of password hash synchronization, see “Understanding Azure AD Password Hash Sync.”)
How attackers can use hard matching to facilitate Azure AD account takeover
To perform this attack, an attacker requires only two permissions:
Write-all-Properties or GenericWrite on an unsynchronized on-prem AD account
Delete on a synchronized on-prem AD account
The following example illustrates this attack on an account with an Active Global Administrator role assignment in Azure AD. Note that this attack works on any synced account.
Nutshell is a synchronized Active Global Administrator in Azure AD with the UPN email@example.com (Figure 2, Figure 3).
Because nutshell is a synchronized user, it has a presence in the on-prem AD environment. The attacker has Write-All-Properties permission on an unsynchronized on-prem AD account AliceIC. The attacker also has Delete permission on the synchronized on-prem AD nutshell account. In addition, the attacker has the password for the AliceIC account.
Here’s how the attacker can use the on-prem user AliceIC to hijack the nutshell Azure AD account.
First, the attacker copies the nutshell Azure AD UPN to the AliceIC on-prem AD userPrincipalName attribute (Figure 4).
Figure 5 shows the population of the nutshell on-prem AD mS-DS-ConsistencyGuid attribute.
Next, the attacker copies the value of the nutshell mS-DS-ConsistencyGuid attribute into the AliceIC mS-DS-ConsistencyGuid attribute (Figure 6).
Finally, the attacker deletes the on-prem nutshell account and waits for synchronization (Figure 7).
Now, the AliceIC on-prem AD account is synchronized to the nutshell Azure AD account. Because Azure AD Connect uses password hash synchronization by default, the AliceIC password and DisplayName attribute are also synchronized to the nutshell Azure AD account.
AliceIC is now an Active Global Administrator and acting on behalf of nutshell (Figure 8). As mentioned earlier, you will find no trace of these changes in on-prem logs and only minimal trace in Azure AD logs.
It’s important to note why attackers might exploit this method:
The use of hard matching to facilitate Azure AD account takeover leaves no trace in on-prem AD logs and only minimal trace in Azure AD logs.
The attack requires only two permissions on target accounts to completely take over any synchronized account with any role.
An attacker who possesses relatively high permissions in AD can take over Azure AD by taking over any synchronized account with an Active/Eligible assignment.
User delegation. If a user or group has been delegated control to manage users in one or more organizational units (OUs) with synchronized and unsynchronized users, then that user or group has full control on these objects and can hijack any of them—theoretically even becoming a Global Administrator.
Account Operators. Any user in the Account Operators group can manage all accounts and has account creation privileges. Therefore, any Account Operator can hijack any synchronized users.
Using Semperis DSP to detect this type of Azure AD account takeover
Semperis Directory Services Protector (DSP) collects Azure AD changes and on-prem AD data and uses this data to detect attempts to exploit this vulnerability. Despite the minimal traces left by the attack, DSP’s specific capabilities enable detection.
Other detections of SyncJacking abuse
You can reasonably (although not definitively) assume that this attack has occurred if two log events occur one after another in Azure AD: “Change user password” followed by “Update User” with a changed DisplayName and a target that uses the same UPN (Figure 9, Figure 10).
MSRC has updated its guidelines to include the following recommendation:
Disable Hard Match Takeover. Hard match takeover allows Azure AD Connect to take control of a cloud managed object and changing the source of authority for the object to Active Directory. Once the source of authority of an object is taken over by Azure AD Connect, changes made to the Active Directory object that is linked to the Azure AD object will overwrite the original Azure AD data – including the password hash, if Password Hash Sync is enabled. An attacker could use this capability to take over control of cloud managed objects. To mitigate this risk, disable hard match takeover.
Our testing shows that SyncJacking works even after disabling hard match takeover. Regardless, this hardening guideline is important to apply.
MSRC states that it is important to enable MFA for all users who have privileged access in Azure AD or in AD. Currently, the only way to mitigate this attack is to enforce MFA on all synced users. This isn’t a surefire way to stop an attacker from accessing your account if SyncJacking is abused, but it can help. Be sure to follow all hardening guidelines provided by Microsoft in the previous link to mitigate many attack surfaces in your hybrid identity environment. For even greater protection, consider implementing DSP for Identity Threat Detection and Response (ITDR).
October 6: Semperis discovers abuse and reports it to MSRC.
October 12: MSRC replies with hardening guidelines.
October 18: Semperis responds to MSRC with new information; attack still works with mitigations applied.
October 27: MSRC reopens the case to review the information.
November 4: MSRC updates documentation hardening guidelines to specifically mitigate against hard matching abuse, notes that the hard matching behavior described here is by design.
November 7: Semperis responds to MSRC; attack still works with hardening guidelines applied.
November 11: MSRC maintains that the behavior is by design.
Special thanks to the following people:
Andrea Pierini (@decoder_it)
Charlie Clark (@exploitph)
Sapir Federovsky (@sapirxfed)
Special acknowledgment to MSRC for recognizing the exposure and rapidly responding with updated guidelines.
The post SyncJacking: Hard Matching Vulnerability Enables Azure AD Account Takeover appeared first on Semperis.