How to Discover Stealthy Admins in Active Directory

Folks,

Today, I wanted to take a few minutes to share how organizations worldwide can discover stealthy admins in Active Directory.

This is part II of the post - How to Discover Stealthy Admins in Active Directory.




A Quick Intro

Lately Active Directory Security seems to have been getting a lot of attention from traditional network security / hacking / cyber security folks, both, on the good side and the not-so-good side. Many of them may be relatively new to the subject of Active Directory Security, and most of them seem to be primarily interested in identifying privileged users in Active Directory.

Interestingly, perhaps because they may be new to this ocean of a subject, they may have started referring to delegated admins in Active Directory as Stealthy Admins, perhaps because they may not be aware of the concept of access provisioning and administrative delegation in Active Directory, even though both these concepts have been around for 17 years now.

If you want to know what I think of the term Stealthy Admins, you can read my last post on this topic ;-)

Anyway, to help these folks, and anyone else who might be interested in discovering "Stealthy Admins in Active Directory", I thought I'd help them understand what it actually takes to correctly make this determination in Active Directory deployments.






A Quick Primer

It is no secret that in IT infrastructures that are powered by Microsoft Windows Server, the proverbial "Keys to the Kingdom" lie in Active Directory. Specifically, the most powerful administrative/privileged domain security groups (e.g. Domain Admins), as well as the domain user accounts of all their members are all stored, protected and managed in Active Directory.

Now, if you were to ask a novice for advice on how to identify privileged users in an Active Directory, he/she will most likely tell you that all you would have to do is identify all those domain security groups that Microsoft says are privileged in nature, and then enumerate the complete membership of these domain security groups, and that's it i.e. you should be done!

Interestingly, would you be surprised if I shared with you that a majority of all organizations worldwide, when asked to furnish a list of privileged users in their Active Directory deployments (to demonstrate regulatory compliance that is), do exactly this!

In reality, if you follow the advice above, you would have merely uncovered the Tip of the Iceberg, because in reality, in most organizations, there exist a FAR greater number of privileged users than do the members of the default AD admin groups.






A Quick Question

To understand where Stealthy Admins come from in Active Directory, let us ask ourselves a quick very simple question.

Assumption: For illustrative purposes, let us assume for a moment, that there is only one default administrative/privileged group in Active Directory - the Domain Admins security group.

Here's the Domain Admins group, and the question is below -

As you can see above, there are only 2 members in the Domain Admins group.

The Question - Based on the above, can we assume that this organization only has 2 privileged users in their Active Directory? i.e. there are only 2 accounts that possess privileged access in this Active Directory - 1) the default Administrator account, and 2) the domain user account of the user Steve Ballmer, as that is what the membership of the Domain Admins group indicates?

Side Note: Would you be surprised if I told that (considering the assumption we've made above) most organizations would just report this as the number or privileged users in Active Directory?!

To answer this question, let us consider the following.




Consider This

Consider the impact of someone being able to perform the following administrative tasks in Active Directory -

1. Change the membership of the Domain Admins group


2. Reset the password of the domain user account of a member of the Domain Admins group


3. Change the permissions on the Domain Admins group, or on the account of any of its members


4. Change the ownership of the Domain Admins group, or on the account of any of its members

The above is most certainly not an exhaustive list of such administrative tasks, but merely a handful of such administrative tasks that can be enacted on Active Directory content, by anyone that has sufficient effective access to be able to do so.

Note: At this point, to advanced users, AdminSDHolder may come to mind. I would encourage them to read this advanced post on AdminSDHolder, and if you want to know how little even Microsoft seems to know, this one too.

Specifically, consider this -

Although in the illustrative example above, the Domain Admins group only has 2 members, shouldn't everyone who can change its membership also be considered a Domain Admin? After all, anyone who could do so could easily and instantly add his/her own account, or that of anyone he/she likes, to the group, as well as take the existing members out of the group!

Similarly, in the illustrative example above, although we only have 2 accounts that are members of the Domain Admins group, shouldn't everyone who can reset the password of any of these accounts also be considered a Domain Admin? After all, anyone who could do so could easily reset the password of these admin accounts, and instantly logon as them!

By the same token, anyone that can change the permissions or the ownership of any one of these default administrative groups or accounts should also be considered to be a privileged user possessing the same level of privilege, because he/she could easily modify the permissions on these objects to grant themselves or anyone else the same level of administrative privilege!




The Answer (to the Question)

In light of what we just considered above, hopefully it should now be clear that to accurately identify privileged users in Active Directory, in addition to enumerating the members of the default administrative/privileged security groups in Active Directory, at the very least, we should also be determining and including exactly -

1. Who can change the membership of every single domain security group (as well as any domain security groups nested in it) in Active Directory that is considered administrative/privileged in nature? 


2. Who can reset the password of every single domain user account that is a member of a domain security group that is considered to be administrative/privileged in nature?


3. Who can modify the security permissions and/or the ownership of every single domain security group and domain user account that is considered to be administrative/privileged in nature?

It must be noted that the keyword here is "at the very least." I say so because there could additionally easily be a specific domain user account or a domain security group that may not be a member of any default privileged group in Active Directory yet be directly be granted access in Active Directory that is tantamount to possessing privileged access in Active Directory!


Now, in case you're wondering - "But how does someone get the ability to change group memberships, reset passwords, etc?!"






Delegation of Administration in Active Directory

This brings us to one of the most powerful, capable, valuable and frequently-used features/strengths of Active Directory - Administrative Delegation. Delegation of administration is a capability that lets organizations distribute and delegate administrative authority for various aspects of identity and access management amongst a large group of IT personnel.

Its premise is simple - since it may be infeasible for a handful of highly privileged Domain Admins to manage thousands of objects in AD, wouldn't it be helpful if organizations could delegate/distribute administrative authority for identity and access management tasks amongst a larger group of IT personnel, who need not posses Domain Admin equivalent privileges!

Delegation of administration lets organizations delegate administrative authority in Active Directory and do so with precision -

In fact, over the last 17 years, there possibly might have been billions of administrative delegations / access provisioning(s) done in Active Directory domains, across Active Directory deployments worldwide.

Incidentally, I only know this because I happened to have authored Microsoft's 400-page whitepaper on the subject back in 2004 titled "Best Practices for Delegating Administration in Active Directory". The appendices of that whitepaper in itself were a treasure trove of knowledge on the subject. Amazingly, that whitepaper's nowhere to be found on microsoft.com these days!

Now, this is a very complicated subject (considering that it required a 400-page whitepaper to cover) so I'm not going to go into too many details here. Instead, I just wanted to share with you how IT personnel end up getting sufficient privileges in Active Directory so as to be able to enact common administrative tasks such as group membership changes, password resets etc.

The short of it is that when a task is delegated to a specific security principal, such as a domain security group, the security permissions required to perform the technical LDAP operation that corresponds to that task on a given type of object, are provisioned in Active Directory, thereby enabling all members of that group to be able to enact that task.

For example, when a domain security group such as IT Operations Support Level 1 is delegated the administrative task "Modify the membership of a group" in a specific organizational unit (OU), the following security permissions are added to the ACL of every domain security group in that OU -  { Allow   IT Operations Support Level 2    Write-Property   Member }

Similarly, when a domain security group such as IT Operations Support Level 2 is delegated the administrative task "Reset user passwords" in a specific OU, the following security permissions are added to the ACL of every domain user account in that OU -  { Allow   IT Operations Support Level 3    Extended Right   Reset Password (User-Force-Change-Password) }

By the same token, when a domain security group such as IT Contractors is to be denied the ability to enact a specific admin task, such as "Reset user passwords" in a specific OU, the following security permissions are added to the ACL of every domain user account in that OU -  { Deny   IT Contractors    Extended Right   Reset Password (User-Force-Change-Password) }

Note: The above is a highly simplified description of how this all works. Of course, there are many subtle yet vital details such as precedence orders which govern which security permissions (amongst numerous allows and denies) eventually prevail, and what access a user actually (i.e. effectively) ends up getting. More on that here. 

Aha! It is all such domain user accounts for whom access may either have been delegated or provisioned on these default admins groups and accounts, and numerous other objects, that are being referred to by these novices as "Stealthy Admins" !



Okay, with this boring theory out of the way, let's find out how to correctly
identify these Stealthy Accounts in Active Directory, shall we?! ...






How to Correctly Discover Stealthy Admins in Active Directory

If you know the subject well, then you know that in order to correctly determine stealthy admins in Active Directory, you need the ability to be able to determine effective permissions / effective access in Active Directory.

If you don't know the subject well enough, then perhaps you may (errantly) believe that simply performing an Active Directory permissions audit to find out "Who has what permissions in Active Directory" would be sufficient. However, you'd be wrong.

Here's why -

If by "Stealthy Admins" one is referring to individuals who possess the ability to enact administrative tasks such as being able to change a domain security group's membership or reset a domain user account's password, or modify the permissions or ownership on an Active Directory object, then the only correct way to identify the identities of all such individuals who can enact these administrative tasks, is to accurately determine effective permissions / effective access on Active Directory objects.

I am not going to be spending any more time helping the world understand what Active Directory Effective Permissions are and why they're so important, so if you want to know more about them, you can read this post, which I highly recommend reading.


Okay, that said, let me actually show this to you, and to do so,
lets continue with that question we asked above...


So, here's the ACL (access control list) protecting the Domain Admins security group -

We have already seen above that is has only 2 members. However, what we should also be wanting to know is exactly how many individuals can enact the administrative task of "changing the group membership" of the Domain Admins group.

As seen above, there are many ACEs in the ACL of the Domain Admins group, each one allowing or denying a specific security principal (user, group, well-known SID or a foreign security principal) various specific Active Directory security permissions.

Now, technically, to find out who can change the group's membership, what we need to do is find out exactly who has sufficient Write Property - Member effective permissions, which is what's needed to be able to modify the Member attribute of this object.


That said, let me show you the only way that I know how to accurately do so -


I launch this tool, use its inbuilt search utility to find and point the tool to the Domain Admins group, and click a button -

In a matter of seconds, the tool accurately determines the complete set of effective permissions that are granted on this Active Directory object, and shows me the results in a most intuitive manner.

Note: At this point, to some, Microsoft' Effective Permissions Tab may come to mind. To find out why it is not only inaccurate but also substantially inadequate, you'll want to read this. To others this tool may come to mind - allow me to share with you that that tool is dangerously inaccurate, even though its developers may not know it. For those to whom tools like dsacls, acldiag, or any one of various Active Directory Permissions Analyzers come to mind, you'll want to read this to learn about why not a single one of them can get the job done.

As can be seen in the snapshot above, we have just identified that although the Domain Admins security group itself has only 2 members in it, there are in fact 11 individuals who can change its membership, including one sneaky persistent bad guy!

From just that one report, the actual number of privileged users just increased by 500%  i.e. went from 2 to 11!

Similarly, the tool can show exactly who has sufficient Modify Permissions and Modify Owner effective permissions on this Active Directory object, and to determine the actual number of privileged users, you'll want to include their identities as well.

Now, because that tool is a Active Directory effective permissions calculator (and in fact the world's only accurate one), it is primarily designed for Active Directory admins and Active Directory security professionals, and thus it determines and delivers its results in terms of effective permissions. However, there might be many individuals, such as IT Auditors, IT Managers, Cyber Security Risk Assessors and others in similar roles who may not be experts in Active Directory Security, and thus may not know technical details such as effective permissions to task mappings etc., yet may have a need to make such determinations.

For all such individuals, we built this tool to help them make the same exact determination -

In contrast to the previous tool, this tool's inbuilt intelligence can not just determine effective permissions, it can additionally also determine effective access in Active Directory, and as a result, it can show you who can actually do what in Active Directory, in plain English i.e. in terms of administrative tasks, eliminating the need for you to know anything at all about Active Directory.

As seen in the snapshot above, this tool's results too indicate that there are a total of 11 individuals who can enact the administrative task of being able to change the membership of the Domain Admins group!


In this manner, within a matter of seconds, today everyone can find out exactly who can enact administrative tasks such as being able to modify a privileged security group's membership, and thus uncover "stealthy admins" in Active Directory!



Now, let me show you another example -


Let us assume that a user, say a Jeff  Bezos, is the only member of the Enterprise Admins group in Active Directory.

Since he is a member of the Enterprise Admins group, he is obviously considered a privileged user.

Now, hopefully you'll agree that since he is a privileged user, anyone who can reset his password should also be considered to be a privileged user since he/she is merely one mouse-click away from becoming an Enterprise Admin, so shouldn't we also be determining exactly who can reset his password?!

Note: Now, in case his account might be Smartcard-enabled, all you'd have to do is find out who can turn off the "Smartcard required for logon" requirement AS WELL AS reset his password, and that much should suffice!

So, let's find out exactly who can reset this Jeff Bezos' password, shall we -

We click a button, have a sip of coffee, and lo and behold, we've just uncovered that a total of 30 individuals have sufficient effective permissions / effective access on his domain user account, so as to be able to reset Jeff Bezos's password!

Think about it - even though in this fictional organization, there was only 1 Enterprise Admin i.e. only 1 user who was a member of the Enterprise Admins group, we just discovered that there are 30 individuals who can reset his password (whenever they want) and thus be him whenever they want!  






How to Audit Specific Stealthy Access in Active Directory

Again, if by "Stealthy Admins" / "Stealthy Access", they're referring to "Delegated Admins" / "Delegated Access", then here are step-by-step directions on how folks worldwide can audit for specific stealthy access in Active Directory -

1. How to Correctly Audit Who can Create User Accounts in Active Directory


2. How to Correctly Audit Who can Change Group Memberships in Active Directory


3. How to Correctly Audit Who can Delete Organizational Units in Active Directory


4. How to Correctly Audit Who can Reset Passwords in Active Directory


5. How to Correctly Audit Who can Change Service Connection Points in Active Directory

While you're on the subject, you may also want to find out how to correctly perform an Active Directory Privileged User Audit.






Scaling It Up!

Now, let's assume that you have thousands of domain user accounts, domain security groups, domain computer accounts, organizational units, service connection points etc. etc. in your Active Directory.

Technically speaking, if you truly want to uncover all "Stealthy Admins" in Active Directory, wouldn't you want to know exactly who can reset the passwords of all the domain user accounts in Active Directory, who can change the membership of all the domain security groups in your Active Directory, who can change the security permissions protecting all Active Directory objects in the domain etc. etc. For example, how about knowing exactly who can reset the CEO's domain user account's password?

Well, if the answer is YES, then you're basically looking at determining effective permissions on thousands of objects in your Active Directory. Now, even if you had the capability to determine effective permissions / access on a single Active Directory by clicking just one button, you'd still have to click a button thousands of times.

That doesn't sound like too much, fun does it, not to mention that it could take weeks to do so. Of course, if you don't even have the capability to determine effective permissions one object at a time, you could easily be looking at months, if not years to make these determinations.

Well, wouldn't it be nice if someone could make this as easy as touching a button?

You know, something like this -

If you can click a button, now you can immediately and of course accurately uncover every single "Stealthy Admin" in your Active Directory, whether you have a few hundred or a few hundred thousand objects in your Active Directory.

For a complete list of all the administrative tasks that you can audit with this tool, please click here.

To novices that might sound easy; if you want to know how difficult this is, you'll want to find an Active Directory security expert, one who has spent years on Active Directory Security, and has thousands of hours of experience in trying to determine effective permissions on various Active Directory objects, and perhaps he/she could help you appreciate just how difficult this is.

Those who truly understand Active Directory Security know that building such a tool is on par with scaling Mount Everest. Then there are some who claim to offer free tooling that could help identify stealthy admins in Active Directory ;-)  Little do they realize that in doing so, they may actually be showing the world just how little they may seem to know about Active Directory Security.





Summary

In today's post, I wanted to help folks understand that what some may refer to as "Stealthy Admins", are merely either delegated admins in Active Directory or IT personnel for whom various levels of access may have been provisioned in Active Directory.

Having said that, I also wanted to show you how to identify these delegated admins, which in line with the title of the post, perhaps we could play along and continue to call "Stealthy Admins in Active Directory."

I also wanted to share with the simple fact that in order to discover stealthy admins in Active Directory, what we need to do is to be able to accurately determine effective permissions on Active Directory objects.

Oh, and I also wanted to convey that when organizations audit privileged users in Active Directory, it is not sufficient to merely include the members of the default Active Directory administrative groups. You also need to include the identities of all such users who possess sufficient effective access in Active Directory so as to be able to modify the memberships of these groups, reset the passwords of all their members, change the security permissions protecting these groups and accounts etc.

If you want to know how to do this correctly, you'll want to read - How to correctly identify privileged users in Active Directory.

Finally, I wanted to demonstrate all of this with two simple illustrative examples, one involving identifying who can change the membership of the Domain Admins group, and one involving identifying who can reset the password of an Enterprise Admin.

That's all for today. Next post onwards, we'll get back on track and
proceed to finish Active Directory Security School for Microsoft.

Best wishes,
Sanjay 

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

Dear Mark,

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

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

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




So, I'd like to ask 1 Question

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

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

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

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


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

Most respectfully,
Sanjay

CEO, Paramount Defenses


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

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

1. What Constitutes a Privileged User in Active Directory?

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

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

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

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

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

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

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

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

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

In short, the answer is (something like) this -

Ans: To do so, all that organizations need to do is to accurately and adequately determine e******** p**********/a***** on their Active Directory objects. That's it.

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

Folks,

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

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




Trillion $ Background

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

Active Directory is the Foundation of Cyber Security Worldwide

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

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



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

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

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

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

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




Some Love for Microsoft

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

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

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

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





Er, What Cyber Security Challenge?

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

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

"From Silicon Valley to New York and London to Sydney, at the very foundation of cyber security and IT of 85+% of all business and government organizations across 190+ countries worldwide lies Microsoft's Active Directory.

Within the foundational Active Directory domains of these organization lie the entirety of their building blocks of their cyber security i.e. their user accounts, computer accounts, security groups, security policies etc. each one of which is represented by an Active Directory object & protected by an Active Directory Access Control List (ACL).

Today, in most of these organizations, there exist millions of ACLs in their Active Directory, and within these ACLs exists an ocean of excessive/unauthorized access, that today paves thousands of privilege escalation paths to literally the entirety of all objects in these Active Directory deployments, including to all their privileged users.

This ocean of unauthorized access exists worldwide today because Active Directory lacks and has always lacked the essential ability to help organizations correctly and adequately audit effective access in Active Directory, and consequently even though organizations have been delegating/provisioning all kinds of access in Active Directory to fulfill various business needs, they've never had the opportunity to correctly audit this ocean of access, resulting in a situation caused over time (i.e. over the years) wherein today unauthorized access pervades Active Directory.

In short, today, at most organizations, no one knows exactly who has what access on any of their building blocks of security, and possibly an excessive number of users, computers and service accounts may have substantial unauthorized access on them, and thus be in a position to easily and instantly compromise their security.

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

Anyone who possesses the tooling to correctly analyze effective access in Active Directory could instantly identify, and either eliminate or exploit, all such unauthorized access grants and the 1000s of privilege escalation paths they pave, and thus be in a position to either formidably defend or completely compromise these organizations.

The potential impact of this huge cyber security challenge is best illustrated by these 7 examples. Its that simple."

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


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

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

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

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





Time to Help Microsoft (and the Entire World)

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

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


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

1. What Constitutes a Privileged User in Active Directory


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


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


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


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


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


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


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


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


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

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

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

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

In Summary

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

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


Best wishes,
Sanjay

CEO, Paramount Defenses

Formerly, Program Manager,
Active Directory Security,
Microsoft Corporation


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

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

Active Directory Access Control Lists (ACLs) - "Actual" Attack and Defense

Folks,

This post impacts the cyber security of every foundational Active Directory deployment in the world, so you may want to read it.


Active Directory Access Control Lists (ACLs)

Active Directory is the foundation of cyber security worldwide because it enables distributed security in Windows environments and it stores, protects and enables the administration of the entirety of an organization's building blocks of cyber security.

In essence, literally from the entirety of the user accounts of an organization's workforce (including those of all privileged users), to the entirety of computer accounts that represent the organization's computers, and from the entirety of the domain security groups that protect the entirety of an organization's IT resources to the entirety of an organization's security policies (GPOs), at thousands of organizations worldwide, all building blocks of cyber security are stored, secured and managed in Active Directory.

Guess what protects each & every one of these building blocks of cyber security i.e. these Active Directory objects, worldwide?

It is Active Directory Access Control Lists (ACLs) -

An Active Directory Access Control List (ACL) protecting an Active Directory Object

Specifically, it is the ACL of an Active Directory object in which the organization's access intent for that object is specified (whether it be the CEO's user account or the Domain Admins group,) and it is this intent that is enforced by the "System."

In fact, today, billions of Active Directory ACLs that exist in Active Directory deployments worldwide, together serve to secure and defend the very building blocks of organizational cyber security at thousands of business and government organizations.

In short, not only do Active Directory ACLs today help protect trillions of dollars of wealth worldwide, they play a paramount role in securing and defending most business and government organizations, and thus they impact business and national security.

(By the way, if you want to get a complete look at an Active Directory object's ACL, here's likely the most capable tool to do so.)





Attack and Defense - Microsoft's Version

On September 18, 2017, i.e. about one week ago, Microsoft shared its thoughts on this subject in a blog post titled -

Active Directory Access Control List - Attacks and Defense

If you haven't read it, I highly recommend that you read it, NOT because you'll learn anything at all, but only because it reveals volumes about just how little Microsoft may actually seem to know about Active Directory Security, ACLs, attacks and defense.


Attack

If you listen to what today's Microsoft has to say, they'll downplay the exploitation of Active Directory ACLs as an attack vector, suggest that recently there's been some attention given to Active Directory ACLs by amateurs, indirectly concede that it may be possible to exploit weaknesses in Active Directory ACLs, tell you about AdminSDHolder to claim that this couldn't likely be used to escalate privilege to privileged users, reticently agree that it might be possible to find ways to compromise non-privileged users/objects in Active Directory and end by saying - "If you find a path with no obstacles, it probably leads somewhere!"


Defense

In regards to defense, the best today's Microsoft can do is tell you that that their latest toy, Microsoft Advanced Threat Analytics (ATA) can detect recon methods used by newbie tooling like Bloodhound (which incidentally is massively inaccurate.)


Folks, what today's Microsoft is telling you about attack and defense, sounds like Baloney.


Sadly, I don't think they're doing it intently though, as it very well might be that they actually either have no one from the old-guard working on this, and/or the new guards truly have no idea about any of this, both of which are really scary scenarios!








The Actual Attack and Defense

Folks, if you understand the subject of Active Directory Security well enough, then you know that Active Directory access control lists (ACLs) today don't just impact organizational security worldwide, they likely impact national and global security.

Further, you also know that today not only does there lie an ocean of access privileges specified within Active Directory ACLs at almost every organization worldwide, but also because Active Directory lacks the ability to adequately help organizations find out who actually what access in Active Directory, for so many years, most organizations have been operating in the dark, and today there likely exist thousands of privilege escalation paths leading to all kinds of privileges, including to privileged users.

By the way, it is now seventeen (17) years since Active Directory has been around, and even though this attack surface has existed since then, it is only now that a few enthusiasts are starting to realize what a gold-mine of information Active Directory is, and just how many privilege escalation paths one could find to just about everything in Active Directory. In fact, some of these enthusiasts may have gotten a little too excited and even released some infantile tooling, which I believe goes by the name Bloodhound, and lo and behold it is one of the hottest pen-test tools today, even though it is massively inaccurate!




Attack

Speaking of attack, the exploitation of excessive/unauthorized access specified in Active Directory ACLs, as illustrated here, summarized here, described here and a realistic example of which is shown here, is a very real and serious possibility today.

That's because in most Active Directory deployments worldwide, today there likely exist thousands of privilege escalation paths in Active Directory ACLs, just waiting to be found (and exploited (by the bad guys), or eliminated (by the good guys)) by anyone who has the skills or the tooling required to accurately perform effective permissions analysis in Active Directory deployments.


To illustrate how serious this is, here are 7 specific examples of Attack that involve the exploitation of Active Directory ACLs -

1. The complete compromise of an organization's entire workforce's credentials, by an unauthorized individual, such as an intruder or a rogue insider, enactable by the use of the hacking tool Mimikatz DCSync which involves requesting and retrieving the secrets (passwords) of the entirety of an organization's domain user accounts, is possible (and can only be made possible) if that unauthorized individual has sufficient Get-Replication-Changes-All effective permissions in the Active Directory ACL of the target Active Directory domain's domain root object. 


2. The complete compromise of an organization's Active Directory privileged domain user accounts and security groups, such as the Administrator account, the Domain Admins group etc., involving an unauthorized password reset and/or a group membership change etc., is possible if that unauthorized individual has sufficient Write-Property (member or blanket), effective permissions or Reset-Password Extended Right effective permissions in the Active Directory ACL of the target Active Directory domain's unique AdminSDHolder object.
   
   

   An Important Note: AdminSDHolder protection only protects the members of those default Active Directory administrative groups that it is intended to cover, and it does so transitively.
   
   However, if any security principals other than those that fall under the AdminSDHolder protection, were to be granted any kind of access in the AdminSDHolder object's ACL, then those security principals would NOT be protected by AdminSDHolder protection, and THAT opens up the possibility of there existing privilege escalation paths from non-privileged users to privileged users protected by AdminSDHolder.
   
   Many organizations do modify the default AdminSDHolder object's ACL for various reasons, such as to implement their own custom delegations, configure or lockdown access to privileged users etc.

  

3. The complete compromise of the majority of an organization's Active Directory content, i.e. all of their domain user accounts, computer accounts, domain security groups, containers, OUs, service connection points etc. whose Active Directory ACL is not marked Protected, by an unauthorized individual, is possible if that unauthorized individual has sufficient Modify Permissions effective permissions in the Active Directory ACL of any large or Top-level Organizational Unit (OU), or on the domain root, because it would allow the unauthorized individual to make a single malicious change and leverage permission inheritance to obtain full control over the entirety* of all objects whose Active Directory ACLs will end up inheriting that malicious ACL change. 


4. A massive (even if temporary i.e. ranging from a few hours to a few days) denial-of-service (DoS) attack on virtually an organization's entire IT infrastructure, their entire workforce and their ability to do business, made possible by something as simple as the deletion of a top-level Organizational Unit (OU) by an unauthorized individual, is possible if that unauthorized individual has sufficient Delete* (details) effective permissions in the Active Directory ACL of that OU.


5. The identity theft and thus compromise of organizational users, involving a password reset of their domain user accounts by an unauthorized individual, is possible if that unauthorized individual has sufficient Reset-Password Extended Right effective permissions in the Active Directory ACL of the victim's Active Directory domain user account. This could also be used to in effect escalate privilege in Active Directory, and there could possibly exist privilege escalation paths leading from a non-privileged user to highly privileged users, in effect also providing a perpetrator system-wide command and control over an organization's IT infrastructure.
   
   

   An Important Note: Organizations that may have various kinds of multi-factor authentication (MFA) in place, such as Smartcards for domain user accounts, should note that if an unauthorized individual has sufficient Write-Property (either blanket, or for the appropriate attribute) effective permissions on a user's domain account, then he/she could easily turn MFA off on the account, in which case, the account's security will fallback to being password based ( i.e. a system-generated random password) and a password reset (assuming the perpetrator also has sufficient effective permissions to do so) would then allow the unauthorized individual to effortlessly steal its identity, i.e. effectively take over that account.



6. A critical denial-of-service (DoS) attack aimed at disrupting one or more possibly mission-critical applications, such as Microsoft Exchange, Centrify Server Suite, Microsoft Rights Management Server, Microsoft Group Policy, Microsoft Terminal Server, Microsoft Azure, Quest Active Roles Server, Quest Change Auditor, Quest InTrust, Quest Privileged Password Manager, BeyondTrust PowerBroker for Windows, Citrix XenApp and XenDesktop, IBM DB2, to name a few, that rely on the use of Service Connection Points in Active Directory, by an unauthorized individual, is possible if that unauthorized individual has sufficient Write-Property (keywords or Blanket) effective permissions in the Active Directory ACL of one or more of the Service Connection Points of that specific mission-critical application.


7. A massive cyber security breach in which an unauthorized individual, such an intruder, a disgruntled or rogue insider, an APT, a compromised delegated admin/service account etc., is able to obtain access to and leak/divulge, exfiltrate, tamper or destroy literally any (some, or all) organizational IT resource of his/her/their choice, such as a specific file, folder, database, server, application etc., or thousands thereof, is possible if that unauthorized individual simply has Write-Property (member or blanket) effective permissions in the Active Directory ACL of the specific domain security group (, such as All Employees, Blueprint Access Group, Email Servers, Project Windham Group, etc.) in Active Directory that is currently gating access to that organizational IT resource, as this would allow that individual to add any domain account under his/her control to the membership of this domain security group and subsequently instantly and legitimately gain unrestricted access to the target organizational IT resource.

Note: In each case above, in lieu of the effective permissions mentioned above, it would alternatively be sufficient for the unauthorized individual to have Modify-Permissions effective permissions of Modify-Owner effective permissions in the ACL of the involved target Active Directory objects.

I could give many more examples, but to the wise a hint is enough, and I've given you 7 concrete examples of just how much damage an unauthorized individual who possesses various levels of unauthorized access in Active Directory ACLs, could do.

The reality is that literally anything and everything in Active Directory could be a target - The Active Directory Attack Surface


Now, that said, let's talk about Defense.





Defense

Take a deep breath of calm because this risk can be actually be easily, swiftly and completely eliminated by organizations.

The truth of the matter is that even though the serious cyber security risk posed by the potential exploitation of the vast number of excessive/unauthorized privilege access grants that are today specified in billions of Active Directory ACLs across thousands of Active Directory deployments, likely poses a clear and present danger to organizational cyber security worldwide, this risk can actually be easily, swiftly and completely eliminated by organizations, leaving no opportunity on the table for perpetrators.


How, you ask?  Keep reading...

A Small Digression

To understand how to mitigate this risk, we need to understand what caused this risk in the first place.

For years now, organizations have been leveraging Active Directory's precise administrative delegation / access provisioning capability to delegate/provision all kinds of access in Active Directory to fulfill business needs.  

While Active Directory makes it very easy to precisely delegate/provision access, unfortunately, it completely lacks the capability to help precisely assess/audit the actual resulting access that ends up getting implemented, and thus organizational IT personnel / AD admins have no way of being able to precisely a) verify the accuracy of their delegations or b) audit who actually has what access provisioned in Active Directory at any point in time.

Further, 3 factors contribute to exacerbating the situation -

1. Active Directory's security model is quite rich and powerful, and thus complex, since it has almost a dozen generic security permissions and five dozen special security permissions (known as extended rights), and further, because mechanisms like inheritance of permissions involve and require precedence orders, applicability etc. all of this makes it difficult to determine the actual access implemented in Active Directory.


2. A majority of all access specified in Active Directory is specified for security groups (as it should be), which given the possibility of group nesting, and often to multiple levels, further complicates not only who all might be ending end up with all kinds of access, but also trying to find out who actually has what access, especially since the membership of any of these groups could be changed by so many others, anytime.


3. Considering the above, the slightest change made in even one place in Active Directory, such as in the ACL of a top-level OU, or the membership of even a single mid-level nested domain security group, could easily end up changing the actual state of access in Active Directory quickly & in many cases substantially.

Consequently, though organizations have been delegating/provisioning access in Active Directory for years now, they have almost never had the means or the opportunity to be able to accurately audit the actual existing state of access in Active Directory, and in light of the above, considering that in most Active Directory domains there may thus far have been 1000s of changes made, there likely exists a vast amount of excessive / unauthorized access, and no one actually knows exactly who can do what in their Active Directory deployments.

End of Digression.

The reason there exists vast amounts of excessive/unauthorized access in Active Directory is that organizations don't have the means to easily and correctly audit/assess who is actually i.e. effectively delegated/provisioned what access in Active Directory.

In order to be able to correctly do so, all that organizations need is the ability to be able to accurately, adequately and efficiently determine exactly who has what effective permissions/access in Active Directory, on a per-object basis, & ideally domain-wide.

By "adequately", I mean that given an Active Directory object, organizations should be able to easily determine a) the complete set of effective permissions provisioned on it, b) as well as the complete list of individuals that have these effective permissions, and c) HOW each one of these individuals is getting these effective permissions, as that data is needed to lock-down access.

Unfortunately, this capability does not seem to natively exist in Active Directory, so most organizations have just been performing basic Active Directory Permissions Audits, which are almost useless, and as a result, no one really knows exactly who can do what in Active Directory!

Over the years, this has resulted in a substantial amount of excessive/unauthorized access in Active Directory, which is best evidenced by the fact that even a tool as massively inaccurate as Bloodhound is able to find so many privilege escalation paths!


That said, here's Defense -

Conceptually, to defend against these attacks, all that organizations require is the ability to be able to accurately and adequately determine Active Directory Effective Permissions on their Active Directory objects, as this will give them a correct picture of who can actually do what on these objects, and show them how these users have such access today, and thus enable them to know exactly which security permissions to tweak in the ACLs of which Active Directory objects, and/or which group memberships to tweak, to lockdown any and all excessive / unauthorized access that is currently provisioned on their Active Directory objects.

Again, by "adequately", I mean that, given an Active Directory object, organizations should be able to determine a) the complete set of effective permissions provisioned on it, b) as well as the complete list of individuals that have these effective permissions, and c) HOW each one of these individuals is getting these effective permissions, as that data is needed to lock-down access.

A Simple 3-Step Defense Process

To defend against these attacks, this simple 3-step process is all that organizations need to perform -

• Step 1 - Perform an Active Directory Effective Privileged Access Audit. This is a simple audit that involves the accurate determination of effective permissions/access in Active Directory, and it is the correct way to identify exactly who actually i.e. effectively has what access (anywhere and everywhere) in an Active Directory domain.


• Step 2 - Analyze the results of this audit to identify all such users who currently possess any kind of access in Active Directory that they should NOT ideally be in possession of. Also identify where they currently possess such access.


• Step 3 - For each such user identified in the analysis of Step 2, for each object on which they have such identified access, further analyze the results of this audit to additionally identify the HOW i.e. the underlying permissions in the ACL of the object that are entitling them to such effective access. Then, use this information to appropriately tweak the underlying ACL or the involved group membership to revoke all such identified excessive / unauthorized access.

In essence, in Step 1 we accurately determine object-specific/domain-wide effective permissions/access, in Step 2 we analyze these results to identify all "unauthorized access" and the underlying permissions in Active Directory ACLs that cause them, and in Step 3 we use this data to tweak these permissions in the ACLs (, or group memberships,) to lockdown Active Directory.

That's it!

For an illustrative step-by-step example that shows how to follow these

steps on a specific Active Directory object, see section IX of this post.

A Simple Example

If I had more time at hand, I would've shown you exactly how to do so, domain-wide. Since I don't, I'll share a quick example.

Lets assume that your organization wants to ensure that no one can make an unauthorized group membership change to any of the thousands of domain security groups in your Active Directory that are being used to protect the entirety of your IT resources.

To do so, technically what you need to do is accurately determine effective permissions on every domain security group in your Active Directory to find out who has Write-Property Member effective permissions on each one of these domain security groups.

Now, this in itself might seem like a herculean undertaking, and it is, but with the involved tooling, you can easily get it done.

Once you've done so, you'll have the accurate technical data that shows you exactly who can change the group membership of each one of your domain security groups in Active Directory, and once you have this insight, you'll be able to identify exactly how many individuals can currently enact this task versus how many should ideally be able to do so, and thus you'll be able to easily identify all such individuals who are not supposed to be able to do so, but nonetheless are able to do so today i.e. you'll be able to identify all users who possess "unauthorized access" as it pertains to this example.

Once you have identified all such users who possess this "unauthorized access", if you know which underlying permissions in the Active Directory object's ACLs are entitling them to this unauthorized access (and you will have this data if you perform the above mentioned audit, because the involved tooling will provide it to you), you can now tweak either the permissions or the membership of the domain security groups to which these permissions are granted, as needed, to revoke this unauthorized access, and in this manner, you can easily, efficiently and provably lockdown the access granted in Active Directory.

An Effective Privileged Access Audit is thus a simple, logical and straight-forward process that involves enacting the above to help organizations easily and accurately obtain the insight they need to identify unauthorized access in Active Directory.

One last thing - wouldn't it be nice if instead of having to determine who has what effective permissions in terms of technical Active Directory permissions (e.g.  Write-Property Member), we could just obtain this information in terms of administrative access entitlements i.e. in terms of who can enact what administrative tasks (e.g. Who can change a group's membership)?

I happen to think so, because security is best kept simple, and we humans can think about and analyze situations described in terms of administrative tasks much better than we can do so in terms of arcane technical permissions. In this regard, the tooling involved in such an audit is designed to deliver this insight in terms of administrative tasks rather than technical permissions. Of course, should you also like the data in terms of technical permissions, the involved tooling can certainly deliver that as well.

Thus, as it pertains to this example, an Effective Privileged Access Audit will deliver the following data to you - a complete list of all individuals who can change domain security groups in our Active Directory, the exact identity of each domain security group whose membership they can change, and the exact underlying security permission in the ACL of that domain security group that entitles this user to being able to change its membership. Armed with this valuable insight, we can easily and completely lockdown Active Directory vis-à-vis this example, in a matter of days.

End of Example.


A comprehensive Effective Privileged Access Audit will thus empower your organization to easily, efficiently and accurately determine the entirety of access that is currently provisioned/delegated in your Active Directory, i.e. it will span finding out who can do what concerning account management, group management, OU and Container management, SCP management, Directory Services management etc. and do so in a matter of hours, not months, and thus it will get you the data you need to adequately lockdown your Active Directory, and in doing so enable your organization to swiftly, measurably and demonstratably attain and maintain least privileged access in Active Directory.

Any organization or individual who needs additional information or clarity into this process may be feel free to contact us. Our technical specialists will be happy to help you adequately understand this process, our compliments (i.e. free of charge.)



So you see, this is all we need to do, and once we've done this, there will be no unauthorized access left in our Active Directory, no matter how large it is, and there will be no unknown privilege escalation paths left for perpetrators to find and exploit. None!

Let me repeat that. Once you've done this, there will be no unauthorized access left in your Active Directory. None... 

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

This is all that organizations need to do to easily, efficiently and accurately identify and lockdown all unauthorized access in Active Directory. From that point on, you'll want to maintain this least privileged access state by performing regular audits.

So, what tooling is needed to perform an Active Directory Effective Privileged Access Audit?  You're going to need this & this.

In fairness, to be totally objective, strictly speaking you can use any tool that can help you accurately and adequately determine effective permissions in Active Directory, at a minimum on a per-object basis, and ideally domain-wide (unless you have years to solve this problem). I only mentioned those two tools because those are the only tools that I know of that can help do this.




In Summary

The potential exploitation of the vast amount of excessive/unauthorized access that exists in billions of Active Directory ACLs worldwide today is a serious challenge that 1000s of organizations face because it impacts their foundational cyber security.

Fortunately, with the right guidance, tooling and executive support, it can be quickly, efficiently and completely addressed.

Here's what we at Paramount Defenses believe -

"We at Paramount Defenses care deeply about cyber security and we understand that left unaddressed, this could pose a serious cyber security risk to organizations worldwide that operate on Active Directory. Be rest assured that Active Directory is a highly robust, trustworthy and securable technology, and here is exactly how organizations can easily, adequately and reliably identify and lock-down privileged access in their foundational Active Directory deployments, leaving no room for perpetrators to identify and exploit any weaknesses."

Lastly, I know that I make it sound so simple, but in reality, this is a very difficult problem to solve, and without the ability to be able to obtain accurate effective access insight, which in turn requires the right tooling, it really is almost impossible to solve.

As for the right tooling, building it requires vision, a deep understanding of the subject, and years to build, test and perfect.

Best wishes,

Sanjay

CEO, Paramount Defenses

Formerly, Program Manager,
Active Directory Security,
Microsoft Corporation


PS: I could've easily communicated all of this in just a simple Executive Summary, and we did - its called The Paramount Brief. In fact, last year, we had even FedEx overnighted it to the CEOs, CFOs and Chairmen of the Top-200 organizations worldwide, and FedEx tracking helped ensure that they all received it. They've all been informed. I even shared it with Microsoft (MSRC).

PS2: To my friends at Microsoft - "This only took a decade of vision, persistence, grit and laser-focused execution to address."

PS3: If you liked this post, you're likely going to love the next few posts.