A Simple Trillion $ Active Directory Privilege Escalation Example (Day 6)

Dear Microsoft,

Today is Day-6 of our advanced Active Directory security school for you. I was going to talk about effective permissions today, but perhaps a concrete example might help everyone first, so today I'll present a very simple, realistic illustrative example.

This example is representative of what you may find in most Active Directory deployments today so it merits undivided attention.

Hacker trying to elevate privilege in an Active Directory deployment

It may seem a bit long and I know that these days everyone prefers a 30-second exec summary, but this illustrates a MASSIVE cyber security challenge that thousands of organizations worldwide likely face today, so you'll want to read it completely.

I only hope that someone at Microsoft has the intellectual capacity to fathom the ramifications of what I've shared below.

A 1000 Paths to Escalate Privilege to a Domain/Enterprise Admin within Active Directory -

Quick Background

It is a well-known fact that if someone can escalate their privilege to that of an Active Directory privileged user (e.g. a Domain Admin, Enterprise Admin etc.), he/she would in effect have gained complete command and control over your IT infrastructure.

Microsoft's guidance does a decent job at describing the default administrative groups in Active Directory; it communicates that all members of (and) all domain security groups considered to be privileged by default in Active Directory are afforded special protection via AdminSDHolder, a process that involves stamping a special protected ACL on all such accounts and groups.  

AdminSDHolder

Most organizations have thus focused their Active Directory privileged user audit and security efforts on identifying (and protecting) all AdminSDHolder protected accounts, and have a fairly good idea of the count and identity of such accounts.

But if you look just ONE level deeper, you'll likely find...

...1000s of privilege escalation paths, leading to these privileged users.

Now, A Simple, Real-World Example

Microsoft, here's an actual real-world example with real data in the Active Directory deployment of a fictional organization. 

To keep it really simple, let's just begin by taking a look at their Domain Admins group -

The Domain Admins Group in Active Directory

As you can see, they've really locked their Active Directory down and have only 2 Domain Admins accounts in Active Directory.

In fact, let us assume that the entirety of their other default administrative groups in Active Directory, i.e. and e.g. Enterprise Admins, Administrators, Schema Admins, Account Operators, Server Operators, etc. also only have the same two members.

Based on the above, if an IT Auditor were required to report on the number of privileged users in their Active Directory, such as to demonstrate regulatory compliance, he/she'd say that this organization only has 2 privileged users in their Active Directory -

1. The default Administrator account, and
2. Steve Ballmer, the Domain Administrator

In fact, not only may this organization's CFO actually be signing-off on this to demonstrate regulatory compliance, but the organization would from this point on be operating on an assumption that they have only 2 privileged users in Active Directory.

Today, at most organizations worldwide, this is the extent of identifying and certifying the number of privileged users in Active Directory i.e. their IT departments do their best to identify all default administrative accounts protected by AdminSDHolder.

Keep reading...




Elementary, Watson!

One day, Mr. Watson, the organization's CISO has a visitor, Mr. Holmes, a friend. Mr. Watson gives an overview of what he does, and as the conversation flows, he shares with Mr. Holmes that in security there is such a thing as privileged users, and that their organization only has 2 privileged users in Active Directory, because the Domain Admins group only has 2 members!

Mr. Holmes

At which point, Mr. Holmes asks Mr. Watson - "But is there anyone who can change the Domain Admins group's membership?"

Slightly taken aback, Mr. Watson says - "Well, er, we never did think of that! Why do you ask?"

To which Mr. Holmes replies - "Its Elementary, Watson!

Here's why this is Elementary:  If someone can change the membership of the Domain Admin's group, he can easily control who is now and who is no longer a Domain Admin, so obviously he/she is also equivalent to being a privileged user, isn't he?!





A Simple Question, A Not So Simple Answer

Immediately after the meeting, Mr. Watson (CISO) called Mr. Ballmer, and asked - "Steve, I know we only have 2 members in the Domain Admins group, (i.e. you + the Admin account) but how many people can actually change the group's membership?"

To which Steve, the Domain Admin responded - "Er, that's a good question Sir! To be quite honest, I've never actually thought about it because I've always assumed it would just be us, but let me try to actually figure it out and get back to you!"

Steve, the Domain Admin, figured he'd begin by taking a look at the ACL of the Domain Admins group, because to answer the question, he'd need to figure out if anyone else had the ability to modify the Member attribute of the Domain Admins group -

The ACL on the Domain Admins Group

Sure enough, there were a few non-default permissions in the ACL protecting the Domain Admins group. (This was the same ACL as on AdminSDHolder, which had been customized, stamped on the Domain Admins group.) For instance, there were Special permissions granted to the IT Contingency Support Team, and Write all properties granted to IT Global Admins etc.

There were Allow permissions (and perhaps a few Deny permissions as well), there were permissions granted to individual users, security groups (which could have nested groups), well-known SIDs, relative SIDs (e.g. Self) etc. and while some were straight-forward, many were marked Special, and there were some granting Full-Control etc. In short, this didn't seem simple.

Where and how should he begin, and how might he be able to answer this simple and elemental question?!

For a moment, he sat there trying to figure out how to answer this question, as he had never really given it much thought before.





Small digression...

Humor

What a co-incidence that a world-renowned expert of Black Hat Conference Presenter fame recently (on June 13, 2017) shared light on this most basic super simple fact with the world! i.e. in Active Directory, admin rights are granted by more than groups -

I'm sorry but that snapshot above (which was sent to me by someone) was just too funny (and pertinent) not to include in here, considering that its 2017 and its been retweeted 326 times & liked 468 times thus far. Like kids say these days ROFL LMAO ;-)

A helpful tip for all such experts (including those who made BloodHound): You're off to a good start, (and (is it just me or do you too find it funny that) you're just realizing all this 15+ years after Active Directory was shipped! ;-) ) so let me help you a bit, like I helped one of your Twitter friends understand this stuff recently. If you want to do this correctly, you have a million miles to go.

In fact it's right there (two tabs to the right) in the snapshot above, but even Microsoft's experts don't get it, as evidenced here.

Oh one other thing - when it comes to Active Directory Security, I learnt that the folks at that Black Hat Conference don't seem to know much. They're so new to this stuff which is why I for one will never be applying to present at that conference again.

End of Small digression...

Aha!  (It is "Who has what Effective Permissions",  Not "Who has what Permissions")

He figured he'd Google the term "Active Directory Permissions Audit" and when he did, he mostly came across numerous advertisements from various vendors, all claiming to help him "Find out who can do what in Active Directory", so he requested trials from all of them, only to come to the realization that all they were doing is helping find "Who has what Permissions in Active Directory", which was hardly useful considering just how many complexities there are in determining who can actually do what in Active Directory, such as correctly taking into account conflicting permissions, precedence orders, overlapping permissions, inapplicable permissions, group memberships, well-known SID inclusions (e.g. Domain Users etc.) and numerous other factors, and that none of these solutions from these vendors could help him answer this simple question.

So much so for these (clueless) vendors trying to help organizations find out "who has what permissions in Active Directory!"

As he was giving it thought, his eyes seemed to notice (almost as though for the first time ever) that there was an Effective Permissions tab as well, and he thought that perhaps that might be something relevant and important given that there's an entire tab for it, so he figured it may have something to do with what he was trying to figure out, so he clicked on it to view it -

The Effective Permissions Tab

Aha! It is upon reviewing this tab he realized that indeed, in order to answer this simple question correctly (i.e. accurately), he would need to take all the permissions specified in the object's ACL into account TOGETHER (and not separately), and that he would need to determine who has sufficient "effective permissions" to modify (i.e. write) the "member" attribute on the group.

[ Quick background on why one needs to determine effective permissions to answer this, and all such questions - a user could be directly or via (direct or nested) group membership(s) allowed a specific set of permissions in one or more ACEs, but could also be denied the same or a subset of those permissions directly or via (direct or nested) group membership(s) in one or more other ACEs that exist in the ACL, and whilst some of these grants may be explicit, others may be inherited, and while some might apply to the object, others may not, and thus in order to determine the user's actual resulting access, one would need to collectively (i.e. TOGETHER) consider the cumulative impact of all the permissions specified in all the ACEs in the ACL. ]





Er, No Solution?

Once he had determined that he needed to determine effective permissions, he figured that he would just use Microsoft's Effective Permissions Tab to do so. It is when he tried to do so that he realized that this tab could at best determine (an approximation of) effective permissions for one user at a time. Since they have 1000s of users in their Active Directory, there was no way he was going to manually enter 1000s of names one-by-one into this tab, then make a note of each individual user's effective permissions.

Upon doing some research online, he realized that all of Microsoft's native tooling related to any sort of effective permissions calculations in Active Directory, such as dsacls, acldiag, accesschk, scripts on TechNet, PowerShell etc., (as well as this ridiculously stupid and dangerously inaccurate free tool) were all substantially inaccurate/inadequate, and thus hardly useful.

So he called the CISO and said - "Mr. Watson, it appears that to answer your question, we need to be able to accurately determine something called effective permissions on the Domain Admins group, but it appears there's no solution to do so, i.e. there appears to be no way to do so easily and accurately, so I'm afraid I don't think we'll be able to figure this out."

Mr. Watson

Mr. Watson replied - "Mr. Ballmer, its 2017. 100% of all major recent cyber security breaches have involved the compromise of a single Active Directory privileged user, and there are a 1000 cyber security companies out there, and you're telling me that there is no way to figure out something as elemental as how many people can control our Domain Admins group membership?!"

The Domain Admin replied - "Well, Microsoft does not have any tooling that can do this accurately and efficiently, nor does any cyber security company covered by what's that company again, yes Gartner. In addition, all the vendors in the Active Directory space merely have simple permissions audit solutions which cannot solve this problem, and no major cyber security or IT company including Dell, EMC, RSA, Palantir, Tanium, Cisco, HP, Centrify etc. and I could name 992 more, seem to have any solution to this problem."

Mr. Watson replied - "Well, look harder, because we have got to be able to figure this out! Can you imagine that we, a multi-billion $ company, don't even know how many individuals can change the membership of our Domain Admins group!"

So Mr. Ballmer did, and just as when he was just about to give up, he chanced upon this, and here's what happened next...





Click, Done

He launched Gold Finger, selected the Effective Permissions Calculator, pointed it to Domain Admins and clicked ONE button -

Gold Finger Effective Permissions Calculator

He realized that even if he did not know a thing about Active Directory technical stuff, he could still have been able to do this by selecting the Effective Access Calculator and done the same -

Gold Finger Effective Access Calculator

In less than 15 seconds, he had uncovered for the first time ever, that although they only had 2 Domain Admins, there were in fact 6 individuals in total who could change the membership of the Domain Admins security group -

1. The Administrator account
2. Erica Lockhart
3. Larry Page
4. Steve Ballmer (himself)
5. Ted Schlein
6. Victor Lombardi

(Technically speaking, here's what the tool did: convert this to this.)

It was partly shock and partly awe, so he immediately called the CISO and informed him that there were a total of 6 individuals who could change the membership of the Domain Admins group, and thus that they may have been operating under a false assumption all this while, and in fact may also have furnished inaccurate evidence to demonstrate regulatory compliance.

There was silence for a moment on the phone.

Mr. Watson asked the Domain Admin - "Well, is there anyone that stands out in particular?!"

Mr Ballmer replied - "While all four are surprising, one in particular is most surprising - Ted Schlein, he's a junior IT operator!"

Wow, they had just discovered that amongst others, a junior IT operator could control the Domain Admins group's membership.



Mr. Watson was a quick learner, so he asked "Well, can you find out how many people can reset Mr. Schlein's password?"

Slightly taken aback, Mr. Ballmer says - "Well, er, I've never thought of that! Why do you ask?"

To which, this time around, Mr. Watson replied - "Its Elementary, Ballmer!

Here's why this is Elementary:  If someone can reset the password of a Domain Admin, he can instantly become the Domain Admin and login as the Domain Admin, so obviously he/she is also equivalent to being a privileged user, isn't he?!






Whoa

This time around the Domain Admin, Mr. Ballmer, pointed Gold Finger at Ted Schlein's account and clicked a button -

Gold Finger Effective Permissions Calculator

In less than 15 seconds, he had discovered, again, for the first time ever, that 28 more individuals possessed sufficient effective access on Mr. Ted Schlein's domain user account in Active Directory so as to be able to reset his password -

Administrator Chris Warner Costas Dimitriou David Parker Ed Newman Eric Boyle Erica Lockhart Frank Murphy Gabriel Peterson James Walsh

Jeff Bezos Juan Batista Julia Walker Kid Zuckerburg Larry Page Laura Michelson Marc Benioff Michael Karp Patrick Sullivan Quincy Lawson

Ray Lane Ryan Johnson Satya Nadella Steve Ballmer Susan Williams Ted Schlein Troy Williams Victor Lombardi Vincent Smith Yaris Constantinou

In other words, they had just discovered at least 28 more individuals who were 10 seconds away from gaining sufficient access to an account that had sufficient access to instantly obtain complete command and control over the Domain Admins group!

(Technically speaking, here's what the tool did: convert this to this.)

Mr. Ballmer called Mr. Watson - "Sir, I think you'll want to see this in person!"





Privilege Escalation Paths

As I said, Mr. Watson was a quick study, and by now had figured out that if 28 more people (than they knew about) could reset the password of a user who could change the membership of the Domain Admins group, there were at least 28 privilege escalation paths to becoming a privileged user in their Active Directory.

He figured that if this simple logic was iteratively applied on to these 28 accounts, the number of paths could possibly be in the hundreds, and with each additional level of iteration, they would likely substantially increase. In fact, if one were to consider all the IT assets stored in Active Directory, by extrapolation, there could be 1000s of privilege escalation paths in Active Directory!

Privilege Escalation Paths in Active Directory

So he asked Mr. Ballmer, the Domain Admin a simple question - "With this tool that you've found, it appears you can do this one object at a time, but we have 1000s of users, so is there an easy way to quickly (efficiently) and accurately figure out who can reset whose passwords in Active Directory, because if we could do so, we may find 1000s of privilege escalation paths?"





Impossible? Done

It turns out that in the whole wide world, with trillions of $ being protected by Active Directory, there is all of ONE way to do this.

Mr. Ballmer used the tool selector in Gold Finger to select the Administrative Access / Delegation Audit Tool, selected the report Who can reset user account passwords?, set the scope to be the entire domain and clicked ONE button -

Gold Finger Administrative Access / Delegation Audit Tool

In seconds, Gold Finger had accurately and efficiently determined effective permissions / effective access on all domain user accounts in their Active Directory and revealed possibly the most valuable intelligence/insight they had seen in years - the complete and accurate list of exactly who can reset whose passwords in their Active Directory, and how they can do so.

To view the actual output of this effective access assessment in this small domain, please click here.

(Technically speaking, here's what the tool did: convert this to this.)

To make a long story short, if you have or possess the ability to accurately assess access entitlements of an entity in a system, which as it pertains to Active Directory means if you have the ability to accurately determine effective access provisioned in Active Directory, then you'll be able to uncover thousands of privilege escalation paths in Active Directory deployments.


In this puny Active Directory alone, there were hundreds, such as this one -

• Ted Schlein, a Junior IT Operator, can change the Domain Admins group membership
• Kid Zuckerburg, a Junior IT Analyst, can reset Ted Schlein's password
• Larry Page, an IT Support Admin, can reset Kid Zuckerburg's password
• James Walsh, an IT Web Administrator, can reset Larry Page's password 

So, the path is:  James Walsh > Larry Page > Kid Zuckerburg > Ted Schlein > Domain Admins group

For a limited time, you can do this for free (one object at time though), courtesy Gold Finger Mini, which we had recently decided to make available for free to help CEOs, CIOs and CISOs see for themselves just how bad the situation really is.

In most real-world, production Active Directory environments, you'll likely easily find 1000s of such privilege escalation paths.






The Weakest Link

For now, the CISO wanted to know what the weakest link might be i.e. is there a link wherein the starting point might be rather easily compromisable, and one that could within minutes easily lead to one gaining privileged access in Active Directory?

So they analyzed the effective access entitlement data that the tool had generated within seconds and guess what they found?

Here's likely the shortest privilege escalation path that could also possibly be the weakest link in this Active Directory -

• Larry Page, an IT Support Admin based in USA, can change the Domain Admins group membership
• James Walsh, an IT Web Administrator based in USA, can reset Larry Page's password
• Kevin Mandia, a temporary contractor based in India, can reset James Walsh's password 

So, the path is:  Kevin Mandia > James Walsh > Larry Page > Domain Admins group

It is possibly the weakest link because it begins with a temporary contractor's account, one that is located in a foreign country and possibly not as protected as the Domain Admin's account, and possibly one that is much more easily compromisable, and leads right to Domain Admin, and merely involves the enactment of 3 simple common tasks that all intermediate accounts involved in the escalation chain already have sufficient access to enact!

[ By the way, in case you're wondering how Mr. Mandia ended up with such access on Mr. Walsh's account, it turns out that someone meant to grant the IT Helpdesk Backup Team Send As permissions on Mr. Mandia's account, i.e. in the ACL (here) protecting his domain user account, but accidentally ended up granting the IT Helpdesk Team Reset Password permissions (which is right below the Send As permissions in Microsoft's ACL Editor UI), resulting in a situation wherein Kevin Mandia, a member of the IT Helpdesk Team ended up getting sufficient effective permissions to be able to reset Mr. Walsh's password. ]

Also, one doesn't need admin credentials to uncover such excessive grants; any domain account will do. In fact, intruders could use Microsoft's free tools (e.g. acldiag) to find low-hanging fruit i.e. any obvious and glaringly apparent excessive permissions. In fact, if you assume breach, then an intruder could take his sweet time to engage in unaudited read-only activity to analyze Active Directory ACLs, and over some time try and find various privilege escalation paths.

Here's a closer look at Kevin Mandia's domain user account in Active Directory -

Kevin Mandia's account viewed in Active Directory Users and Computers

As seen above in Microsoft's UI, Mr. Mandia is a temporary contractor based half way around the world, in Bangalore, India.


So, in effect, if perpetrators could compromise the domain account of this 1 temporary contractor located in Bangalore, India, they could obtain control over the foundational Active Directory of this fictional $ multi-Billion U.S. organization, in minutes!


Think about it for a minute - Microsoft suggests that organizations assume breach. Based on what's been going on, if credential-theft and other techniques can be used to compromise Domain Admin accounts, imagine how much easier it is to compromise a regular domain user account (or his computer), especially one belonging to a temporary contractor! All that the perpetrators need to do is to compromise Mr. Mandia's credentials or his computer and that's it, because the rest is child's play.


To visualize this, imagine that an APT is able to compromise Kevin Mandia's account in Bangalore at 12:30 pm local time (IST), which is 3:00 am (EST) in New York. By 3:02 am (EST) New York Time, they would have enacted 2 legitimate password resets and a group membership change to effectively gain Domain Admin privileges. By 3:05 pm New York Time (EST), they would have removed all existing members from the Domain Admins group, and completely locked down access on/to it, and in effect, they would have gained complete command and control over the Active Directory in less than 5 minutes!

This, while the organization has been operating on the assumption that they only have 2 privileged users in Active Directory.

The CISO

Once the CISO had visualized this, he called the CEO and said - "Sir, I think we may have a problem."

To which the CEO's immediate response was "Before you describe it, tell me, is there a solution?"

(To know the answer , please keep reading.)




There's an old saying - "To the wise, a hint is enough." 

If you're smart, I needn't say a word more; if you're not, I could go on forever and you still wouldn't get it, so this example ends here.

(But the answer is below.)

Oh, One Quick Point

To those who might say, well all that's involved here is a password reset, allow me to widen your horizons a bit, because a password reset is merely one of numerous ways in which you can exploit excessive/unauthorized permissions in Active Directory to gain all sorts of privilege -

1. Password Resets - Password resets are the most obvious and easiest way, because if you have sufficient rights to do so, all you have to do is click a button to compromise that user's identity and elevate privilege.


2. Membership Changes - Membership changes are the 2nd most obvious way, because if you have sufficient rights to do so, again all you have to do is click a button to be a member of that group and elevate privilege.


3. ACL Changes - ACL changes on objects are the most powerful way, because if you have sufficient rights to do so, again all you have to do is click a button to control all access on that object and elevate privilege.


4. GPO Linking - GPO linking is one of the easiest ways to compromise computers, because if you have sufficient rights to do so, all you have to do is click a button to gain privileged access to the computer (and thus to almost everything on it) and elevate privilege.


5. Kerberos Delegation Bits - Modifying bits that control an account's Kerberos delegation settings could enable you to impersonate a user across the network, and if you can do so, you could easily (set up to) impersonate a privileged user.


6. Disabling Smart-card Authentication - If you have sufficient access to disable Smartcard authentication on a domain account, you could weaken security as when you do so, the account will now only be protected by a random password, and if you also happen to have sufficient access to reset its password, you'll have elevated your privilege to that account.


7. Tampering a Service Connection Point - If your organization relies on a 3rd party solution (e.g. this one) to enhance and/or strengthen access, and to properly function that solution relies on service connection points (SCP) in Active Directory, then if you can tamper with that solution's SCPs (e.g. modify its keywords), you could instantly render it useless, thus weakening the security of all IT assets that service helps protect.  

I've shed light on just a few. The more time you spend on this stuff, the more you'll learn and the more ways you'll find.

Oh, and if you think these band-aids will solve the problem, request us, and we'll show you how easy it is to circumvent them.





The Root Cause

At the root/heart of everything I have shared above lies a deep and vast ocean of Active Directory security permissions.

A Vast Ocean

In fact, at the heart of everything I have shared above is a very simple fact - in most foundational Active Directory deployments worldwide, IT departments have been provisioning all kinds of access to fulfill various business needs for years now, and given the complexity of Active Directory's security model and the intricacies involved in access provisioning, such as the fact that when you use groups (as you should), their underlying memberships can change, and above all the fact that while it is easy to precisely provision access, it is very difficult to precisely assess resulting access (because the means to precisely assess resulting access don't exist, as described here) so obviously today there's a dark ocean of security permissions in Active Directory, and together they effectively end up granting an alarmingly vast amount of excessive/unauthorized access on literally everything in Active Directory.

Here's a clarified glimpse of what one drop in the ocean looks like -

ACL on Ted Schlein's Active Directory User Account

What I've shown above is merely a portion of the access control list (ACL) protecting Ted Schlein's account, here.

As you can see, there are numerous access control entries (ACEs) each one specifying one or more types of over a dozen Active Directory security permissions, some of which may be allowed while others denied, and some of which may be specified explicitly while others may be inherited, and of the ones inherited, some may actually apply to the object while others may not, and each such permission is specified for a security principal which might be an individual user, a security group (which may additionally have others security groups nested in it), a well-known security principal (such as Authenticated Users), relative SIDs (such as Self) etc. and it is the entirety of all this taken together that determines who can do what on an Active Directory object, in this case Schlein's account.

In most Active Directory deployments today, there are thousands, if not hundreds of thousands, of such ACLs, and in so many Active Directory deployments, there are as many as 100+ ACEs in each ACL, so there are millions of ACEs in Active Directory that whilst specified individually, ultimately collectively determine the resulting effective access across Active Directory.


Dear Microsoft, in light of this complexity, how are IT personnel reasonably supposed to make any sense out of it?!







What the World Needs

Today, the entire world (i.e. thousands of business and government organizations worldwide) operates on Active Directory.

What the world needs is the ability to accurately and efficiently convert this (protecting this) into this so that we can tractably and easily make sense of this ocean and achieve least-privileged access in our foundational Active Directory deployments, which today are paramount to cyber security.

Done.

Summary

To summarize, today via the above, I just wanted to make the following points -

1. A 1000 Ways to Become Domain Admin - Even in Active Directory deployments wherein credential-theft attacks may no longer be possible, there are still a 1000 ways to elevate privilege to Domain Admin, as shown above.


2. An Ocean of Active Directory Security Permissions - This is made possible because there exists an ocean of security permissions in each Active Directory that ultimately governs effective access on everything stored in Active Directory.


3. Perpetrators May Be On to It - As evidenced by recently introduced free tooling, notably BloodHound which incidentally is substantially & laughably inaccurate, the hacking community has started focusing on weaknesses in Active Directory. 


4. This Impacts all Active Directory Deployments - Today, irrespective of size, this problem is present in every Active Directory, and organizations that do not care about addressing it might end up being sitting ducks for perpetrators.


5. Today, an Easily Addressable Problem - Organizations that operate on Active Directory and wish to address this serious problem now actually have the ability to do so. Whether or not they choose to address it is entirely their call.

ONE LAST THING -

(This part was added later, inspired by a buffoon who left a most ridiculously immature and stupid comment.)

The only reason we had to use Gold Finger in this example is because it is the only tool (that we know of) that can so easily demonstrate the presence of 1000s of privilege escalation paths in Active Directory. This is NOT meant to promote Gold Finger.

Let me repeat that - we have no particular interest in promoting Gold Finger. In fact, in 10+ years as a company, we have NOT once marketed our products, sent a single unsolicited email to anyone, made a single unsolicited phone call, or pitched our product to ANYONE. Not once. During the same period, almost 10,000 organizations have knocked at our doors, unsolicited.

So to that buffoon I'd say - "Buzz off !"  (Why don't you focus on the problem, instead of on the tool used to shed light on it?)

Mature organizations have to assume that there may be nefarious entities out there, some possibly (heavily) state-sponsored, who could have clandestinely developed (and could use) similar tooling. To not assume so would be to be incredibly naïve.

All we care about is organizations addressing this risk (, because left unaddressed, it will remain a huge security risk (and we can demonstrate it to any organization that requests us)), and of course they can use any means they like, to address it.

Again, let there be NO mistake whatsoever about this. I should not have to repeat this again.

I will say this much though, and stand by it - "For all the marketing noise and grandiose claims that the 1000+ cyber security companies and major tech / defense companies out there make, we do find it laughable that not one of them has a solution for such a profoundly elemental and fundamental problem!"



That's it for today. More in the next few days to come. Stay tuned.

Best wishes,
Sanjay


PS: As to that Jr. IT Operator, Ted Schlein, his name and title were inspired by this supposedly brilliant cyber security visionary, who failed to understand even such simple stuff, a decade ago, and passed on helping out. Hey in a way, I'm thankful to him ;-)

PS2: Microsoft, in essence,  this  to  this.  Get it?!    (To gain a deeper understanding of how all this works, you'll want to read the one patent that governs the determination of effective access in Active Directory deployments across the world - this one.)

The Top-5 Cyber Security Risks to Active Directory Deployments (Day-5)

Dear Microsoft,

Today is Day-5 of our advanced Active Directory Security school for you. Since you've been busy trying to address risks posed by credential-theft attacks, and making paradigm shifts, you may likely have forgotten about the top risks to Active Directory.

So, today, I'll educate you about the Top-5 security risks that most Active Directory deployments are likely vulnerable to today.



The Top-5 Security Risks to Active Directory Deployments

The following are the Top 5 security risks that most Active Directory deployments are likely exposed to today -

1. The complete and instant compromise of the credentials of all domain user accounts, including those of all privileged users, enactable via Mimikatz DCSync, by any intruder/insider that has sufficient effective permissions to replicate secrets from Active Directory.


2. The complete and instant compromise of all default Active Directory privileged user accounts and groups, enactable via any AD mgmt. tool, by any intruder/insider that has sufficient effective permissions on the AdminSDHolder object.


3. The complete and instant compromise of most* IT assets stored in Active Directory, enactable via any AD mgmt. tool, by any intruder/insider that has sufficient effective permissions, resulting from wide-scoped insecure inheritable permissions.


4. The complete and instant compromise of all Domain Controllers in the domain, enactable via any AD mgmt. tool, by any intruder/insider that has sufficient effective permissions to link a malicious GPO to the default Domain Controllers OU.


5. The complete and instant compromise of specific IT assets stored in Active Directory, such as the CEO's user account, enactable via any AD mgmt. tool, by any intruder/insider that has sufficient effective permissions to do so.

[ Sufficient reasoning for what makes these risks the top 5 risks, as well as technical details, are furnished below. ]

It is vital to understand that a SINGLE occurrence of risks #1, #2 and #4 above (, and depending on the target, also of risks #3 and #5) could result in the compromise of the ENTIRE Active Directory deployment. This fact CANNOT be overstated enough.




But First, 5 Notable Points About These 5 Risks

Organizations that care about their foundational security may find the following points interesting to note -

1. Not a single one of these risks either requires or involves the use of any credential-theft technique (such as Pass-the-Hash, Kerberos Golden Tickets etc.) and none of these band-aids can prevent an attacker from enacting these risks.


2. Not a single one of these risks requires the attacker to compromise any computer whatsoever i.e. he/she need not compromise even a single Domain Controller, admin workstation, member server, employee laptop etc.


3. Not a single one of these risks requires the attacker to have physical or system access to even a single Domain Controller, data center, admin workstation, or for that matter even a single copy of an Active Directory backup.


4. Not a single one of these risks requires the attacker to possess tooling that is not freely available. Microsoft's native Active Directory management tools, and Mimikatz DCSync, all of which are freely available, are amply sufficient.


5. Not a single one of these risks requires the attacker to be at a specific location. Each one of these risks can be enacted from anywhere in the world (HQ, branch, offshore) as long as the attacker has network access to your Active Directory.

All that an attacker needs to enact these risks is sufficient effective access i.e. Active Directory Effective Permissions.

Oh and , 2 Other Quick Points

For those who may wonder why these risks are higher than risks posed by the compromise of a Domain Controller or an admin workstation, or the risks posed by credential-theft techniques involving the compromise of Active Directory privileged users -

1. For those wondering as to why these risks are higher than the risk posed by the compromise of a Domain Controller (DC) or an admin workstation, it is because to compromise a DC or an admin workstation, one typically requires either unrestricted physical access to it, and/or the ability to breach its system security, both of which are almost always more difficult to obtain than mere network access to Active Directory, which (obviously in addition to sufficient effective permissions) is all that a perpetrator needs to successfully enact any or each of these 5 risks to Active Directory.


2. For those wondering as to why these risks are higher than the risk posed by predominant credential-theft techniques involving the compromise of Active Directory privileged users, we're focused on mature defendable IT environments, wherein organizations have been able to either largely eliminate or minimize the possibility of credential-theft attacks involving the compromise of Active Directory privileged users in their environments, or be in a position to detect their occurrence (via technologies such as Microsoft ATA) and thwart them. Speaking of which, may I suggest reading this.

And now...



An Objective, Formal Risk-Management based Substantiation of these Top-5 Risks -



1. Complete and Instant Compromise of the Credentials of All Domain User Accounts -

• Asset at Risk – Credentials of all Active Directory domain user accounts (including those of all privileged users)
• Threat Source – Any sufficiently privileged intruder (hacker, APT etc.) / insider (disgruntled, rogue or coerced user)
• Attack Surface – Active Directory domain root object
• Enabler - Anyone who possesses Get-Replication-Changes-All extended right effective permissions on the domain root object is allowed to, and thus can, replicate all data including secrets (i.e. passwords) from Active Directory
• Exploitation Procedure – DCSync feature of the Mimikatz tool
• Difficulty – Minimal
• Impact – Very high
• Likelihood / Probability of Occurrence – High
• Physical / System Level Access to DC Required – No
• Resources Required – Network access to Active Directory + Sufficient Effective Permissions in Active Directory
• Mitigation / Prevention – Ensure (at all times) that only the smallest number of most highly trustworthy IT personnel have the Get-Replication-Changes-All effective permissions granted on the domain root object in Active Directory
• Risk Assessment – To find out exactly who can enact this risk, audit Active Directory effective permissions on the domain root object to find out exactly who all effectively have the Get-Replication-Changes-All right granted today
• Detection – Potentially possible via use of Active Directory auditing. However, detection is hardly useful because by the time an audit event/notification is generated / acted upon, substantial damage will likely already have been done
• Additional Info - Here

2. Complete and Instant Compromise of All Default Active Directory Privileged Domain User Accounts and Groups -

• Asset at Risk – All default Active Directory privileged/administrative domain user accounts and security groups (e.g. Administrators, Domain Admins, Enterprise Admins, Server Operators, Print Operators, Account Operators etc.)
• Threat Source – Any sufficiently privileged intruder (hacker, APT etc.) / insider (disgruntled, rogue or coerced user)
• Attack Surface – AdminSDHolder object in Active Directory
• Enabler - Anyone who possesses any one of various modify (WP, WD, CR, FC) effective permissions on the AdminSDHolder object is allowed to, and thus can, manage all default Active Directory domain accounts and groups
• Exploitation Procedure – Use native Microsoft Active Directory management tooling (e.g. ADUC etc.) to maliciously enact an authorized administrative task such as a password reset or a group membership change
• Difficulty – Minimal
• Impact – Very high
• Likelihood / Probability of Occurrence – High
• Physical / System Level Access to DC Required – No
• Resources Required – Network access to Active Directory + Sufficient Effective Permissions in Active Directory
• Mitigation / Prevention – Ensure (at all times) that only the smallest number of most highly trustworthy IT personnel have modify (WP, WD, CR, FC) effective permissions granted on the AdminSDHolder object in Active Directory
• Risk Assessment – To find out exactly who can enact this risk, audit Active Directory effective permissions on the AdminSDHolder object to find out exactly who all effectively have various modify effective permissions granted today
• Detection – Possible via use of Active Directory auditing. However, detection is hardly useful because by the time an audit event/notification is generated / acted upon, substantial damage will most likely already have been done.
• Additional Info - Here

3. Complete and Instant Compromise of Most IT Assets Stored in Active Directory -

• Asset at Risk – Almost all Active Directory content (i.e. all Active Directory objects except those whose ACLs are not marked Protected), such as all domain user accounts, security groups, computer accounts, OUs, SCPs etc. 
• Threat Source – Any sufficiently privileged intruder (hacker, APT etc.) / insider (disgruntled, rogue or coerced user)
• Attack Surface – The entire Active Directory
• Enabler - Anyone who ends up being entitled to any one of various modify (WP, WD, CR, FC) effective permissions on any object in Active Directory is allowed to, and thus can manage that Active Directory object. A single incorrectly specified (whether accidentally or intentionally) inheritable security permission specified at the domain root or at a top-level OU could impact the effective permissions on thousands of Active Directory objects in that domain/OU. 
• Exploitation Procedure – Use native Microsoft Active Directory management tooling (e.g. ADUC etc.) to maliciously enact an authorized administrative task such as a password reset or a group membership change
• Difficulty – Minimal
• Impact – High to Very high
• Likelihood / Probability of Occurrence – High
• Physical / System Level Access to DC Required – No
• Resources Required – Network access to Active Directory + Sufficient Effective Permissions in Active Directory
• Mitigation / Prevention – Ensure (at all times) that all access provisioned in Active Directory adheres to the principle of least privilege, so as to ensure that net resulting effective permissions / effective access on all Active Directory objects only permits authorized personnel to enact administrative tasks on these objects
• Risk Assessment – To find out exactly who can enact this risk, perform a domain-wide Effective Privileged Access Audit in Active Directory to find out exactly who can enact which privileged/admin tasks where in Active Directory
• Detection – Possible via use of Active Directory auditing. However, detection is hardly useful because by the time an audit event/notification is generated / acted upon, substantial damage will most likely already have been done.
• Additional Info - Here

4. Complete and Instant Compromise of All Domain Controllers in the Domain -

• Asset at Risk – All Domain Controllers in an Active Directory domain 
• Threat Source – Any sufficiently privileged intruder (hacker, APT etc.) / insider (disgruntled, rogue or coerced user)
• Attack Surface – The default Domain Controllers organizational-unit (OU) in Active Directory
• Enabler - Anyone who has sufficient effective permissions to be able to modify the list of Group Policy Objects (GPOs) linked to the default Domain Controllers OU in Active Directory is allowed to, and thus can link a GPO to that OU. The linking of a single weak or malicious GPO to the default Domain Controllers OU could weaken the System security of all DCs in that domain, and be used to easily obtain administrative command and control over all DCs. 
• Exploitation Procedure – Use native Microsoft Active Directory management tooling (e.g. ADUC etc.) to link a weak or malicious GPO to the default Domain Controllers OU
• Difficulty – Minimal
• Impact – Very high
• Likelihood / Probability of Occurrence – High
• Physical / System Level Access to DC Required – No
• Resources Required – Network access to Active Directory + Sufficient Effective Permissions in Active Directory
• Mitigation / Prevention – Ensure (at all times) that only the smallest number of most highly trustworthy IT personnel have sufficient effective permissions to be able to link GPOs to the default Domain Controllers OU in Active Directory
• Risk Assessment – To find out exactly who can enact this risk, audit Active Directory effective permissions on the default Domain Controllers organizational unit (OU) object to find out exactly who can link GPOs to this OU
• Detection – Possible via use of Active Directory auditing. However, detection is hardly useful because by the time an audit event/notification is generated / acted upon, substantial damage will most likely already have been done.
• Additional Info - Here

5. Complete and Instant Compromise of Specific IT Assets Stored in Active Directory -

• Asset at Risk – Almost all Active Directory content, such as and including as all domain user accounts (including any executive and non-default privileged user accounts), security groups, computer accounts, OUs, SCPs etc.


• Asset Examples –  The following are a few simple illustrative examples of such assets:
  
  
  
  1. The domain user account of a non-default highly privileged user, one that is not protected by AdminSDHolder, yet possesses Domain-Admin equivalent privilege in Active Directory based on custom access provisioning
  2. The domain user account of an organizational executive (e.g. Chairman, CEO, CFO, CIO, CISO, VP etc.)
  3. A large membership domain security group such as All Employees, or (all) Domain Computers etc.
  4. The domain computer account of a specific computer, such as a high-value email, app or database server
  5. A top-level Organizational Unit that contains thousands of users, computers, groups and other objects
  6. A service connection point of a mission-critical Active Directory integrated service/app, e.g. this one (; here)
  
  
• Threat Source – Any sufficiently privileged intruder (hacker, APT etc.) / insider (disgruntled, rogue or coerced user)
• Attack Surface – The entire Active Directory
• Enabler - Anyone who ends up being entitled to any one of various modify (WP, WD, CR, FC) effective permissions on any object in Active Directory is allowed to, and thus can manage that Active Directory object. A single incorrectly specified security permission (inherited or explicit) in an Active Directory object's ACL could substantially impact the actual resulting effective permissions entitled on that object, resulting in unauthorized effective access on the object.
• Exploitation Procedure – Use Microsoft's Active Directory management tooling (e.g. ADUC etc.) to enact an (un-)authorized administrative task such as a malicious password reset, a group membership change, a user account creation, a computer account delegation change, an OU deletion, a service connection point keyword change etc.
• Difficulty – Minimal
• Impact – High to Very high
• Likelihood / Probability of Occurrence – High
• Physical / System Level Access to DC Required – No
• Resources Required – Network access to Active Directory + Sufficient Effective Permissions in Active Directory
• Mitigation / Prevention – Ensure (at all times) that all access provisioned in Active Directory adheres to the principle of least privilege, so as to ensure that net resulting effective permissions / effective access on all Active Directory objects only permits authorized personnel to enact various administrative tasks on those objects
• Risk Assessment – To find out exactly who can enact this risk, either audit Active Directory effective access on all vital objects in Active Directory (e.g. all exec accounts, sensitive groups large OUs etc.) one-by-one, or perform a tree-wide effective privileged access audit to find out exactly who all can enact which admin tasks on these objects
• Detection – Possible via use of Active Directory auditing. However, detection is hardly useful because by the time an audit event/notification is generated / acted upon, substantial damage will most likely already have been done.
• Additional Info - Here

So Microsoft, there you have it. These are the actual and REAL Top-5 cyber security risks that almost all Active Directory deployments worldwide (including possibly yours) are likely exposed to today. You may want to read this many times over.

BTW, for anyone who needs it, an Executive Summary of the above (in PDF format) can be downloaded from here.

Summary

Today I just wanted to share with Microsoft and the whole world the actual Top-5 cyber security risks that most Active Directory deployments worldwide are substantially exposed to today (; most organizations may not even know that they're exposed.)

In light of the above, I would also encourage folks worldwide to first read the above (with attention to detail, and in its entirety) and then read the following 3 insightful posts, and you'll see why I believe Microsoft doesn't seem to have a clue -

1. 30 Days of Advanced Active Directory Security School for Microsoft


2. A Trillion $ Cyber Security Question for Microsoft regarding Defending Active Directory


3. How Well Does Microsoft Really Understand Cyber Security?

If you still need a hint, I'll give you one - in factually and objectively describing  the Top-5 security risks to Active Directory, how many times did I need to use the term "effective permissions" above? In contrast, when you read the 3 linked posts pointed to above make a note of and compare how many times Microsoft has educated the world about the term "effective permissions."


Microsoft, you'll want to read this (50 times) and absorb it like a sponge absorbs water - Active Directory Effective Permissions.

Alright, Microsoft, this is it for today. Later this week we shall continue with Day-6 of our advanced Active Directory Security school for you, during which I'll cover another fascinating trillion $ topic for you and the world - you likely won't want to miss it.

Best wishes,

Sanjay

PS: I've been meaning to do this on a daily basis, but given my responsibilities (i.e. a global cyber security company to head), time is difficult to take out, thus the delay. That said, if this weren't vital to global security, I wouldn't be wasting my time on it.

The Active Directory Attack Surface (Day 4)

Dear Microsoft,

Today is Day-4 of our advanced Active Directory Audit School for you. Today, I'll help you better understand the Active Directory attack surface, and because my time's valuable, I'll focus on the two specific areas that you don't seem to understand too well.
(If you want to know why I think that you don't understand them that well, just read the post and the PS section that follows.)

The Active Directory Attack Surface

As most organizations know today, the Active Directory attack surface is primarily comprised of 5 components -

1. Domain Controllers

2. Active Directory Backups

3. Active Directory Administrative Accounts and Security Groups

4. Administrative Workstations used by Active Directory Administrative Personnel

5*. Last but not the least, unique to Active Directory, Administrative Delegations / Ocean of Security Permissions

* Note: Strictly speaking, if implemented perfectly the compromise of administrative delegations whilst could result in substantial damage, could not result in the compromise of Active Directory. However, because in reality, today, at most organizations worldwide, the implementation of administrative delegations is far from perfect, realistically speaking the compromise of administrative delegations can easily result in the compromise of Active Directory.

Suffice it to say that if a perpetrator can compromise any one of the above, he/she can compromise Active Directory.




Rationale

Here's why these five components constitute the Active Directory Attack Surface -

1. Domain Controllers (DCs) - The protection of DCs is of utmost importance because the compromise of even a single DC is tantamount to a compromise of the entire Active Directory, considering that Active Directory is hosted on DCs.


2. Active Directory Backups - The protection of physical Active Directory backups is equally important because should a perpetrator be able to obtain physical access to such a backup, with the right tooling, he/she could extract the credentials of all accounts from the backup, including of course, the credentials of all privileged accounts, resulting in a compromise.


3. Active Directory Administrative Accounts and Security Groups - The protection of all Active Directory Administrative Accounts and Security Groups is of utmost importance, because the compromise of a single such Active Directory privileged user account or security group could instantly result in the compromise of the entire Active Directory.


4. Administrative Workstations used by Active Directory Administrative Personnel - The protection of all computers used by all Active Directory administrative/privileged users is of equal importance as well, since their compromise could be used to have malicious code designed to compromise Active Directory, be easily executed in a privileged context.


5. Administrative Delegations / Ocean of Security Permissions in Active Directory - The need to ensure that all administrative delegations done in Active Directory and all access provisioned in Active Directory adhere to the principle of least privilege, is also of utmost importance, as even a single excessive/unauthorized delegation / security permission could give instantly perpetrators the opportunity to easily gain complete command and control over Active Directory.

Since Microsoft's Active Directory Security guidance adequately covers speaking about #1, #2 and #4 above, in the remainder of this post, we will focus on certain aspects of #3 and an overview of #5, especially considering that Active Directory ACLs are rapidly and increasingly becoming the focus of topics like Persistence in Active Directory, and being targeted by amateur pen-testing tools like BloodHound (which incidentally is substantially inaccurate) and other such Active Directory ACL analysis tools.

Speaking of the Attack Vectors to Active Directory Administrative/Privileged Accounts and Security Groups

It is a well known fact by know that Active Directory administrative (privileged) domain accounts (and groups) are target #1 for perpetrators, (because their compromise instantly provides domain-wide root access,) as evidenced by the fact that 100% of all major recent cyber security breaches involved the compromise and misuse of an Active Directory privileged user account.

Speaking of Active Directory administrative accounts and groups, there are 5 main attack vectors that are commonly used to try and compromise them -

1. Credential guessing - This is an archaic approach that is seldom employed today because it is easily thwarted by the presence of simple security measures like domain account lockout security policies.


2. Credential theft and re-use - This has recently been the predominant approach, and includes techniques like Pass-the-Hash (PtH) etc., most of which are becoming harder to enact as Microsoft improves the security of its operating systems and organizations employ various solutions to combat the use, efficacy and success rate of these attack vectors.
   
   Mass credential-theft, enabled by the Mimikatz DCSync remains a very serious threat, but can today be easily thwarted.


3. User Impersonation - This approach primarily involves leveraging Kerberos delegation, wherein a service trusted for (Kerberos) delegation could impersonate a client, and in cases where the client happens to be an Active Directory administrative user or service account, the service could effectively then be impersonate the client across the network.  


4. Credential change (/reset) - This simple approach involves measures aimed affecting a change in a user's credentials, and the primary technique involves simply resetting the user's password, a legitimate administrative task that can be enacted most easily as long as one has sufficient privileges (i.e. effective permissions) to be able to do so.


5. Entitlement misuse - As it pertains to administrative accounts and groups, this simple approach involves resetting user account passwords and/or modifying an administrative group's membership, legitimate administrative tasks that can be enacted most easily as long as one has sufficient privileges (i.e. effective permissions) to enact them. This is likely going to be the next predominant approach as perpetrators have started focusing their attention within Active Directory.

Of the 5 ways listed, #4 and #5 are most relevant today. Speaking of #4 and #5, i.e. credential change and entitlement misuse, consider that any individual who could enact any of the following tasks could instantly obtain admin access in Active Directory -

1. Reset the password of any Active Directory administrative domain user account


2. Modify the membership of any Active Directory administrative domain security group


3. Modify the permissions protecting any Active Directory administrative domain user account


4. Modify the permissions protecting any Active Directory administrative domain security group


5. Modify the permissions protecting any Active Directory Organizational Unit in which a non-default administrative domain user account or domain security group resides (and there could easily be hundreds of such accounts in Active Directory.)

Again, suffice it to say that anyone who can enact any of the tasks above can instantly gain admin access over Active Directory.

Unfortunately, in most Active Directory deployments today, password resets and entitlement misuse remain the #1 real threat, as no one seems to have any clue as to exactly who can enact any of these simple administrative tasks, and as a consequence, most organizations are operating in the dark today.

There are two simple reasons for this - 1) Most organizations have yet to even start giving thought to this remarkably simple attack vector, and 2) of those that may have, most organizations do not know how to correctly analyze permissions on Active Directory objects, which is essential to making these simple yet paramount determinations.

Specifically, they may not know yet that what matters when making these determinations is not "who has what permissions in Active Directory", but "who has what effective permissions in Active Directory", and most simply stated, the difference between the two could be the difference between compromise and security!

Thus, when speaking of the Active Directory attack surface, the protection of admin accounts and groups, albeit vital, remains a weak area, and if left unaddressed, could leave the door WIDE open for perpetrators to gain admin access in Active Directory.

In days to come, I will be sharing a substantial amount of additional detail on this, so anyone interested may want to stay tuned.

The Largest Component of the Active Directory Attack Surface -
Administrative Delegations / Security Permissions

One could easily write a book on this single subject (and Microsoft, as you know, I actually did write a 400-page one on it, titled Microsoft's Best Practices for Delegating Active Directory Administration), yet this is the one area that unfortunately still remains largely unaddressed, and thus provides an OCEAN of opportunities for perpetrators to compromise organizational security.

You see, the most important part of Active Directory is its content, i.e. thousands of domain user accounts, computer accounts, security groups, group policies etc., which are the very building blocks of IT and cyber security today, and the entirety of this content is protected by thousands of access control lists (ACLs), within which lie millions of access control entries ACEs) that together (and not individually/separately) specify who has what permissions on these objects, AND it is this ocean of security permissions that exists within each Active Directory that together ultimately determines the true effective access provisioned in/across Active Directory, and today it comprises the vastest component of the Active Directory attack surface.

Putting it most simply, in addition to the default administrative accounts and groups that exist in Active Directory, and the default permissions that have been provisioned for them, over the years an extensive amount of administrative delegation and/or access provisioning has been done in most Active Directory deployments to fulfill various business needs, and as a result, today substantially many more than just the default administrative accounts and groups have all kinds of access provisioned in the Active Directory, yet no one knows exactly who actually (i.e. effectively) has what access and where in Active Directory.

Want the simplest example? Look no further than Mimikatz DCSync - by default only certain default admin groups have the Get-Replication-Changes-All extended right effectively granted on the domain root. However, a single intended (or unintended) administrative delegation / provisioned access could instantly end up granting this right to who knows how many individuals, and as a consequence, the accounts of any one of them could be used to compromise everyone's credentials within minutes!

It could have been something as simple as an admin trying to provision a single specific permission in Active Directory - Allow All Extended Rights on Descendant objects only on the domain root object, but accidentally ended up provisioning this - Allow All Extended Rights on This object and all descendant objects. Right there, in that one accidental mistake, one could jeopardize the entire organization's security! And this is merely one example. I could give you hundreds of such examples, wherein a single accidental or intentional misconfiguration of Active Directory security permissions could result in the existence of a HUGE hole.

Considering that by default Active Directory grants Authenticated Users blanket read access across Active Directory, literally anyone who knows anything about Active Directory security can use mere authenticated user access to analyze this ocean of security permissions and find thousands of vulnerabilities and privilege escalation paths, which can be easily exploited to inflict damage, and in many cases easily escalate privilege to that of a Domain Admin equivalent account.

In fact, the recently introduced BloodHound penetration testing tool leverages this exact authenticated user access to attempt to make this determination. Unfortunately, it is substantially inaccurate because it makes the same classic mistake that so many IT professionals in the world do i.e. it simply attempts to try and determine "who has what permissions" instead of trying to determine "who has what effective permissions" in Active Directory. (More on this tool's ludicrous inaccuracy in days to come.)

More pertinently, as evidenced by the emergence of such tooling, as Microsoft finally makes progress towards making most of today's predominant hacking/compromise avenues/attack vectors (e.g. Pass-the-Hash etc.) much more difficult to carry out, hackers seem to be rapidly shifting their focus, effort and attention on trying to learn more about and finding ways to exploit any weakness they can find in this ocean of Active Directory security permissions (and there are thousands to be found today.)

In essence, in virtually every foundational Active Directory deployment in the world, this vast ocean of security permissions in Active Directory presents a vulnerable attack surface the size of the Pacific ocean, and in light of the above, this worries us.

So, in days to come, I will be also sharing a substantial amount of detail on this, so anyone interested may want to tune in.

In Summary

To summarize, today I just wanted to help Microsoft and the world better understand what constitutes the Active Directory attack surface, and where organizations should really be focusing their energies if they truly want to protect their foundational Active Directory deployments (because as BloodHound, Mimikatz DCSync etc. show us, that is likely the next wave perpetrators are going to be focused on in the near future; apparently they're still learning, so there is still a little time before the tsunami hits.)

Alright then, that'll be it for today.

Best wishes,
Sanjay


PS: Dear Microsoft, consider this - in light of what I have shared above, the best you've got is baby tools like dsacls, acldiag, an (inaccurate and inadequate) Effective Permissions Tab, PowerShell etc. and you've given the world nothing in this area during the last entire decade, not even guidance, which is what prompted me to say this and ask this. Organizations trying to reduce (i.e. identify, lock-down and protect) the vastest part of their Active Directory attack surface (described above) with your native tools (or with any one of numerous woefully inadequate "Active Directory permissions audit" solutions out there) is like someone trying to accomplish a herculean task, one that actually requires Iron Man's skills and intellectual depth, but has to make do with Donald's (no not this one's, this one's) instead.