Shadow Admin accounts are accounts in your network that have sensitive privileges and are typically overlooked because they are not members of a privileged Active Directory (AD) group. Instead, Shadow Admin accounts were granted their privileges through the direct assignment of permissions (using ACLs on AD objects).
From the attacker’s perspective, these accounts are highly desired because they provide the administrative privileges necessary to advance an attack, and they have a lower profile compared to accounts under the well-known admin groups (ex: Domain Admins).
To maintain a strong security posture, CyberArk Labs highly recommends that organizations get to know all of the privileged accounts in the network, including those Shadow Admins. For that reason, we developed a special tool that scans and discovers privileged accounts based on account permissions. The tool, ACLight, is available for free on GitHub and can be used to discover these Shadow Admin accounts on your network today. You can find ACLight here.
Once you discover these Shadow Admin accounts, we recommend that you take steps to fully protect them.
Background: Defining Privileged Accounts
Most security professionals are well aware of the importance of protecting privileged accounts in networks and the potential damage an attacker can cause with access to a privileged account.
So, what are the privileged accounts?
There are four main categories of privileged accounts:
- Domain privileged accounts, such as Domain admin users, DHCP admin users
- Local privileged accounts, such as Local Administrator accounts on endpoints and servers, and “root” on *nix boxes
- Application/services privileged accounts, such as DB admins or SharePoint admins
- Business privileged accounts, such as Finance users or the corporate Twitter account
In this blog post, we focus on the first category: domain privileged accounts. We prioritized this category because these accounts are the most powerful accounts in a network. If these accounts are compromised, an attacker can easily compromise all other accounts in the domain.
Identifying Domain Privileged Accounts
The basic and naïve way to identify privileged accounts is to review the built-in privileged groups in Active Directory. To do this, one can query and list all the accounts in the groups “Enterprise Admins,” “Domain Admins,” “Account Operators,” “Schema Admins” and so on.
However, what if the organization created their own additional admin groups, such as a new domain admins group named “DA_accounts”? If we stop searching after the first step described above, we will miss all the other unique administrative groups the organization created – and therefore miss those additional highly privileged accounts.
Moreover, what if your organization mismanaged Active Directory permissions and did not have the time (or did not take the time) to take care of the details and update the necessary Access Control Lists (ACL)? There may be legacy sensitive ACL assignments that have been forgotten. Or perhaps a specific account needed a specific permission, but the administrator who made the change did not fully understand the implications of directly assigning the privileged permission.
Figure 1 shows the difference between using group assignments and direct assignments in an ACL.
Figure 1: Delegated ACL permissions in Active Directory
To know and keep track of all our privileged accounts in the domain, we must have a better method of identifying privileged accounts. Let’s consider a new approach, one that looks directly at the ACL permissions.
Understanding ACLs
At the heart of every network there are the Domain Controllers and the Active Directory instances that run on them.
Active Directory is composed of a tree of objects that define the network and all its accounts, assets, groups, system, GPOs and more. Each object in the Active Directory has its own list of permissions (ACEs – Access Control Entries) that make up the ACL. Each object’s ACL defines who has permissions on that specific object and what actions can be performed on it. There are several kinds of permissions, from “Full Control” permission to more specific permissions like “Write,” ”Delete,” “Read” and even some “Extended Rights” such as “User-Force-Change-Password,” which allows the reset of the targeted account password.
Figure 2 shows an example of the ACL of the Active Directory “Domain Admins” group object:
Figure 2: Active Directory tree of objects, each with its own ACL
Figure 3: Advanced look at the ACL of the Domain Admins group object, the specific entry for administrators and the defined permissions
Figure 3 provides a more detailed look at the ACL of the Domain Admins group. Note that the Domain Admins group is granted full access to all objects in the directory by default, but an account does not need to be a member of the Domain Admins group to have those same permissions. An individual account can be granted the same ACEs as a domain admin, yet remain outside of the Domain Admins Active Directory group. Such an individual account would be classified as a “Shadow Admin” account.
Exploiting the Shadow Admin
Once an attacker gets inside the network, he or she will most likely target domain admin privileges to gain flexibility to access desired accounts and assets. However, creating a new account in the Domain Admins group will likely set off alarms, as the account can easily be detected. To stay under the radar, it is in the attacker’s best interest to compromise an existing account and add domain admin permissions directly to the account without changing group membership.
Discovering Shadows Admins through ACL Analysis
As demonstrated above, group analysis is not sufficient when attempting to discover all privileged accounts in the domain. Instead, searching and analyzing the ACL permissions granted to each account is a more comprehensive method.
Permission analysis of Active Directory will identify all the accounts that have sensitive permissions. In a good scenario, those accounts are meant to be privileged. But what if there are new, unknown accounts with administrative privileges? Or perhaps there are known, non-privileged accounts that, for an unclear reason, now have administrative privileges? These accounts could pose a significant risk, as they may have remained unnoticed and unsecured for months or years. Worse, the existence of these Shadow Admin accounts could indicate that a cyber attack is currently in-progress, as these accounts may have been created or exploited by an attacker who later “enhanced” them with extra permissions needed to execute malicious actions.
Let’s see few real examples of Shadow Admins:
Example 1: Account with “Full control” over the Domain Admins group objects.
Figure 4: Shadow Admin example #1
The account “James” shown in Figure 4 is a Shadow Admin. James may not be in a privileged group, but his account is considered privileged because of his permission to register himself to the Domain Admins group at any time.
Example 2: Account with “Reset Password” permission over another known Domain Admin account.
Figure 5: Shadow Admin example #2
“Emily” is a Shadow Admin because of her “Reset password” permission. Even though this is her one and only permission in our domain, it is a very powerful one. Based on this permission, she is just as privileged as the sysadmin account.
Example 3: Account with “Replicating Directory Changes All” permissions.
Figure 6: Shadow Admin example #3
Example 3 carries the highest risk, as any user with this permission has the ability to replicate any object on the directory – including passwords. By default, Domain Controllers and Domain Admins are granted this permission for the purpose of keeping the Master Domain Controller and all other Domain Controllers synchronized. From the attacker’s perspective, any account with a Replicating Directory Changes permission can be used to retrieve the passwords of other accounts on the domain, and thus advance the attacker’s position in the network.
In this scenario, any account with these permissions has the privileges needed to perform a “DCSync” attack and steal the password of every other account. DCSync can be done easily using MimiKatz and other similar tools.
Of the three examples explained above, Example 3 is by far the most dangerous. It’s critical that only Domain Controller and Domain Admin group have these ACEs; no other account or group on the domain should have such an ACL configuration. From the attacker’s perspective, access to this type of Shadow Admin account could be highly valuable in maintaining persistence.
Takeaways and Recommendations
Our research indicates that Shadow Admin accounts are likely prevalent in any organization using Active Directory. When overlooked and left unsecured, these privileged accounts can create unnecessary risk and increase and attacker’s likelihood of success. As such, it’s critical that you know exactly which accounts in your network have sensitive, directly delegated permissions, so that you can take action.
We encourage you to use our Shadow Admins scanning tool, ACLight, to start uncovering these accounts today. You can run the scan using any standard, non-privileged account, as the tool only reads ACLs from AD; it does not modify anything. The output of the scan will be a list of privileged accounts that were discovered from all connected domains.
Next, we highly recommend that you investigate the discovered accounts and take action as appropriate:
- First, check that the newly privileged accounts are not part of an on-going attack
- Be sure that the remaining legitimate accounts truly need the permissions they were assigned
- Follow best practices to protect and secure these privileged accounts including:
- Dividing personal user accounts from their administrative accounts
- Using complex and long passwords, storing them in a secure location and rotating them often
- Monitoring and recording the use of these accounts, and searching for anomalies
For questions and comments, please contact CyberArk Labs.
Additional References
View our research presentation on Shadow Admins at InfoSecurity Europe.
For additional reading on ACLs and how exactly attackers and penetration testers use them, refer to this blog post, “BloodHound 1.3 – The ACL Attack Path Update.”
