Today Active Directory Security has become mission-critical to organizational security worldwide and thus mission-critical to Cyber Security worldwide. On this blog, former Microsoft Program Manager for Active Directory Security, and today, CEO of Paramount Defenses, shares valuable technical insights on Active Directory Security.

Gold Finger The Paramount Brief Gold Finger Mini World Peace

Tuesday, December 12, 2017

How to Correctly Discover Shadow Admins in Active Directory

Shadow Admins - The Stealthy Accounts That You Should Fear The Most, but Needn't Anymore


Folks,

A few weeks ago, CyberArk, a $ Billion+ cyber security company in the Privileged Account Security space, published guidance on how organizations could identify dangerous "Shadow Admin" accounts that exist in almost every Active Directory today.

Here's their blog post - Shadow Admins - The Stealthy Accounts that You Should Fear The Most.


Unfortunately, their well-intentioned guidance (and accompanying tooling) for organizations worldwide, although on-point concerning the real danger that undetected "Shadow Admins" pose to organizations, seems substantially inaccurate.

Thus, to help CyberArk's own cyber security experts, as well as to help all IT and Cyber Security professionals at thousands of organizations better understand this subject, today, I'll show you how to correctly identify "Shadow Admins" in Active Directory.

This is Part II of the following, so you'll absolutely want to read - Paramount Privileged Account Security Guidance for CyberArk.

Pre-Requisites: To follow the contents of, and the examples shared in this post, you'll want to read the following -
  1. Shadow Admins - The Stealthy Accounts that You Should Fear The Most
  2. Paramount Privileged Account Security Guidance for CyberArk




First, Some Quick Background

As we all know, over 85% of organizations worldwide operate on Microsoft's Windows Server platform, and in IT infrastructures powered by Windows Server, at the very heart of cyber security and privileged access lies Microsoft Active Directory.


Not only does Active Directory store and protect the most powerful administrative/privileged accounts in a Windows network, it is also the focal point of  administrative delegation, and over the last 17 years, at most organizations, a substantial amount of access provisioning has been done in Active Directory, both to delegate administrative authority and to fulfill business needs.

Consequently, generally speaking, there are 3 levels of privileged access in Windows networks -
  1. Local administrative/privileged access on domain-joined machines
  2. Delegated administrative access within Active Directory
  3. Unrestricted privileged access (accounts and groups) in Active Directory

Of these 3 levels of privileged access, 1 is least powerful and 3 is most powerful. Level 2 is interesting because depending on the access provisioned/delegated, many level 2 access holders, unbeknownst to anyone, could in fact possess Level 3 access!

Now, consider Level 2 accounts that may not be members of any default admin (privileged) access group in Active Directory.

Should any of these Level 2 accounts directly or indirectly have certain modify access effectively allowed on one or more level 3 accounts or groups, then in effect even though they're not members of any default administrative (privileged) access groups in Active Directory, they would still have access that it tantamount to possessing unrestricted privileged access in Active Directory, and it is such accounts that CyberArk's experts are referring to as "Shadow Admins."

Further, since these accounts are not members of any default admin Active Directory groups, and the extent to which most organizations go to identify privileged users in Active Directory is to enumerate the membership of these default admin groups, at most organizations all such accounts will likely remain undetected, even though a proficient intruder who knows how to identify such accounts could easily identify and subsequently exploit them to effortlessly obtain complete command and control over the entire organization!

Up until this point, CyberArks guidance is accurate.




Ah, Active Directory Effective Permissions 

Now consider this - consider the domain user account of an ordinary user John Doe. Assume that he is not a member of any default admin (privileged) user group in Active Directory. Further assume that in the ACL of the Domain Admins group, he has been directly granted the following Active Directory security permissions -  { Allow John Doe Write-property Member }

Based on the above, do you think John Doe will be able to modify the membership of the Domain Admins group?

Most IT personnel, including CyberArks experts will likely say - YES!

However, if you ask an Active Directory Security expert, his answer will be - Maybe. (It depends.)

So, what does it depend on?!

Consider this. Imagine that there is a security group in Active Directory called Active Directory Security Novices and assume that this security group is NOT a member of any default Active Directory admin groups. However, assume that perhaps a few months ago, someone specified ANY ONE of the following several security permissions in the Domain Admins group's ACL -
  1. { Deny Active Directory Security Novices Write-property Member } OR
  2. { Deny Active Directory Security Novices Write All Properties } OR
  3. { Deny Active Directory Security Novices Full Control }

Now, if you ask an Active Directory Security expert, his answer will still be - Maybe. (It depends.)

The reason it is still Maybe, is because it depends on whether these Deny permissions were explicit (i.e. specified directly in the object's ACL) or whether they were inherited, and whether the Allow permissions for John Doe are explicit or inherited.

If these deny permissions were explicit, then even though there exists an { Allow John Doe Write-property Member } permission for John Doe in the ACL of the Domain Admins group's object, John Doe will NOT be able to change the group's membership!

What I have just shared with you is a very highly simplified example of Active Directory Effective Permissions.


Thus, if one were to merely "search and analyze the ACL permissions granted to each account" one could easily end up with inaccurate results, and in security, even ONE such inaccuracy could mean the difference between secure and breach!

This is where CyberArk's guidance is inaccurate.

Specifically, their guidance and tooling does NOT involve determining effective permissions in Active Directory; it merely involves searching Active Directory ACLs for any permissions granted to individual user accounts, and as we have just seen, such an approach is not only the incorrect way to discover such "Shadow Admin" accounts, it is also dangerously misleading!




The Only Correct Way

The only correct way to find out who actually has what access, including privileged access, in Active Directory is to accurately determine effective permissions in Active Directory. There is NO other way to accurately make this determination. Period.

In fact, Active Directory Effective Permissions are paramount to cyber security because they determine exactly who can do what on any and every object in Active Directory, from the CEO's domain user account to the Domain Admins domain security group!

It is for this simple reason that an organization that does not possess the ability to accurately identify effective permissions in Active Directory could not possibly adequately secure and defend its foundational Active Directory deployment.




Lets See a Demo -

Let us see this in action. In order to keep this very simple, we've used the same domain name for our test Active Directory so that everyone can follow this as an assumed continuation of the examples shared in CyberArk's post.


The Setup

We begin by installing a brand-new Active Directory domain, so it only has default administrative groups and default ACLing.


For our demo, to begin with, we'll create only five objects -
  1. An OU named Demo, to store our demo accounts and groups
  2. A regular domain user account named James
  3. A regular domain user account named Emily
  4. A regular domain security group named Cyberdark Gurus
  5. A regular domain security group named Active Directory Security Novices

That's it. We do not need to create any other objects right now as we're trying to keep this super simple.

Note: Please note that each one of these two domain user accounts and two domain security groups are regular accounts and groups i.e. they are not members of any default Active Directory administrative groups.


The only other thing we will do is make the Cyberdark Gurus group a member of the Active Directory Security Novices group -


Thus, as you can see above, the Cyberdark Gurus group is now a member of the Active Directory Security Novices group.



Demo #1

To begin, we make James a member of the Cyberdark Gurus domain security group -


Next, we will modify the (up until now) default ACL on the Domain Admins security group, and specify the following two explicit permissions -
  1. { Deny Active Directory Security Novices Special* }
  2. { Allow James Write-Property Member}
Special*: Modify Owner, Modify Permissions, Delete, Delete Tree, All Extended Rights, All Validated Writes AND Write All Properties. (We could've easily just denied Write-All Properties and that would have been sufficient.)

Here is the resulting ACL on the Domain Admins security group -



Since we're unable to view the Special permissions in ADUC, we can launch this tool to view the ACL more clearly -



As seen above, we can now clearly see the two permissions we just added (; see Rows #1 and #2.)

Now, as we can see there is clearly a permission allowing James Write-Property member on the Domain Admins group, so does this mean that he is a "Shadow Admin" who can change the Domain Admin group's membership?


To see what CyberArk's ACLight tool determines, let's run it and examine its findings/results -



ACLight has finished its analysis, so let us view its results -


Per ACLight, James is a "Shadow Admin" because the tool seems to have determined that James can modify the membership of the Domain Admins group, as there is an Allow permission granted to him directly in the ACL of the Domain Admins group.

To verify this finding perhaps we should login as James and try to modify the membership of the Domain Admins security group, and see if we are able to succeed in doing so -



As you can see above, the Add and Remove buttons are disabled, which is because ADUC has determined that James does not in fact have sufficient access so as to be able to do so!

Hmm... does this mean that ACLight's findings are inaccurate? Is there even a way to verify this?


Well, let's launch the world's only accurate Active Directory Effective Permissions Calculator, and see what it reveals -


According to this tool, James is NOT on the list of individuals who have sufficient Write-Property Member effective permissions on the Domain Admins security group, and since he is not on the list, according to this tool's findings, he cannot in fact change the membership of the Domain Admins security group, and thus he is NOT a "Shadow Admin"!

In other words, CyberArk's ACLight tool is delivering inaccurate results, because as we have experimentally verified as well, James was NOT in fact able to modify the Domain Admins group membership!

To conclude Demo #1, let us examine why he was not able to do so.

Let us take a closer look at the ACL of the Domain Admins group -


As we can see, the explicit Deny Write All Properties permission specified for Active Directory Security Novices will override the explicit Allow Write-Property Member permission specified for James, BECAUSE James is a member of the Cyberdark Gurus group, which in turn is a member of the Active Directory Security Novices group (which is something not readily apparent here!)

Now, in case you're a CISO or someone who may not know as much about Active Directory effective permissions, you can still make this determination most easily by using the second tool on this page -


As you can see, this tool make this determination and provides its output in plain English, completely obviating the need for you to know any Active Directory security technical details.

Thus, we just saw and verified that indeed the ACLight tool is NOT delivering accurate results!

Before moving on to the second demo, you'll want to undo these two ACL changes to continue to keep it simple.




Demo #2

For our second demo, we'll create a new domain user account called SysAdmin in the Users container, and then we will add it to the default Builtin Admins (i.e. Administrators) group so that it is now a privileged user account -


Now that we have an additional privileged user account to experiment on, let's proceed with demo #2.

To begin, we make Emily a member of the Cyberdark Gurus domain security group -



Next, we will modify the (up until now) default ACL on the SysAdmins privileged domain user account, and specify the following two explicit permissions -
  1. { Deny Active Directory Security Novices All Extended Rights }
  2. { Allow Emily Extended Right Reset Password}

Here is the resulting ACL on the SysAdmin privileged user account -



Again, to see these permissions most clearly, let us view this object's ACL using this tool -



As seen above, we can now clearly see the two permissions we just added (; see Rows #1 and #2.)

Now, as we can see there is clearly a permission allowing Emily the Reset Password extended right on the SysAdmins account, so does this mean that she is a "Shadow Admin" who can reset the SysAdmin's privileged user account's password?


To see what CyberArk's ACLight tool determines, let's run it and examine its findings/results -



ACLight has finished its analysis, so let us view its results -


Per ACLight, Emily is a "Shadow Admin" because the tool seems to have determined that Emily can reset the password of the SysAdmins user account, as there is an Allow permission granted to her directly in the ACL of the SysAdmins account.


To verify this finding perhaps we should login as Emily and try to reset the password of the SysAdmins privileged user account, and see if we are able to succeed in doing so -



As you can see above, Emily is unable to reset the password of the SysAdmins privileged user account and ADUC has displayed the message "Windows cannot complete the password change for SysAdmin because: Access is Denied." In other words Emily does not in fact have sufficient access so as to be able to do so!

Hmm... does this mean that ACLight's findings are inaccurate?

Let's launch the world's only accurate Active Directory Effective Permissions Calculator, and see what it reveals -


According to this tool, Emily is NOT on the list of individuals who have sufficient Reset Password extended right effective permissions on the SysAdmins domain user account, and since she is not on the list, according to this tool's findings, she cannot in fact reset the SysAdmins privieged user account's password, and thus she too is NOT a "Shadow Admin"!

In other words, CyberArk's ACLight tool appears to have yet again delivered inaccurate results, because as we have experimentally verified as well, Emily was NOT in fact able to reset the SysAdmins privileged account's password!

To conclude Demo #2, let us examine why she was not able to do so.

Let us take a closer look at the ACL of the SysAdmins privileged user account -



As we can see, the explicit Deny All Extended Rights permission specified for Active Directory Security Novices will override the explicit Allow Reset Password Extended Right permission specified for Emily, BECAUSE Emily is a member of the Cyberdark Gurus group, which in turn is a member of the Active Directory Security Novices group (which too isn't apparent here!)

Now, in case you're a CISO or someone who may not know as much about Active Directory effective permissions, you can still make this determination most easily by using the second tool on this page -


As you can see, this tool make this determination and provides its output in plain English, completely obviating the need for you to know any Active Directory security technical details.

Thus, we just saw and verified twice that indeed the ACLight tool is NOT delivering accurate results!




Domain-wide Assessment

Now, some of you may find yourself pointing out that the tools we used above only seem to be able to determine effective permissions/access on a per object basis. That is in fact right, and yet they are the only tools on the planet that can accurately determine effective permissions and effective access in Active Directory.

However, there is hope. Organizations can in fact make these determinations domain-wide today by using the following tool, which is the world's only accurate Active Directory Administrative Access / Delegation Audit Tool - 


This tool can make these determinations domain-wide, i.e. on thousands of objects in an Active Directory domain, in a single assessment, at the touch of a single button, and usually within minutes!

Perhaps, if we were Active Directory novices, we may have called is an Active Directory Shadow Admin Discovery/Audit Tool, but since we're experts, we know that what are being referred to as "Shadow Admins", "Stealthy Admins" etc. are merely just "Delegated Admins" in Active Directory, thus the name of this tool i.e. Active Directory Access and Delegation Audit Tool.

In fact this tool above can do in minutes what a thousand Active Directory security experts put together couldn't accomplish in a year, and do so in real (complex) Active Directory environments comprised of thousands of objects, accounts and groups.

Finally to anyone or any organization who may be inspired to make such a tool, by all means, please go ahead and try it. It took us six years of highly disciplined laser-focused Research and Development to build our tooling, and we know a thing or two about Active Directory Security. Should you like some guidance, you may want to read our 120-page patent on how to do so.

That wraps up the Demo.

Note: These two demos above were purposely keep super simple so that anyone (including CyberArk's experts) could replicate these exact steps in any new Active Directory domain and verify that what we have demo'ed above is accurate.




Complexity

Now, if these examples look so simple, that's because they were intended to look simple for illustrative purposes.

In reality, the challenge is exponentially hard. Consider a typical Active Directory deployment - there could easily be well over a hundred ACEs in the ACL of each Active Directory object, there could possibly be thousands of domain security groups to which users could belong, and many of these domain security groups could possibly be nested in other domain security groups, and some of these could be circularly nested, and there could be a substantial amount of administrative delegation and/or access provisioning done in Active Directory, and there could easily be thousands of objects in an Active Directory domain and there could possibly be numerous domains in an Active Directory forest.

Any tool designed to accurately identify such "Shadow Admin" accounts would have to be able to accurately determine effective permissions on every single one of thousands of object in Active Directory, in light of the complexity that I've just shared above.

Based on my assessment, not only does CyberArk's ACLight not evaluate effective permissions in Active Directory, it is light years away from being able to do what I've just described above. The same is true of every other tool you may have heard of out there, including BloodHound, or any PowerShell script anyone could ever write, or anything available from Microsoft.

There is only ONE tool that I know of that can accomplish this monumental feat - its this one, and I know so because I built it.



Summary

Folks, in closing, Privileged Account Security is paramount to organizational cyber security, and please don't just take my word for it, for here's CyberArk communicating in effect the same fact -
"Privileged accounts represent the largest security vulnerability an organization faces today. These powerful accounts are used in nearly every cyber-attack, and they allow anyone who gains possession of them to control organization(al) resources, disable security systems, and access vast amounts of sensitive data."
As I've said above, CyberArk is 100% right. The compromise of even just 1 (i.e. ONE) such privileged account could easily grant perpetrators complete command and control over your entire network and empower them to swiftly take over everything.

In fact, 100% of all major recent high-impact cyber security breaches (E.g. Snowden, Target, JP Morgan, Sony, Anthem, OPM) involved the compromise and subsequent misuse of a single, i.e. just ONE Active Directory Privileged User Account.


CyberArk is also 100% right that in most Active Directory deployments worldwide, today there likely exist a dangerously and excessively large number of such "Shadow Admin" accounts, that for all practical reasons possess the same level of privileged access as do members of default Active Directory administrative / privileged access groups, yet because they're not members of any default Active Directory privileged access groups, these accounts are in fact very difficult to accurately identify.

Consequently, their presence may possibly post a FAR greater risk to organizational cyber security, which is why it is so very important for organizations to be able to accurately discover/identify all such accounts i.e. each and every single one of them.

In this blog post, I wanted to show you why CyberArk's well-intentioned guidance and tooling are in fact inaccurate, as well as show you why we need to be able to accurately determine Active Directory Effective Permissions / Active Directory Effective Access to correctly discover all such "Shadow Admin" accounts in Active Directory.

I hope you've found this to be helpful, and I wish you all, including CyberArk, all the very best.

Best wishes,
Sanjay


PS: Recommended Technical Reading -
  1. Active Directory Privileged Access Insight
  2. Active Directory Effective Permissions
  3. Defending Active Directory Against CyberAttacks (Slide 88 alludes to CyberArk)
  4. The Impact of Compromise of Shadow Admin Accounts in Active Directory
  5. How to Audit Who Can Change Group Memberships in Active Directory?
  6. How to Audit Who Can Delete an Organizational Unit in Active Directory?
  7. How to Audit Who can Create User Accounts in Active Directory?
  8. How to Audit Who can Reset Domain User Accounts Passwords in Active Directory?
  9. How to Correctly Audit/Identify/Discover Privileged Accounts in Active Directory
  10. Active Directory Access Control Lists (ACLs) - Real Attack and Defense 

Friday, December 1, 2017

How to Discover Stealthy Admins in Active Directory

Folks,

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 -


  1. Change the membership of the Domain Admins group

  2. Reset the password of the domain user account of a member of the Domain Admins group

  3. Change the permissions on the Domain Admins group, or on the account of any of its members

  4. 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 -
  1. 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? 

  2. 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?

  3. 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.

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 -



  1. How to Correctly Audit Who can Create User Accounts in Active Directory

  2. How to Correctly Audit Who can Change Group Memberships in Active Directory

  3. How to Correctly Audit Who can Delete Organizational Units in Active Directory

  4. How to Correctly Audit Who can Reset Passwords in Active Directory

  5. 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 

Tuesday, November 21, 2017

How to Identify and Thwart "Real" Sneaky Persistence in Active Directory

Folks,

This is part II of my previous post titled - How To Easily Identify & Thwart Sneaky Persistence in Active Directory.

If you have not yet read that post, I highly recommend reading that post prior to reading this post.



Introduction

A few weeks ago, a presentation titled An ACE Up The Sleeve - Designing Active Directory DACL Backdoors at the Black Hat Conference 2017 (which we skipped) apparently made waves and caught the attention of the world, including that of Microsoft.


In that presentation, a whitepaper on which can now be downloaded from here, its authors have presented what may seem like a ground-breaking revelation to those uninitiated to the subject, but what actually is merely just Active Directory Security 101.

In my previous post, I had shown how to most easily identify and thwart sneaky persistence in Active Directory based on merely "hiding" objects in Active Directory. I had also mentioned that whilst amateurs rely on this technique, proficient perpetrators rely on employing what I called real sneaky persistence in Active Directory, a way to hide that's a 100 times harder to detect.

Today I'll shed light on real sneaky persistence in Active Directory, and show you how to identify and thwart it.





What is Real Sneaky Persistence in Active Directory?

Real sneaky persistence in Active Directory is a technique via which a proficient perpetrator could plant backdoors inside Active Directory access control lists (ACLs) that would be extremely difficult to identify with the naked eye (or even with basic Active Directory permissions analysis tooling) yet allow the perpetrator to gain unrestricted privileged access in Active Directory at will.

Simply put, it involves exploiting the sophistication of Active Directory's powerful security model and the sheer complexity of the ocean of Active Directory security permissions that exist in the thousands of Active Directory ACLs that exist in every Active Directory domain to hide in plain sight wherein none of it is obvious, yet all of it leads to the "Keys to the Kingdom."

For instance, imagine that in the ocean of (i.e. the millions of) Active Directory security permissions that exist inside the ACLs of thousands of Active Directory objects in a domain, a proficient perpetrator were to add even just ONE security permission (ACE) each in the ACL of even just a few (e.g. just two or three) different objects, each one granting a completely unsuspected group completely normal seeming permissions, where none of these would look suspect, but in reality, if you could connect the dots, you would have found a privilege escalation path that begins from a completely uninteresting and unsuspected unprivileged domain user's account and leads directly and unhindered to unrestricted privileged access in Active Directory.


That folks, is "real" sneaky persistence in Active Directory, and it is very dangerous, because it is extremely difficult to detect by those who don't already know of its existence, and it is very easy to exploit by those who know of or can identify its existence!

This is best illustrated with a real-world concrete example, as follows.






A Concrete Example

In order to illustrate "real" sneaky persistence, let us walk through a real-world example. Further, to additionally help contrast "real" sneaky persistence with "basic" sneaky persistence, this example builds on the example presented in the first blog post.

Consider a real-world Active Directory domain. It likely contains thousands of Active Directory objects, each one protected by an ACL, and each ACL containing likely over a hundred security permissions (ACEs), resulting in an ocean (millions) of access -


Note: To continue on from the illustrative example from the previous post, let us begin where we had left off i.e. we had just uncovered an Amateur Bad Guy's domain user account in the Africa OU, which had been hidden using "basic" sneaky persistence i.e. the perpetrator had added an explicit { Deny  Everyone  List Child } security permission / ACE on the Africa OU, which resulted in this object not being visible to organizational IT personnel. 

Here's the Amateur Bad Guy domain user account that we had uncovered in the example in the previous blog post -


Since this Amateur Bad Guy domain user account doesn't really belong to any specific employee or contractor, there are three things we'd really want to know -
  1. Who might have planted this? Active Directory audit logs could possibly have this answer, but this could easily have been planted months/years ago, so another way to answer this question might be by answering the next question.

  2. Might there be any suspect backdoors left in the ACL of this object that could allow whoever planted this hidden account, the ability to regain control of it, and if so, whom do they lead to?

  3. What effective privileged access might this account have in Active Directory? This is vital to know because if someone went through the trouble of hiding this account, it must likely have privileged access somewhere in Active Directory.

Consider this. If we could figure out the answer to question 2, it could also provide us the answer to question 1 i.e. if we can find if there are any interesting backdoors in the ACL of this account, we could likely figure out who may planted this!



It seems like it time for some advanced Active Directory Security sleuthing...


  1. So, lets begin by taking a look at the ACL of this Amateur Bad Guy domain user account -


    As we can see, there are numerous security permissions specified in the ACL of this object. Some of these permissions allow access whereas others deny access, some are explicit whereas others are inherited, some specify permissions for specific groups whereas others specify access for specific users, some specify specific single permissions (e.g. Reset Password) whereas others specify a combination of permissions (e.g. Special), some apply to the object whereas others don't and only exist for potential downstream inheritance, so on and so forth.

    Even this one single ACL on this one Active Directory object seems to be complicated, and in light of all this complexity (Allow/Deny, Explicit/Inherited, permissions for users/groups, applicable/non-applicable permissions etc.) how is one even supposed to accurately figure out exactly what all access all these permissions end up granting, and to whom?

    After all, if we hope to try and identify any potential backdoors in this ACL, we'll need to be able to first accurately determine exactly what all access these various permissions are "effectively" giving, and to whom?

    To figure this out, what we need to do is to determine "Active Directory Effective Permissions" on this object.
    Note: I am not going to delve into what Active Directory Effective Permissions are, why they're paramount, and why neither Microsoft's Effective Permissions Tab nor any other tool can accurately figure them out, as I've already explained all of this in great detail here, so you'll absolutely want to read it (, a few times over.)


  2. So, I launch this tool and click one button to determine exactly who has what effective permissions on this object -


    Within seconds, this tool accurately determines the entirety of all effective permissions granted (allowed) on this Active Directory object, collectively considering the entirety of all security permissions specified in this object's ACL.

    Further, for each such granted (allowed) effective permission, it also shows us exactly who has that effective permission, and exactly which security permissions in this Active Directory object's ACL entitle them to that effective permission.


  3. Now that we are armed with such valuable cyber security intelligence / insight, we can now instantly find out exactly who can actually do what on this object, so within seconds I can find exactly who can actually enact sensitive administrative tasks like being able to reset this account's password, modify its permissions, modify its ownership etc. -


    Now, not only does this tool determine the complete set of effective permissions allowed on an Active Directory object, it also determines the results in terms of individual identities (as opposed to in terms of effective permissions granted to specific security group memberships (which is hardly helpful)), and consequently, we can see with unequivocal clarity exactly which individuals (i.e. specifically their domain user accounts) have what effective permissions on this object.

    Look what I found in the snapshot above!
    - I found that a temporary IT Contractor's account, Kevin Mandia, who we know for a fact is not a member of any of our core IT teams has Modify Owner effective permissions granted to him via Special permissions granted to the IT Operations Support Level 3 group!

    Note: In the interest of brevity, I skipped straight to the suspect account. In general, my analysis would have involved analyzing the list of all individuals who have either of Reset Password, Modify Owner or Modify Permissions effective permissions on this account.

    Aha! This certainly looks suspect, and in fact upon further looking into, we can confirm that this individual should not be possessing any kind of modify access in our Active Directory, so we can infer that most likely this individual may most likely have created and then hidden this domain user account in Active Directory likely to be used as a backdoor!


    Conclusion 1 - The Amateur Bad Guy account was most likely set up by an individual named Kevin Mandia, who according to his job title in Active Directory is a temporary IT contractor currently residing in a foreign location.



  4. Next, I'd want to find out what privileged access, if any, this Amateur Bad Guy's domain user account might have across my entire domain. After all, if someone went through the trouble of hiding this account, it likely may have some level of privileged access somewhere in the domain, so my next objective is to make this determination.

    Now, there are thousands of objects in this Active Directory domain, and there are numerous domain user accounts and security groups that have varying levels of administrative/privileged access granted in this domain, so in order to make this determination and of course do so accurately, I'll need to determine effective permissions / effective access on thousands of objects in Active Directory, and that is no easy task. In fact, both theoretically and practically, it is so difficult that I doubt that even Microsoft, with its entire $ 550 Billion at its disposal, could make this determination.


    That said, let me show you how to do this in minutes. You see, there are generally only a few ways to obtain control over a privileged access account or group - 1) you can reset a privileged account's password, 2) modify a privileged group's membership, 3) modify the permissions of, or 4) modify the ownership on a privileged domain account / security group.

    So, wouldn't it be so helpful if there was a way in which I could easily (and of course accurately) find out exactly who can enact these administrative tasks across an Active Directory domain containing thousands of objects? If I could do so, I would instantly know exactly who can enact these administrative tasks in my domain, and if this Amateur Bad Guy's domain user account were to show up on any of those lists, I'd instantly know exactly how Kevin Mandia could use this intermediate Amateur Bad Guy account to escalate his privilege to that of a Domain Admin equivalent user!

    Okay, enough said, let me show you just how easily we can accomplish this task.


  5. I launch this tool, set the scope to be entire domain, and then just click a single button -


    As soon as I click the button, this tool goes to work, determining effective permissions / effective access on every single object in my domain (i.e. accounts, groups, containers, OUs, GPOs, SCPs etc.), whether there be a few hundred or a few hundred thousand objects in the domain, and within minutes it delivers its results, and in a highly intuitive manner.

    So let's take a look at what we found shall we?


  6. Wow,  look at what we found! -


    As seen above, we've just identified that the Amateur Bad Guy's domain user account in fact has sufficient privileged access so as to be able to change the membership of the Domain Admins group!

    Further, the tool's findings also help us pinpoint and identify exactly how the Amateur Bad Guy's domain user account has sufficient effective permissions so as to be able to change the membership of the Domain Admins security group - it reveals that the ACE that grants Special (List Child, Read Property and Write Property) security permissions to the IT Operations Support Level 2 group in the ACL of the Domain Admins group is responsible for granting the Amateur Bad Guy's domain user account sufficient effective permissions so as to be able to change the group's membership -


    A quick visual confirmation confirms that in fact, the Amateur Bad Guy's domain user account is a member of the IT Exchange Backup Admins group, which in turn is a member of the IT Operations Support Level 2 group, which is the group for which the above identified access is granted in the ACL of the Domain Admins group -



    Now, I don't know about you, but I can tell you that for most IT personnel at most organizations, even just accurately making this effective permissions determination on even just the Domain Admins group, let alone being able to identify the source (i.e. the underlying security permissions) or do this across the entire domain, would be an extremely difficult task, considering the tools at their disposal (i.e. mere Active Directory Permissions Analyzers, PowerShell, dsacls, etc.)


    Conclusion 2 - The Amateur Bad Guy account has sufficient privileged access so as to be able to modify the membership of the Domain Admins group!

    Note: The astute mind will further note that if the perpetrator had sufficient effective permissions to change the group membership of the Domain Admins group, he also has sufficient effective permissions to change the group membership of every default admin group in Active Directory, because those (effective) permissions are based on the ACL protecting the AdminSDHolder object!


In short, here's what we uncovered - in all likelihood, a temporary IT contractor, Kevin Mandia, who is not supposed to have any type of privileged access in our Active Directory, possessed sufficient effective access in our Active Directory so as to be able to modify the permissions on a domain user account that went simply by the name Amateur Bad Guy (and that was hidden using basic sneaky persistence) and thus take full-control over it (Conclusion 1), and further that this Amateur Bad Guy domain user account that was hidden and that we had uncovered in the last example, had sufficient effective access in our Active Directory so as to be able to modify the membership of the Domain Admins group (Conclusion 2)!

In essence, we found a privilege escalation path leading from a completely unsuspected non-privileged domain user account to that of the Domain Admins group, and this path was paved by someone having modified merely two/three security permissions, one each in the ACL of two/three Active Directory objects, of which there might be thousands in our Active Directory!


I could keep going, and present a 1000 such examples, but in the interest of time, I'll stop here and share a few thoughts below, because right there we've already seen how "real" sneaky persistence can be used to go from a completely unsuspected unprivileged domain user account to obtaining unrestricted privileged access in an Active Directory domain!






Just Three ACEs!

As we've just seen above, in an Active Directory domain that has thousands of objects, and hundreds of thousands of security permissions, just ONE individual, i.e. a temporary contractor located in a foreign location (, or someone who has/had sufficient control over his account,) had likely modified just THREE security permissions, one each in the ACL of just three objects, and in doing so, had paved a path that could allow him to gain unrestricted privileged access in this Active Directory domain, at will!



In fact, here are the three ACEs / permissions he had added -

  1. In the ACL of the AdminSDHolder object:
    Explicit   Allow   IT Operations Support Level 2 Group     Special (List Child, Read Property, Write Property)

  2. In the ACL of the Africa OU (i.e. the parent object of the Amateur Bad Guy domain user account):
    Explicit   Deny  Everyone List Child
    This was done to hide this object by employing the "basic" sneaky persistence technique uncovered in this blog post. It must be noted that that this optional "hiding" step was not even necessary; it merely added an extra level of covertness.


  3. In the ACL of the Amateur Bad Guy domain user account:
    Explicit   Allow   IT Operations Support Level 3 Group     Special (Modify Owner, Modify Permissions)

To reiterate, in an ocean of hundreds of thousands of security permissions in an Active Directory domain, all that a perpetrator had to do was tweak three security permissions, one each in the ACL of three otherwise unrelated Active Directory objects!

As you'll likely agree, not a single one of these permissions looks suspect, and the effective permissions they end up granting cannot likely be correctly assessed without the right tooling, so in organizations that lack the ability to audit effective permissions in their Active Directory, these subtle changes he had made could easily remain undetected (i.e. persist) for a long time!







A Small Special Subtlety

The astute mind will also note that the perpetrator specified a combination of permissions in each ACL, even though this wasn't necessary, only because when more than one Active Directory security permission is specified in a single ACE, when viewed in Microsoft's default native tooling, these security permissions specified in that ACE show up as Special, and in order to view them, you have to click on them, so if an admin were to glance at the ACL, such ACEs won't even stand out as suspect -


Further, even if IT personnel would have taken note of this one ACE, in order to accurately determine who can actually do what on that object, they would still also have to collectively take into account the impact of every other ACE in the ACL of that object!

(Recently, we came across an organization wherein in each ACL, there were well over 700 ACEs. Can you imagine trying to manually determine effective permissions on an object that may have hundreds of ACEs specified in that object's ACL?)






Identifying Entitled Users

There is one little thing I wanted to add, and I think the astute minds will further appreciate.

You see, one of the biggest reasons sneaky persistence is so effective is that a majority of access that is provisioned in Active Directory is specified for security groups (as it rightly should be), and thus when most IT personnel attempt to analyze Active Directory security permissions (and to a certain inaccurate degree, effective permissions), their findings are very often in terms of the access (or inaccurately determined effective access) that various security groups might have in their Active Directory.

Considering that a majority of access that is provisioned in Active Directory is specified for security groups, and that security groups could easily contain other security groups, and further that identical or overlapping access that may be allowed (i.e. granted) to certain security groups could also possibly be denied to other security groups, and either explicitly or via inheritance, and that there could easily be large numbers of individuals that could directly or via nesting belong to both such sets of security groups (i.e. that could belong to numerous groups for whom conflicting access is specified in various ways,) it is almost never easy to be able to accurately figure out exactly which individuals actually have what kind of (effective) access, and it is there that one usually misses out on detecting the existence of numerous individuals/accounts that are not supposed to have a specific type of (effective) access in Active Directory, but nonetheless still do so!


In that regard, not only does our effective permissions / effective access tooling completely and accurately determines effective permissions / effective access in and across Active Directory, it also delivers the answers to "who can actually do what in Active Directory" in terms of the identities of individual users, so if there's a suspect account that is not supposed to have a specific type of effective access, but it does, that account will certainly and clearly show up on that list, and thus there's no way to miss it, and that in part (i.e. obviously in addition to the fact that it can uniquely accurately determine effective permissions in Active Directory) is what makes our tooling so extremely effective at being able to identify and thwart even "real" sneaky persistence.







Effective, Powerful and Dangerous

As we have seen above, "real" sneaky persistence is extremely effective, powerful and dangerous.


It is effective because in most Active Directory deployments, unless organizational IT personnel have the means to be able to accurately and efficiently determine effective permissions on Active Directory objects, they're likely never going to be able to figure out the actual access that these sneaky permissions end up granting, and they're almost never likely going to be able to be able to connect the dots.

It is powerful because it provide perpetrators the ability to be able to instantly (re-)gain unprivileged access in Active Directory.

It is dangerous because if a perpetrator can (re-)gain unrestricted privileged access in your Active Directory, that's tantamount to a Domain Admin compromise, and it'd effectively be Game Over right there, and he/she would own your kingdom for eternity.


Consequently, it is paramount for organizations to ensure that there's no "real" sneaky persistence in their Active Directory.







In Short - How to Identify "Real" Sneaky Persistence in Active Directory

Folks, here's the very short of what it takes to identify "real" sneaky persistence in Active Directory.


All we need to do is determine effective permissions / effective access on every single object in our Active Directory domains to determine who is actually granted what effective access in our Active Directory based on the ocean of security permissions that exists in our Active Directory, and do so such that our results are in the form of the identities of all such individuals who possess any type of privileged access in our Active Directory (i.e. whether it be unrestricted or restricted (delegated) privileged access.)

Once we've done so, we'll have the complete picture of exactly who can actually do what in our Active Directory, and once we have that, all we'd have to do is analyze these results, and ANYONE that is NOT supposed/expected to have a certain kind of privileged access but in fact does so today will SHOW UP in our results, allowing us to identify all such sneaky/hidden access.

For instance, as we saw in the example above, by using this approach, we could not only easily determine that a certain user who was not a member of our core IT operations staff had the ability to modify the permissions of a hidden domain user account, and similarly, we could easily determine that that hidden domain user account had the ability to modify the membership of the Domain Admins group!

The two primary reasons this approach works is that a) it involves the determination of accurate effective permissions / effective access in Active Directory, and thus provides us with an accurate picture of who can actually do what, and secondly b) the results identify the identities of all such individuals (and to be specific their domain user accounts) who can enact these tasks, and it is this combination of "accurate results" + "entitled identities" that makes it really easy to identify any and all privileged access in Active Directory that should NOT exist, but in fact does so today!

So you see, once you understand the problem, know how to solve it, and have the right tooling to get it done, it isn't that difficult.







Conquering Everest, Made Easy

If you know Active Directory Security well enough, then you know three things -
  1. The only way to find out who can actually do what on an Active Directory object is by accurately determining effective permissions on that object.

  2. The only way to ensure that there's no such "real" sneaky persistence in Active Directory is to accurately determine effective permissions / effective access across the entire Active Directory domain i.e. on every object in the domain.

  3. Trying to accurately determine effective permissions on even a single object in Active Directory is very difficult for most, so trying to do this domain-wide is almost impossible, and thus on par with say trying to conquer Mount Everest.

If you don't know Active Directory Security well enough, then here's a good starting point for you to learn more.


Let me repeat that because so many folks out there may still not know this - trying to accurately find out who can do what across an entire Active Directory domain is extremely difficult, and thus equivalent to trying to scaling Mount Everest.


It may be worth taking a small pause to think about that for a moment.


Now, that said, today, if you can touch a button, you can now find out exactly who can enact which administrative tasks in and across entire Active Directory domain  i.e.  you can now find out exactly who can do what, where and how in Active Directory -


It may also be worth taking a small pause to think about this for a moment.


In short, today every organization that wants to identity and thwart sneaky persistence in their Active Directory can actually do so because the technology needed to identify and thwart even "real" sneaky persistence in Active Directory, exists today.

To all organizations that are still (i.e. 17 years after Active Directory was shipped) trying to make do with infantile tooling like dsacls, Microsoft's Effective Permissions Tab, PowerShell, Bloodhound, half a dozen basic Active Directory Permission Analyzers out there, etc., all I can most respectfully say is that you may likely just not know Active Directory well enough yet.








The Key to It All

I'm saying this for the umpteenth time. No matter what security challenge you're trying to solve in Active Directory Security, the key to it all likes in being able to accurately determine effective permissions / effective access in and across Active Directory.


So, whether you're trying to secure Active Directory, securely delegate administrative access, identify privileged users in Active Directory, reduce your Active Directory attack surface, protect against insider threats, demonstrate regulatory compliance of access rights in Active Directory, identify privilege escalation paths, find out who can change AdminSDHolder, mitigate the risk posed by Mimikatz DCSync, identify stealthy admins in Active Directory, or identify and thwart sneaky persistence in Active Directory, the key to it all lies in being able to accurately determine effective permissions / effective access in Active Directory.

Sadly, apparently Microsoft has never (i.e. not once) educated its global customer base about the paramount importance of effective permissions to Active Directory security, so let alone possessing the ability to do so, most organizations don't even seem to know what Active Directory effective permissions are! They likely have no idea what a dangerous situation they're in.






Finally, One Last Thing

(This unnecessary section is solely intended for those few individuals out there who may think that this is a plug for our tooling.)

I also did want to make it very clear that neither this post nor any of my other (100+) post(s) here and here are intended to be a plug for our tooling. The only reason I have used our tooling to demonstrate how to solve this and other equally important challenges in Active Directory Security is because it is the only tooling I know of that can help solve these challenges.


We have no particular interest in pitching our tooling to anyone. In fact, during the last ten+ years of our existence, we have not once pitched our tooling to anyone, marketed our products, emailed anyone or called anyone about it, nor have we placed a single advertisement anywhere or paid anyone (vendors, analysts, consultants, journalists, petty award organizers etc.) to promote our tooling, yet we've had 10,000+ organizations from across 150+ countries knock at our door, completely unsolicited.

Further in the interest of objectivity, I've clearly shared above what it takes to solve this problem, so if you know of or can find any other tooling that can help do what it takes to solve this problem, by all means you should feel free to use that option.

Hopefully, I need say no more about this, so I won't.

(Most organizations that understand this stuff deeply appreciate what it is we uniquely do, and are just thankful that we exist.)







Summary

This wraps up my 2 cents on "Sneaky Persistence in Active Directory" which made waves at the Black Hat Conference 2017.

In my previous post I had shown how to most easily identify and thwart "basic" sneaky persistence that involved hiding objects in Active Directory. In this post, I covered "real" (advanced) sneaky persistence and showed how organizations can easily identify and thwart "real" sneaky persistence as well.

"Real" sneaky persistence is 100 times more effective, powerful and dangerous, because it is so hard to detect with the naked eye and/or with infantile tooling. However, organizations that possess the ability to accurately determine effective permissions / effective access in their Active Directory deployments, both on a per-object and a domain-wide basis can very quickly identify and thwart both "simple" and "real" sneaky persistence in their Active Directory.



Lastly, I will only add this much - in almost every Active Directory domain in the world, today there already likely exists an ocean of "real" sneaky persistence/access, and it may likely have paved thousands of privilege escalation paths over time, completely unintentionally, and merely as a result of an extensive amount of administrative delegation and access provisioning that may have been done over the last so many years.

Fortunately, armed with the insight I've shared above, organizations can also identify and eliminate all such sneaky persistence / privilege escalation paths in their Active Directory. Considering that these privilege escalation paths can be identified by anyone that has a domain user account, any intruder who has been able to compromise even one domain user account and knows how to find such paths, could take his/her sweet time to find them (because read access to Active Directory is not audited), and once he/she has found an ideal path, as illustrated here, he/she could act to elevate privilege and possibly take over the entire Active Directory within minutes.

That's all for today.

Best wishes,
Sanjay


PS: Please feel free to share this post with anyone you like, including with the wonderful folks who gave that An ACE Up the Sleeve presentation at Black Hat. If you share it with them, please let them know that in their detailed 64-page whitepaper on Sneaky Persistence in Active Directory, there isn't a single mention of "effective permissions". They too may want to start here.