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



Thursday, November 16, 2017

How to Discover Stealthy Admins in Active Directory (Part I)

Folks,

Today I'd like to touch upon a very interesting topic i.e. how to identify / scan for / discover stealthy admins in Active Directory.

This post is not Part II of  How To Identify & Thwart Sneaky Persistence in Active Directory; that will follow shortly.


Stealthy Admins in Active Directory


Recently, there's been a lot of attention being given to what are being called "Stealthy Admins in Active Directory!"

Stealthy Admins in Active Directory

This concept of Stealthy Admins is along the lines of "Sneaky Persistence in Active Directory" and it deserves a befitting note.




First, An Apology !

[Begin Humor -

Folks, maybe I owe the whole world an apology, and here's what I owe it for -


For years, I've been trying to help the world understand that there exist in Active Directory deployments worldwide, 1000s of excessive / unauthorized privileges (i.e. security permissions), the existence of which endangers organizational cyber security.

To convey this fact, I've used all the right terminology, whether it be "effective permissions" , "effective access", "delegated access", "privilege escalation paths" etc. yet I doubt that most organizations worldwide get the depth of what I'm talking about.

Then come along a few new-comers to the field of Active Directory Security, and since they are just beginning to scratch the surface of Active Directory Security, they're likely amazed to know that there's (so much) more to administrative access in Active Directory than merely the members of the default Active Directory administrative groups (e.g. Domain Admins etc.), and perhaps because they may not be familiar with the notion of "Delegation of Administration" in Active Directory (and/or may not have read the 400-page whitepaper that I wrote on the subject for Microsoft way back in 2004,) they start referring to this stuff as "Stealthy Admins in Active Directory", and lo and behold, suddenly the whole world starts to understand this stuff!

How incredibly dumb must I be to not have figured that all I had to do is call this "Stealthy Admins in Active Directory!" ;-)

-- End of Humor ]


The answer - "Not at all dumb." In fact, anyone that's referring to these delegated administrative accounts as "Stealthy Admins" is merely demonstrating to the whole world how little they actually seem to know about the subject of Active Directory security!

Here's why - If you actually know Active Directory Security, then you likely know about its most capable feature, Delegation of Administration, and if you do, then you undoubtedly know that there are a LOT many more individuals who possess varying levels of admin/privileged access in Active Directory than just the members of the default admin groups in Active Directory.

Specifically, the fact that there might exist administrators in Active Directory (, other than members of the default administrative groups in Active Directory,) who may be able to enact various administrative tasks on default administrative accounts and groups and elsewhere in Active Directory, should come as NO surprise to those who understand Active Directory Security.

The fact that this "Stealthy Admins in Active Directory" misnomer is becoming so popular merely shows that not only those talking about it, but also those embracing it, may not seem to know much about Active Directory Security, and that's worrisome.

I can assure you that if you were to ask some of the best folks in Active Directory and Active Directory Security, such as Stuart Kwan, Joe Richards, Guido Grillenmeier, Micky Balladelli, Jan De Clerq, Andreas Luther and SO many others, they'll all likely agree with me, and laugh at this concept of "Stealthy Admins in Active Directory" introduced by a few folks new to the subject.




Likely Origins

Active Directory has been around for almost two decades, and at thousands of organizations worldwide, administrative authority for enacting administrative tasks such as password resets, group membership changes, account creations and deletions etc. have been delegated MILLIONS OF TIMES by thousands of IT personnel, and in fact, today there likely exist millions of individuals that possess varying levels of delegated administrative access in Active Directory deployments worldwide!

In other words, most organizations are intimately familiar with the concept of delegated access in Active Directory!

If that's the case, then it must be asked as to where this comical phrase "Stealthy Admins in AD" came from?


Here's the most likely answer -
Over the last few years, there's been a substantial increase in the focus on cyber security, and thus also on ways to obtain privileged access in Windows environments, and a large number of traditional "network security" hackers and cyber security professionals appear to have finally realized that at the very heart of cyber security in Windows Server based IT infrastructures lies the Active Directory, so they've started studying Active Directory security with a keen interest, and when you approach this subject from the outside-in (, as opposed to from the inside-out (i.e. you start with AD first)), then of course, the whole concept of administrative delegation is something you may not be aware of, and so of course, when you realize that there's a lot more to administrative access in AD than the mere members of the default administrative groups, you're likely to think of that indirect access as "stealthy access", whereas in fact to those familiar with the subject, that's just Active Directory Security 101!

In short, if you're new to the subject, you're likely going to be a bit surprised that there are actually (a LOT) many more folks that possess admin/privileged access in Active Directory than just the members of the default admin groups in Active Directory, and these to you might appear to be "Stealthy Admins!"




Speaking of Which

No matter what you call it, the fact remains that in virtually every Active Directory deployment in the world, there are far more individuals that possess varying levels of administrative access in Active Directory than the mere members of the default administrative groups, and it is imperative that not only must all those who hold such access in Active Directory be accurately identified, but also that if it is determined that the level of access that they hold is tantamount to unrestricted privileged access, then they must be rightly classified as "privileged users in Active Directory."


For example, consider the Domain Admins group. It may very well be that at an organization, there are only a handful of individuals that are members of this privileged access group in Active Directory. However, it is not sufficient to merely consider the group's membership. One must also accurately determine exactly how many individuals (and exactly who they are,) can enact the administrative task of being able to change the membership of the Domain Admins group. The reason this is so very important, and in fact paramount, is that because anyone who can change the membership of this group can add anyone else to the group and/or remove any existing member from the group!

Similarly, consider the default Administrator account in Active Directory, or for that matter the domain user account of any and every privileged user in Active Directory. Organizations must know at all times exactly who can enact the administrative task of being able to reset the password of each one of these domain user accounts. The reason this too is so very important, and in fact paramount, is that because anyone who can reset the password of any one of these accounts can instantly login as that account, and of course, if he/she can do so, he/she now 0wns your entire Kingdom!

In fact, it is not just group membership changes and password resets that can be used to gain administrative/privileged access in Active Directory. Any individual who enact the task of being able to modify the ownership or the permissions protecting any one of numerous direct and indirect administrative accounts and groups and/or certain objects in Active Directory, is just one step away from being a highly privileged user in Active Directory, and thus must be considered to be equally privileged.

In days to come, I'll shed some light on the various administrative tasks that one can perform in Active Directory to gain/escalate privileged access in Active Directory. That blog post will be Part II of this post. If you need to know right away, you can read this.




The Key to it All

There are some who albeit new to the subject may have at least realized that those who can enact administrative tasks such as password resets, group membership changes etc. also in effect possess the equivalent of privileged access in Active Directory.

Some of them may also claim to offer free tooling that can help organizations identify "Stealthy Admins in Active Directory."

As former Microsoft Program Manager for Active Directory Security, I can almost state with a high degree of confidence that these folks too may be making the classic mistake of mistaking "Who has what permissions in Active Directory" for "Who has what effective permissions in Active Directory", and thus their tooling too (just like this tool and Bloodhound) might also very likely be substantially and dangerously inaccurate, and thus may be delivering vastly incomplete or inaccurate data, reliance upon which could put in jeopardy the security of any organization relying on that data.

To help all such folks, allow me to share that the key to being able to accurately figure out who can enact which administrative tasks in Active Directory lies in being able to accurately determine effective permissions / effective access in Active Directory.


Let me repeat that - the Key to identifying privileged users in Active Directory lies in Active Directory Effective Permissions.

For instance, consider the ACL protecting a domain user account in Active Directory. Just because there exists an ACE in the ACL of this Active Directory object granting a security group, say Group X, to which a user John Doe might belong, say "Allow Group X Reset Password" permissions, it does NOT imply that that specific user John Doe might actually be able to reset that account's password, as there could easily be one or more ACEs, such as a "Deny Group Y All Extended Rights" that could effectively negate the allow access granted by the first ACE, if John Doe were also directly or indirectly a member of Group Y.

I say it could because ultimately it all depends on numerous factors, such as to begin with, which ACE is explicit in nature and which one is inherited, which one allows access and which one denies access, what combination of permissions are they allowing/denying, whether or not they actually apply to the object etc. etc. Further, there could easily be hundreds of ACEs in that (and in each) Active Directory object's ACL, and it is absolutely possible that each one could potentially impact the access granted/denied by each other one!

Those who know the subject well know that the what I've shared above is a super highly simplified example of Active Directory effective permissions are, so perhaps I should share a few helpful pointers to help illustrate this subtle yet profound difference.

Here's some recommended reading to help understand the subtle but profound difference between "Who has what permissions in Active Directory" and "Who has what effective permissions in Active Directory" - Active Directory Effective Permissions

Lastly, for those who truly want to understand this paramount subject, may I recommend reading the patent that governs the accurate determination of who actually has what effective access in Active Directory - United States Patent # 8429708.



As to how to actually discover stealthy admins in Active Directory,
that will follow in part II of this blog post, in a few days.



That's all for now.

The next post (within 5 days) will be Part II of  How To Identify & Thwart Sneaky Persistence in Active Directory.

Thanks,
Sanjay