Cover Photo by David East on Unsplash

Introduction

In this post, I’m going to talk about a concept you may have heard of (shadow admins), what they are, why they are a problem you need to care about, and what to do about them.

What is a shadow admin?

The name should be fairly self explanatory - a shadow admin is a security principal or group that has admin equivalent privileges, but in a way that does not show up through traditional techniques used by companies to audit their IT estate.

Why is that bad?

Again, hopefully self-evident - if you don’t know they are there, how can you audit them, ensure they are in compliance with your Privileged Access Management (PAM) policies, or even ensure that access is removed when it is neither required nor authorised.

Consider also the scenario of a malicious actor who compromises an account that has admin privileges on a host and wants to establish persistence e.g retain that access.

If someone detects the compromised account then it will be disabled, password changed etc.

But if you can use that account to elevate the privileges of an account that otherwise looks unprivileged (either a local account or another domain user) then you are more likely to retain that access for longer without being detected.

How do you become an admin in Windows?

Default Local Groups (the standard/easy way to provision privileged access)

I’m focusing on Windows here because I have a feeling, rightly or wrongly, that this is better understood in Linux - let me know if you think that’s not the case and I’ll happily dive into that for a future post.

In a Windows OS (Client/Desktop or Server), there is a generally accepted view that you are given permissions at a user level or security principal level by way of local group membership (or domain membership if you have the Domain Admins or Enterprise Admins groups in AD added to local groups on your domain joined servers).

There are a number of default local groups on a Windows Server (this data extracted from this table) :

You may recognise those groups. You may well be provisioning admin access by adding Users/Groups to the local Administrators group (which by default contains only the local admin account or SID500) account for that server)

You may also be monitoring for Security Event ID 4735 to detect the addition of security principals to local groups - especially to the Administrators group.

What if I told you I could give myself all the permissions I’d get by being a member of the Administrators group and not be in that group?

Or that monitoring for event ID 4735 wouldn’t help in the slightest?

What magic is this?! Hold that thought for now…

Introducing User Rights Assignments

Straight from Microsoft :

User rights govern the methods by which a user can logon to a system. User rights are applied at the local device level, and they allow users to perform tasks on a device or in a domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to a device and how they can log on. User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects.

Now these are actually a good thing - the ability to be more granular in the permissions you grant is always welcome.

From a least privilege perspective these are great, and I will blog more on effective use of them in a future post.

Where things get tricky with them is that they are not always easy to get visibility of and ensure that they apply only to the security principles that you want them to.

The article above discusses using Group Policy Objects (GPO) to set which users/groups have each permission - this is indeed a good way to do this as it will restore the permissions to adhere to policy every time Group Policy is refreshed (likely every 2 hours or less).

This is also relatively easy to audit using the Resultant Set of Policy (RSoP) tool.

There is also a Powershell cmdlet for it.

You’ll notice both in the Default Local Groups table above and in the User Rights Assignments article there are granular rights that in combination make up the roles of each local group e.g. Administrators contains:

Access this computer from the network;

Adjust memory quotas for a process;

Allow log on locally;

Allow log on through Terminal Services;

Back up files and directories;

Bypass traverse checking;

Change the system time;

Create a pagefile;

Debug programs;

Force shutdown from a remote system;

Increase scheduling priority;

Load and unload device drivers;

Manage auditing and security log;

Modify firmware environment variables;

Perform volume maintenance tasks;

Profile single process;

Profile system performance;

Remove computer from docking station;

Restore files and directories;

Shut down the system;

Take ownership of files or other objects.

Remember I said I could be an admin without being in the local Administrators group?

Here comes the magic…

How do you become a Shadow Admin?

As I mentioned earlier, you can and should set this in GPO, which gives visibility, auditability and governance.

However, by default, GPO settings for this are “Not Defined” which means GPO will not control who has each user rights assignment. So make sure to define each assignment or those you deem most sensitive.

Now, if you also use GPO to enforce who is in each group using GPO Restricted Groups then you might be fooled into thinking you have this covered, especially if you also monitor Security Event 4735 for new members to these groups.

Here’s the crucial bit of missing information - you can apply any or all of these user rights assignments to a user or group by using:

1. NTRIGHTS.EXE from Windows 2003 Resource Kit
2. Powershell Community Extensions

With either of these you could add every user rights assignment to a user account, and it will not show up in RSoP or gpresult. Yes you do need to be an admin to do it, but as mentioned above, this is a useful technique for establishing persistence once you have achieved privilege escalation.

How do you detect the creation of a shadow admin?

As long as you are logging Audit Authorization Policy Change then you will be able to monitor for event ID 4704:

These events record every time a user right is assigned to a user/group and detail:

• Who made the change
• What user/group was assigned a right
• What rights were assigned

The rights are described using the permission/right name, not the friendly name - you can match them up by checking the User Rights Assignment documentation.

How do you find existing shadow admins?

That’s all well and good right, but what about any existing shadow admins? How can you find and remediate them?

1st Properly enforce User Rights Assignments in GPO as described above - in particular, at least for the most sensitive assignments, don’t leave them undefined. Explicitly define who should and shouldn’t have each assignment. WARNING: Make sure to also ensure that default groups that should have a particular assignment, have that included in your GPO in addition to any other security principals you want to assign it to - failure to do so could cause you many problems!

2nd Scan for which users have which assignments by using this excellent script

How do you get rid of them?

Same as for detection - use GPO and also use the scripts from Blake Drumm to find them and use their Set-UserRights.ps1 script or NTRIGHTS.EXE to remove the assignments you wnst to remove, from the accounts that need them removed.

Summary

This was quite a long post but we talked about what a shadow admin is, how they can be created in Windows, how to stop them being created, how to detect at time of creation, how to discover them and remove them.

As ever, thanks for reading and feel free to leave comments down below!

If you like what I do and appreciate the time and effort and expense that goes into my content you can always