Today, I wanted to take a few minutes to share how organizations worldwide can discover stealthy admins in Active Directory.
This is part II of the post - How to Discover Stealthy Admins in Active Directory.
A Quick Intro
Lately Active Directory Security seems to have been getting a lot of attention from traditional network security / hacking / cyber security folks, both, on the good side and the not-so-good side. Many of them may be relatively new to the subject of Active Directory Security, and most of them seem to be primarily interested in identifying privileged users in Active Directory.
Interestingly, perhaps because they may be new to this ocean of a subject, they may have started referring to delegated admins in Active Directory as Stealthy Admins, perhaps because they may not be aware of the concept of access provisioning and administrative delegation in Active Directory, even though both these concepts have been around for 17 years now.
If you want to know what I think of the term Stealthy Admins, you can read my last post on this topic ;-)
Anyway, to help these folks, and anyone else who might be interested in discovering "Stealthy Admins in Active Directory", I thought I'd help them understand what it actually takes to correctly make this determination in Active Directory deployments.
A Quick Primer
It is no secret that in IT infrastructures that are powered by Microsoft Windows Server, the proverbial "Keys to the Kingdom" lie in Active Directory. Specifically, the most powerful administrative/privileged domain security groups (e.g. Domain Admins), as well as the domain user accounts of all their members are all stored, protected and managed in Active Directory.
Now, if you were to ask a novice for advice on how to identify privileged users in an Active Directory, he/she will most likely tell you that all you would have to do is identify all those domain security groups that Microsoft says are privileged in nature, and then enumerate the complete membership of these domain security groups, and that's it i.e. you should be done!
Interestingly, would you be surprised if I shared with you that a majority of all organizations worldwide, when asked to furnish a list of privileged users in their Active Directory deployments (to demonstrate regulatory compliance that is), do exactly this!
In reality, if you follow the advice above, you would have merely uncovered the Tip of the Iceberg, because in reality, in most organizations, there exist a FAR greater number of privileged users than do the members of the default AD admin groups.
A Quick Question
To understand where Stealthy Admins come from in Active Directory, let us ask ourselves a quick very simple question.
Assumption: For illustrative purposes, let us assume for a moment, that there is only one default administrative/privileged group in Active Directory - the Domain Admins security group.
Here's the Domain Admins group, and the question is below -
As you can see above, there are only 2 members in the Domain Admins group.
The Question - Based on the above, can we assume that this organization only has 2 privileged users in their Active Directory? i.e. there are only 2 accounts that possess privileged access in this Active Directory - 1) the default Administrator account, and 2) the domain user account of the user Steve Ballmer, as that is what the membership of the Domain Admins group indicates?
Side Note: Would you be surprised if I told that (considering the assumption we've made above) most organizations would just report this as the number or privileged users in Active Directory?!
To answer this question, let us consider the following.
Consider This
Consider the impact of someone being able to perform the following administrative tasks in Active Directory -
- Change the membership of the Domain Admins group
- Reset the password of the domain user account of a member of the Domain Admins group
- Change the permissions on the Domain Admins group, or on the account of any of its members
- Change the ownership of the Domain Admins group, or on the account of any of its members
The above is most certainly not an exhaustive list of such administrative tasks, but merely a handful of such administrative tasks that can be enacted on Active Directory content, by anyone that has sufficient effective access to be able to do so.
Note: At this point, to advanced users, AdminSDHolder may come to mind. I would encourage them to read this advanced post on AdminSDHolder, and if you want to know how little even Microsoft seems to know, this one too.
Specifically, consider this -
Although in the illustrative example above, the Domain Admins group only has 2 members, shouldn't everyone who can change its membership also be considered a Domain Admin? After all, anyone who could do so could easily and instantly add his/her own account, or that of anyone he/she likes, to the group, as well as take the existing members out of the group!
Similarly, in the illustrative example above, although we only have 2 accounts that are members of the Domain Admins group, shouldn't everyone who can reset the password of any of these accounts also be considered a Domain Admin? After all, anyone who could do so could easily reset the password of these admin accounts, and instantly logon as them!
By the same token, anyone that can change the permissions or the ownership of any one of these default administrative groups or accounts should also be considered to be a privileged user possessing the same level of privilege, because he/she could easily modify the permissions on these objects to grant themselves or anyone else the same level of administrative privilege!
The Answer (to the Question)
In light of what we just considered above, hopefully it should now be clear that to accurately identify privileged users in Active Directory, in addition to enumerating the members of the default administrative/privileged security groups in Active Directory, at the very least, we should also be determining and including exactly -
- Who can change the membership of every single domain security group (as well as any domain security groups nested in it) in Active Directory that is considered administrative/privileged in nature?
- Who can reset the password of every single domain user account that is a member of a domain security group that is considered to be administrative/privileged in nature?
- Who can modify the security permissions and/or the ownership of every single domain security group and domain user account that is considered to be administrative/privileged in nature?
It must be noted that the keyword here is "at the very least." I say so because there could additionally easily be a specific domain user account or a domain security group that may not be a member of any default privileged group in Active Directory yet be directly be granted access in Active Directory that is tantamount to possessing privileged access in Active Directory!
Now, in case you're wondering - "But how does someone get the ability to change group memberships, reset passwords, etc?!"
Delegation of Administration in Active Directory
This brings us to one of the most powerful, capable, valuable and frequently-used features/strengths of Active Directory - Administrative Delegation. Delegation of administration is a capability that lets organizations distribute and delegate administrative authority for various aspects of identity and access management amongst a large group of IT personnel.
Its premise is simple - since it may be infeasible for a handful of highly privileged Domain Admins to manage thousands of objects in AD, wouldn't it be helpful if organizations could delegate/distribute administrative authority for identity and access management tasks amongst a larger group of IT personnel, who need not posses Domain Admin equivalent privileges!
Delegation of administration lets organizations delegate administrative authority in Active Directory and do so with precision -
In fact, over the last 17 years, there possibly might have been billions of administrative delegations / access provisioning(s) done in Active Directory domains, across Active Directory deployments worldwide.
Incidentally, I only know this because I happened to have authored Microsoft's 400-page whitepaper on the subject back in 2004 titled "Best Practices for Delegating Administration in Active Directory". The appendices of that whitepaper in itself were a treasure trove of knowledge on the subject. Amazingly, that whitepaper's nowhere to be found on microsoft.com these days!
Now, this is a very complicated subject (considering that it required a 400-page whitepaper to cover) so I'm not going to go into too many details here. Instead, I just wanted to share with you how IT personnel end up getting sufficient privileges in Active Directory so as to be able to enact common administrative tasks such as group membership changes, password resets etc.
The short of it is that when a task is delegated to a specific security principal, such as a domain security group, the security permissions required to perform the technical LDAP operation that corresponds to that task on a given type of object, are provisioned in Active Directory, thereby enabling all members of that group to be able to enact that task.
For example, when a domain security group such as IT Operations Support Level 1 is delegated the administrative task "Modify the membership of a group" in a specific organizational unit (OU), the following security permissions are added to the ACL of every domain security group in that OU - { Allow IT Operations Support Level 2 Write-Property Member }
Similarly, when a domain security group such as IT Operations Support Level 2 is delegated the administrative task "Reset user passwords" in a specific OU, the following security permissions are added to the ACL of every domain user account in that OU - { Allow IT Operations Support Level 3 Extended Right Reset Password (User-Force-Change-Password) }
By the same token, when a domain security group such as IT Contractors is to be denied the ability to enact a specific admin task, such as "Reset user passwords" in a specific OU, the following security permissions are added to the ACL of every domain user account in that OU - { Deny IT Contractors Extended Right Reset Password (User-Force-Change-Password) }
Note: The above is a highly simplified description of how this all works. Of course, there are many subtle yet vital details such as precedence orders which govern which security permissions (amongst numerous allows and denies) eventually prevail, and what access a user actually (i.e. effectively) ends up getting. More on that here.
Aha! It is all such domain user accounts for whom access may either have been delegated or provisioned on these default admins groups and accounts, and numerous other objects, that are being referred to by these novices as "Stealthy Admins" !
Okay, with this boring theory out of the way, let's find out how to correctly
identify these Stealthy Accounts in Active Directory, shall we?! ...
How to Correctly Discover Stealthy Admins in Active Directory
If you know the subject well, then you know that in order to correctly determine stealthy admins in Active Directory, you need the ability to be able to determine effective permissions / effective access in Active Directory.
If you don't know the subject well enough, then perhaps you may (errantly) believe that simply performing an Active Directory permissions audit to find out "Who has what permissions in Active Directory" would be sufficient. However, you'd be wrong.
Here's why -
If by "Stealthy Admins" one is referring to individuals who possess the ability to enact administrative tasks such as being able to change a domain security group's membership or reset a domain user account's password, or modify the permissions or ownership on an Active Directory object, then the only correct way to identify the identities of all such individuals who can enact these administrative tasks, is to accurately determine effective permissions / effective access on Active Directory objects.
I am not going to be spending any more time helping the world understand what Active Directory Effective Permissions are and why they're so important, so if you want to know more about them, you can read this post, which I highly recommend reading.
Okay, that said, let me actually show this to you, and to do so,
lets continue with that question we asked above...
So, here's the ACL (access control list) protecting the Domain Admins security group -
We have already seen above that is has only 2 members. However, what we should also be wanting to know is exactly how many individuals can enact the administrative task of "changing the group membership" of the Domain Admins group.
As seen above, there are many ACEs in the ACL of the Domain Admins group, each one allowing or denying a specific security principal (user, group, well-known SID or a foreign security principal) various specific Active Directory security permissions.
Now, technically, to find out who can change the group's membership, what we need to do is find out exactly who has sufficient Write Property - Member effective permissions, which is what's needed to be able to modify the Member attribute of this object.
That said, let me show you the only way that I know how to accurately do so -
I launch this tool, use its inbuilt search utility to find and point the tool to the Domain Admins group, and click a button -
In a matter of seconds, the tool accurately determines the complete set of effective permissions that are granted on this Active Directory object, and shows me the results in a most intuitive manner.
As can be seen in the snapshot above, we have just identified that although the Domain Admins security group itself has only 2 members in it, there are in fact 11 individuals who can change its membership, including one sneaky persistent bad guy!
From just that one report, the actual number of privileged users just increased by 500% i.e. went from 2 to 11!
Similarly, the tool can show exactly who has sufficient Modify Permissions and Modify Owner effective permissions on this Active Directory object, and to determine the actual number of privileged users, you'll want to include their identities as well.
Now, because that tool is a Active Directory effective permissions calculator (and in fact the world's only accurate one), it is primarily designed for Active Directory admins and Active Directory security professionals, and thus it determines and delivers its results in terms of effective permissions. However, there might be many individuals, such as IT Auditors, IT Managers, Cyber Security Risk Assessors and others in similar roles who may not be experts in Active Directory Security, and thus may not know technical details such as effective permissions to task mappings etc., yet may have a need to make such determinations.
For all such individuals, we built this tool to help them make the same exact determination -
In contrast to the previous tool, this tool's inbuilt intelligence can not just determine effective permissions, it can additionally also determine effective access in Active Directory, and as a result, it can show you who can actually do what in Active Directory, in plain English i.e. in terms of administrative tasks, eliminating the need for you to know anything at all about Active Directory.
As seen in the snapshot above, this tool's results too indicate that there are a total of 11 individuals who can enact the administrative task of being able to change the membership of the Domain Admins group!
In this manner, within a matter of seconds, today everyone can find out exactly who can enact administrative tasks such as being able to modify a privileged security group's membership, and thus uncover "stealthy admins" in Active Directory!
Now, let me show you another example -
Let us assume that a user, say a Jeff Bezos, is the only member of the Enterprise Admins group in Active Directory.
Since he is a member of the Enterprise Admins group, he is obviously considered a privileged user.
Now, hopefully you'll agree that since he is a privileged user, anyone who can reset his password should also be considered to be a privileged user since he/she is merely one mouse-click away from becoming an Enterprise Admin, so shouldn't we also be determining exactly who can reset his password?!
So, let's find out exactly who can reset this Jeff Bezos' password, shall we -
We click a button, have a sip of coffee, and lo and behold, we've just uncovered that a total of 30 individuals have sufficient effective permissions / effective access on his domain user account, so as to be able to reset Jeff Bezos's password!
Think about it - even though in this fictional organization, there was only 1 Enterprise Admin i.e. only 1 user who was a member of the Enterprise Admins group, we just discovered that there are 30 individuals who can reset his password (whenever they want) and thus be him whenever they want!
How to Audit Specific Stealthy Access in Active Directory
Again, if by "Stealthy Admins" / "Stealthy Access", they're referring to "Delegated Admins" / "Delegated Access", then here are step-by-step directions on how folks worldwide can audit for specific stealthy access in Active Directory -
While you're on the subject, you may also want to find out how to correctly perform an Active Directory Privileged User Audit.
Scaling It Up!
Now, let's assume that you have thousands of domain user accounts, domain security groups, domain computer accounts, organizational units, service connection points etc. etc. in your Active Directory.
Technically speaking, if you truly want to uncover all "Stealthy Admins" in Active Directory, wouldn't you want to know exactly who can reset the passwords of all the domain user accounts in Active Directory, who can change the membership of all the domain security groups in your Active Directory, who can change the security permissions protecting all Active Directory objects in the domain etc. etc. For example, how about knowing exactly who can reset the CEO's domain user account's password?
Well, if the answer is YES, then you're basically looking at determining effective permissions on thousands of objects in your Active Directory. Now, even if you had the capability to determine effective permissions / access on a single Active Directory by clicking just one button, you'd still have to click a button thousands of times.
That doesn't sound like too much, fun does it, not to mention that it could take weeks to do so. Of course, if you don't even have the capability to determine effective permissions one object at a time, you could easily be looking at months, if not years to make these determinations.
Well, wouldn't it be nice if someone could make this as easy as touching a button?
You know, something like this -
If you can click a button, now you can immediately and of course accurately uncover every single "Stealthy Admin" in your Active Directory, whether you have a few hundred or a few hundred thousand objects in your Active Directory.
For a complete list of all the administrative tasks that you can audit with this tool, please click here.
To novices that might sound easy; if you want to know how difficult this is, you'll want to find an Active Directory security expert, one who has spent years on Active Directory Security, and has thousands of hours of experience in trying to determine effective permissions on various Active Directory objects, and perhaps he/she could help you appreciate just how difficult this is.
Those who truly understand Active Directory Security know that building such a tool is on par with scaling Mount Everest. Then there are some who claim to offer free tooling that could help identify stealthy admins in Active Directory ;-) Little do they realize that in doing so, they may actually be showing the world just how little they may seem to know about Active Directory Security.
Summary
In today's post, I wanted to help folks understand that what some may refer to as "Stealthy Admins", are merely either delegated admins in Active Directory or IT personnel for whom various levels of access may have been provisioned in Active Directory.
Having said that, I also wanted to show you how to identify these delegated admins, which in line with the title of the post, perhaps we could play along and continue to call "Stealthy Admins in Active Directory."
I also wanted to share with the simple fact that in order to discover stealthy admins in Active Directory, what we need to do is to be able to accurately determine effective permissions on Active Directory objects.
Oh, and I also wanted to convey that when organizations audit privileged users in Active Directory, it is not sufficient to merely include the members of the default Active Directory administrative groups. You also need to include the identities of all such users who possess sufficient effective access in Active Directory so as to be able to modify the memberships of these groups, reset the passwords of all their members, change the security permissions protecting these groups and accounts etc.
If you want to know how to do this correctly, you'll want to read - How to correctly identify privileged users in Active Directory.
Finally, I wanted to demonstrate all of this with two simple illustrative examples, one involving identifying who can change the membership of the Domain Admins group, and one involving identifying who can reset the password of an Enterprise Admin.
That's all for today. Next post onwards, we'll get back on track and
proceed to finish Active Directory Security School for Microsoft.
Best wishes,
Sanjay
If you don't know the subject well enough, then perhaps you may (errantly) believe that simply performing an Active Directory permissions audit to find out "Who has what permissions in Active Directory" would be sufficient. However, you'd be wrong.
Here's why -
If by "Stealthy Admins" one is referring to individuals who possess the ability to enact administrative tasks such as being able to change a domain security group's membership or reset a domain user account's password, or modify the permissions or ownership on an Active Directory object, then the only correct way to identify the identities of all such individuals who can enact these administrative tasks, is to accurately determine effective permissions / effective access on Active Directory objects.
I am not going to be spending any more time helping the world understand what Active Directory Effective Permissions are and why they're so important, so if you want to know more about them, you can read this post, which I highly recommend reading.
Okay, that said, let me actually show this to you, and to do so,
lets continue with that question we asked above...
So, here's the ACL (access control list) protecting the Domain Admins security group -
We have already seen above that is has only 2 members. However, what we should also be wanting to know is exactly how many individuals can enact the administrative task of "changing the group membership" of the Domain Admins group.
As seen above, there are many ACEs in the ACL of the Domain Admins group, each one allowing or denying a specific security principal (user, group, well-known SID or a foreign security principal) various specific Active Directory security permissions.
Now, technically, to find out who can change the group's membership, what we need to do is find out exactly who has sufficient Write Property - Member effective permissions, which is what's needed to be able to modify the Member attribute of this object.
That said, let me show you the only way that I know how to accurately do so -
I launch this tool, use its inbuilt search utility to find and point the tool to the Domain Admins group, and click a button -
In a matter of seconds, the tool accurately determines the complete set of effective permissions that are granted on this Active Directory object, and shows me the results in a most intuitive manner.
Note: At this point, to some, Microsoft' Effective Permissions Tab may come to mind. To find out why it is not only inaccurate but also substantially inadequate, you'll want to read this. To others this tool may come to mind - allow me to share with you that that tool is dangerously inaccurate, even though its developers may not know it. For those to whom tools like dsacls, acldiag, or any one of various Active Directory Permissions Analyzers come to mind, you'll want to read this to learn about why not a single one of them can get the job done.
As can be seen in the snapshot above, we have just identified that although the Domain Admins security group itself has only 2 members in it, there are in fact 11 individuals who can change its membership, including one sneaky persistent bad guy!
From just that one report, the actual number of privileged users just increased by 500% i.e. went from 2 to 11!
Similarly, the tool can show exactly who has sufficient Modify Permissions and Modify Owner effective permissions on this Active Directory object, and to determine the actual number of privileged users, you'll want to include their identities as well.
Now, because that tool is a Active Directory effective permissions calculator (and in fact the world's only accurate one), it is primarily designed for Active Directory admins and Active Directory security professionals, and thus it determines and delivers its results in terms of effective permissions. However, there might be many individuals, such as IT Auditors, IT Managers, Cyber Security Risk Assessors and others in similar roles who may not be experts in Active Directory Security, and thus may not know technical details such as effective permissions to task mappings etc., yet may have a need to make such determinations.
For all such individuals, we built this tool to help them make the same exact determination -
In contrast to the previous tool, this tool's inbuilt intelligence can not just determine effective permissions, it can additionally also determine effective access in Active Directory, and as a result, it can show you who can actually do what in Active Directory, in plain English i.e. in terms of administrative tasks, eliminating the need for you to know anything at all about Active Directory.
As seen in the snapshot above, this tool's results too indicate that there are a total of 11 individuals who can enact the administrative task of being able to change the membership of the Domain Admins group!
In this manner, within a matter of seconds, today everyone can find out exactly who can enact administrative tasks such as being able to modify a privileged security group's membership, and thus uncover "stealthy admins" in Active Directory!
Now, let me show you another example -
Let us assume that a user, say a Jeff Bezos, is the only member of the Enterprise Admins group in Active Directory.
Since he is a member of the Enterprise Admins group, he is obviously considered a privileged user.
Now, hopefully you'll agree that since he is a privileged user, anyone who can reset his password should also be considered to be a privileged user since he/she is merely one mouse-click away from becoming an Enterprise Admin, so shouldn't we also be determining exactly who can reset his password?!
Note: Now, in case his account might be Smartcard-enabled, all you'd have to do is find out who can turn off the "Smartcard required for logon" requirement AS WELL AS reset his password, and that much should suffice!
So, let's find out exactly who can reset this Jeff Bezos' password, shall we -
We click a button, have a sip of coffee, and lo and behold, we've just uncovered that a total of 30 individuals have sufficient effective permissions / effective access on his domain user account, so as to be able to reset Jeff Bezos's password!
Think about it - even though in this fictional organization, there was only 1 Enterprise Admin i.e. only 1 user who was a member of the Enterprise Admins group, we just discovered that there are 30 individuals who can reset his password (whenever they want) and thus be him whenever they want!
How to Audit Specific Stealthy Access in Active Directory
Again, if by "Stealthy Admins" / "Stealthy Access", they're referring to "Delegated Admins" / "Delegated Access", then here are step-by-step directions on how folks worldwide can audit for specific stealthy access in Active Directory -
- How to Correctly Audit Who can Create User Accounts in Active Directory
- How to Correctly Audit Who can Change Group Memberships in Active Directory
- How to Correctly Audit Who can Delete Organizational Units in Active Directory
- How to Correctly Audit Who can Reset Passwords in Active Directory
- How to Correctly Audit Who can Change Service Connection Points in Active Directory
While you're on the subject, you may also want to find out how to correctly perform an Active Directory Privileged User Audit.
Scaling It Up!
Now, let's assume that you have thousands of domain user accounts, domain security groups, domain computer accounts, organizational units, service connection points etc. etc. in your Active Directory.
Technically speaking, if you truly want to uncover all "Stealthy Admins" in Active Directory, wouldn't you want to know exactly who can reset the passwords of all the domain user accounts in Active Directory, who can change the membership of all the domain security groups in your Active Directory, who can change the security permissions protecting all Active Directory objects in the domain etc. etc. For example, how about knowing exactly who can reset the CEO's domain user account's password?
Well, if the answer is YES, then you're basically looking at determining effective permissions on thousands of objects in your Active Directory. Now, even if you had the capability to determine effective permissions / access on a single Active Directory by clicking just one button, you'd still have to click a button thousands of times.
That doesn't sound like too much, fun does it, not to mention that it could take weeks to do so. Of course, if you don't even have the capability to determine effective permissions one object at a time, you could easily be looking at months, if not years to make these determinations.
Well, wouldn't it be nice if someone could make this as easy as touching a button?
You know, something like this -
If you can click a button, now you can immediately and of course accurately uncover every single "Stealthy Admin" in your Active Directory, whether you have a few hundred or a few hundred thousand objects in your Active Directory.
For a complete list of all the administrative tasks that you can audit with this tool, please click here.
To novices that might sound easy; if you want to know how difficult this is, you'll want to find an Active Directory security expert, one who has spent years on Active Directory Security, and has thousands of hours of experience in trying to determine effective permissions on various Active Directory objects, and perhaps he/she could help you appreciate just how difficult this is.
Those who truly understand Active Directory Security know that building such a tool is on par with scaling Mount Everest. Then there are some who claim to offer free tooling that could help identify stealthy admins in Active Directory ;-) Little do they realize that in doing so, they may actually be showing the world just how little they may seem to know about Active Directory Security.
Summary
In today's post, I wanted to help folks understand that what some may refer to as "Stealthy Admins", are merely either delegated admins in Active Directory or IT personnel for whom various levels of access may have been provisioned in Active Directory.
Having said that, I also wanted to show you how to identify these delegated admins, which in line with the title of the post, perhaps we could play along and continue to call "Stealthy Admins in Active Directory."
I also wanted to share with the simple fact that in order to discover stealthy admins in Active Directory, what we need to do is to be able to accurately determine effective permissions on Active Directory objects.
Oh, and I also wanted to convey that when organizations audit privileged users in Active Directory, it is not sufficient to merely include the members of the default Active Directory administrative groups. You also need to include the identities of all such users who possess sufficient effective access in Active Directory so as to be able to modify the memberships of these groups, reset the passwords of all their members, change the security permissions protecting these groups and accounts etc.
If you want to know how to do this correctly, you'll want to read - How to correctly identify privileged users in Active Directory.
Finally, I wanted to demonstrate all of this with two simple illustrative examples, one involving identifying who can change the membership of the Domain Admins group, and one involving identifying who can reset the password of an Enterprise Admin.
That's all for today. Next post onwards, we'll get back on track and
proceed to finish Active Directory Security School for Microsoft.
Best wishes,
Sanjay
No comments:
Post a Comment