Identity Risks: Shadow Admins, Explained
The security community has been vocal about the risk posed by shadow IT for several years. But what about shadow admins?
The term shadow IT refers to information technology (IT) systems deployed by departments other than the central IT department, usually to bypass the perceived limitations of the centralized information system. It is essentially an IT “desire path,” a shortcut created by an organization’s employee or business unit to facilitate operations despite IT best practices, such as subscribing to a software service without explicit IT approval or creating hosts that are not managed under the IT umbrella. Shadow IT is ubiquitous and poses a serious risk for organizations since security teams and admins lack the visibility, access, or privilege necessary to put the right security controls in place.
Shadow admins are the equivalent of shadow IT, but for identities. This definition includes user accounts that are privileged outside of best practices, and aren’t easily visible to IT or security teams. Yet another layer is that these accounts aren’t managed by PAM or by other identity access management solutions because the IT organization is usually not even aware that they exist. Shadow admins are often service users, domain users, helpdesk, or other operations users that are not members of a highly privileged domain group, but that have privileges delegated to them via direct ACL or nested group memberships. This kind of “misconfiguration” is very common and is found in most organizations.
Best Practice vs Reality
According to best practice, an admin user should be created by adding the account to a privileged group like the domain administrator group in Active Directory (AD) or another privileged group relative to the user’s administrative function. This way the user itself doesn’t have admin privileges, but it has privileges to access sensitive systems and perform sensitive functions by virtue of being part of the privileged group. This approach provides visibility into which accounts have privileges – simply monitor the actions of members of the privileged groups to audit administrative functions. In theory, by looking at the list of users within the privileged groups, IT teams should be able to see all the accounts that can access and make changes to the organizations’ crown jewel systems and policies.
Furthermore, Active Directory can be set to automatically create an event log every time a member of a privileged group takes an action, thus streamlining the auditing process and simplifying the deployment of Privileged Access Management (PAM) solutions that can simply vault all members of privileged groups, rather than having to manage access or vault credentials user by user.
In an ideal world, all admin and service accounts would be created following the best practice of being added directly to a privileged group. In reality, there are various ways in which an account can be misconfigured and end up with higher privileges than it should, without IT teams having awareness of user privileges and, in turn, lacking visibility over its activity.
Creating Shadow Admins – Nested Group Memberships
Nested group memberships are usually set up because user groups frequently have more than one area of responsibility. Backup operators may also have responsibilities in another administrative area, so adding the entire backup operators group to another privileged group may simplify assigning permissions. Nested group memberships may also make it easier to assign permissions across multiple domains, greatly reducing hassle for IT administrators. However, in taking this approach, the relationship between groups may quickly become confusing – this confusion leads to errors. Entire groups may unintentionally be granted admin privileges that they do not need, creating a security risk in the process.
For instance, if group A is added to group B, group B is added to group C, and group C has administrative authority, the privileges of group C will trickle down to group A, making each of the users in that group shadow admins. Nested groups also make layering other security controls like AD event audits and PAM vaulting difficult or noisy.
In a real-world scenario, a sales group could be added to the backup operator group so they can temporarily overcome a problem backing up their data. But the backup operator group is also a member of the exchange administrators group, granting the sales organization permissions to administer email systems. This is an overly simplistic example, but is actually more prevalent than most IT administrators would like to believe. Not only does this condition create security concerns, but it also may blind the identity audit and compliance teams to administrative actions since user event auditing may not perfectly capture all administrative actions if group nestings are overly complex.
The end result of excessive nested group memberships creates a serious security issue, as an entire group of shadow admins are suddenly created and left potentially unmanaged, unmonitored, and exploitable by an attacker looking to move laterally through the network.
Creating Shadow Admins – Direct ACL
An Active Directory Access Control List (ACL) is a set of rules that define which users have which permissions on specific AD objects, such as other user accounts, domains, or computer accounts. A shadow admin is created when a user is assigned a combination of ACLs that grants them administrative privileges in some form.
When scanning an organization’s environment for exposed, unmanaged and misconfigured identities, we often discover users accounts that have a mix of permissions that effectively turns them into privileged users or administrators, without them being part of a privileged group.
For instance, one might find a basic helpdesk operator whose role includes being responsible for resetting passwords, having an inexplicable permission to add user accounts to the domain admin group through a specific ACL. But, much like during a home renovation one might find a pipe fitted through a wall that leads to nowhere, these arrangements are usually made according to some logic that made sense at the time, but is now completely unnecessary and risky. These conditions are usually created to simplify or speed up some kind of troubleshooting operation, but are never reverted after the conditions that drove the requirement have changed.
Users with these permissions, granted with a purpose that no longer exists and soon after forgotten, are shadow admins because they can access and modify privileged assets without being managed by PAM or audited by IT.
Creating Shadow Admins – Chain of Ownership
Another way in which shadow admins are accidentally created is the chain of ownership of accounts. When user A, who has the permission to create new accounts, creates user B, user A retains ownership over user B. Should user B be granted higher privileges, user A would – by virtue of having created and owning that user account- be in a position to take over user B through a password reset compromise.
These types of shadow admins are common with users who were at one point members of the domain administrators group but have since been removed from that group. In one instance, when scanning an organization for identity risks, Illusive found an entire help desk group that was added to the domain admin group so they could manage user accounts, which is clearly an excessive permissions issue. The help desk group was removed from the domain admin group to rectify the over privilege issue. Once the group membership and associated privileges were revoked, members of the group retained ownership of all the user accounts they had created, giving the opportunity to an attacker that compromised a help desk user to move through the chain of ownership and access privileged accounts created in the past.
This is also true for disabled accounts. Regular scanning tools will highlight relationships between active accounts, ignoring those that have been disabled. The ownership of a disabled account, however, remains with the user who created it in the first place, allowing an attacker that compromises the active account to re-enable the disabled account and leverage the higher-level privileges associated with the disabled account.
Shadow Admins: Mitigating Risk by Adopting the Attacker’s Perspective
Shadow admin risk rarely comes alone. Within an organization’s environment, there are usually a plethora of misconfigurations and unmanaged accounts happening at the same time. Identities stored locally on an endpoint, stored FTP, SSH and database credentials, and outdated passwords on privileged accounts – the list goes on. The matter is usually made worse when AD is old: entropy increases, new users and new domains are created, and shortcuts are taken. This means that when an attacker is able to compromise a shadow admin account access to crown jewels is often no more than one step away and it may be the ‘last hop’ to take over the entire domain.
The approach taken by many enterprises to get visibility into identity risks, such as shadow admins, is to run AD ACL and group membership analysis reports. They also use red teams and penetration test exercises and employ tools such as AdFind, Mimikatz, and BloodHound to identify exploitable identities and identify paths to crown jewels. This approach, however, has the limitation of offering a static and incomplete picture of the shadow admins and other vulnerable privileged identities present in the environment. And it is insufficient to protect enterprises from the risks that are continuously created through the misconfigurations, mistakes and oversights that are inherent to business operations.
For this reason, there needs to be a shift towards continuous monitoring of the entire identity risk posture to detect and mitigate shadow admins as soon as they are created. The speed at which today’s environments change and evolve and the increasing sophistication of attackers’ tools, require discovery and mitigation of identity risks to be automated and based on policy and proximity to crown jewels within the environment. Only by continuously finding the exploitable paths an attacker would take to reach sensitive assets will security teams be able to fend off advanced ransomware and protect today’s number one attack vector: identities.