This blog describes a vulnerability discovered by Fox-IT last year in Azure AD Connect, which would allow anyone with account creation privileges in the on-premise Active Directory directory to modify the password of any cloud-only account in Azure AD. Because of the way accounts are commonly configured, this could often enable an attacker to take over the highest admin accounts (Global Administrator) in Azure AD.
Azure AD Connect – connecting on-premise and the cloud
When companies use Azure, for example for Office 365, it is common to synchronize the accounts in Azure with the accounts on-premise. This way users can sign in with the same identity, and often with the same password, for their Azure resources. Azure AD connect is a utility offered by Microsoft which enables this by continuously synchronizing on-premise data with Azure AD. The two most common ways for this are via Active Directory Federated Services (ADFS) and Password Synchronization.
With password synchronization, the password of every account is synchronized from Domain Controllers on-premise and pushed to Azure. The privileges required for this are similar to the privileges of Domain Controllers (who use the same protocols to synchronize between each other), making the Azure AD Connect server a high-value target for attackers. With ADFS, the authentication is not performed in Azure but on a server on-premise, which becomes the authority for the Azure AD environment. In this post we will focus on Azure AD Connect configured in Password Synchronization mode, but it is likely that the vulnerability also applied to other methods of authentication.
From on-premise to the cloud?
This story started on an assignment for one of our clients, where we performed a scenario based penetration test. In such tests, flags are defined that the testers will try to achieve during the test by escalating privileges and compromising business critical systems. In this assignment, one of the flags was to gain access to the inbox of the CEO, which was in Office 365. The CEO’s account also had Multi Factor Authentication (MFA) enforced, meaning that even if we did accomplish to obtain the password, we still wouldn’t be able to access the inbox without disabling MFA or using phishing. We could not obtain the flag by taking over his workstation either, as the person in question was out-of-office during the limited time-frame available for the assignment.
For some of the different flags we already obtained Domain Admin privileges in the network. The question we asked ourselves was: given a certain amount of access in the on-premise Active Directory, can we compromise Azure AD as well?
Account synchronization
Whenever a new account is added to the on-premise directory in an Organizational Unit configured for synchronization, Azure AD Connect will create a user in Azure AD and match the account using the account’s properties. Depending on which attributes are configured for synchronization, things like name, title, phone number, etc will be copied from the on-premise account to the Azure AD account.
We started looking if there is also a process to connect existing cloud users (which maybe were created in Office 365 already) to on-premise accounts. Some searching led us to this document, which described how it’s possible to match existing accounts using SMTP matching. If a new account is created on-premise with the same proxyAddress attribute as one of the SMTP proxy addresses of the Azure AD account, the account would be changed from a cloud-only account to a synchronized account. This process overwrites the existing password for the Azure AD account with the password from the on-premise account.
Finding the correct target account
To match an account, a few requirements have to be met. The account should:
– Not yet by synchronized with the on-premise directory
– Have a mailbox associated (otherwise the proxy address would be empty), an active license is not required
– Not have Multi Factor Authentication enforced since overwriting the password does not change MFA requirements
The first two requirements can be queried using Azure AD Powershell modules. There are multiple modules for this, the modules with the most Azure AD functions are the MSOnline and AzureAD powershell modules. These modules differ slightly in approach, with the MSOnline module being more focused on Office 365 and the AzureAD module having more functionality for Azure AD and the Azure Resource Manager. In the example below we use the MSOnline module, which is now deprecated but at the time of writing still contains functionality not available in other modules.
First we query for the roles in the directory. While the highest privileged role is called Global Administrator in the Azure portal, it is actually called Company Administrator in the Office 365 terminology. Any Azure AD user can by default query all roles, groups, users and members (similar to on-premise Active Directory).
With the Get-MsolRole command we list all the roles in our Azure AD:
We then list the members of the Global Administrators role:
With the get-msoluser command we can query individual users and their properties:
From here we can establish whether the user is cloud-only or synchronized from the on-premise directory, since in the latter case the LastDirSyncTime field will have a value associated. Similarly the proxyAddresses attribute shows any mailboxes associated with the user, which we can use to target it. It is also possible to query if a user has MFA enforced, since that will make the StrongAuthenticationRequirements field contain data, however this can only be queried by high-privileged users.
Even though enforcing Multi Factor Authentication is frequently recommended by both Microsoft and security researchers, it is still very common for several accounts to exist that don’t have this enforced. Examples of this are accounts used in automated processes, such as user migrations. Another example is the emergency break-glass account, which presence is recommended by Microsoft in case other admin accounts are locked out or some authentication methods are not available. Though the documentation is updated nowadays, the official Microsoft recommendation up until late 2018 was to not enforce MFA on this account and to exclude it from any Conditional Access policies, making it a prime target to this attack.
Exploitation
In the test directory above we found a cloud-only account with most likely no MFA enforced, but with a mailbox attached. To exploit this, we create a new user in Active Directory with the same SMTP address as the victim account:
Azure AD Connect will automatically pick up the account on it’s next sync cycle, joining the accounts and overwriting the Azure AD account’s password with the password we just set for the on-premise user. In the Microsoft 365 admin center this user now shows up as Synced with on-premise:
We can now log in with this user in Azure AD and manage everything in Office 365. This includes delegating ourselves access to the CEO’s mailbox, and thus obtaining our flag:
Impact and disclosure
While in the above scenario we already had Domain Admin privileges and thus could perform any action in the on-premise directory, these privileges are not required for the actions we performed. The creation of new accounts is often delegated to IT admins in helpdesk positions, who are delegated control of limited Organizational Units in larger organizations. This vulnerability means that even in organizations with thousands of employees, a single compromised helpdesk account would be sufficient to take over the highest privileged account in Azure AD and Office 365 (provided that the previously mentioned conditions were met).
We reported this issue to Microsoft through MSRC in June 2018, and they resolved the issue in November 2018. Since then if you try to link an account with high privileges to an on-premise directory account, a new account will be created instead.
Recommended defenses
As mentioned previously, this attack only works when Multi Factor Authentication is not enforced for all admin accounts. Sadly this is still the case in many organizations. This means that if some way is discovered to bypass password authentication, the account can immediately be abused by attackers. Enforcing MFA for all admin accounts greatly reduces the risk of password related leaks or vulnerabilities.
If for whatever reason you are unable to enforce MFA for some (Global) Administrator accounts, and you do have access to the Cloud Security center (which does require a subscription including this), you can configure an alert for this account which will notify other admins if anyone logs in with this account.
If you do want to know more about my Azure AD research and other vulnerabilities, you can watch my Troopers talk about Azure AD on YouTube or access just the slides here.