This is my umpteenth Trillion $ post.
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 this 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.
I must say that for someone likely new to the subject, the authors of this presentation at least seem to have (correctly) figured out that entire kingdoms can be owned if you get deep enough into the ocean of a subject that is Active Directory Security.
What surprised me far more is to see Microsoft apparently struggling for an answer to this; here's proof - in the last ONE month alone Microsoft's ATA Team has posted TWO blog posts in response to this presentation, on Sep 18 here and on Oct 11 here.
I find it surprising because when I was at Microsoft, as Program Manager for Active Directory Security, I authored Microsoft's official 400-page whitepaper on the subject, titled Best Practices for Delegating Administration in Active Directory, and that was a decade ago. Even if you read just the Appendices of that Microsoft whitepaper, you'll know far more than most folks out there.
Today I'll show how everyone can easily thwart sneaky persistence in Active Directory, and the key to it is literally Everyone ;-)
First Some
Theory
Their exhaustive whitepaper on this material was 64 pages long, and full of detailed technical material. All those details may have been necessary to explain all this to a majority of cyber security folks out there, both on the good, and on the bad side.
However, for those of us who have been doing this for 17+ years, we can get to the crux, and the bottom of it, in ONE minute.
So to help everyone understand the basis of this rather simple solution, here's some very quick Trillion $ theory -
- Active Directory stores and protects the entirety of an organization's building blocks of cyber security, from all of its domain user accounts to all of its domain security groups, and all these blocks are protected by Active Directory's solid, incredibly powerful and sophisticated security model (, which it had better be, considering that today it helps secure trillions of dollars of wealth, worldwide.)
- Speaking of security, simply put, each Active Directory object is protected by an access control list (ACL), which contains one or more access control entries (ACEs), each one of which specifies (i.e. Allows or Denies) one or more Active Directory security permissions (of which there are 11 generic permissions, and 80+ special permissions, (i.e. Extended Rights and Validated Writes)) for a specific security principal, either explicitly or via inheritance.
- These Active Directory security permissions include List Child, List Object, Read Control, Read Property, Write Property, Create Child, Delete Child, Standard Delete, Delete Tree, Write DACL, Write Owner, Validated Writes and Extended Rights (of which there are 80+), and they govern everything from the ability to create, delete and modify Active Directory objects, to the ability to modify both the owner of and the permissions on the objects themselves, as well as the ability to view Active Directory objects. Further, each Active Directory object has an owner, and the owner implicitly has the ability to modify permissions (i.e. Write DACL aka Modify Permissions) on the object.
- Finally, because each of these security permissions can be specified for both users and groups, and a user could be a member of various such groups, it follow that multiple permissions specified in an Active Directory ACL could impact the actual permissions a user has. Since permissions can overlap as well as conflict, a precedence order governs which security permissions will prevail over the others, and the resulting set of permissions a user ends up with on an Active Directory object is generally referred to as the user's Active Directory effective permissions.
- Thus, theoretically, anyone who has sufficient Modify Owner or Modify Permissions effective permissions on an Active Directory object, could control and thus possibly allow or deny literally anyone or literally Everyone (the well-known security principal S-1-1-0) any permission on the object.
- Now, and so, as it pertains to controlling an object's visibility, there are in fact 2 modes, the List Child mode (default mode) and the List Object mode in Active Directory that govern object visibility. In the List Child mode, an object will only be visible to a user if he/she effectively has List Child permissions on its parent object. In the List Object mode, an object will only be visible to a user if he/she effectively has both List Child permissions on the parent object AND List Object permissions on the object itself. (By effectively, I mean effective permissions.)
Now, taking all of that theory into account, here's the essence of this attack vector -
If a user were to specify Deny Everyone List Child permissions explicitly on an Active Directory Organizational Unit (OU), then literally no one (including privileged users) would be able to see the contents of that specific OU.
That user could then possibly hide objects in that OU, such as a domain user account that he/she may have full control over, and that may directly or indirectly be a member of an Active Directory privileged group, or that may have powerful modify effective permissions on various other objects in Active Directory (e.g. AdminSDHolder.)
Since no one would have visibility into that OU, no one (including privileged users) would be able to see them, and thus not only could these hidden objects be around for a long time (i.e. "persist"), they could also be used at-will to (re-)obtain privileged access in Active Directory!
That right there, is the essence and the crux of this most simplistic attack-vector called "sneaky persistence in Active Directory."
Next, Just 2
Questions
Before I show you how to easily mitigate "Sneaky Persistence in Active Directory", I'd like to pose just two questions, one to the authors of that presentation/white-paper, and one to the experts at Microsoft, because these questions are very important -
- Question to the authors - How did the attacker get Modify Owner / Modify Permissions effective permissions on the domain user object and the OU he/she wished to hide, to begin with? I ask because by default, ordinary (i.e. non-privileged) domain user accounts do not have these effective permissions either on themselves or on OUs, to begin with.
One of a few possible answers could be - He/she was a member of a privileged Active Directory security group, or a member of a group to which these permissions had been delegated, and thus had these effective permissions.
The point being that it should be made very clear that not just any domain user account can enact this attack-vector. Only those individuals who have either sufficient modify permissions effective permissions, or sufficient modify owner effective permissions on the relevant objects in Active Directory, or the Take ownership privilege on DCs, can do so. - Question to Microsoft - If a user does not have sufficient List Child effective permissions on an Active Directory object, then should he/she be able to view its child objects? I ask because in your latest blog, you're publicly wondering as to - "So, this made me think - is there a way we can identify all the objects to which I don't have permissions?!"
If the answer is NO, which it absolutely should be, and IS, then you shouldn't even be wondering if there might be a way to do so, because there shouldn't be a way to do so, and if you may have found a way to do so, then shouldn't that technically be an error (or what some might casually call a bug) and a security issue that should be fixed?!
I could ask 50 such questions to the authors and to Microsoft, and perhaps I may, but for now I'll leave it at this.
Finally,
The Answer
Now, and finally is the answer, and its so unremarkably simple that I can't believe I'm having to spend my precious time on it.
Here's the PREMISE for the answer -
The objects in question appear hidden to us due to one and one reason only, i.e. in the ACL of their parent object is a very specific ACE - Explicit Deny Everyone List Child This object only / This object and all child objects
In light of the above, here's the ESSENCE for the answer -
Consider this - one may not be able to view the hidden object, but one can definitely view and inspect the ACL of the parent object, because by default Authenticated Users have amongst other permissions, blanket Read Permissions on all objects in Active Directory.
So, literally all that one needs to do is perform some very basic Active Directory permissions analysis (which you could do with PowerShell, dsacls, or any professional-grade Active Directory Permissions Analyzer) to identify all such objects (typically OUs and Containers) in whose ACL Everyone is explicitly denied List Child permissions!
Once you've identified all such objects, all you'll need to do is remove these ACEs from their ACLs, and you'll instantly be able to see all such hidden objects i.e. there will be no more sneaky persistence in Active Directory!
You see, that's how elementally and unremarkably simple this is. That's it, and that's all there is to it!
In fact, since seeing is believing, let me SHOW you how easy this is to do step-by-step -
- Consider the following fictional Active Directory domain -
Might there be any "hidden" objects in this domain? We don't know, and if there are any "hidden" objects in it, we certainly won't be able to see them! So let's figure this out, shall we?! - Its time for some basic Active Directory permissions analysis so I launch this tool, select the report "Who has what permissions in an Active Directory tree?", set Find settings as follows, set scope to be the domain, and click a button -
Find Explicit Deny List Child permissions, granted to a specific security principal, Everyone
The tool then goes to work, analyzing every single ACE in the ACL of every single Active Directory object in this domain, identifying all such objects in whose ACL there exists an ACE that matches the exact permission combination we're looking for, and once its done, if there are any such objects, it will have identified all such objects, within seconds.
- Oh look, it found ONE object in this Active Directory domain, in whose ACL there exists the exact specific permissions we're looking for i.e. Explicit Deny List Child permissions, granted to a specific security principal, Everyone -
- Let's confirm this finding by viewing the ACL of the Africa OU object -
We now have visual confirmation that indeed there is an Explicit Deny List Child permissions, granted to Everyone.
Now that we've found at least one such object, we know that there likely may be "hidden" objects in our Active Directory, because if there exist any objects that may be child objects of this object, then certainly they're currently hidden from us.
- Let's take a quick look by focusing on the Africa OU in the Active Directory Users and Computers Snap-in -
As we can see above, visually, this OU certainly appears to be empty i.e. there do not seem to be any objects in it.
- If there indeed are any these "hidden" objects in this OU, then to unhide these "hidden" objects, all we need to do is remove the ACE that is specifying an Explicit Deny List Child permissions to Everyone -
- Having removed this ACE, let's refresh the Africa OU in the Active Directory Users and Computers Snap-in to see if there in fact exist any "hidden" (child) objects in it -
Viola' ! Sure enough, we can NOW see that there in fact was ONE "hidden" object inside the Africa OU, and although it is not clear what the Schema class of this object is, we can see its name, which is Amateur Bad Guy.
The most likely reason we cannot see much about this object is that whoever hid it in there may also have specified some form of deny permissions to prevent everyone from being able to read its properties, and perhaps even from viewing the permissions protecting this object. (That sounds very much like what's described in that whitepaper!)
Specifically, if you see the Where pane, you'll see that this exact ACE was found in the ACL of the Africa OU, whose DN is "ou=Africa,ou=Corp,dc=root,dc=local", and if you see the What pane, you'll see the exact ACE in that OU's ACL!
Ah, let's stop right here for a moment, because right up there we've just thwarted sneaky persistence in Active Directory!
You see, with the right tooling for the task, it took us just 4 seconds to find all suspect objects in our Active Directory, i.e. those in whose ACL there were Explicit Deny List Child permissions granted to Everyone, 6 more seconds to verify this in ADUC, and then a mere 4 seconds to remove that ACE. A quick refresh of ADUC took another 6 seconds, and we're still at 20 seconds, and we've been able to find all "hidden" objects (which in this illustrative example, was 1 object) in this Active Directory domain!
In comparison, consider this...
In the whitepaper, regarding Defenses, the authors state - "Some defenders may believe the detection of these types of backdoors is a lost cause... ...the primary method for detection and investigation remains properly tuned event logs for DCs... ... one interesting defensive tool is the use of AD replication metadata." etc. Seriously?!
Oh, and the most amusing part is to see Microsoft try even harder, and I'm quoting this verbatim from here - "This does sound like an issue... ...so, this made me think - Is there a way we can identify all the objects to which I don't have permissions?" 😉
Microsoft, when you say such things, it makes us wonder - How well does Microsoft understand Cyber Security ?
Again, wasn't this SO easy? To reiterate, literally, all we had to do is identify all objects in our Active Directory in whose ACL there is an Explicit Deny List Child permission granted to Everyone! The rest is easier - remove these ACEs, and you're done!
The rest of it is just about taking control over that "hidden" object, and below I have shown just how easy that is too -
- Now, let us attempt to take a look at the Properties, and in particular the ACL of this Amateur Bad Guy object in ADUC, which can be viewed by clicking on the Security Tab -
As one can see above, whilst attempting to open the Security tab, we are notified that we do not have sufficient access to view the permissions protecting this object, which is what we had suspected. Specifically, the message states that -
"You do not have permission to view the current permissions settings for Amateur Bad Guy. It can not be determined if you have the permission to make changes. Permission changes will be allowed but it can not be guaranteed that the changes will successfully apply."
- When the Security tab is opened, the Permission entries field seems empty.
This indicates that the amateur bad guy may have specified a permission denying say Full Control to Everyone, as that would also include denying the ability to view the object's Security Descriptor, and thus its DACL (Permissions), SACL, Primary Group and Owner fields. - So, let us attempt to click the Owner tab to see if we can see the object's owner.
Sure enough, we are unable to see the object's owner, which is consistent with our hypothesis that the owner of this object may most likely have denied Full Control to Everyone on this object. However, as evidenced by the following message, if we have sufficient effective permissions or the appropriate privilege, then we could take (or change the) ownership of this object.
Specifically, the message states -
"You can take or assign ownership of this object if you have the required permissions or privileges."
Now, because I'm logged in as a Domain Admin, I do have the "Take ownership" privilege, so I should be able to take ownership of this object, and/or assign someone else as its owner, so I am going to assign ownership to the Domain Admins group.
- I proceed to click the Other Users and Groups button, and specify that Domain Admins be the new owner of this object -
I then click OK again.
- As one can see below, I have been successfully able to change the object's ownership to Domain Admins -
As one can see above, the object's ownership has now changed from Amateur Bad Guy to Domain Admins!
- Now, since I'm a member of the Domain Admins group, I'm effectively an owner of this object, and thus I now have implicit Modify Permissions security permissions on this object, so I should now also be able to view the permissions protecting this object -
Indeed, as seen above, I can now see the object's permissions, so let's see what we find, shall we?
- Ah, there it is. There is the ACE specifying Explicit Deny Full Control permission granted to Everyone on this object!
It is this explicit deny ACE that was preventing us from seeing the properties and permissions on the domain user account object of this amateur bad guy.
So I proceed to remove that ACE! With that ACE no longer being there, we should now be able to clearly see the object in ADUC, so let's see if we can do so.
- As one can see, now we can clearly see the object in ADUC -
There you go. We now have Full Control over this object!
So, there you have it. We easily identified and thwarted "sneaky persistence" in Active Directory. Could this have been easier?
Two quick points -Finally, to be completely objective, I just wanted to mention that since Active Directory permissions audits are relatively easy to perform (compared to say this or this), you can use any permissions analyzer of your choice. I only illustrated the above with our tooling because it is the easiest way I know of to perform such analysis. This isn't a plug for our tool; this is too easy for us.
- A smart attacker could have made Everyone a member of some security group and granted the Explicit Deny List Child to that security group instead. In that case, to find all such objects, all you need to do, is that in the Fields setting above, in the granted to part, change the granted to a specific security principal part to granted to all security principals.
- If you are primarily interested in searching for hidden user objects, and you have a large Active Directory domain, you can substantially speed-up and optimize the entire process by merely specifying and applying a simple LDAP filter such as (|(objectClass=organizationalUnit)(objectClass=container)). This will result in the tool only retrieving the ACLs of all OUs and Containers, and avoid retrieving the ACLs of every single object in your Active Directory (of which there could be thousands of user accounts, computer accounts, security groups etc.) which is unnecessary, because you can only instantiate user accounts under OUs, Containers and any other object classes permitted by your Schema.
Now, Consider This...
You see, most folks would stop there. But that is where experts begin, and here's a preview of what they'd focus on next...
You see, since this Amateur Bad Guy domain user account that we just uncovered doesn't really belong to any specific employee or contractor, there are three things I'd really want to know -
- 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.
- 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?
- 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.
In my next post, I'll show you how to answer each one of these three questions. I'm not doing so in this post only because this has already been a long post, and perhaps its best to keep its focus on to identifying any hidden objects in Active Directory.
Okay, I'll give you a very quick preview of my next post! See, I figured I'd try and find out who all might have Modify Owner effective permissions on this Amateur Bad Guy's account, so I used this tool to figure it out in seconds, and look what I found! -
The details will follow in a few days :-)
"Real" Dangerous Sneaky Persistence in Active Directory
Folks, sneaky persistence based on merely "hiding" objects is rather easy to identify and thus thwart, and thus is generally a trick used by those new to the subject, because as I've just illustrated above, this can be easily identified and uncovered.
"Real" sneaky persistence in Active Directory is what experts use, and it involves exploiting the sheer complexity of the ocean of Active Directory security permissions that exist in Active Directory ACLs to, as they say, hide in plain sight, wherein none of it is obvious, and detecting it substantially more difficult.
Let me give you an example - imagine that in the ocean of (i.e the millions of) Active Directory security permissions that exist in an Active Directory, within the ACLs of thousands of Active Directory objects, a proficient perpetrator could add merely 3 ACEs, each one granting a completely unsuspected group completely normal seeming security permissions, but in reality, if you could connect the dots, you'd 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.
You may not believe this, but in most Active Directory deployments worldwide today, there already very likely exist thousands of such paths, and its not even because they may have been purposefully paved. In fact, they exist today primarily because of what is described in this trillion dollar document.
That is "real" sneaky persistence, and its very dangerous, because its extremely difficult for most IT personnel to detect!
In fairness to the authors of this presentation/whitepaper, I should also mention that they may have very briefly alluded to "real" sneaky persistence in two paragraphs in the section "Stealth Primitive - A "Patsy" User." Unfortunately, their claim that their toolset (Bloodhound) can walk these types of relationships back, but that this task is not trivial using other toolsets is inaccurate. In fact, their own tooling (self admittedly) doesn't take "effective permissions" into account, and thus may be quite inaccurate.
I am not going to go into the details of "real" sneaky persistence in this post, because that is a topic best addressed in its own stand-alone blog entry, so my next blog entry in a few days, will be on that. Oh, and even though "real" sneaky persistence is almost a 100 times more difficult to identify, I will also show you just how easily organizations can now do that as well.
You see, all it too needs, is An (ingenious ability to find the right) ACE up the (entire populace's) Sleeve.
A Quick Note on Their Backdoor Case Studies
If you read the whitepaper, you'll find that the second-last section is Backdoor Case Studies, in which they've done their best to bring everything they've learnt about the subject, together, to show how sneaky persistence can be used to plant backdoors.
In fact, here are a few topics on which they've shared a few backdoor case studies - a DCSync Backdoor (which I've already shown how to easily identify here), subverting LAPS, Exchange Strikes Back and abusing GPOs and Constrained Delegation.
They're absolutely right in that there are very many ways in which one can plant such backdoors in Active Directory!
However, without getting into the details today, let me also say that every single backdoor one could plant using these (or any) strategies can be instantly identified by merely being able to audit effective permissions on Active Directory objects, and further that all such backdoors can be instantly identified by performing an Active Directory Effective Privileged Access Audit.
In days to come, in a follow-up post, I'll explain why I say so. The short of it is that once you can accurately determine exactly who has what effective permissions on an Active Directory object, and the "who" part is solely a list of individual user accounts, then any and all such hidden access will immediately come to light, and be instantly identifiable, leaving no place to hide!
To reiterate, any and every backdoor someone could ever hide in Active Directory can be identified by possessing the capability to determine effective permissions in Active Directory. After all, there's a reason there's an (although almost useless) Effective Permissions Tab in Microsoft's tooling, and that reason very simply is that effective permissions are paramount to security.
Speaking of which, in that 64-page technical whitepaper, there was not a single mention of the term "effective permissions", even though half its content is focused on explaining that there are various security permissions that can be allowed or denied and be explicit or inherited, governed by precedence orders etc. all of which actually leads to, well, "effective permissions!"
But if in over a decade even Microsoft didn't realize this, can one expect a few passionate enthusiasts to get it that easily?!
A Quick Note to the Black Hat Conference Board
Gentlemen, two years ago, i.e. one year prior to this year, when this presentation was made at the Black Hat Conference 2017, for the first, only and last time, I had submitted a proposal for a presentation which was titled - "How an intruder could own a Microsoft Active Directory deployment within minutes / Zero to Enterprise Admin within Minutes!"
That presentation involved demonstrating how "real" sneaky persistence could allow an intruder to go from zero to root within minutes. You turned down my presentation, but you allowed this basic presentation that year, and this presentation this year.
I'm beginning to realize that you folks too may not yet know enough about Active Directory Security, and now it all makes sense. I am glad though that at least you allowed one or two presentations on Active Directory Security at your conference this year.
In general, since the distinguished folks on your selection board are supposed to be amongst the best in cyber security, it may be worth considering learning more about Active Directory Security yourselves, so next time, you can make better decisions.
This Impacts the Whole World
Before I sign-off, let me ask a question - "Do you know who's running on Active Directory today?" The Answer - Who's Not?
In other words, what I just shared above impacts the foundational cyber security of over 85% of all organizations worldwide.
You see, from the world's biggest Cloud Computing companies, to the world's biggest Internet, Defense, Banking, Oil and Gas, Manufacturing, Healthcare, Transportation, Hospitality <etc.> <etc.> companies, literally everyone's running on Active Directory.
Summary and Gratitude
In summary, identifying and thwarting simple sneaky persistence in Active Directory is literally a matter of/involving "Everyone" (pun intended), and hopefully the above should help everyone. In a few days, I'll also shed light on "real" sneaky persistence.
You see, sometimes it just takes common-sense, and as goes an old Chinese saying - "Why use Cannon to Kill Mosquito?!"
I would thus like to most sincerely thank the authors of this presentation and the Black Hat Conference for finally bringing the important subject of Active Directory Security to the CENTER-STAGE, because amongst all the areas in cyber security, when its comes to organizational cyber security, today Active Directory Security is possibly the most important, i.e. it is Paramount.
My next post on "Real" Sneaky Persistence should be out in a few days - here.
Best wishes,
Sanjay.
CEO, Paramount Defenses.
PS: Of all the challenges I've helped solve for Microsoft's global ecosystem, on a scale of 1 to 10, this one's a 1 and that's a 9.