Today Active Directory Security is mission-critical to organizational security worldwide and thus mission-critical to Cyber Security worldwide. On this blog, former Microsoft Program Manager for Active Directory Security, and today, CEO of Paramount Defenses, shares valuable technical insights on Active Directory Security.


Thursday, December 1, 2016

Attack Methods for Gaining Domain Admin Rights in Active Directory

Folks,

Today I'd like to share with you the top-10 ways in which an intruder or a rogue/coerced insider could actually rather easily and quickly gain Domain Admin equivalent administrative access/power/privilege in any Active Directory environment in the world.

Please note that the only reason I'm publishing this simple list is because apparently there is a similarly titled list out there that apparently does not cover even one of the top-10 ways in which an intruder could gain Domain Admin rights in Active Directory.

Original source: http://www.paramountdefenses.com/blog/top-10-ways-to-gain-domain-admin-privileges-in-active-directory



Attack Methods for Gaining Domain Admin Rights in Active Directory -



  1. Use Mimikatz DCSync to obtain credentials of all domain accounts, including those of all privileged user accounts.


  2. Add an inheritable Allow Full Control security permission in the ACL protecting the domain root object to instantly gain domain-wide administrative access on 99% of all objects in the domain i.e. those whose ACL is not marked Protected.


  3. Reset the password of any existing Domain Admin equivalent domain user account, then logon using new password.


  4. Modify the group membership of any Domain Admin equivalent domain security group by adding an account you control to that group, then instantly logon using that account and have that admin group's SID in your Windows access token.


  5. Modify the contents of any one of numerous sensitive objects in the System container and/or in the Configuration or Schema partitions to gain administrative access in Active Directory. Here is one of 100+ examples:  Simply modify the defaultSecurityDescriptor attribute of the User class Schema object in the Schema to grant an account of your choice full control on all newly created domain user accounts, especially one created for an administrative/privileged user.)


  6. Add a Allow Reset Password or Allow Write-Property Member permission in the AdminSDHolder object's ACL to instantly gain the ability to take over any/every administrative account and group protected by AdminSDHolder.


  7. Add Allow Write Property - GPLink and Allow Write Property - GPOptions permissions in the ACL protecting the Domain Controllers OU, then link a compromising group policy to that OU that would allow you to logon interactively on DCs and/or to gain administrative access on DCs. Once you have admin access on a DC, you own the entire kingdom.


  8. Establish a cross forest trust or external trust with a forest controlled by the intruder/perpetrator


  9. Set the Password not required bit on any administrative/privileged domain user account, then instantly perform a logon.


  10. If any form of MFA (multi-factor authentication, e.g. Smart cards etc.) is in use, simply disable its use by modifying the relevant attribute on the target administrative/privileged user's domain account, then instantly perform a password reset and logon to that account using the newly set password. (If you have sufficient rights, a password reset takes 1 second.)



It should be noted that not a single one of these attack methods involves the use of password hashes or Kerberos tickets.

I should also mention that these are merely the top-10 ways to do so. There are many many (100s) more ways in which one could accomplish this objective, simply by modifying appropriate content in Active Directory. In almost every Active Directory deployment, there are 1000s of objects that can be modified to gain all kinds of elevated/privileged access in Active Directory. One's ability to (exploit or) adequately protect Active Directory is a function of one's depth/expertise in Active Directory security.

For those who wish to learn more about Active Directory Security, this deck is a good starting point - Active Directory Security.

It must also be mentioned that each one of these attack vectors can be easily mitigated by possessing a single fundamental cyber security capability, that most organizations do not (even seem to know about, let alone) possess today. Here's a hint.

Stay tuned for MUCH more, in days to come.

Best wishes,
Sanjay


PS: This was a 30-second brain-dump of about 0.01% of our knowledge in Active Directory Security. We generally prefer to let our work do the talking, so here are three simple examples of our work that embody our deep knowledge - one, two and three.


PS2: If you liked this blog post, you may also like the following -
  1. Active Directory Beyond the MCSE for the Black Hat Conference 2016
  2. A Letter to Benjamin Delpy regarding Mimikatz and Active Directory Security
  3. The Paramount Brief - Declassified and Substantiated
  4. Trillion $ Privileged Access Insight on the OPM Breach
  5. A Simple $100B Question and a follow-up Simple Trillion $ Question, both to/for Microsoft

Tuesday, October 25, 2016

Best Practices for Securing Active Directory

Folks,

As you may know, given the foundational role of Active Directory in business, its security is paramount to organizational cyber security today, and it appears that organizations worldwide are finally starting to take Active Directory security seriously.

As former Microsoft Program Manager for Active Directory Security, to help Microsoft Corp better understand Active Directory security (and to help organizations worldwide measurably enhance Active Directory security), last week we released the Paramount Defenses deck on Active Directory Security, titled Defending Active Directory Against Cyber Attacks.
You can download it from here - http://www.paramountdefenses.com/defending-active-directory-against-cyberattacks.html


Rare, High-Value Active Directory Security Insight

With over 90+ insightful slides covering all relevant aspects of Active Directory security, of course, it could very well have been titled Best Practices for Securing Active Directory, so I thought I'd share a link to it here. Here's the Table of Contents -


1. Introduction: Active Directory - Importance, Impact of Compromise and Attack Surface
2. Top-5 Active Directory Security Risks, Attack Vectors and Methods
3. Top-5 Active Directory Threat Sources
4. Top-5 Active Directory Security Risks (The Details)
5. A Note on Credential Theft Vectors
6. Top-5 Active Directory Security Measures
7. An Ocean of Access Privileges in Active Directory + How to Limit Access Privileges in Active Directory
8. Five Examples of Limiting Access Privileges in Active Directory
9. Automated Privileged Access Audit in Active Directory
10. Five Examples of Impact of Compromise
11. Five Special Active Directory Security Topics
12. Summary, Helpful Pointers and Insights

If you're into Active Directory Security, you won't want to miss it - it's right here.

Best wishes,
Sanjay


PS: If you're looking for Microsoft's whitepaper, you can find it here. If you want to know what the most important topic in Active Directory Security is, and one that Microsoft's experts completely missed covering in that whitepaper, you'll want to read this.

Wednesday, August 3, 2016

How to Easily Dump/Export Active Directory Security Permissions/ACLs

Folks,

Today, I'd like to take a small break from some important technical stuff  and cover some very simple stuff, which is to share with you the easiest way in the world to dump/export Active Directory security permissions/ACLs, because this is elemental.

But first a very quick overview of Active Directory security permissions and ACLs might be helpful.

If you want to get straight to the details, you can skip to section 3 below.




1. A Quick Overview of Active Directory Security Permissions and ACLs

As you may know, every object in Active Directory is protected by an access control list (ACL), which is comprised of zero or more access control entries (ACEs), each one of which allows or denies a specific set of security permissions (of which there are many in Active Directory) to a specific security principal (user, group or well-known security principal.)

Active Directory Security Permissions specified in an Active Directory Access Control List (ACL)


Together, the security permissions specified in an Active Directory object's ACL serve to protect that Active Directory object, and specify who is allowed or denied what security permissions onto that object (which of course includes all its attributes.)

Since even a quick overview of the various permissions in Active Directory could take a few paragraphs, here's a pointer to a very quick overview of the Active Directory Security Model and Active Directory security permissions, which as you may know, include over a dozen generic permissions, dozens of extended rights and several validated writes. Alternatively, you can refer to Appendices C, D and E of Microsoft's official whitepaper on administrative delegation, which I wrote back in 2003.

In essence, Active Directory ACLs and the security permissions specified within them control access to the entirety of Active Directory content, and thus lie at the very foundation of cyber security in a Microsoft Windows Server based IT infrastructure.




2. The Need to be able to Dump/Export Active Directory Security Permissions/ACLs

IT personnel responsible for administering Active Directory deployments, delegating and maintaining administrative authority in Active Directory, provisioning secure access for applications and other stakeholders to Active Directory content, auditing Active Directory security etc. often have a need to be able to dump/export Active Directory Security permissions/ACLs.

In fact, here are 5 specific use-cases -
1. Perform security analysis to identify who is specified what access across an Active Directory domain
2. Identify the list of all security principals that have any sort of access granted in an Active Directory domain
3. Determine what security permissions are granted to whom, where and which ones in Active Directory
4. Obtain a detailed, fully-sortable view of all security permissions/ACLs in an Active Directory partition. 
5. Export/dump an Active Directory object's ACL for detailed offline-analysis, comparison, audit and archival.

Today these needs are elemental to the foundational cyber security of virtually every Active Directory deployment in the world.





3. The World's Easiest Way to Dump/Export Active Directory Security Permissions/ACLs

Today the easiest, fastest and most reliable way to dump/export Active Directory security permissions/ACLs in Active Directory is via this specialized Active Directory ACL Viewer and Exporter tool - 
Gold Finger Active Directory ACL Viewer and Exporter


Click, Done. If you can click a button, you can export Active Directory security permissions/ACLs in seconds. It's that simple.


Active Directory Security Permissions/ACL Dump


Here's some sample output (; you can click the image below to enlarge it + download complete CSV file from here) -
Active Directory ACL Dump
 
The Active Directory security permissions/ACL dumps generated by the tool are very easily sortable by virtually every relevant field, including object type, object name, distinguished name, permission type (Allow/Deny), security principal, each of the 13 individual generic Active Directory permissions (RC LC LO WO WD SD DT CC DC CR SW RP WP), attribute/class, inheritance, applies to and inheritance flags (CI (Container Inherit), ID (Inherited), IO (Inherit-Only) and NP (No Propagate)), making it very easy to sort the data by any field, and easily perform rich and efficient ACL/security analysis.

In fact, with this dedicated tool, if you can click a button, you can instantly -
1. Obtain a highly-detailed, fully-sortable view of the access control list (ACL) of any Active Directory object.
2. Analyze an Active Directory object ACL by being able to sort it by any field (e.g. Type, Security Principal etc.) 
3. Sort an Active Directory object's ACL by any of the 13 generic permission types (e.g. Create Child, Delete etc.)
4. Export/dump an Active Directory object's ACL for detailed offline-analysis, comparison, audit and archival.
5. Export/dump the ACLs of any, some or all Active Directory objects in any Active Directory partition.

Right below, I've shared 7 real-world examples, complete with their ACL dump output so you can see the data for yourself.





4. Seven Real-World Examples of Active Directory Security Permissions/ACL Dump

Here are 7 real-world examples of Active Directory ACL dumps, with actual outputs, that you can perform with this tool -

 
1. Dump the security permissions/ACLs of all objects in the domain: output
2. Dump all protected ACLs in the domain: output
3. Dump the security permissions/ACLs of all privileged users and groups in the domain: output
4. Dump the security permissions/ACLs of all users in the domain whose title contains the word Cloud: output
5. Dump the ACLs of all objects in the domain that are owned by the Builtin Administrators group: output
6. Dump the ACLs of all organizational units that are immediate children of the Corp organizational unit: output
7. Dump the ACLs of all organizational units that are up to 2 levels deep in the Corp organizational unit: output

To view the actual ACL dumps for each of the examples above, simply click on the associated output links above.




5. Seven Design Goals

Here are 7 design goals we had when developing our dedicated Active Directory Security Permissions/ACL Dump Tool -

1. Ease of Use - Ability to dump Active Directory permissions/ACLs at the touch of a button.
2. Complete Flexibility - Ability to use LDAP filters to customize scope of objects whose ACLs are to be dumped.
3. Scope and Depth Control - Ability to specify the scope and depth of objects whose ACLs are to be dumped.
4. Easily Analyzable and Sortable Results - The results retrieved should be rich and easy to analyze and sort.
5. Zero Dependencies - The tool should not require any configuration changes or special permissions.
6. Easy installation - The tool should be installable on any domain-joined machine in under 2 minutes.
7. Advanced Features - It should be able to perform special retrievals such as to be able to -
a. Export/dump all ACLs marked protected
b. Export/dump the ACLs of all objects that are owned by a specific user/group
c. Export/dump the ACLs of all objects with a specific Primary Group

Its specialized features embody these goals and make it substantially more capable than other tools (e.g. dsacls, acldiag, etc.)

In addition, because all of our tools are professionally built to the highest standards of security, reliability and trustworthiness, organizations do not need to worry about the accuracy, integrity or security risks associated with amateur/custom-built scripts.



Summary

Today, our Gold Finger Active Directory Security Permissions/ACL Viewer and Export Tool is used in 6 continents worldwide, by so many of the world's top business and government organizations, perhaps because its the easiest, most reliable and trustworthy way to dump Active Directory ACLs.

To learn more + to get a free trial, visit - http://www.paramountdefenses.com/active-directory-acl-permissions-viewer.html

Of course, because we know first-hand that there's a lot more to Active Directory Security Audit than performing Active Directory ACL dumps, we also offer the world's most capable Active Directory Permissions Analyzer and the world's only accurate Active Directory Effective Permissions Tool, Active Directory Effective Access Audit Tool and the world's only Active Directory Administrative Access and Delegation Audit Tool.

In essence, we offer the world's most comprehensive suite of Active Directory security, access and effective access audit tools, all available in a single user-interface, with zero dependencies, two-minute installation and Windows-integrated security.

More information on our Gold Finger Suite is online at - http://www.paramountdefenses.com/goldfinger.html

Best wishes,
Sanjay

Monday, August 1, 2016

How to Prevent a Perpetrator from Using Mimikatz DCSync feature to perform Credential Theft from Active Directory

Folks,

Today, I'd like to take a few minutes to show you 5 simple steps that you can enact in 5 minutes to prevent a perpetrator from using the DCSync feature of Mimikatz to perform credential theft from Active Directory. This is very important, so please read it.

I'm not going to go into too many details regarding the specific threats posed by this feature of Mimikatz, or its details, use and exploitation. For that kind of stuff, you can check this out. What I will do is provide a quick overview, cover some pertinent aspects, including why its so important to do this, and most importantly show you exactly how to easily do this.

A succinct version of this blog post can be found at - How to Lockdown Active Directory to Thwart the Use of Mimikatz DCSync



I. Quick Overview

As you may know, Mimikatz, is a hacking tool developed by a certain Mr. Benjamin Delpy that can, to put it mildly, gather credential data from Windows systems. It can do a lot more, and you can read all about it's numerous capabilities here.

An Intruder using Mimikatz

The short of it is that any perpetrator who has administrative control over an owned machine can use Mimikatz to easily obtain and reuse the credentials of anyone who may have logged on that machine.

When run on non-domain controllers, the impact is limited to being able to obtain/access/reuse the credentials of only those individuals that may have logged on that machine. In a typical Active Directory environment, you may at most have a few individuals that may have logged on to a specific machine. By few, I mean a very small number compared to the total number of domain user accounts in Active Directory. So, at most, the damage would be restricted to the credential compromise/theft of those individuals that logged on the owned machine. Of course, this could be used to target other domain-joined hosts on the network etc. but in general, one likely couldn't obtain access to the credentials of the entire user population.

In contrast, if a perpetrator could successfully run mimikatz on a Domain Controller, then he/she could easily dump LSASS on the Domain Controller to obtain access to the password hashes of all domain accounts and thus easily obtain access / effectively compromise the credentials of your entire user population!




II. But wait, its Already Game Over

Please note that it is IMPERATIVE to understand that in order to "successfully" run Mimikatz on a Domain Controller, the perpetrator would have to be logged on as an Admin on the Domain Controller, and here's the Trillion $ point - IF THE PERPETRATOR CAN LOGON AS AN ADMIN ON A DOMAIN CONTROLLER, it is already GAME OVER right at that point!

Perpetrator having Admin Creds on on a Domain Controller

He/she need not do anything else to play God! At that point, he/show already effectively owns your entire Kingdom. Incidentally, only those perpetrators who do not know this trivial fact will need to enact many more steps to play God.

In essence, if an unauthorized individual can logon to even one DC as an Admin, please consider your entire Active Directory forest compromised. It's that simple. You're done. Its over. There's nothing more left to defend. (A little more on that here.)

Thus, it is of paramount importance to ensure that only the most trustworthy and authorized individuals are allowed access to and ability to logon to Domain Controllers!




III. A Seemingly Simple Mitigation?

Consequently it follows that if you can ensure that the perpetrator can never logon to your Domain Controller as Admin, (it used to be that) you don't have to worry about his/her ability to essentially access/steal the credentials of your entire user populace (i.e. all domain users in your Active Directory, which could be 1000s or for some companies, a 100,000+ users.)

Logon to Domain Controllers Locked Down
I say used to be, because Mimikatz recently got a new feature called DCSync, as a result of which, if the perpetrator has sufficient privileged access delegated/provisioned to him/her in the Active Directory, then he/she no longer need logon to a Domain Controller as admin to be able to in effect compromise/steal the credentials of your entire user populace, because via the tool, he/she could request that Active Directory replicate out to him/her all Active Directory data including secrets (i.e. password hashes), and once the tool has these secrets, the rest is easy and automated by the tool.

As a result, today denying a perpetrator the ability to logon as Admin on to a Domain Controller is no longer a sufficient mitigating measure for this risk. To reliably mitigate this risk, an additional essential measure, described below, is required.




IV. But First, A Quick Background of the New Vector

Before I can share information on the additional essential measure, I should share some background information on the new vector, so you can understand why this additional step is essential and required.

As a result of this new DCSync feature, Mimikatz can now leverage a capability in Active Directory wherein a user who effectively has sufficient rights to do so, can basically request that Active Directory replicate out to it, the entire Active Directory partition contents, including secrets, which are essentially the password hashes stored in Active Directory.


In effect, instead of having to logon to a Domain Controller, the perpetrator can simply request that Active Directory send over all the password hashes to the perpetrator, thus obviating the need to be able to logon to a Domain Controller, and thus bypassing the protections put in place that would prevent him/her from logging on as an Admin on Domain Controllers!

The ability to enact the administrative task of Replicating all Active Directory data, or more simply put the ability to replicate secrets out from an Active Directory domain is governed by a single system-level access grant, i.e. an Active Directory security permission (strictly speaking, an Extended Right) called Replicating Directory Changes All. Anyone who effectively has this extended right granted to him/her on the domain NC head, i.e. in the access control list (ACL) of the domain root object can replicate secrets out from Active Directory. This ability has existed in Active Directory since 2000. (More on this extended right below.)




V. The Replicating  Directory Changes All Extended Right

As mentioned above, the ability to replicate data, including secrets (i.e. password hashes) from an Active Directory domain is controlled by the Replicating Directory Changes All extended right. Its CN is called DS-Replication-Get-Changes-All -
The Replicating Directory Changes All extended right in the ACL on the Domain Root object

For those who are technically inclined, you can checkout Appendix D of Microsoft's whitepaper on Administrative Delegation in Active Directory which I wrote for Microsoft way back in 2003. Its Rights GUID is 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2.

Only those individuals who effectively have this extended right granted to them in the ACL of the domain root object (also known as the NC head) can replicate all data (including secrets i.e. password hashes) from the Active Directory.




VI. The Second Essential Measure - Lockdown Replicating Directory Changes All Extended Right

If it is this extended right that controls who can replicate all data, including secrets (password hashes) out of Active Directory, then it logically follows that simply locking down who effectively has this right granted to them would be a second essential measure towards mitigating the risk posed by a perpetrator's ability to steal/compromise the credentials of your entire user populace!


Now, the act of locking down this right is fairly simple and straight-forward. However, before you can do so, you'll need to be able to precisely determine/assess exactly who all have this extended right effectively granted to them in the first place, and after you have taken the steps to lock it down, you'll need to verify that the steps you have taken to lock it down have actually achieved the desired lockdown.

It turns out that in order to do both, i.e. precisely determine/assess exactly who all currently have this extended right effectively granted to them, as well as to verify that post lockdown, only the intended individuals have this right effectively granted to them, you require the ability to be able to accurately determine (something known as) effective permissions in Active Directory.

In other words, one can neither accurately figure out who currently has this right effectively granted, nor accurately verify the lockdown measure without being able to (accurately) determine effective permissions in Active Directory.




VII. The Need to Determine Effective Permissions

By default, only the most powerful administrative groups in Active Directory as well the domain's Domain Controllers have this extended right granted to them.

So in environments wherein the security permissions on the domain root have NEVER been changed, it may be safe to assume that only members of the most powerful administrative groups can replicate secrets out of the Active Directory.

However, as you'll agree, most Active Directory deployments have been around for years, and over the years, many IT personnel may have changed permissions all across Active Directory, including on the domain root for various reasons, such as to delegate administration, provision access for/to line-of-business applications or to lockdown access in Active Directory.

As a result, in 99.9% of all Active Directory deployments, the ACL on the domain root objects is no longer the same as the original default ACL when the domain was created. Consequently, it would be unwise and dangerous to assume that this permission grant would not have changed.

Numerous IT personnel may have the Get Replication Changes All right effectively granted to them Active Directory


In fact, for reasons outlined below, it can almost be guaranteed that many more individuals that should ideally have the ability to replicate secrets out of Active Directory, have the ability to do so today -
1. An administrator may have deliberately made access provisioning changes on the domain root object, either to grant or deny additional individuals or groups this specific access i.e. Get Replication Changes All
2. An administrator may have accidentally ended up granting or denying this specific access, such as by granting or denying a specific user or group All Extended Rights or Full Control instead of this specific extended right 
3. A malicious administrator may have deliberately granted an obscure group, containing other nested groups or specific user accounts, this extended right as a backdoor, so that, in the future, were he/she to be terminated, he/she could use that obscure account to replicate secrets out and in effect own the entire domain.
Point 2 in particular is worth reiterating. Any blanket permissions such as All Extended Rights, or Full Control, specified in the ACL of the domain root that may have been deliberately or accidentally specified will undoubtedly cover this extended right, and thus could unknowingly end up granting tremendous power to some individual who is not ideally authorized to possess it.

Finally, as you may know, there are many permission entries, each one of which directly/indirectly allows or denies some access for some security principal. Ultimately what matters is that the system takes into account the appropriate precedence orders and resolves any conflicting rights to arrive at the determination of whether or not to grant a specific security principal the requested access. In other words, what determines the actual access a user has on an Active Directory object are his/her effective permissions.

It is for the above reasons that when trying to audit access in Active Directory, it is grossly insufficient to merely analyze "who has what permissions" and in fact absolutely essential and paramount to analyze "who has what effective permissions".

Thus, to answer the simple yet paramount cyber security question "Who effectively has the Replicating Directory Changes All extended right on the domain root", what is needed is the ability to determine effective permissions on the domain root object.

The concept of effective permissions is very important to understand, yet hardly understood, and as a result, most individuals, including many IT professionals as well as proficient hackers, tend to mistake "who has what permissions" for "who has what effective permissions."

To reiterate, considering all the permissions specified in the ACL of an Active Directory object, the difference between the various permissions specified for a user and the actual effective permissions that a user ends up with, could be NIGHT and DAY, and could be the difference between SECURITY and COMPROMISE.




VIII. Determining Effective Permissions on Active Directory Objects

Given the vital importance of effective permissions, Microsoft provides an Effective Permissions Tab in Active Directory to help organizations determine effective permissions on Active Directory objects.
The Effective Permissions Tab in Active Directory

Unfortunately, Microsoft's Effective Permissions Tab is virtually useless, because of two main reasons, the first one being that it is not always accurate, but/and more importantly, the second one being that it can at best determine effective permissions for one user at one time.

Security Principal Selector

This (second reason) might not readily appear limiting, but if you consider an environment with thousands (or even hundreds) of users, you'll realize that the only way to accurately determine a specific effective permission on an Active Directory object is to enter the identity of each one of these thousands of users one by one to arrive at an accurate picture of who really has what effective permissions on that object, and as you can see, doing so could be very arduous, time-consuming and painstaking.

The same is true of the effective permissions capability of Microsoft's acldiag command-line tool.

Security Warning: In regards to Active Directory Effective Permissions tools, please note that this specific tool is exremely inaccurate, and thus any reliance on it could potentially result in the introduction of dangerously inaccurate changes. The same is true of any script(s) etc. available on Microsoft TechNet.

Ideally, what is required is the ability to be able to quickly (i.e. within minutes, not days) and accurately determine effective permissions on the domain root, such that one could easily determine the list of all individuals to whom this critical extended right is effectively granted, as well as how they have it effectively granted.

For instance, something like this -
Gold Finger Active Directory Effective Permissions Tool

The snapshot above (click to enlarge) is that of the world's only accurate Active Directory Effective Permissions Tool.

Armed with a tool such as the above, IT personnel can now instantly identify exactly who effectively has this (and in fact any) right granted on the domain root (and in fact on any object in any Active Directory partition) within seconds, at a button's touch.






IX. How to Correctly Lockdown the Replicating Directory Changes All Extended Right on the Domain Root

With the background information gained above, your are now in a position to easily lockdown the Replicating Directory Changes All extended right on the domain root in 5 simple steps -
Note: The following steps utilize the following Active Directory Effective Permissions Tool - http://www.paramountdefenses.com/active-directory-effective-permissions-tool.html

1. The first step is to determine effective permissions on the domain root. The really hard way to do so is to use the Effective Permissions Tab in Active Directory, and enter the identity of every user in your domain and make a note of whether or not they have the Replicating Directory Changes All extended right effectively granted to them. As mentioned above, the easy way to do this is to use this Active Directory Effective Permissions Tool.  Simply click a button and you're done.

For instance, in the following domain, using such a tool we have identified that a total of 15 users are effectively granted the Replicating Directory Changes All extended right in the domain root object -

Specifically, we can see that the following 15 users currently have this right effectively granted to them -
  1. Administrator
  2. Alex Simons,  Cloud Active Directory Administrator
  3. Chris Betz,  Cloud Engineer Architect
  4. DC1
  5. Gene Farrell,  DevOps Cloud Engineer
  6. Hayden Hainsworth,  Cyber Security Cloud Engineer
  7. Jeff Bezos,  Cloud DevOps Operator
  8. Ken Malcolmson,  DevOps Cloud Engineer
  9. Marc Benioff,  Cloud DevOps Admin
  10. Michael Brown,  Cloud Product Manager
  11. Mike Neil,  Cloud Software Engineer
  12. Satya Nadella,  Cloud DevOps Engineer
  13. Stephen Schmidt,  Cloud Security Engineer
  14. Steve Ballmer,  IT Analyst
  15. Terry Hanold,  Cloud Operations Engineer

2. The second step is to analyze the results of the effective permissions analyze and identify all users who currently have this critical right assigned to them, and identify how many of these users should NOT have this critical right assigned to them.

For instance, here we have identified that the following individuals should not actually have this critical access right granted to them, but happen to have it granted nonetheless -

Specifically, based on our corporate security policies, we have identified 12 users who should not ideally have this right effectively granted to them -
  1. Alex Simons,  Cloud Active Directory Administrator
  2. Chris Betz,  Cloud Engineer Architect
  3. Gene Farrell,  DevOps Cloud Engineer
  4. Hayden Hainsworth,  Cyber Security Cloud Engineer
  5. Jeff Bezos,  Cloud DevOps Operator
  6. Ken Malcolmson,  DevOps Cloud Engineer
  7. Marc Benioff,  Cloud DevOps Admin
  8. Michael Brown,  Cloud Product Manager
  9. Mike Neil,  Cloud Software Engineer
  10. Satya Nadella,  Cloud DevOps Engineer
  11. Stephen Schmidt,  Cloud Security Engineer
  12. Terry Hanold,  Cloud Operations Engineer

In case it helps, the complete CSV file for this effective permissions audit (pre-hardening) generated using the above tool can be found here.



3. Once you have done so, the third step involves determining HOW these users are currently ending up with these effective permissions, because in order to lockdown access, we will need to know HOW they are ending up with these permissions. Once we know the HOW, we can proceed to make the appropriate changes.

For instance, below, to find out how a user has this extended right effectively granted to them, we simply click on the user's name, and the underlying ACE (/ security permission) is displayed -

Specifically, in the snapshot above, we have been able to determine that Alex Simons, a Cloud Active Directory Administrator effectively has this right granted to him due to the following access control entry in the ACL of the domain root:  Allow root\IT Cloud DevOps Team (All) Extended Right(s).

(It turns out that in this example, the 12 users who should not effectively have this right granted, but do nonetheless, all have this access by virtue of membership in the IT Cloud DevOps Team group.)

We now know which ACE to tweak and/or which security group membership to change to take away this effective right from Alex Simons -




4. The fourth step is to actually make the changes required to lockdown access i.e. to make any necessary ACLing / permissioning changes, and/or changes to any group memberships as required to in effect take away these unintentionally granted (and thus in effect unauthorized) permissions, ultimately resulting in a situation wherein only those who should have this critical right effectively granted, have it granted.

For instance, to lockdown Alex Simon's access, we remove the ACE that was granting this access to the IT Cloud DevOps Team group, and as a result members of that group should no longer have this right granted to them -




5. The last step is to verify that after you have taken the lockdown steps, the resulting effective access is indeed such that only those who should have this critical right granted have it granted, and that no other individuals have this critical right effectively granted to them.

For instance, we simply run the Effective Permissions tool again, and we can see that NOW only those (a very small set of highly trustworthy and authorized) individuals who should be the only ones to have this right effectively granted to them, have it effective granted to them -

In the snapshot above, we can now see and verify/confirm that indeed, only 3 users have this critical right effectively granted to them -
  1. Administrator
  2. DC1
  3. Steve Ballmer,  IT Analyst

In case it helps, the complete CSV file for this effective permissions audit (post-hardening) generated using the above tool can be found here.


In this manner, having enacted these 5 simple steps in just a few minutes, we can easily and reliably lockdown the effective grant of the Replicating Directory Changes All extended right on the domain root, and consequently enact the second essential and necessary measure required to prevent the unauthorized replication of secrets from Active Directory, and to mitigate the risk of the mass credential theft of all domain user accounts in Active Directory.




X. This is VERY Important!

As explained above, it is VERY important that only the absolutely minimum possible number (0/1) of users have this critical right effectively granted to them.


If even one additional user is effectively granted this critical right, and the perpetrators can identify them and compromise their account(s) (credentials), then they will simply be minutes away from being able to steal the credentials of every user in the Active Directory domain, including all privileged users such as all Domain Admins, Enterprise Admins, Built-in Admins etc.

So, in a way, today, the security of an entire Active Directory domain (and thus forest) depends on exactly who effectively has sufficient enough rights to be able to replicate secrets out of Active Directory!

In other words, to put it simply, if this security right grant is not fully locked down, it could be Game Over very quickly.




Summary

To summarize, in this blog post, I wanted to and have shared the following information with you -
  1. How a perpetrator can use the DCSync feature of Mimikatz to steal the credentials of your entire user populace
  2. What makes it possible for the DCSync feature of Mimikatz to work
  3. What mitigation measures we can take to lockdown who can replicate secrets from Active Directory
  4. What are the reasons due to which more people than those allowed by default may effectively have this right granted
  5. Why we need to be able to determine effective permissions precisely to assess and verify who effectively has this right
  6. How to mitigate the risk posed by the DCSync feature of Mimikatz in 5 simple steps (i.e. how to render it useless.)

Organizations worldwide can now use this information to quickly and easily prevent a perpetrator from using Mimikatz' DCSync feature to perform mass credential theft from Active Directory.

Alright, my time's up. I hope you have found this information to be useful and valuable.

Best wishes,
Sanjay



PS: To demonstrate just how deeply we care about cyber security globally, any* organization that wishes to find out exactly how many individuals effectively have this right granted today, can now do so completely free (; via the free Try Now option.)

Friday, July 29, 2016

Active Directory Beyond the MCSE for the Black Hat Conference 2016

Folks,

Today, the reputed Black Hat Conference 2016 kicks off in Las Vegas. It is heavily sponsored by some of the biggest cyber security vendors, and over the next few days, 1000s of attendees will have over 100 briefings to choose from to attend.
The Black Hat Conference

A 100+ briefings. NOW, at the very foundation of cyber security of over 90% of all organizations worldwide, including at the foundation of most organizations that are sponsoring it and attending it, lies the bedrock of enterprise security in a Windows Server based IT infrastructure - Active Directory, and guess how many briefings out of 100 are on Active Directory Security?

1. In case you didn't get that, I'll spell it out: ONE.  ( Uno, Un, 一, один, एक.)  moja (that's 1 in Swahili for crying out loud!)

That's right, ladies and gentlemen, at the very foundation of cyber security of over 90% of all organizations worldwide lies Active Directory, and the Black Hat Conference 2016 has 1 briefing on it's security, titled Active Directory Beyond the MCSE.

Although I needn't say a word more, because the Black Hat Conference Review Board's selection of briefings only seems to have exemplified a global lack of gravitas on the paramount subject that is Active Directory Security, I will. Seriously, 1/100?

By the way, the abstract for the briefing Active Directory Beyond the MCSE by Sean Metcalf (whose efforts I respect) begins with - "Active Directory is leveraged by 95% of the Fortune 1000 companies for its directory, authentication, and management capabilities." The word leveraged may be an understatement because it suggests that these organizations have a real choice.




Active Directory - An Organization's Most Valuable Digital Asset

In reality, in a Microsoft Windows Server based IT infrastructure, Active Directory is the very foundation of distributed security (network authentication, resource authorization and auditing) and in fact the very lifeline of the network. In reality, please know that in a Microsoft Windows Server based IT infrastructure, not a LEAF moves without the Active Directory being involved.


So, allow me to share the paramount importance of Active Directory Security with you - "Should an organization's foundational Active Directory deployment be compromised, its very foundation of cyber security would have been compromised." Period.

Should your Active Directory be compromised, from privileged user accounts to executive accounts (CEO, CFO, CIO, CISO etc.), and from the entirety of your hosts to the entirety of your data, everything could potentially be instantly compromised.

Need one say more?


In fairness, the Black Hat Conference Review Board did have an opportunity to demonstrate gravitas and double that ratio to (a still dismal) 2/100, because a briefing titled - "How to (i.e. an intruder could) own a Microsoft Active Directory deployment within minutes  / Zero to Enterprise Admin within Minutes." was also submitted. Unfortunately, to Black Hat's own loss, it was declined.

Let me repeat that. A briefing titled "Active Directory Beyond the MCSE" by a MCM was accepted, but a briefing titled "How to own a Microsoft Active Directory deployment within minutes" by an ex-Microsoft Active Directory security expert was declined.

To us, it made no difference. For thousands of Black Hat attendees though, they're unfortunately going to miss out on learning about something profoundly important - the existence of 1000s of easily exploitable privilege escalation paths that lie (literally) within the foundational Active Directory deployments of their employer's organizations, and jeopardize their security today.




Billions of ACLs within Active Directory Deployments Worldwide (An Attack Surface the Size of the Pacific Ocean)

Folks, today, in thousands of Active Directory deployments across the world, right within these Active Directory deployments, lie billions of access control lists (ACLs) protecting billions of vital Active Directory objects, which represent administrative accounts and groups, executive and employee user accounts, all domain computers accounts, all domain security groups, service connection points, group policies, contacts, and the entirety of Active Directory configuration content (including the Schema, the Configuration partition, the System container, the domain root object etc. etc.) The list goes on and on and on...


... yet, virtually no organization seems to know exactly who has what privileged access in their foundational Active Directory.

In short, if you're into Active Directory security, you'll want to (literally) look INTO Active Directory, and if when you'll look inside, you'll find an ocean of security permissions protecting Active Directory objects, with the ratio of permissions to objects exceeding 50:1 on average. Domain Admins are just the tip of the Iceberg in this ocean of Active Directory and its security permissions.

In fact I doubt anyone at the Black Hat Conference 2016 has any idea how to actually analyze these billions of ACLs worldwide to determine exactly who has what effective access across organizations worldwide. We were happy to open the world's eyes into this vast ocean that lies within Active Directory, and show them just how easy it is for intruders to connect the dots and obtain the keys to any door in the kingdom, as well as the Keys to the Kingdom. Unfortunately for the conference's attendees, thanks to the Conference Review Board's probable lack of understanding of this stuff, we're not going to (be) do(ing) that.

Oh well, I'm sure the Review Board must have had its reasons. They all seem to accomplished experts and we wish them well.


My time is very valuable, so I will leave it at this.

But I will pose just one question to the Black Hat Conference Review Board because it impacts global cyber security today. Of course, any presenter at Black Hat 2016, as well as any sponsor of Black Hat 2016 may also feel free to answer the question -




A Simple Question -

With the introduction of the DCSync feature in Mimikatz, the security of an entire Active Directory deployment (and by extension the security of the very foundation and thus the entirety of that organization) boils down to this:
Anyone who effectively has the Get Replication Changes All extended right granted to them in the access control list (ACL) protecting the domain root object can now easily compromise the credentials of all Active Directory domain accounts, including those of all Active Directory privileged user accounts, and 0wn the organization.

It logically follows that only the absolute bare minimum (0/1) number of individuals should effectively have this right granted.

Now, though by default, only the most highly privileged administrative personnel have this right effectively granted, since most Active Directory deployments have been around for many years, in almost all of them, the ACL protecting the domain root may have been modified several times, and as a consequence the default access may have changed substantially, resulting in a situation wherein a potentially excessive number of individuals might effectively possess this right, yet no one may really know exactly how many individuals effectively have the Get Replication Changes All extended right granted today, and who they are.

ACL on the domain root object in Active Directory

Thus today it is imperative and paramount for every organization in the world to know exactly who effectively has the Get Replication Changes All extended right granted in the ACL of their domain root object, and how they have it. (The need to know how is essential for being able to lock-down access for all those who currently have this critical access effectively granted, but should not have it.)

So the simple $100B question is -
"Precisely HOW should 90% of organizations worldwide (i.e. those that operate on Active Directory) make this paramount determination in their foundational Active Directory deployments?"  i.e. how do they find out exactly who effectively has the Get Replication Changes All extended right granted in the ACL of their domain root object, and how they have it?

By HOW, I mean that I'd like for someone (anyone) to demonstrate how to make this determination accurately and in a timely manner, in a real-world Active Directory environment, where there might easily by a 100+ permissions specified in the domain root ACL, each permission allowing or denying some form of access to some user, group or well-known security principal.

I look forward to an answer from the Black Hat Conference because it directly impacts foundational cyber security worldwide.

What else could be more important than denying perpetrators the 2nd easiest opportunity to 0wn entire Kingdoms worldwide?



I'll let you be the judge of whether or not this is important enough to have been presented at Black Hat, especially in light of this.

Best wishes,
Sanjay



PS: In fairness, I did ask them too - A Simple $100B Active Directory Security Question for Alex Simons at Microsoft.

PS2: I will answer this question in a few days, right here on this blog as well as there on that blog.

Tuesday, July 19, 2016

Time to teach the World a thing or two about Active Directory Security

Folks,

If you understand cyber security, then you know that at the very foundation of cyber security worldwide lies Active Directory.

Over the last ten years, we've had thousands of organizations worldwide knock at our doors to request our assistance, so we have a very good idea of just how much organizations know about Active Directory Security today. (And we worry.)

Microsoft Active Directory

Today, even those considered Active Directory security experts and cyber security experts by some, don't seem to know much about what truly constitutes Active Directory Security, i.e. the innards of Active Directory security. In fact, for years, they've merely been operating at the periphery of Active Directory Security, yet, they've managed to make quite some noise.

Unfortunately, today most organizations remain vastly vulnerable. So, to help experts worldwide, and to help Microsoft and its global ecosystem, I think its time that we teach the world a thing or two about Active Directory Security, so they can elevate the level of knowledge at which they operate, and perhaps actually address the most critical of all Active Directory security risks.

In days to come, you can expect us to shed light on some technicals that actually do pertain to Active Directory Security.

You may want to stay tuned.

Best,
Sanjay

Friday, July 15, 2016

Praise for Sean Metcalf of ADSecurity.Org + Active Directory Security 101 for the World and the Black Hat Conference 2016

Folks,

Today, as former Microsoft Program Manager for Active Directory Security, I'd like to take a few minutes to publicly recognize and praise the efforts that Mr. Sean Metcalf has put in over the last few years to help raise awareness about the importance of (and weaknesses in) Active Directory Security.

[Quick process note - you'll want to read this blog post in its entirety.]

For those of you who may not know Sean Metcalf, he runs the ADSecurity.org website, and is a Microsoft Certified Master (MCM) in Directory Services. He has also spoken at numerous conferences such as Black Hat, Def Con, DerbyCon etc.
Sean Metcalf presenting at Black Hat 2015
Today, as a valued consultant, he helps many organizations assess the security of their Active Directory deployments.

I do not know him personally, nor have I ever met him, but I've heard of his efforts, and I appreciate them and wish him well.




Praise for his Efforts

Folks, I believe Sean's journey into Active Directory Security began in 2011, i.e. almost 5 years ago, when he was inspired by an email from his friend. In March of 2011, he committed to his friend that he would pass all the tests required to be an MCITP:EA in 2 months! Keep in mind that around that time he was also the proud father of 1-year old triplets, so you can imagine how determined he must have been to succeed.

Fast forwarding to February 2012, on Super Bowl Sunday, he attended the elite Microsoft Certified Master (MCM) Directory Services Program in Building 40 at Microsoft headquarters in Redmond, WA. (I have fond memories of Building 40 as I spent 4 years of my own life in it (2001-2005.))

At 9:00 pm on February 21st, he received an email which read - “Congratulations! You have earned the Microsoft Certified Master | Windows Server 2008 R2 Directory certification!
During his journey thus far, he has put a lot of effort and acquired a wealth of knowledge, starting from the very basics.

Speaking of basics, for instance, he once learnt the optimal way to find users in Active Directory, and another time he learnt how to Active Directory recon without requiring admin rights. (Of course, since Authenticated Users have blanket read access in Active Directory, performing AD recon requires no admin rights whatsoever. Zilch. Its easy-peasy, and today anyone can do substantial basic AD recon with this free tool at a button's touch.) Over the years, he continued on to gain advanced knowledge.

Over the last few years, Sean has put in a considerable amount of effort on researching numerous aspects of Windows and Active Directory Security and sharing his research online via 70+ posts at his blog.

In doing so, he has helped many organizations gain a deeper understanding of various aspects of Active Directory/Windows Security, predominantly vulnerabilities involving Microsoft's implementation of Kerberos and related attack vectors such as Pass-the-Hash, Pass-the-Ticket, Kerberos Golden Tickets, as well as related tooling (e.g. Mimikatz) etc.

Great work, Sean!  The world could use more people like you, so thank you again for all your efforts.





First Things First

Sean had recently posted a blog entry on Attack Methods for Gaining Domain Admin Rights in Active Directory, and in it he lists a few attack vectors -
  1. Passwords in SYSVOL & Group Policy Preferences
  2. Exploit the MS14-068 Kerberos Vulnerability on a Domain Controller Missing the Patch 
  3. Kerberos TGS Service Ticket Offline Cracking (Kerberoast)
  4. The Credential Theft Shuffle 
  5. Pass the hash evolves into Pass-the-Credential 
  6. Gain Access to the Active Directory Database File (ntds.dit)
Sean has done a good job in providing adequate details and mitigations for each of them. In days to come, time-permitting, I'll shed some more light on them. For now, the salient part of that blog post, which is in the first paragraph is worth noting:


"The techniques described here “assume breach” where an attacker already has a foothold on an internal system and has gained domain user credentials."

(Hmm. If one were to assume breach, and knew how to do this, or had this or this, the Kingdom would be 0wned in minutes.)

In contrast, each of the attack vectors listed above seem like they take way too much effort to compromise an Active Directory, in comparison to the most potent, effective and powerful Active Directory attack vector which unfortunately is not on that list yet i.e. this one. In days to come, I'll share more details on it, in a blog post titled - Breach to Owned in 5 Minutes.

By the way, when I say 0wned, I mean its Game Over. The attacker will have attained complete control over the entire Active Directory forest, and there's nothing anyone will be able to do to stop him. Period.





Active Directory Security 101 for the World, and for the Black Hat Conference 

Since Sean will be presenting at Black Hat in a few days, I think Sean will likely agree that during his journey, he too must have realized that Windows Security and Active Directory security are vast subjects and there's an ocean of knowledge to be gained.
I say so from my own personal experience, because as former Microsoft Program Manager for Active Directory Security, here are just a few areas of Windows Security I had to master back in 2001 -
Distributed Security, AuthN, Authz, Auditing, Winlogon, Kerberos, NTLM, Digest, SSPI, SPNEGO, Mutual Auth, Logon Sessions, Windows Stations, Profiles, LUIDs, Access Tokens, SDs, ACLS, ACEs, Privileges, Rights, SMB, Lan Manager, NULL Sessions, Names Pipes, COM, SSL, TLS, SChannel, SAM Server, Federation, DCs, DS Repl, Trusts, SID Filtering, LDAP, DPAPI, SAML, Effective Permissions, PKI, Name Mappings, GCs, DNTs, DC Locator, ESENT, ADAM, ADFS, WinLogon, SID History, TDOs, TLNExclusions, ANR, Cross Refs, msDsQuotas, DFS, FRS, LVR, Credman, PAC, Windows Integrated Auth, DBDump, userAccountControl, Constructed Attributes, PDC Chaining, SAML, ADAM, RODCs, FGPP, Certificate Services,  Token Bloat, Password Resets, Active Directory Privilege Escalation and about 100 other topics that come to mind.

Now, during the last few years, thanks mostly to a little bit of creative systems programming efforts of a certain Mr. Benjamin Delpy, what was until then deemed theoretical came to life, creating a menace for Microsoft's ecosystem and endangering the security of thousands of organizations, and ultimately leading to Microsoft putting in a lot of effort to introduce many new security features, acquiring a company or two, and releasing guidance on how organizations could protect themselves from credential theft and reuse attacks. Impactful work on Mr. Delpy's part though, as it helped enhance Windows security.

(On a lighter note, interestingly, given how corporations work, Mr. Nadella and company might even use this to tout Windows' 10 new security features and continue their aggressive push to get the world on Windows 10, whether or not people want it ;-))


(Also interestingly, it appears that the largest financial beneficiary from Mimikatz may possibly have been a little Israeli start-up named Aorato, given its recent acquisition by Microsoft, albeit for petty change. Recently, interesting to see the former VP of Research at Aorato exchange notes with Mr. Delpy on Twitter quite a few times. Hmm ;-) By the way, on a lighter note, not too long ago, a few years ago, one day, someone at Aorato sat thinking for two hours (as to) how to build an attack path, and then realized that everyone has access to Active Directory! Hilarious!! - that video's here (2:10 onwards.) But I digress.)



Anyway, in all of this hoopla, a few CARDINAL points, including the world's #1 attack vector, seem do have gotten drowned -


1. Mimikatz requires local admin credentials to run on a Windows machine. To the uninformed, Mimikatz might sound like wow, but to the informed, it is merely an artifact of the a simple security truism - "You cannot prevent the administrator of a machine from controlling its Trusted Computing Base (TCB)." Conceptually, all Mimikatz does is inject code into LSASS and utilize the Crypto API to do a few things that can lead to credential harvesting, replay and misuse.  I'm not belittling it; I'm just saying its just a system-level routine running as admin injecting code into LSASS and exploiting a few features in Windows designed to make network authentication a little more seamless.
2. Kerberos Golden Tickets require the NTLM password hash of the domain's KRBTGT account, which can only* be obtained by logging on to a Domain Controller as Admin. In other words, in order to acquire a Kerberos Golden Ticket, you at a minimum* need to have logged on as Admin on a Domain Controller. Any kid in Kindergarten will tell you that if you can logon to a Domain Controller as Admin, you already OWN the entire Active Directory forest! So, you don't need to work so hard (i.e. dump LSASS etc.) after that to get anywhere! Simply spawn a process as SYSTEM and you can play GOD in seconds! So again, what's the big deal here?
* Last year, a DCSync feature was added to Mimikatz, allowing it to be able to request and obtain from Active Directory, all data including account password data from a targeted Domain Controller. Again, to the uninitiated, this might sound like Wow, but to some of us, this is hardly surprising. Here's why. In order for the "DCSync" feature to work, the attacker requires that he/she effectively have the DS-Replication-Get-Changes-All extended right set on the domain root. Er, I wrote Microsoft's Whitepaper titled Best Practices for Delegating Active Directory Administration way back in 2003, and as early as then, we have said very clearly that if you have this right, you can in effect replicate password data out from the Active Directory, and play G0D!
Here's the extend right listed in Appendix D of my delegation whitepaper, published online as early as 2003. Point being that if you have this extended right granted in ACL of the domain root object, you already are for all practical purposes a God-like Admin, so what's the big deal here

In short, to the uninitiated, all this hoopla caused by Mimikatz and the like may be wow-worthy, but to some of us, its just an example of someone utilizing some advanced Windows Security programming to convert a theoretical risk into reality.

In all of this hoopla, over the last few years, the world seems to have completely ignored (and thus still remains highly vulnerable to) the biggest risk to Active Directory security - that of Active Directory Privilege Escalation based on the identification and exploitation of unauthorized effective access grants in Active Directory.




Some Dots to Connect

Those who know how to exploit that risk can, given access to a single insider's credential (non-admin domain user/computer account) likely take over and shut down virtually any Active Directory forest, within minutes, from any domain-joined machine,WITHOUT requiring a SINGLE admin to have logged on an 0wned machine, let alone requiring the ability to logon to a DC as admin -

Active Directory Privilege Escalation

By the way, password resets are simply one out of umpteen ways to exploit this system-wide weakness. Group membership changes, group policy link changes, service connection point keyword changes, sensitive ACL modifications, disabling two-factor authentication, etc. etc. all fall under this attack vector. So, its a little more than just password resets.

In fact, 99% of the world doesn't know much about this risk. Those who do know that it poses a substantially greater cyber security danger to the world, than do these basic credential-theft attacks. I'll spare the details for another blog-post, and/or if you are really interested, and you're good at connecting dots, here are some dots for you to connect -
Dot 1 - The Paramount Brief 
Dot 2 - The Attack Surface
Dot 3 - The Attack Vector
Dot 4 - Five Minutes
Dot 5 - An Interesting Picture
Dot 6 - 100% Mitigatable

In short, while we've seen Mr. Metcalf and 1000s of IT personnel worldwide focus on Kerberos related attacks, or simple SYSVOL related attacks etc. etc., we've not seen anyone talk about this huge security hole that's the size of the Pacific Ocean in virtually every Active Directory deployment out there.





Billions of ACLs (The Pacific Ocean)

Folks, today, in thousands of Active Directory deployments across the world, right within these Active Directory deployments, lie billions of access control lists (ACLs) protecting billions of vital Active Directory objects, which represent administrative accounts and groups, employee user accounts, all domain computers accounts, all domain security groups, service connection points, group policies, contacts, and the entirety of Active Directory configuration content (including the Schema, the Configuration partition, the System container, the domain root object etc. etc. etc.) The list goes on and on and on...


... yet, virtually no one in any organization has any idea as to who can truly do what in their foundational Active Directory.

In short, if you're into Active Directory security, you'll want to (literally) get INTO Active Directory, and if when you'll look inside, you'll find an ocean. Domain Admins are just the TIP of the Iceberg in this ocean of Active Directory security permissions.





10 SIMPLE Active Directory Security Related Questions -

To Sean Metcalf and other Active Directory security focused cyber security experts in the world, including those at Microsoft, I would like to most respectfully pose a few very simple, fundamental, elemental Active Directory security questions to consider -


In any production Active Directory forest in the world, does anyone know -
1. Exactly who has the Replication Get Changes All extended right effectively granted in the domain root's ACL?
2. Exactly who can change the security permissions in the ACL on the domain root object?
3. Exactly who can reset the password of all Built-in-Admin, Domain Admin and Enterprise Admin accounts?
4. Exactly who can disable the use of Smartcard authentication on accounts in Active Directory? 
5. Exactly who can change the security permissions in the ACL of the AdminSDHolder object?
6. Exactly who can control linking the default Domain Controller Policy?
7. Exactly who can control linking the default Domain Policy?
8. Exactly who can delete Organizational Units (possibly containing 1000s of objects)?
9. Exactly who can set the Password not required bit on Active Directory domain user accounts?
10. Exactly who can set the Trusted for Unconstrained Delegation bit on computer accounts in Active Directory?

You see, not only are these simple, elemental, fundamental questions directly related to Active Directory security, they impact the foundational cyber security of business and government organizations worldwide, and that's why Active Directory administrators, security experts and IT teams worldwide (including Microsoft IT) must have answers to these at all times.

Not only that, for those that may not know this, these questions also directly impact the effectiveness of Mimikatz, and the degree to which a hacker could use Mimikatz in his/her efforts to compromise an organization.

In fairness to Sean Metcalf, in one blog post, he did very briefly touch upon the topic of delegated access in Active Directory, and I quote from this post -
Not tracking/monitoring/documenting delegated access to Active Directory -
"The best way to administer Active Directory and associated resources is to create custom groups and delegate specific access for these groups. If this isn’t planned and executed properly, this delegation can get out of control enabling far greater resource access for accounts than planned. Regular auditing of groups and their access is required to properly ensure Active Directory security. Don’t use the existing default groups to delegate rights to custom groups (ex. Help Desk members in “Account Operators” group) since the default groups provide more rights than are typically required. Delegation can be properly leveraged to ensure appropriate rights for each admin group. This requires gathering true requirements in plain English and translating them to system access rights."

For completeness, this good advice could have been rounded off with an appropriate concluding sentence such as: "Likewise, because delegations can be changed by many, anytime, it is very important to assess them frequently. This requires analyzing effective system access rights, and translating them back into plain English." (i.e. in other words, this or this.)

But if you look closely, in the 70+ posts on Active Directory security, at most a handful of them have touched upon the subject of administrative delegation, and unfortunately, none talks about "assessing who is delegated what access".

Again, in complete fairness to him, behind the global ignorance on this subject lies an aging behemoth's own ignorance.





A Trillion $ Keyword

If you find yourself thinking too hard about the above questions, don't sweat it. I'll give you a hint.



The answer to the above questions lies in a very simply, fundamental, elemental concept that no one, including the world's top/popular cyber security companies, such as Microsoft, Cisco, IBM, Google, Amazon.com, EMC, Dell, HP, CA, Centrify, Palo Alto Networks, FireEye, CyberArk, Beyond Trust, Leiberman Software, Thycotic, Checkpoint Software, Palantir Technologies, Kasperky Labs, Tripwire, DarkTrace, Lockheed Martin, BAE Systems, Tanium, BAH, etc. etc., likely has a clue how to (or the ability to) accurately and efficiently determine - this.

Or for that matter, something like this, this and this (and if you're smart, you'll understand the power of this.)

By the way, in all likelihood, even the cyber security companies listed above most likely don't have the answers to the above questions in their own foundational Active Directory deployments. (Speaking of which, "magic-quadrants" etc. are laughable!)

More on all this in days to come.

Oh, and in case you happen to chance upon this and think it will do it, let me tell you that that piece of software is not only woefully inadequate, it is dangerously inaccurate. I cannot over-emphasize the "dangerously" part. Virtually the same is true of this, this and almost anything else out there.

So, if anyone knows anyone in the world that possesses the ability to accurately answer even ONE of the questions listed above in any production Active Directory deployment, I'd like to know.






Time's Up

Unfortunately, my 10-minute timer just rang, so my time's up. I'll have to end this here.


All said and done, Sean has done a great job on helping people understand the importance of Active Directory Security thus far, and it is my hope that he will continue to expand his knowledge and continue to share it with the rest of the world.

Please know that my praise for Sean is sincere, and should not be taken any other way. The objective of this blog post was two-fold - to praise Sean's tremendous efforts thus far, and to help the world understand just how much more there is to learn in the ocean of a subject called Active Directory Security.

In all seriousness, the sheer amount of effort he has put in to help the world understand the importance of Active Directory security, and shed light on various attack vectors is clearly noticeable when you visit his blog, and is praiseworthy.


Before I sign off, I should mention that when he received his MCM certification, Sean Metcalf (deservingly and humbly) shared -
"NOW I AM A MICROSOFT CERTIFIED MASTER in Directory Services, 1 of only about 100 in the WORLD!"

As former Microsoft Program Manager for Active Directory Security (I believe 1 of only about 1 in the world) I'd like to congratulate him on his hard-earned accomplishments and contributions over the years.

So much effort, and great work, Sean! Please keep up the good work. If I can help you in any way, please do not hesitate to let me know. As you'll hopefully agree, there's so much more for everyone to learn, and here are three helpful pointers to get started - one, two and three.

Best wishes.
Sanjay


PS: Sean, good luck at Black Hat 2016. Unfortunately, thanks to the Black Hat Review Board's lack of knowledge on Active Directory Security, I won't be attending Black Hat. If you want to know why, just ask them to share the email I sent them.

PS2: If you're into cyber security, you may find this this blog interesting.