By Rich Peckham, Sr. Solution Architect, Silverfort
Shadow Admin accounts are user accounts that have sensitive privileges – not because they are members of a privileged Active Directory (AD) group, but because they were inadvertently assigned permissions that can allow them to take over other privileged accounts, and leverage them to reach their target systems to compromise them.
If a Shadow Admin account is compromised, it can be very risky for the organization. After all, these user accounts can be used to compromise additional accounts and gain administrative privileges.
Yet identifying these accounts and restricting their access is not a trivial task.
A Deeper Look at Shadow Admins
A Shadow Admin is a user who is not a member of AD administrative groups like Domain Admins, Enterprise Admins, Schema Admins, Administrators, etc. Yet this user will have rights to some sort of administrative capabilities on an admin account, that enable this user to gain further administrative capabilities.
These administrative capabilities include:
- Full Control Rights (user or group)
- Write All Properties (on a group)
- Reset Password (on a user)
- All Extended Rights (on a user)
- Change Permissions (user or group)
- Write Member (on a group)
- Write Owner (user or group)
- The Actual Owner (user or group)
Additionally, any user who can take over and control a Shadow Admin of any level, would also be considered a shadow admin.
Let me explain with an example:
Let’s say Bob is a Domain Admin (a member of the Domain Administrators group). This means that Bob has administrative access to Active Directory.
Figure 1: Bob is a member of the Domain Administrators Group
Alice is not a member of the Domain Administrators Group. However, Alice has the ability to reset Bob’s password. Therefore, Alice can reset Bob’s password, login as Bob and execute tasks that require Domain Admin privileges on his behalf. This makes Alice a “Shadow Admin”.
Figure 2: Alice can reset Bob’s password which makes her a “Shadow Admin”
Now, let’s say Larry can reset Alice’s password. This means that Larry can reset Alice’s password, login as Alice, change Bob’s password, then login as Bob and execute tasks that require Domain Admin privileges. This makes Larry a level 2 shadow admin.
Figure 3: Larry can reset Alice’s password, which makes him a “Shadow Admin” as well
And It doesn’t end with Larry. Who can reset Larry’s password?
The process continues and an organization could, potentially, have many shadow admins.
Why and How Are Shadow Admins Created?
There are a few reasons why shadow admins exist in our networks:
- Human Error or Mismanagement of User Rights: Shadow Admins can be created by inexperienced administrators by mistake or because they did not fully understand the implications of direct privilege assignments. Although there are no malicious intents behind such shadow admin accounts, they can still present risk to the environment by allowing users unauthorized access to sensitive assets.
- Created for Temporary Use but Never Removed: Although this is considered a bad practice, in some cases IT administrators may grant accounts temporary privileges that turn the users into shadow admins, with the intention to remove these privileges at a later date. While this can solve immediate problems, these privileges are often left in place, leaving these accounts with unsupervised administrative privileges.
- Adversaries May Create Shadow Admins for Hiding Activities and Remaining Stealthy: Once admin privileges have been achieved, attackers can create a shadow admin accounts to allow persistence and to conceal their activities. These shadow admin accounts can then be used to hide malicious activities while that attacker remains stealthy.
Regardless of the reason behind their creation, shadow admins pose risk to the organization as they allow unauthorized individuals to perform activities that they shouldn’t perform. If an adversary gains control over a shadow admin account, it can be used as an attack vector.
The fact that these accounts are not monitored or supervised means that not only you don’t know you should restrict their access (you can’t fix problems you don’t know about), but it also means that unauthorized access and changes may go undetected. In some cases, such unauthorized access or changes may be detected too late – after sensitive data was leaked or after critical systems were compromised.
How Can I Determine Who My Shadow Admins Are?
Identifying shadow admins is a very challenging and complex problem. You first have to determine who your administrators are, i.e. all the users who belong the AD Groups that provide them administrative privileges. Some AD groups are obvious, like the Domain Admin group. But some groups are less obvious. We’ve seen that in many organizations, different administrative groups are created to support different business purposes. In some cases, you can even find nested groups. It’s important to map out all the members of these groups. As we map out the group memberships, we have to take into consideration not only the user identities that show up in the member list, but also any user’s Primary Group ID configurations.
Understanding the members of our administrative groups in AD is an important first step, but it’s not enough for identifying all privileged accounts in the domain. This is because they do not include the shadow admins. To detect the shadow admins, you need to analyze the ACL permissions granted to each account.
Think You Can Analyze the ACLs? Think Again
As explained above, to detect shadow admins you need to analyze the ACL permission of each account in AD, to understand if the account has privileges over any administrative groups or individual admin accounts. This, in itself, is a very difficult, if not impossible, task for any human being.
If you are able to perform this analysis – it will provide you the first level of shadow admins.
But it’s not enough – you now need to analyze all the ACLs again to understand who has privileges to change these first level shadow admins. And then again, and again, and again – this process needs to continue until all the levels of your shadow admins are detected.
And what if you found a shadow admin group? That complicates things even more.
The bottom line is that this important analysis can’t be a manual task.
How Can Silverfort Help?
Silverfort periodically queries Active Directory to get the different ACLs of all the objects in the domain. It automatically identifies common admin groups. It then analyzes the ACLs in search of shadow admin users and groups that have equivalent privileges to the members of these admin groups – privileges that effectively make them shadow admin accounts/groups. It continues to analyze the ACLs to determine as many times as needed to identify all levels of shadow admin accounts and groups making sure you have full visibility into those potentially dangerous accounts.
This comprehensive list should then be reviewed by AD administrators to determine if the privileges or these shadow admin accounts and groups are legitimate or not, and if they should be restricted or supervised.
Figure 4: Silverfort automatically identifies shadow admin accounts that should be reviewed to determine if their privileges are legitimate or not
In addition, Silverfort continuously monitors and analyzes all the access requests across the domain. It considers shadow admins as high-risk accounts. Silverfort automatically identifies, in real-time, sensitive activities, like an attempt to reset a user password, and either alert on it, or require the user the validate his/her identity with multi-factor authentication (MFA) before allowing the password reset. This can prevent unauthorized changes to user accounts as well as any unauthorized access to sensitive assets in the network.
Figure 5: example of a Shadow Admin policy defined to request MFA verification before allowing the user to reset a password
Rich Peckham, Sr. Solution Architect, Silverfort
Rich is a Solution Architect at Silverfort. He has more than 20 years of experience with Active Directory and Cybersecurity. Prior to joining Silverfort, Rich was a Senior Infrastructure Systems Engineer with Facebook for 2 years. Prior to Facebook, Rich was with Microsoft for over 10 years as a Senior Premier Field Engineer for Active Directory and then as a Senior Service Engineer specializing in Active Directory Cybersecurity. Rich is also a Microsoft Certified Master in Active Directory on Windows Server 2008 and Windows Server 2008 R2 and a Microsoft Certified Solutions Master in Windows Server 2012.
If you would like to learn more about this – contact us to schedule a demo