Today Active Directory Security is 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.

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

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.