How to Identify and Thwart "Real" Sneaky Persistence in Active Directory

Folks,

This is part II of my previous post titled - How To Easily Identify & Thwart Sneaky Persistence in Active Directory.

If you have not yet read that post, I highly recommend reading that post prior to reading this post.



Introduction

A few weeks ago, a presentation titled An ACE Up The Sleeve - Designing Active Directory DACL Backdoors at the Black Hat Conference 2017 (which we skipped) apparently made waves and caught the attention of the world, including that of Microsoft.

In that presentation, a whitepaper on which can now be downloaded from here, its authors have presented what may seem like a ground-breaking revelation to those uninitiated to the subject, but what actually is merely just Active Directory Security 101.

In my previous post, I had shown how to most easily identify and thwart sneaky persistence in Active Directory based on merely "hiding" objects in Active Directory. I had also mentioned that whilst amateurs rely on this technique, proficient perpetrators rely on employing what I called real sneaky persistence in Active Directory, a way to hide that's a 100 times harder to detect.

Today I'll shed light on real sneaky persistence in Active Directory, and show you how to identify and thwart it.





What is Real Sneaky Persistence in Active Directory?

Real sneaky persistence in Active Directory is a technique via which a proficient perpetrator could plant backdoors inside Active Directory access control lists (ACLs) that would be extremely difficult to identify with the naked eye (or even with basic Active Directory permissions analysis tooling) yet allow the perpetrator to gain unrestricted privileged access in Active Directory at will.

Simply put, it involves exploiting the sophistication of Active Directory's powerful security model and the sheer complexity of the ocean of Active Directory security permissions that exist in the thousands of Active Directory ACLs that exist in every Active Directory domain to hide in plain sight wherein none of it is obvious, yet all of it leads to the "Keys to the Kingdom."

For instance, imagine that in the ocean of (i.e. the millions of) Active Directory security permissions that exist inside the ACLs of thousands of Active Directory objects in a domain, a proficient perpetrator were to add even just ONE security permission (ACE) each in the ACL of even just a few (e.g. just two or three) different objects, each one granting a completely unsuspected group completely normal seeming permissions, where none of these would look suspect, but in reality, if you could connect the dots, you would have found a privilege escalation path that begins from a completely uninteresting and unsuspected unprivileged domain user's account and leads directly and unhindered to unrestricted privileged access in Active Directory.

That folks, is "real" sneaky persistence in Active Directory, and it is very dangerous, because it is extremely difficult to detect by those who don't already know of its existence, and it is very easy to exploit by those who know of or can identify its existence!

This is best illustrated with a real-world concrete example, as follows.






A Concrete Example

In order to illustrate "real" sneaky persistence, let us walk through a real-world example. Further, to additionally help contrast "real" sneaky persistence with "basic" sneaky persistence, this example builds on the example presented in the first blog post.

Consider a real-world Active Directory domain. It likely contains thousands of Active Directory objects, each one protected by an ACL, and each ACL containing likely over a hundred security permissions (ACEs), resulting in an ocean (millions) of access -

Note: To continue on from the illustrative example from the previous post, let us begin where we had left off i.e. we had just uncovered an Amateur Bad Guy's domain user account in the Africa OU, which had been hidden using "basic" sneaky persistence i.e. the perpetrator had added an explicit { Deny  Everyone  List Child } security permission / ACE on the Africa OU, which resulted in this object not being visible to organizational IT personnel. 

Here's the Amateur Bad Guy domain user account that we had uncovered in the example in the previous blog post -

Since this Amateur Bad Guy domain user account doesn't really belong to any specific employee or contractor, there are three things we'd really want to know -

1. Who might have planted this? Active Directory audit logs could possibly have this answer, but this could easily have been planted months/years ago, so another way to answer this question might be by answering the next question.


2. Might there be any suspect backdoors left in the ACL of this object that could allow whoever planted this hidden account, the ability to regain control of it, and if so, whom do they lead to?


3. What effective privileged access might this account have in Active Directory? This is vital to know because if someone went through the trouble of hiding this account, it must likely have privileged access somewhere in Active Directory.

Consider this. If we could figure out the answer to question 2, it could also provide us the answer to question 1 i.e. if we can find if there are any interesting backdoors in the ACL of this account, we could likely figure out who may planted this!



It seems like it time for some advanced Active Directory Security sleuthing...

1. So, lets begin by taking a look at the ACL of this Amateur Bad Guy domain user account -
   
   
   
   
   
   As we can see, there are numerous security permissions specified in the ACL of this object. Some of these permissions allow access whereas others deny access, some are explicit whereas others are inherited, some specify permissions for specific groups whereas others specify access for specific users, some specify specific single permissions (e.g. Reset Password) whereas others specify a combination of permissions (e.g. Special), some apply to the object whereas others don't and only exist for potential downstream inheritance, so on and so forth.
   
   Even this one single ACL on this one Active Directory object seems to be complicated, and in light of all this complexity (Allow/Deny, Explicit/Inherited, permissions for users/groups, applicable/non-applicable permissions etc.) how is one even supposed to accurately figure out exactly what all access all these permissions end up granting, and to whom?
   
   After all, if we hope to try and identify any potential backdoors in this ACL, we'll need to be able to first accurately determine exactly what all access these various permissions are "effectively" giving, and to whom?
   
   To figure this out, what we need to do is to determine "Active Directory Effective Permissions" on this object.
   

   Note: I am not going to delve into what Active Directory Effective Permissions are, why they're paramount, and why neither Microsoft's Effective Permissions Tab nor any other tool can accurately figure them out, as I've already explained all of this in great detail here, so you'll absolutely want to read it (, a few times over.)

   
   


2. So, I launch this tool and click one button to determine exactly who has what effective permissions on this object -
   
   
   
   
   
   Within seconds, this tool accurately determines the entirety of all effective permissions granted (allowed) on this Active Directory object, collectively considering the entirety of all security permissions specified in this object's ACL.
   
   Further, for each such granted (allowed) effective permission, it also shows us exactly who has that effective permission, and exactly which security permissions in this Active Directory object's ACL entitle them to that effective permission.
   



3. Now that we are armed with such valuable cyber security intelligence / insight, we can now instantly find out exactly who can actually do what on this object, so within seconds I can find exactly who can actually enact sensitive administrative tasks like being able to reset this account's password, modify its permissions, modify its ownership etc. -
   
   
   
   
   
   Now, not only does this tool determine the complete set of effective permissions allowed on an Active Directory object, it also determines the results in terms of individual identities (as opposed to in terms of effective permissions granted to specific security group memberships (which is hardly helpful)), and consequently, we can see with unequivocal clarity exactly which individuals (i.e. specifically their domain user accounts) have what effective permissions on this object.
   
   Look what I found in the snapshot above! - I found that a temporary IT Contractor's account, Kevin Mandia, who we know for a fact is not a member of any of our core IT teams has Modify Owner effective permissions granted to him via Special permissions granted to the IT Operations Support Level 3 group!
   
   

   Note: In the interest of brevity, I skipped straight to the suspect account. In general, my analysis would have involved analyzing the list of all individuals who have either of Reset Password, Modify Owner or Modify Permissions effective permissions on this account.

   
   Aha! This certainly looks suspect, and in fact upon further looking into, we can confirm that this individual should not be possessing any kind of modify access in our Active Directory, so we can infer that most likely this individual may most likely have created and then hidden this domain user account in Active Directory likely to be used as a backdoor!
   
   
   
   
   Conclusion 1 - The Amateur Bad Guy account was most likely set up by an individual named Kevin Mandia, who according to his job title in Active Directory is a temporary IT contractor currently residing in a foreign location.
   
   



4. Next, I'd want to find out what privileged access, if any, this Amateur Bad Guy's domain user account might have across my entire domain. After all, if someone went through the trouble of hiding this account, it likely may have some level of privileged access somewhere in the domain, so my next objective is to make this determination.
   
   Now, there are thousands of objects in this Active Directory domain, and there are numerous domain user accounts and security groups that have varying levels of administrative/privileged access granted in this domain, so in order to make this determination and of course do so accurately, I'll need to determine effective permissions / effective access on thousands of objects in Active Directory, and that is no easy task. In fact, both theoretically and practically, it is so difficult that I doubt that even Microsoft, with its entire $ 550 Billion at its disposal, could make this determination.
   
   
   
   
   That said, let me show you how to do this in minutes. You see, there are generally only a few ways to obtain control over a privileged access account or group - 1) you can reset a privileged account's password, 2) modify a privileged group's membership, 3) modify the permissions of, or 4) modify the ownership on a privileged domain account / security group.
   
   So, wouldn't it be so helpful if there was a way in which I could easily (and of course accurately) find out exactly who can enact these administrative tasks across an Active Directory domain containing thousands of objects? If I could do so, I would instantly know exactly who can enact these administrative tasks in my domain, and if this Amateur Bad Guy's domain user account were to show up on any of those lists, I'd instantly know exactly how Kevin Mandia could use this intermediate Amateur Bad Guy account to escalate his privilege to that of a Domain Admin equivalent user!
   
   Okay, enough said, let me show you just how easily we can accomplish this task.
   



5. I launch this tool, set the scope to be entire domain, and then just click a single button -
   
   
   
   
   As soon as I click the button, this tool goes to work, determining effective permissions / effective access on every single object in my domain (i.e. accounts, groups, containers, OUs, GPOs, SCPs etc.), whether there be a few hundred or a few hundred thousand objects in the domain, and within minutes it delivers its results, and in a highly intuitive manner.
   
   So let's take a look at what we found shall we?
   



6. Wow,  look at what we found! -
   
   
   
   
   
   As seen above, we've just identified that the Amateur Bad Guy's domain user account in fact has sufficient privileged access so as to be able to change the membership of the Domain Admins group!
   
   Further, the tool's findings also help us pinpoint and identify exactly how the Amateur Bad Guy's domain user account has sufficient effective permissions so as to be able to change the membership of the Domain Admins security group - it reveals that the ACE that grants Special (List Child, Read Property and Write Property) security permissions to the IT Operations Support Level 2 group in the ACL of the Domain Admins group is responsible for granting the Amateur Bad Guy's domain user account sufficient effective permissions so as to be able to change the group's membership -
   
   
   
   
   A quick visual confirmation confirms that in fact, the Amateur Bad Guy's domain user account is a member of the IT Exchange Backup Admins group, which in turn is a member of the IT Operations Support Level 2 group, which is the group for which the above identified access is granted in the ACL of the Domain Admins group -
   
   
   
   
   
   Now, I don't know about you, but I can tell you that for most IT personnel at most organizations, even just accurately making this effective permissions determination on even just the Domain Admins group, let alone being able to identify the source (i.e. the underlying security permissions) or do this across the entire domain, would be an extremely difficult task, considering the tools at their disposal (i.e. mere Active Directory Permissions Analyzers, PowerShell, dsacls, etc.)
   
   
   Conclusion 2 - The Amateur Bad Guy account has sufficient privileged access so as to be able to modify the membership of the Domain Admins group!
   
   

   Note: The astute mind will further note that if the perpetrator had sufficient effective permissions to change the group membership of the Domain Admins group, he also has sufficient effective permissions to change the group membership of every default admin group in Active Directory, because those (effective) permissions are based on the ACL protecting the AdminSDHolder object!

   
   

In short, here's what we uncovered - in all likelihood, a temporary IT contractor, Kevin Mandia, who is not supposed to have any type of privileged access in our Active Directory, possessed sufficient effective access in our Active Directory so as to be able to modify the permissions on a domain user account that went simply by the name Amateur Bad Guy (and that was hidden using basic sneaky persistence) and thus take full-control over it (Conclusion 1), and further that this Amateur Bad Guy domain user account that was hidden and that we had uncovered in the last example, had sufficient effective access in our Active Directory so as to be able to modify the membership of the Domain Admins group (Conclusion 2)!

In essence, we found a privilege escalation path leading from a completely unsuspected non-privileged domain user account to that of the Domain Admins group, and this path was paved by someone having modified merely two/three security permissions, one each in the ACL of two/three Active Directory objects, of which there might be thousands in our Active Directory!


I could keep going, and present a 1000 such examples, but in the interest of time, I'll stop here and share a few thoughts below, because right there we've already seen how "real" sneaky persistence can be used to go from a completely unsuspected unprivileged domain user account to obtaining unrestricted privileged access in an Active Directory domain!






Just Three ACEs!

As we've just seen above, in an Active Directory domain that has thousands of objects, and hundreds of thousands of security permissions, just ONE individual, i.e. a temporary contractor located in a foreign location (, or someone who has/had sufficient control over his account,) had likely modified just THREE security permissions, one each in the ACL of just three objects, and in doing so, had paved a path that could allow him to gain unrestricted privileged access in this Active Directory domain, at will!

In fact, here are the three ACEs / permissions he had added -

1. In the ACL of the AdminSDHolder object:

   Explicit   Allow   IT Operations Support Level 2 Group     Special (List Child, Read Property, Write Property)



2. In the ACL of the Africa OU (i.e. the parent object of the Amateur Bad Guy domain user account):

   Explicit   Deny  Everyone List Child

   This was done to hide this object by employing the "basic" sneaky persistence technique uncovered in this blog post. It must be noted that that this optional "hiding" step was not even necessary; it merely added an extra level of covertness.
   



3. In the ACL of the Amateur Bad Guy domain user account:

   Explicit   Allow   IT Operations Support Level 3 Group     Special (Modify Owner, Modify Permissions)

To reiterate, in an ocean of hundreds of thousands of security permissions in an Active Directory domain, all that a perpetrator had to do was tweak three security permissions, one each in the ACL of three otherwise unrelated Active Directory objects!

As you'll likely agree, not a single one of these permissions looks suspect, and the effective permissions they end up granting cannot likely be correctly assessed without the right tooling, so in organizations that lack the ability to audit effective permissions in their Active Directory, these subtle changes he had made could easily remain undetected (i.e. persist) for a long time!







A Small Special Subtlety

The astute mind will also note that the perpetrator specified a combination of permissions in each ACL, even though this wasn't necessary, only because when more than one Active Directory security permission is specified in a single ACE, when viewed in Microsoft's default native tooling, these security permissions specified in that ACE show up as Special, and in order to view them, you have to click on them, so if an admin were to glance at the ACL, such ACEs won't even stand out as suspect -

Further, even if IT personnel would have taken note of this one ACE, in order to accurately determine who can actually do what on that object, they would still also have to collectively take into account the impact of every other ACE in the ACL of that object!

(Recently, we came across an organization wherein in each ACL, there were well over 700 ACEs. Can you imagine trying to manually determine effective permissions on an object that may have hundreds of ACEs specified in that object's ACL?)






Identifying Entitled Users

There is one little thing I wanted to add, and I think the astute minds will further appreciate.

You see, one of the biggest reasons sneaky persistence is so effective is that a majority of access that is provisioned in Active Directory is specified for security groups (as it rightly should be), and thus when most IT personnel attempt to analyze Active Directory security permissions (and to a certain inaccurate degree, effective permissions), their findings are very often in terms of the access (or inaccurately determined effective access) that various security groups might have in their Active Directory.

Considering that a majority of access that is provisioned in Active Directory is specified for security groups, and that security groups could easily contain other security groups, and further that identical or overlapping access that may be allowed (i.e. granted) to certain security groups could also possibly be denied to other security groups, and either explicitly or via inheritance, and that there could easily be large numbers of individuals that could directly or via nesting belong to both such sets of security groups (i.e. that could belong to numerous groups for whom conflicting access is specified in various ways,) it is almost never easy to be able to accurately figure out exactly which individuals actually have what kind of (effective) access, and it is there that one usually misses out on detecting the existence of numerous individuals/accounts that are not supposed to have a specific type of (effective) access in Active Directory, but nonetheless still do so!

In that regard, not only does our effective permissions / effective access tooling completely and accurately determines effective permissions / effective access in and across Active Directory, it also delivers the answers to "who can actually do what in Active Directory" in terms of the identities of individual users, so if there's a suspect account that is not supposed to have a specific type of effective access, but it does, that account will certainly and clearly show up on that list, and thus there's no way to miss it, and that in part (i.e. obviously in addition to the fact that it can uniquely accurately determine effective permissions in Active Directory) is what makes our tooling so extremely effective at being able to identify and thwart even "real" sneaky persistence.

Effective, Powerful and Dangerous

As we have seen above, "real" sneaky persistence is extremely effective, powerful and dangerous.

It is effective because in most Active Directory deployments, unless organizational IT personnel have the means to be able to accurately and efficiently determine effective permissions on Active Directory objects, they're likely never going to be able to figure out the actual access that these sneaky permissions end up granting, and they're almost never likely going to be able to be able to connect the dots.

It is powerful because it provide perpetrators the ability to be able to instantly (re-)gain unprivileged access in Active Directory.

It is dangerous because if a perpetrator can (re-)gain unrestricted privileged access in your Active Directory, that's tantamount to a Domain Admin compromise, and it'd effectively be Game Over right there, and he/she would own your kingdom for eternity.


Consequently, it is paramount for organizations to ensure that there's no "real" sneaky persistence in their Active Directory.







In Short - How to Identify "Real" Sneaky Persistence in Active Directory

Folks, here's the very short of what it takes to identify "real" sneaky persistence in Active Directory.

All we need to do is determine effective permissions / effective access on every single object in our Active Directory domains to determine who is actually granted what effective access in our Active Directory based on the ocean of security permissions that exists in our Active Directory, and do so such that our results are in the form of the identities of all such individuals who possess any type of privileged access in our Active Directory (i.e. whether it be unrestricted or restricted (delegated) privileged access.)

Once we've done so, we'll have the complete picture of exactly who can actually do what in our Active Directory, and once we have that, all we'd have to do is analyze these results, and ANYONE that is NOT supposed/expected to have a certain kind of privileged access but in fact does so today will SHOW UP in our results, allowing us to identify all such sneaky/hidden access.

For instance, as we saw in the example above, by using this approach, we could not only easily determine that a certain user who was not a member of our core IT operations staff had the ability to modify the permissions of a hidden domain user account, and similarly, we could easily determine that that hidden domain user account had the ability to modify the membership of the Domain Admins group!

The two primary reasons this approach works is that a) it involves the determination of accurate effective permissions / effective access in Active Directory, and thus provides us with an accurate picture of who can actually do what, and secondly b) the results identify the identities of all such individuals (and to be specific their domain user accounts) who can enact these tasks, and it is this combination of "accurate results" + "entitled identities" that makes it really easy to identify any and all privileged access in Active Directory that should NOT exist, but in fact does so today!

So you see, once you understand the problem, know how to solve it, and have the right tooling to get it done, it isn't that difficult.







Conquering Everest, Made Easy

If you know Active Directory Security well enough, then you know three things -

1. The only way to find out who can actually do what on an Active Directory object is by accurately determining effective permissions on that object.


2. The only way to ensure that there's no such "real" sneaky persistence in Active Directory is to accurately determine effective permissions / effective access across the entire Active Directory domain i.e. on every object in the domain.


3. Trying to accurately determine effective permissions on even a single object in Active Directory is very difficult for most, so trying to do this domain-wide is almost impossible, and thus on par with say trying to conquer Mount Everest.

If you don't know Active Directory Security well enough, then here's a good starting point for you to learn more.

Let me repeat that because so many folks out there may still not know this - trying to accurately find out who can do what across an entire Active Directory domain is extremely difficult, and thus equivalent to trying to scaling Mount Everest.

It may be worth taking a small pause to think about that for a moment.


Now, that said, today, if you can touch a button, you can now find out exactly who can enact which administrative tasks in and across entire Active Directory domain  i.e.  you can now find out exactly who can do what, where and how in Active Directory -

It may also be worth taking a small pause to think about this for a moment.


In short, today every organization that wants to identity and thwart sneaky persistence in their Active Directory can actually do so because the technology needed to identify and thwart even "real" sneaky persistence in Active Directory, exists today.

To all organizations that are still (i.e. 17 years after Active Directory was shipped) trying to make do with infantile tooling like dsacls, Microsoft's Effective Permissions Tab, PowerShell, Bloodhound, half a dozen basic Active Directory Permission Analyzers out there, etc., all I can most respectfully say is that you may likely just not know Active Directory well enough yet.








The Key to It All

I'm saying this for the umpteenth time. No matter what security challenge you're trying to solve in Active Directory Security, the key to it all likes in being able to accurately determine effective permissions / effective access in and across Active Directory.

So, whether you're trying to secure Active Directory, securely delegate administrative access, identify privileged users in Active Directory, reduce your Active Directory attack surface, protect against insider threats, demonstrate regulatory compliance of access rights in Active Directory, identify privilege escalation paths, find out who can change AdminSDHolder, mitigate the risk posed by Mimikatz DCSync, identify stealthy admins in Active Directory, or identify and thwart sneaky persistence in Active Directory, the key to it all lies in being able to accurately determine effective permissions / effective access in Active Directory.

Sadly, apparently Microsoft has never (i.e. not once) educated its global customer base about the paramount importance of effective permissions to Active Directory security, so let alone possessing the ability to do so, most organizations don't even seem to know what Active Directory effective permissions are! They likely have no idea what a dangerous situation they're in.






Finally, One Last Thing

(This unnecessary section is solely intended for those few individuals out there who may think that this is a plug for our tooling.)

I also did want to make it very clear that neither this post nor any of my other (100+) post(s) here and here are intended to be a plug for our tooling. The only reason I have used our tooling to demonstrate how to solve this and other equally important challenges in Active Directory Security is because it is the only tooling I know of that can help solve these challenges.

We have no particular interest in pitching our tooling to anyone. In fact, during the last ten+ years of our existence, we have not once pitched our tooling to anyone, marketed our products, emailed anyone or called anyone about it, nor have we placed a single advertisement anywhere or paid anyone (vendors, analysts, consultants, journalists, petty award organizers etc.) to promote our tooling, yet we've had 10,000+ organizations from across 150+ countries knock at our door, completely unsolicited.

Further in the interest of objectivity, I've clearly shared above what it takes to solve this problem, so if you know of or can find any other tooling that can help do what it takes to solve this problem, by all means you should feel free to use that option.

Hopefully, I need say no more about this, so I won't.

(Most organizations that understand this stuff deeply appreciate what it is we uniquely do, and are just thankful that we exist.)







Summary

This wraps up my 2 cents on "Sneaky Persistence in Active Directory" which made waves at the Black Hat Conference 2017.

In my previous post I had shown how to most easily identify and thwart "basic" sneaky persistence that involved hiding objects in Active Directory. In this post, I covered "real" (advanced) sneaky persistence and showed how organizations can easily identify and thwart "real" sneaky persistence as well.

"Real" sneaky persistence is 100 times more effective, powerful and dangerous, because it is so hard to detect with the naked eye and/or with infantile tooling. However, organizations that possess the ability to accurately determine effective permissions / effective access in their Active Directory deployments, both on a per-object and a domain-wide basis can very quickly identify and thwart both "simple" and "real" sneaky persistence in their Active Directory.

Lastly, I will only add this much - in almost every Active Directory domain in the world, today there already likely exists an ocean of "real" sneaky persistence/access, and it may likely have paved thousands of privilege escalation paths over time, completely unintentionally, and merely as a result of an extensive amount of administrative delegation and access provisioning that may have been done over the last so many years.

Fortunately, armed with the insight I've shared above, organizations can also identify and eliminate all such sneaky persistence / privilege escalation paths in their Active Directory. Considering that these privilege escalation paths can be identified by anyone that has a domain user account, any intruder who has been able to compromise even one domain user account and knows how to find such paths, could take his/her sweet time to find them (because read access to Active Directory is not audited), and once he/she has found an ideal path, as illustrated here, he/she could act to elevate privilege and possibly take over the entire Active Directory within minutes.

That's all for today.

Best wishes,
Sanjay


PS: Please feel free to share this post with anyone you like, including with the wonderful folks who gave that An ACE Up the Sleeve presentation at Black Hat. If you share it with them, please let them know that in their detailed 64-page whitepaper on Sneaky Persistence in Active Directory, there isn't a single mention of "effective permissions". They too may want to start here.

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

Folks,

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

Best,
Sanjay

CEO, Paramount Defenses



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

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

Folks,

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, 3, 4), 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,
Sanjay

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.