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 Access Control Lists. Show all posts
Showing posts with label Access Control Lists. 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