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

Thursday, November 16, 2017

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


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.


Tuesday, October 24, 2017

How To Easily Identify & Thwart Sneaky Persistence in Active Directory


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

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

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 -

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

  2. Question to MicrosoftIf 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.

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 -

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

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

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

  4. 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!

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

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

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

  8. 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!)

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

  1. 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."

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

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

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

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

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

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

  8. 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 -
  1. 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.

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

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.

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

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 just showed you how to solve this problem in 1 minute! In days to come, I'll also be sharing with the world how to easily solve the problem of Active Directory botnets in 1 minute, which was the topic of the second presentation on Active Directory Security at your Black Hat Conference 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?!"

That said, the focus on Active Directory Security, and in particular on the ocean of unauthorized access grants that exist in billions of Active Directory ACLs worldwide today, is spot-on and very important, because its what's protecting trillions today.

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.

Best wishes,

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.
         Here's a 2, a 3, a 4, a 5, a 6, a 7, an 8 and a 10.

Wednesday, October 18, 2017

Coming Soon... How to Thwart Sneaky Persistence in Active Directory


As I briefly mentioned earlier, a few weeks ago, at the Black Hat Conference 2017 (which we skipped) on Cyber Security, two fine gentlemen made an interesting presentation titled An ACE Up The Sleeve - Designing Active Directory DACL Backdoors.

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 in reality is actually just Active Directory Security 101.

With full respect to its authors, I will say that for someone who may have been relatively new to this subject (which most cyber security pen testers, ethical hackers and hackers are these days) and coming from a mainstream pen-testing/attack background (i.e. generally focused on and employing local credential-theft attack-vectors) they got close to actual sneaky persistence in AD.

Incredulously and amazingly, perhaps because a majority of cyber security experts (both, defenders and attackers) and IT pros may not know Active Directory Security that well, this presentation has been garnering a lot of attention, including at Microsoft.

Here's proof - In the last ONE month alone, Microsoft's Advanced Threat Analytics (ATA) Team has published TWO blog posts in response to this presentation (on Sep 18 here and on Oct 11 here), so this clearly seems to have Microsoft's attention!

Speaking of which, here's a quote from Microsoft's latest blog post regarding this topic/presentation - "In general, this is a very important goal for an attacker and is a big part of a successful mission performed either by a nation state or by a hacker group."

Wow!   Hmm.    Keep reading ;-)

How to Easily Thwart Sneaky Persistence in Active Directory

I may no longer officially be an employee of Microsoft, but I am former Microsoft Program Manager for Active Directory Security, and just because I work for a different company now, that neither diminishes my knowledge nor my passion to help the world.

So, in a few days, right here, to help organizations worldwide, including to help my fine colleagues at Microsoft who seem to be struggling to figure out how to deal with this, I will share just how EASY it is to thwart sneaky persistence in Active Directory -

If you truly understand Active Directory Security, then you know that there are far greater challenges facing most organizations worldwide, so to help put this behind them, and to adequately address that whitepaper, I'll pen an insightful post on the subject.

BTW, 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. It appears these wonderful folks are trying too hard!

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..., this made me think - Is there a way we can identify all the objects to which I don't have permissions?;-)

This one's actually quite simple.  The answer, coming up, in a few days...


CEO, Paramount Defenses

Update - October 24, 2017 > Here it is - How To Easily Identify & Thwart Sneaky Persistence in Active Directory

Wednesday, October 11, 2017

A Paramount Question for Microsoft Azure CTO : he said 'Ask me anything'

Dear Mark,

You Sir, are Mark Russinovich, Chief Technology Officer (CTO) of Microsoft Azure, and for you I have the greatest of respect.

A few days ago at Microsoft Ignite, you said - "Ask me anything!" -

By the way, I must compliment you for doing so, because when you do so, you really have to be ready for any/every question!

So, I'd like to ask 1 Question

Mark, on behalf of 1000s of Microsoft's organizational customers, I'd like to most respectfully ask you just one simple question -

Question: How can/should organizations find out exactly who actually has what privileged access in their Active Directory ?

Specifically, how can organizations determine exactly who can do what on the 1000s of domain user accounts, domain computer accounts, domain security groups, containers, OUs, SCPs etc., including of course all their privileged and executive domain user accounts and groups that reside in their foundational Active Directory?

I only ask this question because as you too will likely agree, this 1 simple question directly impacts and thus is paramount to the foundational cyber security of over 85% of all organizations worldwide, all of whom operate on Microsoft Active Directory.

I really do hope that on behalf of Microsoft, you'll answer this question, for organizations worldwide look forward to the answer.

Most respectfully,

CEO, Paramount Defenses

PS: Sir, if you've ever heard of AccessChk.exe and know what it does,
(and I believe you have), then you know the answer to this question.

PS2: As former Microsoft Program Manager for Active Directory Security, I'd like to offer a hint. The answer to this question is also the (premise for, and thus the same as the) key to the ten questions below, and in essence it involves just two words -
1. What Constitutes a Privileged User in Active Directory?

2. How to Correctly Audit Privileged Users/Access in Active Directory?

3. How to Render Mimikatz DCSync Useless in an Active Directory Environment?

4. How to Easily Identify and Thwart Sneaky Persistence in Active Directory?

5. How to Easily Solve The Difficult Problem of Active Directory Botnets?

6. Why are the World's Top Active Directory Permissions Analysis Tools Are Mostly Useless?

7. Why is the Need to Lockdown Access Privileges in Active Directory Paramount to its Defense?

8. How to Attain (Lockdown) and Maintain Least Privileged Access (LPA) in Active Directory?

9. How to Securely Delegate and Correctly Audit Administrative Access in Active Directory?

10. How to Easily Secure Active Directory and Operate a Bulletproof Active Directory deployment?

In short, the answer is (something like) this -
Ans: To do so, all that organizations need to do is to accurately and adequately determine e******** p**********/a***** on their Active Directory objects. That's it.

Monday, October 9, 2017

Some Love For Microsoft + Time to Help Microsoft (and the Entire World)


This is a Trillion $ post. I wanted to show some love for Microsoft and help them out, as it appears they could use some help.

BTW, for those wondering who I am to make such a statement, I'm a nobody who knows a thing about a thing that impacts WD.

Trillion $ Background

From the White House to the Fortune 1000, Microsoft Active Directory is the very foundation of cyber security at over 85% of organizations worldwide. In fact, it is also the foundation of cyber security of almost every cyber security company worldwide.

Active Directory is the Foundation of Cyber Security Worldwide

The compromise of an organization's foundational Active Directory deployment could have disastrous consequences for the organization and its stakeholders, and the real extent of damage would be a function of the perpetrators' proficiency and intent.

If you understand the inner workings of Active Directory based networks, then you know that the amount of damage that we've seen in recent breaches such as the Equifax breach, is nothing, compared to the amount of damage that can actually be done.

Thus far, perpetrators have been focused on simple attack vectors such as credential-theft attacks aimed at the compromise of an organization's privileged users (e.g. Domain Admins), and over time Microsoft has made their enactment much harder.

As these attack vectors become harder to enact, perpetrators have started focusing on increasing their knowledge about Active Directory, and exploring ways to try and target and compromise Active Directory itself, as evidenced by the fact that in the last year alone, we've seen the introduction of Mimikatz DCSync, BloodHound and recently the advent of Active Directory Botnets.

Today Active Directory security, and in particular Active Directory access control lists (ACLs) impact organizational security and national security, worldwide. Speaking of which, and just so the world knows, here is Microsoft's take on them, and here is ours.

Perpetrators seem to be learning fast, and building rapidly, so the next big wave of cyber breaches could involve compromise of Active Directory deployments, unless organizations act swiftly to lock-down their foundational Active Directory deployments.

To do so, organizations worldwide need the right insight, guidance and tooling to adequately lock-down their Active Directory deployments. Unfortunately, Microsoft doesn't seem to know much about it (proof: 1, 2, 34), and thus may be unable to help.

Some Love for Microsoft

Today I may be the CEO of Paramount Defenses, but I'm also former Microsoft Program Manager for Active Directory Security, and I for one deeply love Microsoft, and deeply care about the foundational cyber security of all organizations worldwide, so I'm going to help Microsoft and the entire world adequately secure and defend their foundational Active Directory deployments.

To Satya (Nadella) and my former colleagues at Microsoft I say - "Microsoft is one of the greatest companies in the world today, and we care deeply and passionately about not only the role we play in society and the impact we have on billions of people, but also the responsibility that goes along, so we're* going to help the world address this colossal cyber security challenge."

* I may no longer be a Microsoft employee, but I still do care deeply and equally, so I'm happy to help you.
  If I were you, I'd most respectfully embrace this opportunity, be thankful for it, and not squander it.

To my friends at Microsoft, if I may have recently been a tad critical of you, its only because I care deeply about our customers, and I know that Microsoft can do much better at educating its global customer base about a matter of paramount importance.

Er, What Cyber Security Challenge?

Now, there might be billions of people and thousands of organizations worldwide who may have absolutely no idea about what I'm talking about, so perhaps I should succinctly and unequivocally spell it out not just for the entire world, but also for Microsoft.

Stated simply, and as described in The Paramount Brief, here's the #1 cyber security challenge that impacts the world today -

"From Silicon Valley to New York and London to Sydney, at the very foundation of cyber security and IT of 85+% of all business and government organizations across 190+ countries worldwide lies Microsoft's Active Directory.
Within the foundational Active Directory domains of these organization lie the entirety of their building blocks of their cyber security i.e. their user accounts, computer accounts, security groups, security policies etc. each one of which is represented by an Active Directory object & protected by an Active Directory Access Control List (ACL).
Today, in most of these organizations, there exist millions of ACLs in their Active Directory, and within these ACLs exists an ocean of excessive/unauthorized access, that today paves thousands of privilege escalation paths to literally the entirety of all objects in these Active Directory deployments, including to all their privileged users.
This ocean of unauthorized access exists worldwide today because Active Directory lacks and has always lacked the essential ability to help organizations correctly and adequately audit effective access in Active Directory, and consequently even though organizations have been delegating/provisioning all kinds of access in Active Directory to fulfill various business needs, they've never had the opportunity to correctly audit this ocean of access, resulting in a situation caused over time (i.e. over the years) wherein today unauthorized access pervades Active Directory.
In short, today, at most organizations, no one knows exactly who has what access on any of their building blocks of security, and possibly an excessive number of users, computers and service accounts may have substantial unauthorized access on them, and thus be in a position to easily and instantly compromise their security.

  • A Trillion $ Note: Most organizations (and perpetrators, as well as the Bloodhound Tool) audit "Who has what permissions in Active Directory?" Unfortunately, that does not provide the accurate picture. What they need to audit is "Who has what effective permissions/access in Active Directory?" Sadly, Microsoft has NEVER provided this guidance in an entire decade, so no one even seems to know this.

Anyone who possesses the tooling to correctly analyze effective access in Active Directory could instantly identify, and either eliminate or exploit, all such unauthorized access grants and the 1000s of privilege escalation paths they pave, and thus be in a position to either formidably defend or completely compromise these organizations.
The potential impact of this huge cyber security challenge is best illustrated by these 7 examples. Its that simple."

As simple as it is, not a single one* of the 1000+ cyber security companies that exist today has a solution for this challenge.

Let there be no mistake about this - a proficient intruder who possesses tooling that lets him/her correctly analyze effective permissions/access in Active Directory, could easily find, hundreds if not thousands, of unauthorized access grants in most Active Directory domains, and exploit them to compromise and obtain complete command and control over the organization.

If you find this hard to believe, you don't have to take my word for it, as here is Microsoft finally acknowledging it, and doing their best to downplay it. By the way, if they truly understood the depth of this problem, what they should've actually said is here.

Unfortunately, perpetrators can develop their own tooling and they don't even have to be 100% accurate (e.g. Bloodhound.)

Fortunately, organizations that possess the right tooling (e.g. 1, 2) can reliably mitigate all such security risks to Active Directory, from Mimikatz DCSync to Active Directory Privilege Escalation and from Sneaky Persistence to Active Directory Botnets, before perpetrators have the opportunity to exploit them, leaving no unauthorized access in Active Directory for perpetrators to exploit.

Time to Help Microsoft (and the Entire World)

Over the next few days, not only am I going to help reduce the almost total lack of awareness, education and understanding that exists at organizations today concerning Active Directory Security, I am also going to help organizations worldwide learn just how they can adequately and swiftly address this massive cyber security challenge before it becomes a huge problem.

Of course, today we can also uniquely empower organizations worldwide to adequately secure and defend their foundational Active Directory deployments, and we are happy to help organizations that request our help, but we are not going to go to anyone explicitly offering our help, because we're not your ordinary company.

So, in days to come, we'll begin by educating the world about the following -

  1. What Constitutes a Privileged User in Active Directory

  2. How to Correctly Audit Privileged Users/Access in Active Directory

  3. How to Render Mimikatz DCSync Useless in an Active Directory Environment

  4. How to Easily Identify and Thwart Sneaky Persistence in Active Directory

  5. How to Easily Solve The Difficult Problem of Active Directory Botnets

  6. Why the World's Top Active Directory Permissions Analysis Tools Are Mostly Useless

  7. Why is the Need to Lockdown Access Privileges in Active Directory Paramount to its Defense?

  8. How to Attain (Lockdown) and Maintain Least Privileged Access (LPA) in Active Directory

  9. How to Securely Delegate and Correctly Audit Administrative Access in Active Directory

  10. How to Easily Secure Active Directory and Operate a Bulletproof Active Directory Deployment

You see, each one of these Active Directory security focused objectives can actually be easily accomplished today, but and in order to do so, what is required is the ability to be able to accurately and adequately audit effective access in Active Directory.

Each one of these topics is absolutely essential for organizational cyber security worldwide, and if you know of even one other entity (e.g. individual/company) on the planet that can help the world address each one of these objectives today, let me know.

So, within the next 7 days, as a part of this, I'll start penning the above, and you'll be able to read them right here.

In Summary

If you truly understand Active Directory Security, then you know that literally the entire world's wealth is being protected by it, so and thus we just cannot afford for organizations to start having their foundational Active Directory deployments being breached.

Together, we can help adequately secure and defend organizations worldwide and deny perpetrators the opportunities and avenues they seek to compromise our foundational Active Directory deployments, because we must and because we can.

Best wishes,

CEO, Paramount Defenses

Formerly, Program Manager,
Active Directory Security,
Microsoft Corporation

PS: To anyone who believes they know more about Active Directory Security than us, or can help the world more than we can, go ahead and demonstrate that you can - this is your opportunity. If you can, let's see it. If you can't, you'll want to listen to us.

PS2: If you liked this post, you may also like the 20+ posts that are a part of - Helping Microsoft with Active Directory Security.