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.