In his TROOPERS19 talk (“I’m in your cloud … reading everyone’s email”), Dirk-jan Mollema discussed an issue he discovered that enabled the use of SMTP matching (also called soft matching) to synchronize Active Directory (AD) users to Azure AD, with the goal of hijacking unsynchronized accounts. Jan stated that Microsoft blocked the ability to synchronize on-prem accounts that had active assignments to administrative roles within Azure AD.
We dug into this statement. Bad news: Our research shows that anyone with account creation privileges in an AD environment can modify the password of an Azure AD user and—with a few prerequisites—obtain privileged access via eligible role assignments.
What leads to this Azure AD vulnerability?
Most organizations use Active Directory to manage permissions and access to network resources. Many of these organizations are also starting to use Azure AD, a cloud-based identity and access management service, to manage user identities and access privileges to resources such as the Azure portal and Office 365.
In hybrid identity implementations, objects are synchronized between the on-premises AD environments and Azure AD tenants. In such environments, users can use the same identity for both on-prem AD and Azure AD.
Azure AD Connect
Azure AD Connect is a Microsoft application designed to achieve a hybrid identity by synchronizing on-prem AD objects with Azure AD objects. Azure AD Connect encompasses many features, the most important ones being password hash synchronization, pass-through authentication, federation integration (with ADFS), and synchronization (with Azure AD Connect Sync). Password hash synchronization and general synchronization are most relevant to this discussion.
During an Azure AD Connect Express installation, new accounts are created to support the synchronization.
- AD DS connector account:
- Used to read and write to AD
- Granted the Replicate Directory Changes and Replicate Directory Changes All permissions for use of the Password Hash Sync
- Prefixed with MSOL_########
- ADSync service account: Used for synchronization and for accessing the SQL database
- Azure AD Connector account:
- Used to write information to Azure AD
- Granted the special Directory Synchronization Accounts role, which has permissions only to perform directory synchronization tasks
- Prefixed with Sync_*
In a hybrid identity implementation, integrity between on-prem environments and Azure AD tenants is important. To achieve this goal, Azure AD Connect matches user objects between Azure AD and AD.
During initial Azure AD Connect setup and synchronization, a source anchor attribute is chosen. This attribute uniquely identifies a user object between AD and Azure AD. Azure AD Connect performs matching by looking at this attribute and matches user objects between Azure AD and AD using one of two techniques:
- Hard matching
- Soft (SMTP) matching
Hard 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 and older use objectGUID.
- Azure AD Connect version 1.1.524.0 and newer use mS-DS-ConsistencyGuid.
When the mS-DS-ConsistencyGuid attribute is unpopulated, Azure AD Connect writes the user’s objectGUID to that attribute. ImmutableID is the corresponding value on the Azure AD object—essentially, the base64-encoded objectGUID. Figure 1 shows an example of getting the ImmutableID of an Azure AD object from the on-prem AD user’s objectGUID.
Soft (SMTP) matching
Soft (SMTP) matching uses two attributes that exist in both AD and Azure AD:
- userPrincipalName
- proxyAddress
Soft matching succeeds when user objects are matched, so long as two conditions apply:
- The userPrincipalName attribute in Azure AD matches the one in AD.
- The primary proxyAddress attribute in AD matches the proxyAddress in Azure AD.
When a hard or soft match succeeds, the matching user object is updated. If no match exists, a user object is created in the Azure AD tenant to match the on-prem AD user object, using the account’s attributes.
Password hash synchronization
Password hash synchronization is an authentication method that is implemented in Azure AD hybrid identity environments. This method, which is enabled by default, synchronizes the hash of the user’s on-prem AD password to Azure AD every two minutes. Password hash synchronization enables users to use the same password to log in to both AD and Azure AD. (For a more detailed explanation of password hash synchronization, see Semperis – Understanding Azure AD Password Hash Sync.)
Active versus eligible roles
Azure AD users can be assigned roles that grant permissions to manage various Azure AD resources. Roles can be either active or eligible assignments.
Eligible assignments require the user to activate the role. To do so, the user must perform an MFA action, provide a business justification, or request approval from designated approvers. Eligible roles can be assigned permanently or for a specific period (Figure 2). There is no time limit on when a permanently assigned eligible role needs to be activated.
Active assignments don’t require any user action for the use of the role. Users have the privileges associated with a role for as long as they remain assigned to that role (Figure 3).
How SMTP matching becomes an Azure AD vulnerability
An object in Azure AD can be managed in Azure AD or on-prem AD. Each object has a flag showing whether the account has been synchronized with an on-prem account. The following example shows this flag in the Azure Users panel. User Lee Gu is synchronized (Figure 4); user Lynne Robbins is not (Figure 5).
Figure 5You can also see these settings in the Office 365 Active Users panel, in the Sync Status column (Figure 6 and Figure 7).
Figure 7
At times, you might want to transfer a cloud-managed user account’s source of authority. For example, suppose that a user account is created directly from Office 365, which makes the user cloud-managed. But you want to manage that user through on-prem AD, as we do the rest of your users.
To do so, you can use directory synchronization. This method uses SMTP matching to synchronize the Office 365 user account with an on-prem user account, based on the proxyAddress attribute.
To synchronize accounts by using SMTP matching, two steps are required:
- Create an AD account with the same userPrincipalName as the Azure AD account.
- Configure the proxyAddress attribute to match the Azure AD user’s proxyAddress
Figure 8 shows the Lee Gu user properties in on-prem AD. Here, you create the user and assign it the same proxyAddress and userPrincipalName as the cloud-managed Lee Gu user.
Figure 9 shows the Lee Gu user properties on Azure AD.
If Azure AD Connect finds an object in Azure AD with the matching userPrincipalName and proxyAddress attributes, SMTP matching occurs. If password hash synchronization is configured, which it is by default, this process overwrites the existing password for the Azure AD account with the password for the on-prem account.
Important notes about the SMTP matching process:
- The AD user must be newly synchronized.
- Dirk-jan found that if the Azure AD user is an active high-privileged user, the synchronization does not work. For example, you can’t synchronize an on-prem user to an active Global Administrator Azure AD user. (This issue was fixed after Dirk-jan discovered it.)
- If the userPrincipalName of the on-prem user doesn’t match the cloud-based user, then a new cloud user is created. This user is synchronized with the on-prem user and has a valid Office 365 email address, which is determined by its userPrincipalName attribute rather than by its proxyAddress
For example, if you try to synchronize user Megan Bowen by using the proxyAddress attribute but a different userPrincipalName, the result is a new Azure AD user—even if you have no access or permissions on Azure AD (Figure 10).
If you create a new on-prem user with the same proxyAddress attribute but a different userPrincipalName (Figure 11), you end up with two user objects named Megan Bowen, each with a different userPrincipalName. The newer object is synchronized, and the original object is cloud-managed by Azure AD (Figure 12).
Figure 12
You can log in with the new cloud user account and on-prem password and configure MFA (Figure 13).
How SMTP matching can lead to abuse
The Semperis Research Team discovered that it is possible to use SMTP matching to synchronize on-prem users to Azure AD users that are eligible for administrative roles. Attackers who have gained on-prem access can use this approach to compromise Azure AD.
The SMTP matching process works for high-privilege users who are eligible for a privilege that has not been activated. Abuse is possible whether the administrative role has been made eligible directly to the user or via an Azure group that is eligible to activate the role.
To abuse SMTP matching, either MFA must be unused or role activation must not require an MFA verification. We created a list of all the high-privileged roles that do not require MFA verification for role activation (Table 1).
Table 1. High-privileged roles and MFA verification requirements
| Require MFA | Do not require MFA |
| Azure Information Protection Administrator Billing Administrator Cloud Application Administrator Compliance Administrator Conditional Access Administrator Customer LockBox Access Approver Directory Writers Dynamics 365 Administrator Exchange Administrator Global Administrator Intune Administrator Partner Tier1 Support Partner Tier2 Support Power BI Administrator Privileged Role Administrator Security Administrator SharePoint Administrator Skype for Business Administrator User Administrator |
Guest User Restricted Guest User Guest Inviter Helpdesk Administrator Service Support Administrator User Directory Readers Device Users Azure AD Joined Device Local Administrator Device Join Workplace Device Join Directory Synchronization Accounts Device Managers Application Administrator Application Developer Security Reader Reports Reader Message Center Reader Desktop Analytics Administrator License Administrator Cloud Device Administrator Authentication Administrator Privileged Authentication Administrator Teams Communications Administrator Teams Communications Support Engineer Teams Communications Support Specialist Teams Administrator Insights Administrator Message Center Privacy Reader External ID User Flow Administrator External ID User Flow Attribute Administrator B2C IEF Keyset Administrator B2C IEF Policy Administrator External Identity Provider Administrator Compliance Data Administrator Security Operator Kaizala Administrator Global Reader Search Administrator Search Editor Password Administrator Printer Administrator Printer Technician Authentication Policy Administrator Groups Administrator Power Platform Administrator Azure DevOps Administrator Hybrid Identity Administrator Office Apps Administrator Network Administrator Insights Business Leader Teams Devices Administrator Attack Simulation Administrator Attack Payload Author Usage Summary Reports Reader Knowledge Administrator Knowledge Manager Domain Name Administrator Attribute Definition Administrator Attribute Assignment Administrator Attribute Definition Reader Attribute Assignment Reader Exchange Recipient Administrator Identity Governance Administrator Cloud App Security Administrator Windows Update Deployment Administrator Windows 365 Administrator Edge Administrator Virtual Visits Administrator Insights Analyst |
For example, suppose cloud-managed user Lidia Holloway is eligible for the Global Administrator role (Figure 14).
You use SMTP matching to synchronize this user with a new on-prem user (Figure 15).
After using Lidia’s on-prem password to log in to Azure AD, the Global Administrator role can be activated (Figure 16). To do so, you need to use MFA (“Additional verification required”). If the original cloud user didn’t require MFA, you can simply configure it and then activate the role (Figure 17).
Figure 17
You can activate a role that does not require MFA extra verification but can be elevated to Global Administrator, such as Application Administrator. And as Dirk-jan describes, that role can then be directly escalated to the Global Administrator role.
Using Semperis DSP to detect this Azure AD vulnerability
Semperis Directory Services Protector (DSP) collects Azure AD change data. To detect an attempt to exploit this vulnerability, DSP looks for the specific attack pattern, which includes synchronizing an AD user with an Azure AD user who is eligible for a high-privilege role, followed by activation of that role. DSP security indicator (SI) “Azure AD Role activation after synchronization” identifies this pattern. DSP also identifies the “AAD user eligible for a high privilege role that is not synced to AD” SI, which indicates Azure AD users that are eligible for a high-privilege role and have the proxyAddress attribute but are not synchronized with an on-premises account, making them vulnerable to this attack.
Other detections of SMTP matching abuse
Another option is to use Azure audit logs to search for any synchronization and role activation in your environment (Figure 18).
In this example, you can see that the Action Client Name is “DirectorySync” and that the Old Value for LastDirSyncTime is empty. This information indicates that this is the first time the user synchronized with on-prem AD.
The following log shows role activation (Figure 19). Using the RoleDefinitionOriginId attribute, you can search for the activated role.
SMTP matching abuse remediation
To prevent this exploit, Microsoft recommends requiring MFA for all users (“Harden your Azure AD Connect server”). Mitigation is achieved by ensuring that users have MFA configured before granting them an eligible role. You can also disable the option to use soft matching for synchronization.
Disclosure
This issue was reported via the Microsoft Security Response Center (MSRC) on June 10, 2022. Microsoft replied on July 13: “[B]ased on our assessment, there are mitigative controls in place that a user can use to avoid this vulnerability. We determined the behavior to be by design.”
Learn more
To learn more about protecting your organization from AD and Azure AD vulnerabilities, see the following resources:
