An Ocean of Access Privileges in Active Directory Deployments (Day 8)

Folks,

Today is Day-8 of our Active Directory security school for Microsoft. I was going to talk about effective permissions today, but perhaps I should shed light on the ocean of access privileges that lies within Active Directory deployments worldwide today.


An Ocean of Access Privileges within Active Directory Deployments Worldwide

In virtually every Active Directory deployment in the world today, irrespective of its size (small or big), the entirety of its content i.e. the thousands of objects that reside within each Active Directory deployment, is protected by an ocean of access privileges.

Specifically, each object in Active Directory is protected by a unique Windows security descriptor, which contains amongst other components, an access control list (ACL) which is comprised of numerous access control entries (ACEs), each one of which serves to Allow or Deny a specific type of access (of which there are a dozen types) for a specific security principal, and together i.e. collectively (, and not individually) it is this entire set of security permissions specified in an Active Directory object's ACL that determine the actual (i.e. resulting/effective) access that is authorized on each one of these Active Directory objects.


For instance here is the ACL protecting the domain user account of the CEO of a fictional multi-billion dollar organization -

The ACL on the CEO's Domain User Account  

(To view the ACL (generated via this tool) click here.)

As you can see, there are numerous security permissions that specify various types of access, some of which Allow access and some of which Deny access, and of these, some are explicitly specified while others are inherited from parent objects, and while some specify access for individual users, others specify access for security groups and well-known security principals. Further while most of these might actually be applicable on the object some may exist only to be inherited downstream to child objects.

In a typical Active Directory domain, in these ACLs, access privileges, of which there are a dozen generic Active Directory security permissions and over five dozen special security permissions (extended rights), are specified for 100s if not 1000s of unique domain security groups, domain user accounts, domain computer accounts and various well-known security principals.

Further, in many Active Directory deployments worldwide, there are easily over 100 security permissions (ACEs) specified in the ACL of each Active Directory object, and there are easily 10s of 1000s of objects in Active Directory, and consequently today there likely exist millions of security permissions in most Active Directory deployments.

Here's what 0.001% of this ocean of security permissions in an Active Directory domain actually looks like - here.

(At one of our customers, one of their Active Directory domains had 100,000+ objects and 250+ ACEs in each object's ACL.)

In other words, as you can see, in each Active Directory deployment there is an ocean of access privileges today, and it is this ocean of access privileges that together controls and governs who ultimately has what access on everything in Active Directory, including who ultimately has privileged access (the Keys to the Kingdom), in these foundational Active Directory deployments.




In this Ocean Lie the Answers

In order to be able to answer even one (1) of the following paramount cyber security questions, organizations must be able to accurately determine "who has what effective permissions" in this ocean of access privileges that lies in their Active Directory -

1. Exactly how many privileged users are there in an organization’s Active Directory?
2. Exactly how many privileged security groups are there in an organization’s Active Directory?
3. Exactly who can reset the password of a privileged user to elevate privilege in an organization’s Active Directory?
4. Exactly who can modify the group membership of a privileged security group to elevate privilege in Active Directory?
5. Exactly who can create, delete and manage user accounts, computer accounts, groups, OUs etc. in Active Directory?
6. Exactly who can compromise the credentials of all accounts by using Mimikatz DCSync ?
7. Exactly who manage the domain user accounts of the organization’s executives (Chairman, CEO, CFO, CIO, VPs etc.)?
8. If Smartcard authentication or similar measures (i.e. band-aids) are in use, exactly who can instantly disable them?

The operative and paramount word here is "effective permissions" i.e. to be able to answer these questions, one must be able to accurately determine "who has what effective permissions" not "who has what permissions" in and across Active Directory.

More on that in days to come.

Best wishes,
Sanjay


PS: I'm going to try and keep these posts short and to the point from now on.

Lack of Gravitas at Organizations + Risks of Amateur Tooling (Day 7)

Folks,

If you review what I've shared thus far on Active Directory Security, you may likely see why I believe that Microsoft may have completely missed out, for over a decade, on educating the world about what clearly is such a vital aspect of cyber security.

However, in Microsoft's slight defense, I'd also like to add that organizations and amateur vendors are partly responsible too.



In Ever So Slight Defense of Microsoft

First and foremost, I would like everyone to know that I love and care deeply for Microsoft, (and have many friends at Microsoft,) which is the only reason that I am spending so much effort on helping Microsoft and the world understand all this important stuff.

As I indicated on Day-0, the sole objective of conducting this school for Microsoft is because they completely missed out on educating their customers about the importance of "Effective Permissions" to Active Directory security for an entire decade.

In support, I provided irrefutable proof: Top-3 official/primary sources of guidance from Microsoft on Active Directory security -

1. Microsoft's original 100+ page official Best Practice Guide for Securing Active Directory (Part I) and Part II

2. Microsoft's latest official Best Practices for Securing Active Directory guidance, introduced by Microsoft's CISO

3. Microsoft's latest 5+ hour series of 12+ videos on Defending Active Directory Against Cyber Attacks

As of Jan 26, 2017 (and likely even today), if you did even a simple keyword search for the term "effective permissions" across these 3 official authoritative sources of guidance from Microsoft, you'll find 0 instances of the term "effective permissions."

Zero!      нуль, nul, صفر , 零,Null, μηδέν, ʻole, אֶפֶס , शून्य, ゼロ,제로, nihil, sero !

In all likelihood, if you were to additionally review 10+ years worth of Microsoft TechEd presentations, i.e. a 1000+ of them, presented by Microsoft and other industry experts, again you may likely find virtually zero mention of "effective permissions."

In light of these facts, as hard as I try, it is very difficult for me to defend Microsoft's complete ignorance on the subject.


That said, if I had to try, I would probably have said the following -

If I were still at Microsoft, in its defense I would probably have said - "generally speaking, at Microsoft our primary charter is to make BIG, lasting changes, such as embracing the Cloud, and of course helping safeguard our customers from serious risks to their security (e.g. combating credential-theft attacks.) It does appear though that, for whatever reason, one such serious risk (illustrated here) may not have been on our radar all this while, and we will begin by looking into how and why we may have systemically and completely forgotten to educate our customers about it, for an entire decade.

(Most of my friends at Microsoft would agree that at the very least Microsoft should have adequately educated its customers.)

After all, for Microsoft to have completely missed providing any guidance on such a vital security topic for more than a decade, more than a few folks would've had to have missed this / not gotten it (at all) - several folks on the Product Development Team, Security Business Unit, Microsoft Research, Trustworthy Computing Group, MCS, PSS, MS IT and others, but we'll let it go and focus on helping them get it.

Moving on to...




Lack of Gravitas at Organizations

Microsoft may not be entirely responsible for a global lack of understanding on such a fundamental aspect of cyber security.

Over the last decade, at Paramount Defenses, we've had an opportunity to learn a lot about several thousand organizations, all of whom knocked at our doors unsolicited, and if there is one commonality we've found, it is that most organizations seem to lack gravitas and the depth of knowledge required to adequately protect their foundational Active Directory deployments.

IT Personnel at Organizations

We could share stories many almost unbelievable stories with you, and we're talking about so many of the biggest organizations in the world, but we will never do that because we're professionals. I will just leave it at saying that at the end of the day, based on what we have seen thus far, there are 3 aspects that organizations seem to lack (to varying degrees) -

1. First and foremost, the understanding that if their Active Directory is compromised, the very foundation of their cyber security is compromised and thus that the very fabric of trust across their network would have been pierced.


2. Secondly and as a consequence, (the fact that) adequate protection of foundational Active Directory deployments may not even be on their radar, let alone it being one of the top (and adequately funded) cyber security priorities today.


3. Lastly, at many organizations, IT groups/departments seem to lack the depth of knowledge as well as the expertise required to adequately protect their foundational Active Directory deployments.

Given that Microsoft's documentation at least unequivocally states the value and importance of adequately protecting Active Directory, in light of the above 3 points, it appears that perhaps organizations may likely also be partly responsible -

Quoting Bret Arsenault, Microsoft’s CISO from the Foreward of Microsoft's official whitepaper on Active Directory Security – “Active Directory plays a critical role in the IT infrastructure, and ensures the harmony and security of different network resources in a global, interconnected environment.”

How much clearer could Microsoft have been than the CISO of Microsoft Corporation stating the above?

Sadly, the reality on the ground today is that so many organizations worldwide do not yet seem to be taking the security of their foundational Active Directory deployments as seriously as they should, and thus may not even know what the attack surface is, what the top Active Directory security risks are, what the easiest avenues to compromise may be, how colossal the impact of an Active Directory security breach could be, what risk mitigation measures they should be enacting to protect Active Directory etc.

Here's super simple evidence - Each week we get to speak to Domain Admin equivalent IT personnel from many organizations across the world, and in many cases, they just do not seem to know what effective permissions in Active Directory are.

I must ask this with complete respect - "Realistically speaking, if Domain Admins at such prominent business and government organizations do not even seem to what effective permissions are, how can these organizations protect their foundational Active Directory deployments?" (No, we're not talking about Mom and Pop Stores, we are talking about multi-billion $ organizations.)





Lastly, Risks of Amateur Tooling (From Amateur Vendors)

The one other thing I will add is that the presence of amateur vendors in the Active Directory security space worries us, because they may be worsening the situation. I say that because not only may their solutions actually be exposing organizations to far greater security risks, their misleading marketing may be giving customers a false sense of security, and that's dangerous.

Sales Associate at Amateur Vendor

Allow me to explain. We know of several vendors in the Active Directory Security space that offer very basic Active Directory reporting/management solutions. If you look into whose behind them, you'll find that many of them are built by puny companies in developing countries by mostly amateur developers, which makes you wonder how reliable and secure their solutions might be. Some of them are outright inaccurate and many of them are not even digitally signed, and they are being sold to and being used by Domain Admin equivalent IT personnel at multi-billion dollar business and government organizations across the world.

Further, more concerning is that fact that many of them are required to be run either as System on Domain Controllers or in highly elevated security contexts such as Domain Admin! Specifically, many of them require organizations to add the service account being used by that solution to the membership of the Domain Admins group.

Code

That, in our professional opinion, is a serious risk, because in essence you have potentially untrustworthy code that isn't even digitally signed, written by amateur developers, with its codebase residing who knows where, running as System on DCs or as Domain Admin at thousands of prominent business and government organizations in the United States, Europe and far beyond!

Think about it. If a nefarious entity or an APT were to be able to compromise even one of these vendors and acquire the ability to tamper with their code-base, it could very quickly completely compromise hundreds, if not thousands of organizations!

This also raises the question as to who at these organizations is authorizing the deployment of a solution to be run as System on DCs or as an Domain/Enterprise Admin, when it is not even digitally signed, i.e. that's trustworthiness evaluation 101.


Finally, there is the part about misleading marketing giving customers a false sense of security, elaborated below.

There are several vendors that offer very basic Active Directory Permissions Audit solutions (i.e. basically well-presented Active Directory ACL dumps) that are substantially inadequate if what you're trying to do is audit privileged access in Active Directory.

Yet, their marketing verbiage (both on-site and in advertisements displayed on Google, Bing etc.) misleads organizations into believing that their products are sufficiently capable of getting the job done, and because these customers don't know better (because Microsoft has never talked about Effective Permissions), they end up acquiring these solution to perform basic Active Directory permissions audits, which obviously provide them with a substantially misleading picture, as a result of which they end up making highly sensitive access-control decisions based on inaccurate data, and in doing so, from that point on, they end up operating on a false sense of security.

Should you like to see what I'm talking about for yourself, simply click here, or Google Active Directory Permissions Audit.

In contrast, technically speaking there is only one correct way to audit privileged access in Active Directory - this.

In fact, one of these solutions is so inaccurate that (to paint you a picture) if it were a security scanner being used at an airport, let alone boarding the flight, we would get out of the airport immediately. The shocking part is that not only does its vendor not know that its not accurate, they've actually spent some marketing dollars to get coverage in a few publications, and of course the publications ran with it, so now you have a vendor that has an inaccurate solution that is also vouched for by small-time publications, and how many IT personnel do you think actually have the expertise to evaluate its accuracy? They'll just see the endorsement from a publication, give it a second's thought, and run with it, and in doing so will have jeopardized their security.

In short, the availability of misleading and potentially low-assurance solutions from many puny vendors does not help security.




Wrapping It Up

Alright, I've said enough today. The point is that Microsoft alone may not be entirely to call out for the fact that 99% of the world has no clue that there's likely a security hole the size of the Pacific Ocean in their foundational Active Directory deployments.

Organizations too likely bear some responsibility for being deep in the dark, especially given that so many of them have been operating on Active Directory for years. Lastly, vendors with misleading marketing and products don't help the situation either.

Next post onwards, we'll get objective and technical and dive into some serious Active Directory security internals.

Best,
Sanjay


PS: The objective of this is to help Microsoft get the importance of effective permissions/access to Active Directory security, so that they in turn can help their global customer base understand the sheer vitality of this essential cyber security capability.

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