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 AdminSDHolder. Show all posts
Showing posts with label AdminSDHolder. Show all posts

Tuesday, June 19, 2018

Some Interesting Figures from an Active Directory ACL Dump of Security Permissions from a default Windows Server 2016 Active Directory Domain

Folks,

I had only 2 minutes to blog today, so within the 2 minutes I had, I thought I'd generate, put together and share some interesting figures about the default Active Directory security permissions in a Windows Server 2016 based Active Directory domain.

It took a mere 3 seconds to do a domain-wide ACL dump of a Windows Server 2016 based Active Directory domain -


Active Directory Domain-wide ACL Dump




Domain-wide ACL Dump Download URL

You can download the entire actual domain-wide ACL dump from here.




Some Interesting Figures

Here are some interesting figures that took a minute to put together -
  • Total number of object classes instantiated in domain partition: 40
  • Total number of Active Directory objects in the domain: 242
  • Total number of Active Directory ACLs (duh, obviously!): 242
  • Total number of Active Directory security permissions (aka ACEs): 6677
  • Total number of explicit Active Directory security permissions: 1323
  • Total number of inherited Active Directory security permissions: 5354  
  • Total number of inherit-only Active Directory security permissions: 3746
  • Total number of unique security principals for whom permissions are specified: 27
  • Total number of objects whose ACLs were marked "Protected" : 20

  • Total number of Allow security permissions: 6677
  • Total number of Deny security permissions: 0
  • Total number of security permissions specified for Domain Admins: 246
  • Total number of security permissions specified for Enterprise Admins: 230
  • Total number of security permissions specified for Administrators: 231
  • Total number of security permissions in the ACL of the AdminSDHolder object: 24
  • Total number of security permissions in the ACL of the domain root objects: 53
  • Total number of specific extended rights specified in these security permissions: 19
  • Total number of attribute-specific write-property security permissions: 15

The exact security permissions can be viewed in the downloadable ACL dump (link provided above).



Unique Security Principals

Here's the list of the 27 unique security principals for whom security permissions are granted in the domain -
  1. Pre-Windows 2000 Compatible Access
  2. Cloneable Domain Controllers
  3. Enterprise Read-only Domain Controllers
  4. Domain Controllers
  5. Key Admins
  6. Enterprise Key Admins
  7. Creator Owner
  8. Self
  9. Enterprise Domain Controllers
  10. Administrators
  11. Incoming Forest Trust Builders
  12. Authenticated Users
  13. Domain Admins
  14. Enterprise Admins
  1. Everyone
  2. System
  3. Account Operators
  4. Print Operators
  5. Group Policy Creator Owners
  6. RAS and IAS Servers
  7. Domain Computers
  8. Network Service
  9. Cert Publishers
  10. Windows Authorization Access Group
  11. Terminal Server License Servers
  12. DnsAdmins
  13. DC1 (<domain computer account>)

The exact permissions granted to each one of these security principals can be viewed in the ACL dump (; link provided above).



Instantiated Object Classes

Here's the list of the 40 object classes, instances of which exist in the domain -

  1. Domain-DNS
  2. Container
  3. Organizational-Unit
  4. Lost-And-Found
  5. Infrastructure-Update
  6. ms-DS-Quota-Container
  7. Rpc-Container
  8. File-Link-Tracking
  9. Link-Track-Volume-Table
  10. Link-Track-Object-Move-Table
  11. Domain-Policy
  12. Class-Store
  13. Group-Policy-Container
  14. NTFRS-Settings
  15. Dfs-Configuration
  16. Ipsec-Policy
  17. Ipsec-ISAKMP-Policy
  18. Ipsec-NFA
  19. Ipsec-Negotiation-Policy
  20. Ipsec-Filter
  1. ms-DS-Password-Settings-Container
  2. ms-Imaging-PSPs
  3. TPM-InformationObjectsContainer
  4. User
  5. Builtin-Domain
  6. Group
  7. Foreign-Security-Principal
  8. Sam-Server
  9. Computer
  10. RID-Manager
  11. RID-Set
  12. ms-DFSR-GlobalSettings
  13. ms-DFSR-ReplicationGroup
  14. ms-DFSR-Content
  15. ms-DFSR-ContentSet
  16. ms-DFSR-Topology
  17. ms-DFSR-Member
  18. ms-DFSR-LocalSettings
  19. ms-DFSR-Subscriber
  20. ms-DFSR-Subscription

Each instance of these object classes, and their complete ACLs can also be viewed in the ACL dump (;link provided above).



Permission-Specific Breakdown

Finally, here's a breakdown of the number of security permissions of each Active Directory permission type -
  • Number of security permissions (ACEs) granting Read Control (RC): 1977
  • Number of security permissions (ACEs) granting List Child (LC): 2171
  • Number of security permissions (ACEs) granting List Object (LO): 1968
  • Number of security permissions (ACEs) granting Read Property (RP): 5704
  • Number of security permissions (ACEs) granting Write Property (WP): 2072
  • Number of security permissions (ACEs) granting Create Child (CC): 1001
  • Number of security permissions (ACEs) granting Delete Child (DC): 779
  • Number of security permissions (ACEs) granting Standard Delete (SD): 803
  • Number of security permissions (ACEs) granting Delete Tree (DT): 586
  • Number of security permissions (ACEs) granting Extended Right (CR): 1299
  • Number of security permissions (ACEs) granting Validated Write (SW): 1389
  • Number of security permissions (ACEs) granting Modify Permissions (WD): 978
  • Number of security permissions (ACEs) granting Modify Owner (WD): 978

Finally, the exact ACEs that specify each one of these permissions can also be viewed in the ACL dump (;link provided above).



Detailed Security Permissions Analysis

Time permitting, you can analyze the entire ACL dump to perform detailed Active Directory security permissions analysis. Since the tooling splits the permissions field up into individual columns for permissions, it makes it very easy to analyze these ACLs.

For instance, you can easily find out exactly what security permissions are granted to a specific user or group, or find out exactly which users or groups are granted a specific Active Directory permission. You can also easily identify all inherit-only security permissions, as well as all Allow permissions, Deny permissions, Explicit permissions, Inherited permissions etc. etc.. I could go on with many more interesting facts/figures, but I'll stop here because my 2 minutes are up :-).

BTW, this is super easy and what we consider child's play (which is also why I didn't want to give this more than 2 minutes of my time.) Since it took just 3 seconds to dump these ACLs, I was happy to give it 2 minutes ; Oh, and we use our own tooling.

Alright then, my 2 minutes are up, so back to work.

Thanks,
Sanjay

Thursday, September 21, 2017

Did Microsoft Just Reveal How Little It May Seem to Know about Active Directory Security In Speaking of Access Control List Attacks & Defense?

Folks,

Three (3) days ago i.e. on September 18, 2017, Microsoft's Advanced Threat Analytics (ATA) Team posted a blog post titled -



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


When you read it, it will likely be unequivocally clear to you as well as to just how little Microsoft seems to understand about not just the sheer depth and breadth of this monumental challenge, but about the impact it could have on organizations worldwide!


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

That said, in that post, the best Microsoft could do is concede that this could be a problem, wonder why organizations might ever need to change AdminSDHolder, falsely assume that it may not impact privileged users, praise a massively inaccurate tool for shedding light on this attack vector, and end by saying - "If you find a path with no obstacles, it probably leads somewhere!"

Oh, and the very last thing they tell you that is their nascent ATA technology can detect multiple AD reconnaissance methods.


You really have to read it to get what I'm saying. Seriously, here's all this post mostly touched upon - a quick overview of Active Directory ACLs, an overview of AdminSDHolder protection in Active Directory, and a note on delegated permissions in AD.

Oh, and they thanked whoever made that massively inaccurate tool called Bloodhound for bringing ACLs to the front, literally!

By the way, that baby of a tool, Bloodhound just recently came out, and I've been saying this since for half a decade now, here. Maybe to learn a thing or two re AD Security, the good folks at Microsoft should Google "Active Directory Privilege Escalation"


Perhaps the one line that stood out most (of many lines that stand out) is -

"Why would you want to change AdminSDHolder manually? 
To date, our team hasn't found a solid reason!"

Microsoft, when you publicly ask such a question, you reveal how little your team may know about Active Directory Security.

(Dear Microsoft, FYI, and in case you didn't know, likely the number #1 thing most organizations need to do to secure/lockdown access to/on all their default privileged user accounts and security groups in Active Directory, is to change AdminSDHolder!)

Oh, and has it ever occurred to you that many mature organizations may choose to implement their own custom AD delegation models, in which case they may not even end up relying on default AD administrative accounts and groups, in which case your point concerning ACL based vulnerabilities not impacting privileged users and groups in Active Directory would be moot.




You see, here's what they should have said - "We care deeply about cyber security and we understand that left unaddressed, this could pose a serious cyber security risk to our customers. Be rest assured that Microsoft Active Directory is a highly robust and securable technology, and here's exactly how organizations can adequately and reliably identify and lock-down privileged access in their Active Directory deployments, leaving no room for perpetrators to identify and exploit any weaknesses."

The reason I say that should've been the response is because if you know enough about this problem, then you also know that it can actually be completely and sufficiently addressed, and that you don't need to rely on detection as a security measure.

Sadly, since they don't seem to have a clue as to this, you're likely not going to get that response from Microsoft.

BTW, to appreciate how little Microsoft seems to understand about this huge cyber security challenge, you'll want a yardstick to compare Microsoft's response with, so here it is (; you'll want to read the posts) - Active Directory Security School for Microsoft.



Finally, if this is how little Microsoft seems to understand about such a profoundly important cyber security challenge concerning your own technology, I cannot help but wonder how well their customers might actually be protected in its recent Cloud offering!


It is now abundantly clear that Microsoft may need help, so in days to come, I'm going to help them out.

Best wishes,
Sanjay



Monday, June 19, 2017

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

Dear Microsoft,

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


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



The Top-5 Security Risks to Active Directory Deployments

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

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

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

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

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

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

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


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




But First, 5 Notable Points About These 5 Risks

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

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

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

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

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

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

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




Oh and , 2 Other Quick Points

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

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

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


And now...



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



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

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



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

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



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

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



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

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



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

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

  • Asset Examples –  The following are a few simple illustrative examples of such assets:

    1. The domain user account of a non-default highly privileged user, one that is not protected by AdminSDHolder, yet possesses Domain-Admin equivalent privilege in Active Directory based on custom access provisioning
    2. The domain user account of an organizational executive (e.g. Chairman, CEO, CFO, CIO, CISO, VP etc.)
    3. A large membership domain security group such as All Employees, or (all) Domain Computers etc.
    4. The domain computer account of a specific computer, such as a high-value email, app or database server
    5. A top-level Organizational Unit that contains thousands of users, computers, groups and other objects
    6. A service connection point of a mission-critical Active Directory integrated service/app, e.g. this one (; here)

  • Threat Source – Any sufficiently privileged intruder (hacker, APT etc.) / insider (disgruntled, rogue or coerced user)
  • Attack Surface – The entire Active Directory
  • Enabler - Anyone who ends up being entitled to any one of various modify (WP, WD, CR, FC) effective permissions on any object in Active Directory is allowed to, and thus can manage that Active Directory object. A single incorrectly specified security permission (inherited or explicit) in an Active Directory object's ACL could substantially impact the actual resulting effective permissions entitled on that object, resulting in unauthorized effective access on the object.
  • Exploitation Procedure – Use Microsoft's Active Directory management tooling (e.g. ADUC etc.) to enact an (un-)authorized administrative task such as a malicious password reset, a group membership change, a user account creation, a computer account delegation change, an OU deletion, a service connection point keyword change etc.
  • DifficultyMinimal
  • ImpactHigh to Very high
  • Likelihood / Probability of OccurrenceHigh
  • Physical / System Level Access to DC Required No
  • Resources Required – Network access to Active Directory + Sufficient Effective Permissions in Active Directory
  • Mitigation / Prevention – Ensure (at all times) that all access provisioned in Active Directory adheres to the principle of least privilege, so as to ensure that net resulting effective permissions / effective access on all Active Directory objects only permits authorized personnel to enact various administrative tasks on those objects
  • Risk Assessment – To find out exactly who can enact this risk, either audit Active Directory effective access on all vital objects in Active Directory (e.g. all exec accounts, sensitive groups large OUs etc.) one-by-one, or perform a tree-wide effective privileged access audit to find out exactly who all can enact which admin tasks on these objects
  • Detection – Possible via use of Active Directory auditing. However, detection is hardly useful because by the time an audit event/notification is generated / acted upon, substantial damage will most likely already have been done.
  • Additional Info - Here



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

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



Summary

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


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

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

  3. How Well Does Microsoft Really Understand Cyber Security?

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


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


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

Best wishes,


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

Wednesday, February 22, 2017

AdminSDHolder


Folks,

Today is Day-0 of Microsoft's 30-day Active Directory Security School, which starts on May 22, 2017. Today, I'll answer the 2nd (here's the 1st) $100 B question I had asked them, which concerns AdminSDHolder, the root of organizational cyber security worldwide.

[The insight I have provided below is worth a proverbial $100 Billion, so in your own interest, you should read it in its entirety.]



AdminSDHolder

If you're Microsoft, or one of millions of Windows/Active Directory admins or cyber security pros worldwide, you know that at the heart, root & foundation of administrative/privileged access in Active Directory lies one Active Directory object - AdminSDHolder.

In the interest of brevity, I'll skip the details and provide a very brief background here. In essence, all default Active Directory accounts and groups that are considered to be administrative in nature by Active Directory are protected with a special protected locked-down access control list (ACL), which is the access control list of the AdminSDHolder object -

AdminSDHolder

It logically follows that anyone who can modify the permissions specified in the AdminSDHolder object's ACL can easily control and impact the security afforded to all default Active Directory administrative accounts and groups, such as Domain Admins, Enterprise Admins, Administrators, Backup Operators, etc., as well as the default Administrator account, and all such accounts.

In other words, anyone (e.g. a rogue or coerced insider, an intruder, APT etc. ) who could modify the permissions specified in the AdminSDHolder object's ACL could instantly obtain complete administrative control over the entire Active Directory forest!




A $ Billion Question -

So a $ Billion question begs itself, and all organizations operating on Active Directory must ideally have an exact answer today -


Q: "In our Active Directory domain(s), exactly who can modify the permissions specified in the AdminSDHolder object's ACL?"

(If you're thinking "That's easy; just perform a permissions audit using dsacls, PowerShell etc.", think again. Its not that simple.)

$100 Billion side-note: A few days ago, I had posed the same question to Microsoft here. They're likely not going to answer it, so to help Microsoft, as well as 1000s of organizations worldwide, I've answered the question below.




The Answer Illustrated

The answer is best illustrated with a walk-through example. In your own best interest, I highly recommend going through it.

Let us assume that a fictional publicly-held organization is required to identify (i.e. audit) exactly who can modify the security permissions protecting the AdminSDHolder object to demonstrate regulatory compliance, since that is what determines who controls the most powerful and prized privileged/administrative accounts in an Active Directory based IT infrastructure.

To try and answer this question, lets begin by diving right in and launching Active Directory Users and Computers to locate and view the ACL on the AdminSDHolder object -





A closer look reveals that this is a modified (i.e. non-default) AdminSDHolder ACL, in which access changes have been made, as evidenced, for example, by the presence of security permissions that are specified for numerous non-default domain security groups such as IT Contingency Support Team, IT Global Admins Team etc. -


Since this is no longer a default AdminSDHolder ACL, the resulting (effective) permissions/access granted to various individuals by the various permissions specified in the ACL may now differ (likely) substantially from those granted by the default ACL!



For instance, let us consider the impact of the Special security permissions specified for the IT Contingency Support Team -


The Special permissions specified for the IT Contingency Support Team include Allow Modify Permissions and All validated writes. Since it includes Modify Permissions it impacts our answer, so its worth taking a look at the membership of this group.




A closer look at the IT Contingency Support Team indicates that there is a another domain security group nested inside it -



Upon further expansion, one finds that the IT Contingency Support Team has as a member the IT Data Center Operations Team, which in turn has as member the IT Cloud DevOps Team, which in turn has 12 users that are members of that group -



In essence, this one single Special permission alone ends up indirectly (i.e. via 3 levels of nested group nesting) granting 12 individuals Modify Permissions on this ACL.

However, it should also be noted that there could also be one or more Deny permissions in the ACL that could similarly end up denying one or more of these 12 individuals the same Modify Permissions on this ACL, and thus it is not sufficient to merely analyze any one permission in isolation. *Further any such Deny permission may or may not end up negating the Allow, because the resulting access in this case would also depend on the nature (Explicit/Inherited) of both the Allow and Deny permissions.

* By default, the AdminSDHolder ACL is protected. However, since most Active Directory deployments have been around for years, it is possible that someone could have accidentally unchecked the Protected check-box, in which case it will inherit ACEs from the parent. As experts, we take every possible scenario into account. As such, this being an illustrative example applies to most objects in Active Directory (whose ACLs are unprotected) so in most cases, when making such determinations, inherited permissions will need to be taken into account.

As such, as seen above, there are many ACEs (access control entries) in the object's ACL (access control list), each one of which allows or denies a specific security principal (which could be a user, a computer, a security group, a well-known SID etc.) one of more specific Active Directory security permissions, and each one could either have been directly (explicitly) specified on the object, or may have been inherited via inheritance of permissions from the ACL in the object's parent.

In essence, the only way to answer this question is to accurately determine the new resulting (effective) permissions/access granted on this object, which involves collectively taking into account the entirety of all permissions specified to all security principals (users, groups well-known security principals etc.), in light of their permissions types (Allow/Deny) and nature (Explicit/Inherited), to ultimately identify all individuals who effectively possess Modify Permissions permissions on this object.

Specifically, not only will one have to correctly resolve allow vs deny conflicts taking into account the explicit vs inherited nature of each permission, but one will have to expand any and all relevant security group memberships, many of which could contain multiply nested groups (some of which may be circularly nested), and if needed also dynamically evaluate any specified well-known SIDs (e.g. Authenticated Users etc.) and of course, also analyze all relevant security permissions, i.e. in this case, not only those that allow/deny Modify Permissions but also those that allow/deny Full-Control, and of course do all this (each time) with 100% accuracy and no possibility of error.

(The astute mind will have already inferred by now, why this is not a matter of simply performing an audit of "Who has what permissions in Active Directory" or writing a simple (or for that matter even a very complicated) PowerShell script to do so.)

In summary, one needs to determine effective permissions/access granted on this Active Directory object, considering all the permissions, both allowed and denied, whether granted explicitly or inherited, to all the security principals specified in the ACL.

In short, what one needs to do is accurately determine Active Directory Effective Permissions.


In fact, Active Directory Effective Permissions are so important that Microsoft provides an entire tab for it in its native tooling -


To reiterate, the fact that along with Permissions, Auditing and Owner(ship), the fourth tab in Microsoft's native Active Directory management tooling is for Effective Permissions conveys just how important effective permissions are to Windows security.


Here's a closer look at the Effective Permissions Tab in Active Directory -

Active Directory Effective Permissions Tab

As important as it is, unfortunately the Active Directory Effective Permissions Tab provided in Microsoft's native Active Directory management tooling is (and has been so for 10+ years now) substantially inadequate for the following reasons -
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, ONE user at a time
3. Finally, it cannot identify the underlying permissions that entitle a specific user to a specific effective permission

It is for these 3 reasons that it is unable to help organizations assess and lockdown effective permissions in Active Directory, and consequently, most organizations worldwide do not yet have a definitive answer to this and other profoundly vital questions.


(Apologies for the digression.) NOW, to continue on with the example...


Let us assume that the organization has a simple one domain Active Directory forest containing 5000 employee accounts and 10,000 computer accounts, one each for 10K domain-joined computers (e.g. laptops, mail, file, web and application servers.)

Since the Active Directory Effective Permissions Tab can only determine effective permissions ONE user at a time, the only way to definitively determine the identities of all individuals in the company who effectively have Modify Permissions permissions granted on the AdminSDHolder object would be to compile a list of each of these 5000 domain user accounts and 10,000 computer accounts, and then manually enter the identities of each of these accounts ONE BY ONE -


It should be clearly evident that such a process could be very laborious and easily take an excessively long time (i.e. a few days, if not weeks) and require substantial effort, each time the organization needed to make such a determination.

It is also worth noting that in the event that it is found that a user who is not supposed to have this effective permission granted does have it nonetheless, there is no way to easily know which underlying security permission in the ACL is entitling this user to this effective permission, and without that piece of intel, it would be very difficult to revoke this identified unauthorized access.


In essence, in reality, due to the shortcomings of the Effective Permissions Tab in Microsoft's Active Directory management tooling, and a general lack of awareness about the need, value and importance of determining effective permissions in Active Directory, today most organizations have NO idea as to EXACTLY who effectively has Modify Permissions permissions on the AdminSDHolder object, and thus likely have NO clue as to exactly who can control AdminSDHolder in their Active Directory.

By the way, virtually every method described in various forums on Microsoft TechNet on how to determine effective permissions in Active Directory and/or audit delegations, is technically substantially inaccurate, as is this dangerously inaccurate free tool.

Speaking of which, not a single other Microsoft tool such as dsacls, acldiag, etc. or for that matter any other 3rd party tool can accurately determine effective permissions in Active Directory. Some do offer Active Directory Permissions Audit Tools, but those are like baby-toys compared to an Active Directory Effective Permissions Audit Tool, because with them, you're still left to do a MOUNTAIN of work yourself to determine effective permissions, assuming you know how to do so accurately.)

In essence, even though there are 100s of cyber security companies in the world, including some big ones, not a single one of them offers an Active Directory Effective Permissions Audit Tool. Hmm... so much so for demonstrating thought leadership!



So, is there NO way for organizations to accurately and efficiently calculate effective permissions in Active Directory today?


In other words, is there NO way in which 20,000+ organizations worldwide that operate on Microsoft Active Directory, whose cumulative market cap handily exceeds $10 Trillion, can today find out exactly who controls the Keys to their Kingdom(s)?




Well, (thanks to the foresight of one individual, and a decade's work by one cyber security company,) there is ONE way...



Here's how business and government organizations worldwide, including Microsoft IT, can easily, efficiently and accurately determine exactly who has what effective permissions on not just AdminSDHolder but on any object in their Active Directory:

Open Gold Finger, select the Active Directory Effective Permissions Calculator, point it to AdminSDHolder, and click a button -

Gold Finger Active Directory Effective Permissions Calculator


Within a matter of seconds, Gold Finger will uniquely and accurately determine and reveal -
1. The complete set of all effective permissions granted on the object, including of course Modify Permissions
2. For each such effective permission, the complete set of all authenticatable security principals i.e. all domain (user, computer and service) accounts that have a specific effective permission granted on the object
&
3. For each such account, the exact underlying security permissions in the object's ACL that entitle this account to this specific effective permission.

Armed with such valuable intel, organizations can finally, and likely for the first time ever, not only instantly find out exactly who controls the Keys to their Kingdom, but also lock-down access to minimize the number of individuals who can currently do so.

(Incidentally, armed with the same intel, an intruder could also very quickly uncover and exploit the easiest possible path to the Keys to the Kingdom. That is why we only license Gold Finger to legitimate organizations and only for use in their AD domains.)

(In fact Gold Finger can also automatically determine effective permissions/access across an entire domain at a button's touch to exactly find out not only who has they Keys to the Kingdom, but also who has the keys to every door in the kingdom.)




Summary

In summary, considering the fact that 100% of all major recent cyber security breaches involved the misuse and compromise of just ONE Active Directory privileged user account, and the fact that the ACL on AdminSDHolder controls the security of all default administrative (i.e. privileged) accounts and groups in Active Directory, at the very least, every organization that operates on Active Directory today must know exactly who can control the permissions specified in AdminSDHolder's ACL.


The only other thing I will add is that I find it unbelievable that in over a decade, for whatever reason, Microsoft has not once educated its customers about the vital need and importance of determining effective permissions in their foundational Active Directory deployments. Not once! I wonder what that conveys about a company trying to woo the world to embrace its Cloud.

In their own best interest, every organization must strive to understand the profound importance of what I have shared above.

This stuff is paramount to organizational cyber security today.

Best wishes,
Sanjay



PS: The Answer

In short, the simple answer to this elemental yet profoundly vital cyber security question is -
To accurately determine exactly who can modify the security permissions specified in the AdminSDHolder object's ACL, organizations need to accurately determine Active Directory Effective Permissions granted on the object.

I could've easily just shared this one-line answer, but most folks worldwide wouldn't have gotten it, thus the example.

Tuesday, February 14, 2017

AdminSDHolder (and another $100 Billion Question for Microsoft)

Dear Microsoft,

On May 22, we start our 30-day advanced Active Directory Security School for you. To help you prep, I thought I'd ask you another $ 100 Billion question, which is at the root (pun intended) of organizational cyber security worldwide - AdminSDHolder.



AdminSDHolder

If you're Microsoft, or one of millions of Windows/Active Directory admins or cyber security pros worldwide, you know that at the heart, root & foundation of administrative/privileged access in Active Directory lies one Active Directory object - AdminSDHolder.

In the interest of brevity, I'll skip the details and provide a very brief background here. In essence, all default Active Directory accounts and groups that are considered to be administrative in nature by Active Directory are protected with a special protected locked-down access control list (ACL), which is the access control list of the AdminSDHolder object -

AdminSDHolder

It logically follows that anyone who can modify the permissions specified in the AdminSDHolder object's ACL can easily control and impact the security afforded to all default Active Directory administrative accounts and groups, such as Domain Admins, Enterprise Admins, Administrators, Backup Operators, etc., as well as the default Administrator account, and all such accounts.

In other words, anyone (e.g. a rogue or coerced insider, an intruder, APT etc. ) who could modify the permissions specified in the AdminSDHolder object's ACL could instantly obtain complete administrative control over the entire Active Directory forest!




A $ Billion Question -

So a $ Billion question begs itself, and all organizations operating on Active Directory must ideally have an exact answer today -


Q: "In our Active Directory domain(s), exactly who can modify the permissions specified in the AdminSDHolder object's ACL?"

(If you're thinking "That's easy; just perform a permissions audit using dsacls, PowerShell etc.", think again. Its not that simple.)




A $100 Billion Question for Microsoft

In light of the above, the security of an entire Active Directory deployment also boils down to this:
Anyone who can modify the permissions specified in the AdminSDHolder object's ACL  could easily compromise all default Active Directory administrative domain user accounts and groups, & by extension all of Active Directory.

So, to my esteemed former colleagues at Microsoft, I have a very simple question for Microsoft -
"Precisely what does Microsoft recommend that customers do to accurately make this paramount determination in their foundational Active Directory deployments?"  i.e. how do they accurately determine exactly who can modify security permissions specified in the AdminSDHolder object's ACL?"
To be clear, in Active Directory environments that have been around for years now, and in which a non-trivial amount of access provisioning/changes have been done in Active Directory, including wherein changes have been made to the default AdminSDHolder ACL (for instance as illustrated in the visual above), how do they accurately determine exactly who can modify security permissions specified in the AdminSDHolder object's ACL?

In case you're wondering why this is a proverbial $100 Billion question, if you were to add up the market cap of all organizations worldwide that operate on Active Directory, it would handily exceed $10 Trillion. Now, considering the potentially colossal impact of compromise resulting from a cyber security incident involving a perpetrator having modified AdminSDHolder to gain complete command and control over an organization's foundational Active Directory, you should be able to see why this is a $100B Q.


We, i.e. your customers and I, look forward to an answer. Your customers look forward to it because they have a right and an urgent need to know how to do so. I look forward to it because I'd like to see how well Microsoft still understands AD security.

Please allow me to give you a hint - here.  (To help organizations worldwide, I'll answer the question right here in a few days.)

Respectfully,
Sanjay.


PS: One more hint. The answer is a term mentioned 20+ times in this 2-pager and 0 times in Microsoft's official 100-pager.

PS2: My apologies for asking this publicly. It is 2017 after all, not 2007 (, which is when you should've already addressed this.)

PS3: Interestingly, due to a complete lack of guidance from Microsoft on advanced stuff, when it comes to AdminSDHolder, today most organizations are still just trying to figure out basic stuff, such as how to find & cleanup orphaned AdminSDHolder objects i.e. accounts that still have admincount=1 even though they may no longer be a member of any default admin groups.

PS4: February 22, 2017 updated - Microsoft, the answer is here.

Tuesday, June 28, 2016

How to find out who can control/manage the AdminSDHolder object in Active Directory?

Folks,

As you may know, at Paramount Defenses, we lead and operate the world's largest community of Active Directory Security Professionals on LinkedIn, compromised of 2500+ individuals from 1000+ top organizations across 100+ countries worldwide.

(Our group is a sales-free and recruiter-free technical discussion group, and is completely free to join.)

Active Directory Domain Controllers

Earlier today, during one of our many technical discussions titled "What are the security implications of someone being able to modify the security descriptor protecting the domain root object in Active Directory", one of our valued members, Daniel Ulrichs raised a very good question (mentioned below) that merited its own discussion.

(Incidentally, on the question above, Daniel also recently publicly shared his thoughts on the question on his blog here.)



Q: Who can control the AdminSDHolder object in Active Directory?

Daniel's thoughtful inputs prompted our latest conversation which focuses on the question - "How to find out who can control AdminSDHolder i.e. who can change the ACL stamped on the AdminSDHolder object?"
As you may know, all accounts considered to have (unrestricted) administrative access in Active Directory are secured by a special protected ACL, which happens to be the ACL on the AdminSDHolder object.


This is one of the most important questions in cyber security today since it directly impacts privileged user access in Microsoft Active Directory deployments and thus profoundly impacts the foundational security of 85% of all organizations worldwide.
Needless to say, anyone who can control the security of the ACL on the AdminSDHolder object holds the "Keys to the Kingdom" because he/she can impact the security of every administrative account in Active Directory.
Today, ideally all organizations should, at all times, know exactly who can change the ACL on the AdminSDHolder.

Ideally, along the same lines, there are many such questions that all organizations must know the exact answers to at all times, but for now, we're focused on this one fundamental Active Directory security question because it is cardinal to cyber security.

I, of course know the answer to the question. I'm only asking this for the benefit of our group members. Should you wish to participate in this discussion, or explore numerous such discussions, you're welcome to join the group and the conversation.

To join, simply visit - http://www.linkedin.com/groups?gid=2006946

Best wishes,
Sanjay