Advisory: Flaw in Azure AD Connect Software Can Allow Stealthy Admins to Gain Full Domain Control
We recently reviewed a customer’s network and found that 85%(!) of all users in the network had some unnecessary administrative privilege. The excessive privilege stemmed from an indirect inclusion in a protected admin group. Most Active Directory audit systems easily alert on excessive privileges, but will often miss users who have elevated domain privileges directly through domain discretionary access control list (DACL) configuration. We refer to these users as stealthy admins.
As we investigated stealthy admins further, we discovered a surprising issue was occurring when customers were installing Microsoft Office 365 with Azure AD Connect software in hybrid deployments. We found a flaw with how the Azure AD Connect software configures the AD DS directory synchronization account (MSOL) that causes networks to have many unwanted stealthy admins due to an improper default configuration. This flaw affects enterprises that have Microsoft Office 365 deployments, that have an on-premise Active Directory, and have used the Azure AD Connect to connect between the on-premise and the cloud (hybrid deployments).
In this advisory blog we will discuss
- Understanding Stealthy Admins
- Details on the Azure AD Connect Account Flaw
- Who is Impacted
- How Stealthy Admins can be Exploited
- How Organizations can Protect Themselves
The below video provides a brief overview with instructions on steps to take to protect your organization.
What are Stealthy Admins?
An important principle for making an organization more secure is the principle of minimal privileges. The core of this principle is to make sure each person (or any other entity) in the organization has the bare minimum amount of permissions that is necessary for carrying out their tasks. Even when the principle is applied well, some users will be tasked with managing the organization’s network and will have ‘carte blanche’ to perform any operations in the network. In a Microsoft Active Directory domain setting, these are the Domain Admins. Usually, users are granted Domain Admin privileges by being a member of a pre-defined security group. You can review some of these groups here.
Microsoft permissions model, managed through ACLs, is highly complex. It contains nesting hierarchies, complex ownerships rules, custom object permissions and many other nuances.
One interesting property is that users can achieve effective domain admin permissions even though they are not a member of any of the protected security groups – these are stealthy admins.
There are many permissions users might have that are equivalent to full domain admin privileges, and more are being published. Without diving too deep into technical details, here is a non-exhaustive list of notable examples of permissions that can make a user a stealthy admin:
- Add to Group – A user/group can be given specific permissions to add users to a given security group. As strange as it might sound, a user can be given permissions to add users to the protected Domain Admins group (or other groups granting similar permissions).
Elevation method: A user can make themselves a domain admin at any given point.
- Reset Password – A user/group can be given specific permissions to reset another user’s password.
Elevation method: Again, albeit strange, a non-admin can be given specific permission to reset an admins password, and use the new password to login.
- Replicate Domain – An even more interesting permission is the permission to replicate the domain. The replicate permission often includes the right to read all password hashes from the domain controller.
Elevation method: Once you obtain an admin’s password hash, you could use it to perform admin actions. (You might find this fact very interesting as many software packages require this specific permission!)
Stealthy admins are widespread in enterprises. In fact, we rarely examine a network where no stealthy admins are found. So, how are stealthy users “born”? Most of the time, they are created without any malicious intent but as part of some software package installation process or from a specific business need where an administrator follows least privilege guidelines but may forget to follow up and remove them.
The Flaw in Azure AD Connect Account (MSOL)
We have recently encountered a very notable example that we have seen in over 50% of our clients related to the Azure AD Connect account (when installed with the Express Settings). Azure password synchronization is used as an on-premises extension of Azure AD as a way to sync passwords between on-premises network and cloud services. As such, obviously it requires domain replication permissions to extract the passwords. We view this configuration as problematic for a couple of reasons.
First, as previously stated, such accounts are often less monitored than full domain admins even though they have relatively high privileges.
But a more serious issue is that the account has no AdminSDHolder protection. As this user is not considered an admin, it does not have AdminSDHolder protection, and it is possible to have other non-privileged users reset its password. In many networks we found that this account was a main attack path for attackers with Account Operator permissions to escalate their privileges and become full domain admins.
Imagine a help desk technician with permissions to reset non-admin passwords but no other domain admin privileges. Because the MSOL account is generated under the Built-in Users container, and the Built-in Account Operators group (e.g. helpdesk team) has permissions to reset passwords for the Built-in Users container, this gives the account operator full de facto access to domain passwords, as well as other elevated privileges (e.g. Domain Admin).
Here is a video that shows how the Azure AD connect flaw could be exploited:
Who Is Impacted?
All enterprises who have Microsoft Office 365 hybrid deployments, that have an on-premise Active Directory, have used the Azure AD Connector to connect between the on-premise and the cloud. This effects a significant number of enterprises and could be in the hundreds of thousands of companies.
How Stealthy Admins Can Be Exploited
We consider stealthy admins to be a security issue for a couple of reasons: First, these users are very often overlooked and are not managed with the same tools other admin accounts are, yet they still have administrative privileges. Also, since these users didn’t get their permissions through a regular security group, it is possible they were given permissions by mistake, or even more gravely, by someone with malicious intent. Just this year, there were two findings published that unveiled new techniques to create stealthy admin backdoors (one at BlackHat and one at DEF CON). Finally, since stealthy admins are lacking visibility and protection they usually pose an increased attack surface as their credentials can be harvested and exploited just like admins.
MSRC Response On the Discovered Flaw:
Microsoft acknowledged the issue and has released a Microsoft Security Advisory 4056318 and a PowerShell script that addresses the flaw by adjusting the permissions of the Active Directory domain accounts to modify properties of the AD DS synchronization account (MSOL). In future new installs of Azure AD Connect with Express Settings, only Enterprise Admins, Domain Admins and built-in Administrators of the domain will be able to modify the MSOL account (e.g. reset its password).
Preempt Customers have been protected from this flaw since October with defense in depth — They receive both alerting on discovery of stealthy admins in their network as well as real-time prevention when suspicious behavior is detected from any of these users. Customers seeking more information can contact email@example.com
How Organizations Can Protect Themselves
Stealthy admins pose a risk to your organization’s security posture. In order to protect your network we advise:
- Review all stealthy administrators in your network. Preempt offers a review of the stealthy admins as part of the Preempt Platform.
- For each stealthy admin, decide whether added permissions are indeed necessary. If not, you should remove those privileges, otherwise, we suggest adding the user to one of the Active Directory protected groups. Specifically, for the AD DS directory synchronization Account (MSOL), apply the permissions fix using the PowerShell script provided by Microsoft. For other accounts, you can view and manage all administrative privileges directly from the Preempt platform.
- You should protect your privileged (known and stealthy) users by adding protection. Using the Preempt Platform you can automatically respond to suspicious activity based on identity, behavior and risk (from any user with any level of privilege, including stealthy admins). Based on the level of risk and policy, the user could be challenged to verify their identity with MFA, blocked, or more.
Posted by Preempt Research Team on December 12, 2017 9:42 AM