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.


Showing posts with label Black Hat Conference. Show all posts
Showing posts with label Black Hat Conference. Show all posts

Wednesday, December 27, 2017

How to Easily Solve the Difficult Problem of Active Directory Botnets


Folks,

The year's almost coming to an end, and I just realized that one of the topics that I had not yet addressed as a part of my basic Active Directory Security School for Microsoft was this inane topic of Active Directory Botnets so today's post is on AD Botnets.

There's less than 100 hours left this year, and I value every minute, so this one's going to be short, yet sufficient.



Active Directory Botnets


Earlier this year, one of the two presentations on Active Directory Security at the famous Black Hat Conference USA 2017 was titled - The Active Directory Botnet. (The other one was An ACE Up the Sleeve - Designing Active Directory ACL Backdoors.)

Both of these presentations seem to have gotten a lot of attention, and as to the presentation on Active Directory Botnets, its authors said that this is (and I quote) "a nightmare of an implementation error with no easy fix!"


Well, today I'll show you just how easy it is to solve/fix this supposedly difficult problem :-)

In today's post, I am not going to go into the details of how attackers could set up these botnets because my focus is on helping organizations eliminate the very possibility of this issue, so if you're interested in the technical details, here are a few pointers -
  1. The slides of the presentation titled The Active Directory Botnet that was made at the Black Hat Conference 2017
  2. A video of the presentation titled The Active Directory Botnet that was made at the Black Hat Conference 2017
  3. A short interview with the presenters of this presentation.

Since my purpose is on helping organizations mitigate this issue, I'm going to focus on the mitigation aspect.




What Makes This Possible

In order to find out how to easily mitigate this issue, it helps to first understand what makes this issue possible in the first place.

Here's the short of what makes this all possible  -



As you may know, Active Directory, being the very foundation of cyber security in a Microsoft Windows Server network, stores and protects the entirety of an organization's domain user accounts, security groups, computer accounts, security policies etc.

As you may also know, in Active Directory literally everything is an object, and an object is essentially a collection of numerous attributes, as defined in the Active Directory Schema. So for example, there exist attributes for elements such as a user's first name, last name, password, manager, contact details, address details, user profile, a picture etc. etc.

Further, Active Directory's powerful security/delegation model makes it very easy for IT personnel to provision access in Active Directory for various stakeholders, to fulfill business needs wherein these stakeholders may need to be able to modify any of these fields/attributes. For example, if an HR application may have a need to change the Manager field/attribute on user accounts, such access can be very easily and precisely delegated for that HR application's service account.

Now, it turns out that by default, Active Directory also lets all domain user account holders modify certain fields/attributes on their own domain user accounts. Examples of such fields/attributes include Address, Assistant, Personal-Title, Phone-Home-Other, Phone-Ip-Other, Picture, Street-Address, WWW-Home-Page  etc. to name a few.

These attributes could store values of various data-types, so for instance, while some could simply and solely store a text string, others could store a distinguished name, and still others could store binary data. An example of an attribute that can solely store a text value is Surname and an example of an attribute that can store binary data is Picture.

Finally, to simplify access control, numerous such related fields/attributes can be aggregated together into an Active Directory construct known simply as a Property-Set.

Examples of Active Directory Property Sets include Personal Information, Private Information, Web Information, etc.


Tying all of the above together, in the access control list (ACL) of every domain user account, by default there are explicit access control entries (ACEs) that grant the security principal Personal Self, the ability to modify the Personal Information, Phone and Mail Options and Web Information property sets. Since the Personal Self  security principal on an Active Directory user object maps to the domain user account itself, the presence of these security permissions provides sufficient effective access to the domain user account holder to be able to modify all the attributes that are members of these property sets!

Now, imagine a scenario wherein the computer onto which this domain user account usually logs on has been compromised. In that scenario, the attacker could now have malicious code run in the security context of this domain user account, and if so, then one of the things that malicious code could do is update these attributes on the user's domain user account! 

In such a scenario, how the attacker chooses to use this default ability to update these attributes in Active Directory is purely a function of his/her imagination, and it so happens that in this particular case, the presenters of that specific presentation at Black Hat came up with a scenario wherein attackers could choose to use this default access granted to domain user accounts to introduce and operate Botnets in Active Directory environments!






How to Easily Solve the Supposedly Difficult Problem of
Active Directory Botnets -

According to the authors of this presentation, this is (and I quote) "a nightmare of an implementation error with no east fix!

If you ask me, I'll tell you "this is an issue that can be mitigated in minutes, and here's how" -



All that organizational IT personnel need to do is write a simple script whose purpose is simply to remove those explicit ACEs in the ACLs of domain user accounts in an Active Directory that grant the Personal Self security principal Write-Property permissions to the involved property sets.

Specifically, here are the three explicit ACEs that you may want to remove -
  1. { Allow   SELF   Read/write personal information }
  2. { Allow   SELF   Read/write phone and mail options }
  3. { Allow   SELF   Read/write web information }

Such a script can be written and be executed within minutes, and once it has been executed, there should no longer* be any ACEs in the ACLs of the organization's domain user accounts that would allow these domain user accounts the ability to modify these attributes on their own objects, and as a consequence, perpetrators will no longer be able to leverage this default modify access in Active Directory, resulting in a situation where this issue would no longer be an issue at all, since the underlying enabler of this issue would have been eliminated!
* Kindly see sections titled A Caveat and An Advanced Tip below

It really is as simple as this! That's it!


Now, some might ask - "But wouldn't this impact the ability to users to modify such attributes in Active Directory and/or cause potential application compatibility issues if certain apps were relying on this default access to properly function today?!"

The answer to that question is that realistically speaking, domain user accounts holders should not ideally possess any level of modify access in the Active Directory, and most likely no default applications should be relying on this default access granted to domain user accounts to function, so the application compatibility impact of making this change could be none to minimal.
Disclaimer: Organizations know their unique Active Directory environments best, so before acting on this advice, organizations will want to ensure that there in fact are no Active Directory integrated applications or business use-cases that leverage this default modify access granted to domain users on their accounts. This advice is provided on a best-efforts basis and your use of it is subject to our Terms of Use.

That's literally all there is to it, and that is literally how easy it is to solve this inane problem!





One Caveat

There is ONE caveat that could possibly still enable a perpetrator to still try and leverage the limited write-property access that might remain even after you remove each one of those explicit ACEs that grant SELF modify access to those property sets.

Here's the caveat - at the domain root, there is an inheritable permission specified that is inherited by all objects, including all user objects, and it grants SELF the ability to read and write the Private Information property set -  { Allow   SELF   Special }



Members of the Private Information property-set include* - 
  1. ms-PKI-Credential-Roaming-Tokens
  2. MS-PKI-RoamingTimeStamp
  3. MS-PKI-DPAPIMasterKeys
  4. MS-PKI-AccountCredentials
* This property-set has the above four members in Windows Server 2008 R2 and beyond.


As a result, theoretically speaking, a perpetrator could possibly try to use these attributes to achieve the same mal-effect.

However, in practice, should the system be using these attributes, then any values that the perpetrator might write into these attributes will likely get overwritten by whatever the system writes into them, thus in practice rendering that option infeasible.

Of course, if you know for a fact that these attributes are not being used in your environment, then you can simply remove this ACE from the domain root, which will then have the effect of it being removed from all domain user accounts as well.
Disclaimer: Organizations know their unique Active Directory environments best, so before acting on this advice, organizations will want to ensure that there in fact are no Active Directory integrated applications or business use-cases that leverage this default modify access granted to domain users on their accounts. This advice is provided on a best-efforts basis and your use of it is subject to our Terms of Use.





An Advanced Tip

Those who know the subject well know that even if each one of these ACEs no longer exist, a user could still possibly have sufficient effective permissions so as to be able to modify one or more attributes on the domain user account, should there be other permissions in the ACL of the account that might effectively grant the user sufficient effective access so as to be able to do so. The only way to correctly find out whether or not a user can in fact still modify attributes on his/her domain user account is by accurately determining Active Directory effective permissions on that domain user account.

Gold Finger Active Directory Effective Permissions Calculator

For instance, in the snapshot above, one can see that on the domain user account of a user, Jeff Bezos, the user Jeff Bezos still has write-property effective permissions to the Phone-Ip-Other attribute (which is a member of the Personal Information property-set), and he has this access on his own account not by virtue of those SELF ACEs but in fact by virtue of the fact that there exists an ACE that grants the IT Cloud DevOps Team domain security group, of which he is a member, Write-Property information to the Personal Information property set.

The likelihood of this is low, yet in the interest of completeness, since it is always a possibility, I felt the need to mention this, and security conscious organizations will want to take Active Directory Effective Permissions into account for completeness.





Summary

Today, I just wanted to take a few minutes to share with you just how easily organizations worldwide can solve this supposedly difficult problem of Active Directory Botnets! Of all the problems I've helped solve this year, this one was by far the easiest.


The short of it is that this inane issue can be mitigated within minutes by simply using basic scripting to remove the very ACEs that grant domain user accounts the ability to modify the attributes that this attack vector leverages. It really is as simple as that!

I apologize if this post was short and to the point. I usually spend a lot more time on my posts, but its almost the end of the year, and my time is very valuable, so I decided to keep it short. Besides this is so easy, that it only needed minutes to address.

Best wishes,
Sanjay

Wednesday, October 18, 2017

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

Folks,

As I briefly mentioned earlier, a few weeks ago, at the Black Hat Conference 2017 (which we skipped) on Cyber Security, two fine gentlemen made an interesting presentation titled An ACE Up The Sleeve - Designing Active Directory DACL Backdoors.


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

With full respect to its authors, I will say that for someone who may have been relatively new to this subject (which most cyber security pen testers, ethical hackers and hackers are these days) and coming from a mainstream pen-testing/attack background (i.e. generally focused on and employing local credential-theft attack-vectors) they got close to actual sneaky persistence in AD.


Incredulously and amazingly, perhaps because a majority of cyber security experts (both, defenders and attackers) and IT pros may not know Active Directory Security that well, this presentation has been garnering a lot of attention, including at Microsoft.


Here's proof - In the last ONE month alone, Microsoft's Advanced Threat Analytics (ATA) Team has published TWO blog posts in response to this presentation (on Sep 18 here and on Oct 11 here), so this clearly seems to have Microsoft's attention!

Speaking of which, here's a quote from Microsoft's latest blog post regarding this topic/presentation - "In general, this is a very important goal for an attacker and is a big part of a successful mission performed either by a nation state or by a hacker group."

Wow!   Hmm.    Keep reading ;-)





How to Easily Thwart Sneaky Persistence in Active Directory

I may no longer officially be an employee of Microsoft, but I am former Microsoft Program Manager for Active Directory Security, and just because I work for a different company now, that neither diminishes my knowledge nor my passion to help the world.


So, in a few days, right here, to help organizations worldwide, including to help my fine colleagues at Microsoft who seem to be struggling to figure out how to deal with this, I will share just how EASY it is to thwart sneaky persistence in Active Directory -


If you truly understand Active Directory Security, then you know that there are far greater challenges facing most organizations worldwide, so to help put this behind them, and to adequately address that whitepaper, I'll pen an insightful post on the subject.


BTW, in the whitepaper, regarding Defenses, the authors state - "Some defenders may believe the detection of these types of backdoors is a lost cause... ...the primary method for detection and investigation remains properly tuned event logs for DCs...  ... one interesting defensive tool is the use of AD replication metadata." etc. It appears these wonderful folks are trying too hard!

Oh, and the most amusing part is to see Microsoft try even harder, and I'm quoting this verbatim from here - "This does sound like an issue...  ...so, this made me think - Is there a way we can identify all the objects to which I don't have permissions?;-)


This one's actually quite simple.  The answer, coming up, in a few days...

Best,
Sanjay

CEO, Paramount Defenses



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

Wednesday, July 26, 2017

An ACE Up the Sleeve: Designing Active Directory ACL Backdoors

Folks,

Earlier today, two fine gentlemen gave a nice presentation titled An ACE Up the Sleeve: Designing Active Directory ACL Backdoors at the Black Hat Conference 2017.


Here's the abstract of their presentation -
"Active Directory (AD) object discretionary access control lists (DACLs) are an untapped offensive landscape, often overlooked by attackers and defenders alike. The control relationships between AD objects align perfectly with the "attackers think in graphs" philosophy and expose an entire class of previously unseen control edges, dramatically expanding the number of paths to complete domain compromise. 
While DACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence. It's often difficult to determine whether a specific AD DACL misconfiguration was set intentionally or implemented by accident. This makes Active Directory DACL backdoors an excellent persistence opportunity: minimal forensic footprint, and maximum plausible deniability. 
This talk will cover Active Directory DACLs in depth, our "misconfiguration taxonomy," and enumeration/analysis with BloodHound's newly released feature set. We will cover the abuse of AD DACL misconfigurations for the purpose of domain rights elevation, including common misconfigurations encountered in the wild. We will then cover methods to design AD DACL backdoors, including ways to evade current detections, and will conclude with defensive mitigation/detection techniques for everything described."

I didn't have to be there to know that this would be a well-received and fascinating presentation.  Nice work, gentlemen!



The World of Active Directory ACLs

I'd like to welcome them to the important world of Active Directory ACLs. Even though they may have recently discovered this fascinating world, they're still far ahead of thousands of organizations worldwide, which only goes to prove what I've said here.

Active Directory ACLs

Given how much time they may have spent on Active Directory ACLs (even in just the last few months), they'll likely get this.

Let me tell you that they are a 100% correct that within the ocean of Active Directory ACLs that exists in every Active Directory deployment worldwide, there are a million (pl)ACEs for a intruder/perpetrator/insider to hide within, oh, and for anyone who knows how to find them, there are also thousands of  exploitable Active Directory privilege escalation paths to find.

They may also have shown you how to design Active Directory DACL backdoors, including ways to evade current detections, assuming by current detections, they're referring to the use of existing tooling like dsacls, acldiag, PowerShell scripts, <fill in the blank with your favorite Active Directory ACL analyzer/permissions audit tool> to analyze Active Directory ACLs, you know the tools most IT personnel having been using for years at 1000s of organizations because Microsoft never educated them better.

Fortunately, and they may not know this, organizations that possess the right tooling can now easily identify and eliminate all such insecure (pl)ACEs leaving no place left to hide in Active Directory ACLs i.e. there'll be zero ways left to evade detection.

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


So, what is the right tooling ?  Well, I will be penning a post titled something along the lines of  No more (pl)ACEs To Hide : Identifying Active Directory ACL Backdoors and/or How to Thwart Persistence In Active Directory in a few days, so you'll just have to wait for it, but if you're curious, I'll give you a big hint; it has to do with this - Active Directory Effective Permissions.

Over all, these gentlemen are spot-on and 100% right, and I sincerely commend their efforts to help organizations become aware of the vulnerabilities that lie deep within the thousands of ACLs inside their foundational Active Directory deployments.  




How to Identify and Thwart Sneaky Persistence in Active Directory

[Nov 22, 2017 Update] - Here are two posts on how to identify and thwart sneaky persistence in Active Directory -
  1. How to Easily Identify and Thwart Sneaky Persistence in Active Directory

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


Best wishes,
Sanjay



PS: A Helpful Reading List - For everyone who'd like to get into the fascinating world of Active Directory Security/ACLs -

 
  1. Best Practices for Delegating Active Directory Administration

    (especially the Appendices, and the other guides + the free LDP tool.)

  2. Defending Active Directory Against Cyber Attacks (Microsoft)

  3. Defending Active Directory Against Cyber Attacks (Paramount Defenses)

  4. Advanced Active Directory Security School for Microsoft


Tuesday, July 25, 2017

Active Directory Effective Permissions - Paramount to Cyber Security

Folks,

If you're into Cyber Security, and you could read only one piece this year, you'll likely want to read this post - its that important.

[ Some Context: Here is the associated press release - Paramount Defenses Skips Black Hat Conference 2017 to Educate World About Importance of Active Directory Effective Permissions to their foundational cyber security. ]

Today, I'll shed light on Active Directory Effective Permissions, a most vital topic that Microsoft (for reasons best known to them) apparently completely forgot to educate the world about, for a decade, even though it is paramount to cyber security worldwide.

Privileged Access in Active Directory

It is Active Directory Effective Permissions that determine who has what privileged access at 1000s of organizations worldwide.


(By the way, I find it astounding that even 17 years after Active Directory was shipped, 1000s of Microsoft's major organizational customers still don't seem to know about something so fundamental to their foundational cyber security - Effective Permissions.)


This incredibly important post is a bit long so for enhanced readability, it is comprised of the following 12 sections-
  1. This is Paramount
  2. A Simple $ Billion Example
  3. Active Directory Effective Permissions
  4. Their Importance
  1. The Effective Permissions Tab
  2. A Huge Challenge
  3. What Organizations Need
  4. The Solution
  1. The Answer
  2. A Note About Microsoft
  3. About Black Hat Conference
  4. Summary





This is Paramount

Let's begin by understanding why this is so relevant and paramount to the foundational cyber security of every organization.


Consider this. In an Active Directory deployment (the foundation of IT and cyber security at most organizations in the world,) do you know what is the only way to answer each & every one of the following 10 basic and elemental cyber security questions? -

  1. Exactly who has what level of privileged access where and how in Active Directory?

  2. Exactly who can create new user accounts, security groups, OUs, SCPs etc. in Active Directory?

  3. Exactly who can delete existing user accounts, security groups, OUs, SCPs, etc. in Active Directory?

  4. Exactly who can reset the password of which user accounts (including privileged users) in Active Directory?

  5. Exactly who can modify the membership of which groups (including all privileged groups) in Active Directory?

  6. Exactly who can modify the ACL of the AdminSDHolder object to control all privileged access in Active Directory?

  7. Exactly who can modify the contents of the Configuration and Schema partitions to gain control of Active Directory?

  8. Exactly who can manage all accounts, computers, groups, OUs, DCs, SCPs, Trust relationships etc. in Active Directory?

  9. Exactly who can compromise everyone's credentials by replicating secrets from Active Directory via Mimikatz DCSync?

  10. If any Active Directory integrated defense-in-depth measures such as these i.e. Smartcard authentication, MFA, Auditing, Random Password Manager, Password Vault etc. are in use, exactly who can disable them to render them useless?

The answer: Active Directory Effective Permissions.  (Not "Who has what permissions in Active Directory.") 


Organizations that do not have exact answers to these 10 simple questions cannot
be considered secure, so let's talk about Active Directory Effective Permissions.





A Simple $ Billion Example

This paramount cyber security concept is best understood via an illustrative example, so let's consider a real-world scenario -

Data Center

A fictional multi-billion dollar organization operates a high-security data-center, in which reside its high-value servers, including most of its file servers, web servers, app servers and Domain Controllers (DCs). Responsibility of managing all servers in the data-center is entrusted to the Data-Center Operations Team, an on-site team of highly trustworthy and proficient IT personnel.

To facilitate the privileged access this team needs, the organization created (and is using) an Active Directory security group called Data-Center Operations Team, and added it (via group policy) to the local Administrators group on all servers and DCs.

In effect, anyone who is a member of this highly privileged Active Directory (domain) security group Data-Center Operations Team has system-wide admin access and can thus control virtually everything in this multi-billion dollar organization's network.

Cognizant of this fact, the organization has worked really hard to minimize the number of individuals in this highly privileged Active Directory security group, and has been able to reduce its memberships to just 6 individuals -


Here are the members of this highly privileged Active Directory security group -

  1. David Parker, IT Manager
  2. Erica Lockhart, IT Administrator
  3. Larry Ellison, IT Administrator
  1. Michael Karp, IT Security Analyst
  2. Pamela Fitzgerald, IT Auditor
  3. Patrick Sullivan, Senior Operations Analyst
Speaking of which, for enhanced security, the organization also uses additional security measures to secure and defend all of its privileged user accounts (e.g. Enterprise Admins, Domain Admins etc.) which currently totals 15, including these 6 accounts.


Now, a Billion $ question begs itself - Although this highly privileged and mission-critical domain security group currently only has 6 members, "Exactly how many individuals can change the membership of the Data-Center Operations Team group?!"

This question is paramount because anyone who could change this group's membership could instantly take over everything.


The answer to this simple yet paramount question
lies in Active Directory Effective Permissions...





Active Directory Effective Permissions

First off, as you may know, to find out who can change the membership of the Data-Center Operations Team security group, you have to find out who all actually have sufficient access so as to be able to modify the group's Member property/attribute.

Next, some very quick theory. As you know, literally everything in Active Directory is an object, and each object is protected by an access control list (ACL) that is comprised of zero of more access control entries (ACEs), each one of which Allows or Denies one or more of a dozen types of security permissions to a specific security principal (user, group or well-known SID), and together i.e. collectively (, and not individually) these security permissions impact the resulting access on the object.

With that theory in mind, let's take a quick look at the ACL protecting the Data-Center Operations Team security group, with the intent of finding out who all actually have sufficient access so as to be able to modify the group's Member property -

The ACL protecting the Data-Center Operations Team domain security group in Active Directory

As you can see above, there are numerous ACEs in the object's ACL, each one of which either explicitly or via inheritance, Allows or Denies, one or more of a dozen types of security permissions to various security principals. In fact, observe that -
  1. There are numerous Allow and Deny permissions, some of which are explicitly specified on the object, whereas others are inherited down from the object's parent object, and their actual impact is determined by a precedence order.

  2. There are numerous types of Active Directory security permissions that are specified, such as Write - Member (Property), Write - Group Membership (Property-Set), Write All Properties, Modify Permissions, SpecialFull Control etc.

  3. There are numerous security principals for whom these security permissions are specified, including individual users('s accounts), security groups, and well-known security principals (e.g. Domain Users, Authenticated Users, Self, etc.)

  4. Of the numerous security groups for which access is specified, they could have other security groups nested in them (, and some could also possibly be circularly nested,) and thus could easily end up impacting access for many users.

  5. Of these various access control entries / security permissions that exist in an Active Directory object's ACL, not all of them may actually be applicable to the object, as they may exist solely to facilitate inheritance to downstream objects.

[ Note: For detailed observation, you can download the entire ACL protecting this object here. ]

Considering the above, how do we find out who all have sufficient access to be able to modify the group's Member property?

As observed above, there are numerous security permissions that are specified in various ways (Explicit/Inherited, Allow/Deny) for numerous users and groups (which could in turn contain other groups) in an Active Directory object's ACL, and (theoretically) each one of these permissions could overlap or conflict with each other, thus collectively impacting the actual resulting access.


To see this in action, let us attempt to evaluate the impact that just even two following randomly selected ACEs in this object's ACL can have on the resulting access of a randomly chosen user, Peter Thiel  -
ACE # 13:   Allow    IT America Admin Team             Write All Properties                                                   Inherited 
ACE #  9:    Deny    IT Operations Support Level 3    Write Property - Group Membership Property Set    Inherited

In case it helps, Peter Thiel's (domain user account's) domain security group memberships are displayed below -



As you can see, Peter Thiel happens to indirectly be a member of each of the domain security groups for which permissions are specified in these two ACES, so both these ACEs will end up impacting the actual access that Peter Thiel has on this group.

If you were to consider the first ACE shown above solely by itself, you may errantly conclude that Peter Thiel can modify the membership of this group, because Peter Thiel is a member of the IT Helpdesk Operators group, which is turn is a member of the IT American Admin Team group, which is allowed blanket Write All Properties, and that includes Write Property - Member.

However, if you were to also consider the second ACE shown above, then you will correctly conclude that Peter Thiel cannot in fact modify the membership of this group, because Peter Thiel is also a member of the IT Helpdesk Team group, which in turn is a member of the IT Operations Support Level 3 group, which is denied Write Property - Group Membership Property Set, and it so happens that the Member property is a member (pun unintended) of the Group Membership Property Set.

In essence, it turns out that even though Peter Thiel has Allow Write All Properties specified on the object indirectly, he also has Deny Write Group Membership Property Set specified on the object indirectly, and since the inherited Deny access will override the inherited Allow access, he will effectively have the ability to modify all properties except the Member property on the Data-Center Operations Team security group, and as a result, he will not actually be able to modify the membership of this group.

Now, it must also be mentioned that if there were to be even one other ACE that would explicitly end up allowing Peter Thiel Write-Property - Member whether directly or indirectly, that explicit Allow would override the inherited Deny, in which case, he would in fact be able to modify the group's membership. In such a case, it must further be mentioned that if there were to be even one other ACE that would explicitly end up denying Peter Thiel Write-Property - Member whether directly or indirectly, that explicit Deny would override the explicit Allow, in which case he would not in fact be able to modify the group's membership.

So you see, there could easily be well over a 100 ACEs in the object ACL, and each and every single one of these that specifies either of Write-Property - Member attribute, the Write Group Membership Property Set, Write All Properties or Full Control access, whether it be an Allow or a Deny and whether be explicitly specified or specified via inheritance, will likely directly or indirectly (i.e. via nested group memberships or well-known RIDs and SIDs ) impact whether or not Peter Thiel can change this group's membership, and they will also undoubtedly impact the complete list of users who will actually be able to change this group's membership. In other words, there could easily be over a 100 ACEs in the object's ACL and the permissions they specify collectively impact the resulting access on the object!

Thus, the only way to correctly (i.e. accurately) find out what access the ACEs in an ACL actually end up entitling on the object, and to whom, is to collectively take them into account and determine the resulting i.e. effective access they end up granting.

Consequently, the actual set of permissions / access that a user ends up being granted (i.e. allowed) on an Active Directory object, in light of having correctly considered the collective impact of the entirety of all security permissions specified in all of the ACEs in the object's ACL, are known as the user's effective permissions on that object.

As seen above, it is a user's effective permissions that determine what access a user actually has on an Active Directory object.





Their Importance

Active Directory Effective Permissions are extremely important because as illustrated above, it is "what effective permissions does a user have" and not "what permissions does a user/group have" that determines whether or not a specific user has a specific type of access granted on an Active Directory object.



Consequently, it is Active Directory Effective Permissions that gate every single LDAP operation that can be performed on Active Directory content.

Privileged Access in Active Directory

In other words, they control everything, including who can create, manage and delete all domain user accounts and security groups (including all privileged accounts and security groups), containers, OUs etc. in and across Active Directory.

In fact, in a Microsoft Windows Server based IT infrastructure, from user authentication to secure network-wide authorization to organizational IT assets, not a leaf moves without (access to) Active Directory being involved, and not a single access to Active Directory, whether it be read access or modify access, is possible without users having sufficient effective permissions to do so.

If users did not have sufficient effective permissions in Active Directory, the entire organization would come to a stand still. By the same token, if someone had sufficient effective permissions in Active Directory, he/she could control the entire network!






The Effective Permissions Tab

The importance of Active Directory Effective Permissions is perhaps best conveyed by the fact that in addition to the tabs for Permissions, Auditing and Owner(ship), the fourth tab in Microsoft's native security tooling is for Effective Permissions -

Effective Permissions Tab

In other words, for Microsoft to have dedicated an entire tab for Effective Permissions, they must be at least as important to cyber security (if not more so) as Permissions, Auditing and Owner(ship), which we all know are important for obvious reasons.

Unfortunately, as important as effective permissions are to organizational security today, Microsoft’s Effective Permissions Tab for Active Directory is not only not 100% accurate, it is substantially inadequate (; and has been so for a decade now.)

Here's why -
  1. It is not always 100% accurate, since it self-admittedly does not take all relevant factors into account

  2. Most importantly, it can only determine (an approximation of) effective permissions (granted to) ONE user at a time

  3. It cannot show which underlying permissions in the object’s ACL entitle a specific user to a specific effective permission

As to its accuracy, as shown in the snapshot above, in reference to the example considered in the previous sections above, for the user Peter Thiel, it is indicating that Peter Thiel has Write all properties effectively allowed. This is inaccurate because as illustrated in the example above, in reality, Peter Thiel has the ability to write (to) all properties except the Member property, and this fact is evidenced by the following snapshot -

Insufficient Access
As seen above, the Add and Remove Member buttons are disabled (grayed out) for Peter Thiel because he does not in fact have sufficient effective permissions to modify the Member property on the Data-Center Operations Team security group.


As to its limitation of only being able to determine an approximation of effective permissions for one user at a time, this single limitation renders this tab virtually useless, because due to this limitation, the only way for an organization to determine exactly who all have a specific type of effective permission on a specific Active Directory object, would be to have IT personnel manually enter the identities of every single one of thousands of domain accounts one by one, and make a note of each user's effective permissions, and that is neither practical nor realistically feasible.


As to its inability to be able to identify and pinpoint the underlying security permissions in the object's ACL that are entitling a specific effective permissions for a specific user, this ability is essential if organizations are to have any hope of being able to lockdown any excessive effective permissions/access that may have been identified on a specific Active Directory object. After all, if you don't know which ACE / security permission / security group membership you need to tweak to eliminate or lockdown an excessive effective permission, how are you going to mitigate the identified risk?


In short, in reality, the substantial deficiencies inherent in Microsoft's Effective Permissions Tab make it virtually unusable. The same is true of most other tools from Microsoft that claim to do effective permissions, including dsacls, acldiag, accesschk etc.

Further, whilst numerous vendors claim to offer solutions that can help find out "who can do what in Active Directory" or "who has what effective permissions", not a single one of them actually determines effective permissions, let alone being able to determine them accurately. They merely perform basic permissions analysis. Finally, this one tool that claims to be able to do effective permissions is not only dangerously inaccurate, it has the same deficiencies as Microsoft's Effective Permissions Tab.





Huge Challenge

(This section is for all amateurs who might say - "What's the big deal here? I imagine I could this with some PowerShell?")

As we saw above, merely evaluating the collective impact of just 2 ACEs alone can be complicated. In many real-world Active Directory deployments, there may be over a 100 ACEs in the ACL of each Active Directory object, and correctly collectively considering the entirety of all security permissions specified in each of these ACEs can be extremely difficult.


In fact, the accurate determination of effective permissions in Active Directory poses a HUGE challenge for the world.

Here's why -
  1. Active Directory's security model, albeit extremely powerful, is substantially more complex than the traditional Windows file and folder security model. For instance, while there are only a few generic permissions in the file and folder security model, there are almost a dozen generic permissions in Active Directory's security model, and in addition there are also almost five dozen special permissions known as Extended Rights, all of which substantially increases its complexity.

  2. The problem size is substantially larger, in that there are far more ACEs in an Active Directory object's ACL than there are in a file or a folder's ACL. In many Active Directory deployments, there may easily be over a 100 ACEs in each Active Directory ACL, considering that a substantial amount of access provisioning is done in Active Directory to facilitate administrative delegation and to configure access for various Active Directory integrated applications and services.

  3. The existence of and thus the need enumerate of a possibly large number of domain security group memberships, especially those that may be deeply nested as well as those that may be circularly nested, further increases the complexity of the process of performing accurate access evaluation and conflict resolution.

  4. The inclusion of numerous arcane details that are unique to Active Directory, such as including the impact of object ownership on effective access, dynamically evaluating relative well-known RIDs etc. further complicates the process.

Consider this - Imagine trying to determine effective permissions on an Active Directory organizational unit, in whose ACL there exist 150 ACEs, 100 of which specify varying levels of access for security groups, 75 of which (i.e. security groups) contain nested security groups, 50 of which contain deeply nested security groups, and 25 of which deny various forms of access and 10 of which are circularly nested, and you'll get a sense of just how difficult this process can be to perform, let alone automate.





What Organizations Need

In light of the fact that Active Directory Effective Permissions are vital and in fact paramount for organizational cyber security, today, organizations absolutely need the ability to be able to accurately and efficiently determine effective permissions in their Active Directory deployments.


After all, considering that the foundational Active Directory deployments of most organizations have been in operation for years now, in most deployments today there very likely exists rampant unauthorized / excessive effective permissions / access, so organizations need to identify and lockdown all such unauthorized / excessive effective permissions / access, especially that granted on mission-critical content, such as all high-value (privileged and executive) user accounts and security groups, the Domain Controllers OU, the domain root, AdminSDHolder, various parts of the Configuration and Schema partition etc.

Here are 3 simple needs that organizations have regarding determination of Active Directory effective permissions -
  1. Accuracy - First and foremost, the ability to be able to accurately determine effective permissions in Active Directory

  2. Efficiency - Secondly, the ability to be able to efficiently determine effective permissions in Active Directory i.e. ideally be able to determine the complete set of effective permissions granted on an object, as well as the identities of all users who have these effective permissions granted, without having to enter each user's identity one at a time.

  3. Source-Identification - Finally, the ability to be able to identify which underlying security permissions in the object's ACL are entitling a specific user to a specific effective permission on a specific Active Directory object.  

If these 3 simple needs could be fulfilled, organizations could swiftly attain and maintain least privileged access (LPA) in and across their foundational Active Directory deployments.





The Solution - An Adequate Active Directory Effective Permissions Calculator

Given just how important it is for all organizations to be able to adequately determine effective permissions in Active Directory, it was clear to me about a decade ago that if the world didn't have an adequate solution for this, in years to come we would all be facing a major cyber security challenge.

So, about a decade ago we decided to take on this huge challenge and started working to build an adequate solution to address it, because we had understood back then just how important and essential this was going to be for the world, in years to come.

(The intention was never to build a cyber security company per se, but rather a desire to take this huge challenge head-on, and to see if we could solve it, and further to see how well we could solve it i.e. just how easy could we make it for everyone. The company and its products are merely an outcome of the successful pursuit of this desire to address this challenge for the world.)

Today, it is my privilege to share with you the outcome of over half a decade of innovative, industrious and committed research and development, so allow me to share with you Gold Finger for Active Directory, the world's only accurate Active Directory Effective Permissions Calculator / Tool that also delivers on everything organizations need to address this huge challenge -

Gold Finger Active Directory Effective Permissions Tool / Audit Tool / Calculator

At the touch of a single button, Gold Finger can -
  1. First and foremost, accurately determine effective permissions on Active Directory objects

  2. Secondly, it can determine the complete set of effective permissions granted on an object, as well as the identities of all users who have these effective permissions granted, without having to enter each user's identity one at a time.

  3. Finally, it can also identify which underlying security permissions in the object's ACL are entitling a specific user to a specific effective permission on a specific Active Directory object, thus helping making remediation very simple. 
I suppose the only thing more remarkable that Gold Finger's abilities is its simplicity of use. All you need to do it launch Gold Finger, point it to an object in Active Directory, and click a button.

When you click that button, under the hood and completely transparent to you, over half a million lines of code go to work, and within minutes, if not seconds, determine the complete set of effective permissions entitled on an Active Directory object, the complete set of individuals to whom each of these effective permissions are entitled, and the underlying security permissions in the object's ACL that entitle every identified user to every entitled effective permission on the object.

On a humorous note, the only downside of its remarkable simplicity is that it makes the solving of such a difficult technical challenge look so simple that people often wonder what the big deal is! I mean you just click a button, and you're done ;-)


In order to appreciate just how difficult and complex this problem is to solve, perhaps its worth taking a look under the hood...


Under the hood, when you click that button, Gold Finger begins by locating Domain Controllers, identifying the object, retrieving its access control list, and then it initiates the computation of accurate effective permissions analysis on the object, which involves so many technical functions such as but not limited to discovering and analyzing the Schema, resolving SIDs, correctly expanding all relevant security group memberships many of which could be deeply nested, identifying and resolving circularly nested security group memberships, analyzing individual permissions in each ACE (of which there could technically be over a 100 in an ACL), evaluating the impact of each one of them in light of numerous factors such as and not limited to precedence orders, applicability, suitability, inclusion in property sets etc. as well dynamically evaluating any and all well-known RIDs (e.g. Domain Users) and SIDs (e.g. Everyone), mapping Self SIDs to the security principal if applicable, etc. and a whole lot more, and ultimately arriving at its output, and presenting it in a fashion that is as intuitive and user-friendly as it could possibly be.

In contrast, all that most of the currently available Active Directory Permissions Analysis/Audit solutions in the world do today is merely retrieve an Active Directory object's ACL, and report the identities of the security principals encountered in the ACL along with the security permissions specified for that security principal in the ACL. (Some of them may expand a few security group memberships.) In effect, they do about 1% of what needs to be done to do this correctly (because they don't know better), yet they have thousands of customers who too don't know better, and happily proceed to act on dangerously inaccurate data.


Now, consider this - Active Directory environments can be so diverse in nature (from a small 100 object single Active Directory domain/forest for a small business to a globally dispersed Active Directory forest with possibly dozens of domains and 100s of 1000s of objects) that it is extremely difficult to build a product / solution that can automate this process such that it can just work in any Active Directory environment!

One of our many customers worldwide, a prominent 3-letter acronym government agency has 250+ ACEs in the ACL of every object in their Active Directory, and Gold Finger accurately determines effective permissions on these objects within minutes.

There is only one other thing I'd like to mention - while this tool can automatically determine effective permissions and effective access on individual Active Directory objects, its big brother, the Privileged Access and Delegation Audit Tool (i.e. this one) can accomplish the monumental feat of automatically being able to do so on 1000s of objects i.e. an entire Active Directory domain!

Thus, as you can see not only is this paramount to global cyber security today, it is by no means an easy problem to solve, let alone automate. In fact it is almost impossible, and at Paramount Defenses, we go to great lengths to make what is considered impossible as easy as touching a button.






The Answer

This post would not be complete without providing the answer to the paramount cyber security question posed above, which was - "Exactly how many individuals can change the membership of the Data-Center Operations Team group?!"

The Answer: 27.

So, while this vital security group only has 6 members, today there are 27 individuals who can change/control its membership.

In fact, here is the complete set of effective permissions entitled on the Data-Center Operations Team security group.

Now, in case you're wondering how I figured it out, it was actually rather simple; I just clicked one button -

Gold Finger Active Directory Effective Permissions Tool / Audit Tool / Calculator

Specifically, I launched Gold Finger, pointed it to the Data-Center Operations Team domain security group in Active Directory, and clicked the Run button. That's it. A few moments later, as shown above, I had the results. (Here is the exported output.)

So, as you can see, without the ability to determine effective permissions in Active Directory, and of course, do so accurately, we would never know just how many individuals can control the membership of such a vital security group, and who they are.

Without this valuable insight, the organization would have continued to indefinitely operate under the false assumption that only 6 people could control the entirety of their high-business impact (HBI) servers in their highly secure data-center, whereas in fact in reality there are 27 individuals who can do so today!

(Oh, and we haven't yet evaluated and included the number and identities of individuals who have effective modify permissions on this group, and the number and identities of individuals who can reset the passwords of those 27 individuals and who have effective modify permissions on each one of those 27 accounts. Yet at the very least, we've been able to answer the question.)

That is what we mean when we say that most organizations today are operating in the dark. There are many many more individuals that possess all kinds of privileged access in Active Directory than those that they think they know about.





A Note About Microsoft

Folks, as former Microsoft Program Manager for Active Directory Security, I care deeply about Microsoft as well as the foundational cyber security of all organizations worldwide, so I wanted to share a few thoughts.



By now, you've hopefully comprehended just how important Active Directory Effective Permissions are to organizational cyber security. They are absolutely paramount to Active Directory Security, and Active Directory Security is absolutely paramount to the organizational security of thousands of organizations, and to the security of Microsoft's ecosystem.

If this is the case (and this is the case,) how could Microsoft have completely forgotten to educate its global customer base about such an important and mission-critical aspect of cyber security for an entire decade?! It is absolutely astounding!

Last year, when they finally provided some earnest guidance on the importance of defending Active Directory, while they spoke at length about security permissions in Active Directory, they again completely forgot to tell the world about the fact that to attain and maintain least privileged access in Active Directory, you need to determine effective permissions in Active Directory!

It is in light of the above that I asked this question - How Well Does Microsoft Really Understand Cyber Security?

I find it partly amusing and partly concerning that on one hand Microsoft may not even have educated its customers about such a vital aspect of cyber security for an entire decade (most likely because this paramount aspect of cyber security wasn't even on their radar), yet on the other hand, it is wooing and wants the world to entrust their cyber security in its recent Cloud offering!


One cannot emphasize enough just how paramount Active Directory Effective Permissions are to global security today. In most organizations worldwide, due to almost complete ignorance about the value and importance of effective permissions, we have a situation wherein most organizations are operating in the proverbial dark, and there in all likelihood exist thousands of excessive / unauthorized effective access grants, which pave thousands of privilege escalation paths in Active Directory, which can today be easily identified and exploited by any insider / intruder who knows how to determine effective permissions in Active Directory, even if with marginal accuracy.

Fortunately, since organizations worldwide can now accurately and efficiently determine Active Directory effective permissions, they can now finally secure and defend the very foundation of their security, their foundational Active Directory deployments.





A Note About the Black Hat Conference 2017

Folks, as some of you may know, the famed Black Hat Conference is on in Las Vegas, Nevada, USA.

Black Hat Conference

The Black Hat Conference is supposedly one of the top cyber security conferences in the world, and given how vital cyber security is today, thousands will be attending, and numerous cyber security experts will be presenting at Black Hat this year.

YET, not a single one of these top cyber security experts knows much about Active Directory Effective Permissions, or how to calculate them, or their paramount importance to Active Directory Security and thus to organizational security, or has a solution.

NOT one of them!

This, when in fact Active Directory Security is at the very foundation of cyber security of almost all organizations worldwide whose employees (from IT Security Analysts to CISOs) will be attending the Black Hat Conference in Las Vegas this year!


( Last year I learnt just how much (or should I say how little) the Black Hat Conference Review Board seems to know about Active Directory Security, when I had a chance to communicate with them about a presentation I wanted to do on Active Directory Security last year to help raise awareness, which they declined. They allowed a presentation titled "Active Directory Beyond the MCSE" by a respected MCM, but they declined a presentation titled "From Zero to Enterprise Admin Within Minutes" by former Microsoft Program Manager for Active Directory Security. In light of this, I will let you be the judge of how much they seem to know. The loss was solely theirs, and I will NOT be applying to present at the Black Hat Conference again.

In retrospect, I can't blame them, because as I have said and proven, over the years, Microsoft has provided ZERO guidance on this to the world, so how're Black Hat's experts supposed to know about this paramount aspect of cyber security? So hey Black Hat Conference Review Board, here's Active Directory Security 101 to get you guys ramped up - Active Directory Security. )


By the way, this year there will be a presentation titled "An ACE Up the Sleeve: Designing Active Directory ACL Backdoors."

Here's its description -
"Active Directory (AD) object discretionary access control lists (DACLs) are an untapped offensive landscape, often overlooked by attackers and defenders alike. The control relationships between AD objects align perfectly with the "attackers think in graphs" philosophy and expose an entire class of previously unseen control edges, dramatically expanding the number of paths to complete domain compromise.
While DACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence. It's often difficult to determine whether a specific AD DACL misconfiguration was set intentionally or implemented by accident. This makes Active Directory DACL backdoors an excellent persistence opportunity: minimal forensic footprint, and maximum plausible deniability.
This talk will cover Active Directory DACLs in depth, our "misconfiguration taxonomy," and enumeration/analysis with BloodHound's newly released feature set. We will cover the abuse of AD DACL misconfigurations for the purpose of domain rights elevation, including common misconfigurations encountered in the wild. We will then cover methods to design AD DACL backdoors, including ways to evade current detections, and will conclude with defensive mitigation/detection techniques for everything described."

Finally a talk at the Black Hat Conference focused on weaknesses in Active Directory DACLs !  Kudos, but/and I just have one question - What took you guys so long?!  I mean, are these "experts" just now realizing all this in 2017  i.e. 17 years after Active Directory was shipped!  We have been saying this for years now, and 've already solved this problem over half a decade ago !

The respectable "experts" giving this presentation on Active Directory Security are absolutely right that "Active Directory ACLs are an untapped offensive landscape, often overlooked by attackers and defenders alike, and that while ACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence." That said, what these respected experts (may or) may not yet know is that at the root, crux and heart of all this actually lie Active Directory Effective Permissions.

So, to help these experts, newbies, and the entire world, in a few days, on this blog, I'll share just how easily organizations can now find and eliminate each one of these backdoors, leaving NO room to hide, or as they persist. Interestingly, the solution to that too involves (surprise!) Active Directory Effective Permissions.  Speaking of which, I doubt there will be any mention of Active Directory Effective Permissions in the ACE Up the Sleeve presentation, again thanks to 0 guidance from Microsoft!

As for that BloodHound tool, although it has gained much popularity especially amongst pen testers, it is massively inaccurate because it makes the same classic mistake that people have been making for years now i.e. it tries to find out "who has what permissions in Active Directory" when in fact what it should be trying to do is find out "who has what effective permissions in Active Directory."  The fact that it can still find so many holes only shows and proves just how bad the situation is out there!

Technically, comparing Gold Finger to Bloodhound is like comparing a Lamborghini to a prototype of the world's 1st car.

The one other very important thing to note is that while Bloodhound primarily aids attackers in attacking Active Directory, Gold Finger primarily aids organizational IT personnel in defending Active Directory, and in fact today Gold Finger may be the only solution that can help organizations identify and eliminate any backdoors or paths that attackers could find using Bloodhound.


Alright, enough of this. Actually, the Black Hat Conference doesn't deserve much mention here, but since the one presentation on Active Directory is completely focused on Active Directory ACLs, and since so many organizations are tuned-in to Black Hat this week, I figured they ought to know about a matter of paramount importance to the very foundation of their cyber security.


While I'm at it, let me tell you that not a single one of the world's top cyber security companies, including Microsoft, Cisco, IBM, Google, Amazon, EMC, Dell, HP, CA, Centrify, Palo Alto Networks, Blue Coat, 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 about this or a solution to help organizations determine Active Directory Effective Permissions (, when in fact likely at their very foundation too lies Active Directory.)  Not a single one of them!





In Summary

I've been sharing my thoughts and perspectives for years now, on the Cyber Security Blog, the Active Directory Security Blog, and recently on the Paramount Defenses Blog. Of all the posts I've penned thus far (, and I've penned well over a 100 by now), this is possibly the most important one yet.

It is so because what I shared today directly impacts the foundational cyber security of thousands of government and business organizations in the world, and AFAIK, nothing is more important than securing and defending the very foundation of security.


It is Paramount (; and thus the name, Paramount Defenses.)


Make no mistake about one fact - no Active Directory deployment can be secured without possessing the ability to determine effective permissions / effective access in Active Directory, and no organization (not matter how big or powerful it may be) whose foundational Active Directory is not secure, can be considered secure from a cyber perspective.

That's all for today, Day 10 of this.

Best wishes,
Sanjay


PS: If you liked this blog post, you may like reading (each one of) these + stuff here, thinking about this, and checking this out. If you only have time to read one of them, I would read this one or this - A Trillion $ Active Directory Privilege Escalation Example.