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
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:
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).
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).
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
Cloud Application Administrator
Conditional Access Administrator
Customer LockBox Access Approver
Dynamics 365 Administrator
Partner Tier1 Support
Partner Tier2 Support
Power BI Administrator
Privileged Role Administrator
Skype for Business Administrator
Restricted Guest User
Service Support Administrator
Azure AD Joined Device Local Administrator
Workplace Device Join
Directory Synchronization Accounts
Message Center Reader
Desktop Analytics Administrator
Cloud Device Administrator
Privileged Authentication Administrator
Teams Communications Administrator
Teams Communications Support Engineer
Teams Communications Support Specialist
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
Authentication Policy Administrator
Power Platform Administrator
Azure DevOps Administrator
Hybrid Identity Administrator
Office Apps Administrator
Insights Business Leader
Teams Devices Administrator
Attack Simulation Administrator
Attack Payload Author
Usage Summary Reports Reader
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
Virtual Visits Administrator
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).
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.
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.”
To learn more about protecting your organization from AD and Azure AD vulnerabilities, see the following resources: