TL;DR explanation of what SDDL is, how to read it, and does it even matter.
Welcome to Part VIII of our Auditing AD Series.
Part I: 3 warm up questions to get us started
Part II: Who can reset the CISO’s password?
Part III: Who can execute DCSync?
Part IV: Who can modify the Domain Admins group?
Part V: Domain dominance in minutes via ACL abuse (i.e. why auditing AD matters)
Part VI: Why Allow statements matter a LOT more than Deny ones
Part VII: Sneaky persistence via hidden objects in AD
Part VIII: SDDL, what is it, does it matter?
Part IX: Do you know who owns your domain?
Part X: Who can push ransomware via Group Policy?
Part XI: Free ways to simplify auditing AD
Part XII: Sidenote on arcane rights like Self
Part XIII: Sidenote on the ScriptPath right
Part XIV: Self & so called “Effective Permissions”
Part XV: Inheritance Explained & an Example
Part XVI: Summary of our Auditing AD Series
Annex A: Scrubbing Group Policy for local admins
Annex B: What Property Sets in AD are, & why they matter
Annex C: Dangerous Rights & RE GUIDs Cheatsheet
Annex D: Mishky’s Blue Team Auditor
Annex E: Even ChatGPT gets this stuff wrong
Annex F: Get-ADPermission Cheatsheet
Annex G: Mishky’s Red Team Enumerate & Attack tools
Background
This part was prompted by a vendor’s question, found at https://www.cyber-security-blog.com/2020/01/who-needs-wmds-today.html.
“Today, all you need is two WDs in the same (pl)ACE and its Game Over.
Puzzled? Allow me to give you a HINT:
Here’s a simple question: What does the following non-default string represent and why should it be a great cause of concern?
(A;;RP;;;WD)
…
[Edited for brevity]
(A;CI;RPWDLCLO;;;WD)
…
PS2: If this intrigues you, and you wish to learn more, you may want to read this — Hello World :-) “
What’s this vendor even talking about?
I was curious, but the link didn’t explain anything. Luckily Google had the answer.
First things first; this string of characters is known as Microsoft’s Security Descriptor Definition Language (SDDL). It is used for Access Control Entries (ACEs) in Access Control Lists (ACLs). These ACLs control access to registry keys, files & folders, and of course Active Directory objects. Since this series is about auditing AD we will focus on SDDL in that context.
Microsoft describes SDDL as:
“The security descriptor definition language (SDDL) defines the string format that the ConvertSecurityDescriptorToStringSecurityDescriptor and ConvertStringSecurityDescriptorToSecurityDescriptor functions use to describe a security descriptor as a text string. The language also defines string elements for describing information in the components of a security descriptor.”
What is SDDL and why should I even care?
Short answer; it’s the old, pre PowerShell way of enumerating ACLs.
Long answer; Microsoft introduced SDDL back in Windows 2000. PowerShell wasn’t introduced until 2006, so enumerating, auditing, or being able to just actually read ACLs was a lot rougher back then. In 2022 there’s not much reason to bother with SDDL. If you really want to see it then just query:
Get-Acl (Get-ADDomain).DistinguishedName | Select-Object SDDL | Format-ListOr
(Get-Acl (Get-ADDomain).DistinguishedName).sddl
How to read SDDL
The best way is with an example. Our sample ACE in the ACL of the domain root is, from this vendor’s question:
(A;CI;RPWDLCLO;;;WD)
So let’s break this down.
A = Allow (ACE type)
CI = Container Inherit (means child CNs inherit as an explicit ACE)
RP = Read Property, WD = Modify Permissions, LC = List Contents, LO = List Object (list of privileges granted by this ACE)
;;; = no ObjectType or Inherited Object Type specified, essentially the same thing as ObjectType set to all 0s in PowerShell
WD = SDDL_EVERYONE, aka ‘Everyone’ in AD
Therefore, (A;CI;RPWDLCLO;;;WD) gives Everyone ‘Modify Permissions’ or WriteDACL in PowerShell parlance. It also gives them ReadProperty, ListChildren, & ListObject. The WriteDACL though is obviously very bad for security. It means that any Domain User could change the ACL on the domain root, give themselves the rights required to execute DCSync, pull the krbtgt hash, and start forging tickets.
That’s it, that’s the answer to this vendor’s question.
SDDL vs PowerShell’s method
As a comparison, pull the SDDL as mentioned above:
(Get-Acl (Get-ADDomain).DistinguishedName).sddlYou can copy/paste the entire ugly thing into Notepad and Ctrl + F ‘WD)’ to see any ACEs that apply to Everyone. You will see (D;;DC;;;WD) & (A;;RP;;;WD), which means Deny DeleteChild & Allow ReadProperty
Or if you prefer to get human readable output immediately and not Google up a cheatsheet for SDDL, just query
(Get-Acl (Get-ADDomain).DistinguishedName).Access | Where {$_.IdentityReference -like “*Everyone*”}
All you have to do is remember that if the ObjectType is set to all 0s it means all Properties. Simple, easy, legible.
Cheatsheet for SDDL
There are 6 fields in an ACE in SDDL:
- ACE type (allow/deny/audit)
- ACE flags (inheritance and audit settings)
- Permissions (list of incremental permissions)
- ObjectType (GUID)
- Inherited Object Type (GUID)
- Trustee (SID)
The ACE type are:
The ACE flags are:
The ACE permissions are:
Please note that while not technically the same thing, GenericWrite and WriteProperty with ObjectType 00000000-0000-0000-0000-000000000000 will essentially grant the same rights.
Please note that PowerShell easily supports the ability to give only specified Extended Rights and writing to only specified AD attributes via specifying ObjectTypes. Just use the handy cheatsheet at http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm and Ctrl + F.
For example, below we see that a user has been given only the two Extended Rights required to execute DCSync.
Trustee (SID):
Summary
I found snippets of info from several different sources on Google and put it together to enumerate ACLs in SDDL. I didn’t see a table mapping SDDL to GUI to PowerShell rights anywhere, so I put one together using Microsoft documentation.
SDDL information is not all that hard to find once you know what you are looking for. It is simply outdated and not readily legible, nor is it simple to query.
Caveat
However I would not doubt that some attackers out there are using SDDL in their tools to run queries. After all, as Will Shroeder, Andy Robbins, and Lee Christensen so aptly stated:
“As an offensive researcher, if you can dream it, someone has likely already done it … and that someone isn’t the kind of person who speaks at security cons [conferences].”
Hence it is something to be aware of. More knowledge is always good.
SDDL is also still used in a few acrane places in Windows, for example logs as seen here.
By the way, if you copy/paste the SDDL the vendor listed here into
ConvertFrom-SddlString -Sddl $SDDL -Type ActiveDirectoryRights
You’ll get an error, probably because it doesn’t start with the owner.
Huh, that’s exactly why.
Maybe they didn’t want you to consider the impact of ownership on their examples.
If you need to query who can ‘Modify Permissions’ in GUI terminology or WriteDACL in PowerShell’s terms on the domain root, then just:
(Get-Acl ‘dc=corp,dc=local’).Access | Where {($_.ActiveDirectoryRights -like “*WriteDACL*”) -and ($_.AccessControlType -eq “Allow”)}
It really is that simple. You don’t need to dig up info on arcane SDDL from Windows 2000 to see who has privileges in AD.
References:
https://www.cyber-security-blog.com/2020/01/who-needs-wmds-today.html
https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-definition-language
https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-definition-language
https://clan8blog.wordpress.com/2016/08/08/sddl-explained/
https://blogs.msmvps.com/alunj/2006/02/13/sddl-easier-to-read-except-when-its-not/
http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm
https://www.varonis.com/blog/the-difference-between-everyone-and-authenticated-users
https://zflemingg1.gitbook.io/undergrad-tutorials/privilege-escalation/privilege-escalation
https://devblogs.microsoft.com/oldnewthing/20220510-00/?p=106640
