BSides Hawaii 2020: Dude, Wheres My Domain Admins

Dude, Where’s My
Domain Admins?
Making AD recon and privilege escalation more difficult
for attackers
Joel M. Leo, MCSE SI/CP&I, CISSP, SEI SAP

BSides Hawaii - Dude, Where's My Domain Admins? © 2020 Joel M. Leo
Mahalos!
Hi Tech Hui
@pyrotek3 (Sean Metcalf – adsecurity.org)
@gentilkiwi (Benjamin Delpy – mimikatz and more)
SpecterOps (Bloodhound and more)
@harmj0y
@cptjesus
@_wald0

About Me
• Live and work in Honolulu, Hawaii
• Active Directory Architect and Principal Systems Engineer for Gap Inc.
• Principal Consultant for Hi Tech Hui - https://www.hitechhui.com
• PoC for Def Con Groups 808 https://dc808.org @defconhawaii
@joelmleo
https://www.linkedin.com/in/joelmleo

Problem Statement
What’s the problem Earthman?
Default Active Directory permissions allow
any authenticated user to enumerate the
entire directory, including security-sensitive
principals such as Domain Administrators.

Killchain
Image credit: Microsoft
https://docs.microsoft.com/en-us/advanced-threat-analytics/ata-threats

Solution TL;DR
Tighten down AD permissions so only privileged principals can
enumerate these sensitive identities
Ok, a little more detail:
• ***Plan extensively*** and take a system state backup of a DC!
• Create groups & add members according to plan
• Enable “List Object” mode
• Remove ‘Authenticated Users’ from the ‘Pre-Windows 2000 Compatible
Access’ group!
• Modify OU/container ACLs
• Modify AdminSDHolder ACL and let SDProp do its thing

Technology Background
• AD DACLs, ACEs, and Implicit Deny
• Generic Read, decomposed
• “List Object mode”
• AdminSDHolder & SDProp
All of these capabilities are already in-the-box with Windows
Server. There are no additional products or licenses required.

AD DACLs, ACEs, and Implicit Deny
• DACL = Discretionary Access Control List - applies to an object
to define the object’s set of permissions using ACEs. Not to be
confused with SACLs, which are used for auditing access.
• ACE = Access Control Entry – the individual entries listed on a
DACL that grant a principal permission on the object
AD follows the “implicit deny” model with “access-based
enumeration” – if you aren’t granted permissions to something in
AD you’re implicitly denied access to it & it won’t be listed in
search results, GUI tools, etc.

Generic Read Permission
“Generic Read” permission is just the combination of:
• RC – Read Control; read the security descriptor of the object
• LC – List Content; list the contents of the object
• RP – Read Properties; read the properties/attributes of the object
• LO – List Object; permission to list the object when the parent
container’s contents are enumerated
These permissions can be separately granted. You see where this is
going =)

List Object Mode
Exposes ‘List Object’ control and enforces its permissions
• A principal now requires List Contents on the parent container and/or List
Object on the objects within to have the object listed when the parent
container’s contents are enumerated
• Enabled by setting dSHeuristics to ‘001’
• dSHeuristics is an attribute of CN=Directory Service,CN=Windows
NT,CN=Services in the Configuration partition of AD
• Affects the whole forest
• Unicode string value that controls many aspects of AD functionality
• Default string Is null
• If the string is NOT empty in your environment, then you need to replace
the third character from the left with ‘1’
• More about dSHeuristics: https://docs.microsoft.com/en-
us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-
33950617d2c5

List Object Mode

AdminSDHolder & SDProp
AdminSDHolder is an object that provides the DACL for
protected accounts and groups, including Domain Admins
SDProp is a process that executes every 60 minutes on the PDC
emulator which compares protected objects’ DACL with
AdminSDHolder’s. If they differ, inheritance is disabled, the DACL
on AdminSDHolder is applied to the object, and its adminCount
attribute is set to 1
More infoz: https://adsecurity.org/?p=1906

Bringing It All Together
With List Object mode enabled, a user that is not granted
permissions to enumerate objects (List Object permission on the
objects themselves) and isn’t granted permissions to List Contents
on the parent container will not be able to see those objects in the
directory.
We modify the DACLs on parent containers and AdminSDHolder,
which then applies the ACL to each of the protected groups and
their members through SDProp.

Lab Environment
• Single AD domain
• Mostly default
• Privsep
• Regular account: joelmleo
• Sysadmin: sa-joelleo
• Domain admin: da-joelmleo

All accounts,
including regular
account
- joelmleo
Can see the Domain Admins
group and everything else

Solution Outline
1. PlanPlanPlan - Who needs to have access to what, and what permissions
do they need?
2. Take a system state backup of a domain controller
3. Create groups and add members according to your plan
4. Enable "List Object mode”
a. Remove ‘Authenticated Users’ from the ‘Pre-Windows 2000 Compatible Access’
group!
5. Modify OU/container ACLs
a. Remove ‘List Contents’ permission from ‘Authenticated Users’
6. Modify AdminSDHolder ACL
a. Remove ‘Authenticated Users’
b. Add the group(s) which should be able to see these with Read permissions
7. Let SDProp do its thing

Our Plan
Goal: Hide our Domain Admins (and other protected entities) from
enumeration by unprivileged users
Containers that hold the objects we want to hide: ‘CN=Builtin,’
‘CN=Users’ & ‘OU=Administrative Users,OU=Users,OU=Lab
Accounts’
Group that will be granted privileges to enumerate these hidden
objects: ‘HiddenObjects-Enumerate’
Members of our Sysadmin team should be able to enumerate
these objects with their sa- accounts, so they will be added to the
above group

ChChChChaangees 1
• Created ‘HiddenObjects-Enumerate’ group
• Added sa- accounts as members

ChChChChaangees 2
• Removed ‘Authenticated Users’ from the ‘Pre-Windows 2000
Compatible Access’ group
• Set dSHeuristics to ‘001’

ChChChChaangees 3
• Removed ‘List Contents’ permission from ‘Authenticated Users’
on
• CN=Builtin
• CN=Users
• OU=Administrative Users,OU=Users,OU=Lab Accounts
• AdminSDHolder changes
• Removed ‘Authenticated Users’ permissions
• Added ‘HiddenObjects-Enumerate’ with ‘Generic Read’ perms
• Manually kicked off SDProp (I cheated – could have waited an
hour)

Demo:
Execute Solution

Regular Account
- joelmleo
Can no longer see the Domain
Admins group, or any other
protected principal

Domain Admins??

Demo:
Run Some Queries

Privileged Account
sa-joelleo
Can still see the Domain Admins
group and all other protected
principals

What Else Can This Do?
• Can be used to hide accounts that need long-lived passwords
from casual enumeration
• Better choice would be to rotate the passwords =)
• Hide service accounts, including gMSAs
• Hide sensitive computer accounts
• Admin workstations
• Sensitive servers
• Hide GPOs

What Doesn’t This Solve?
• This does nothing for you if everyone is a domain admin
• Efficacy is greatly reduced if privileged users are allowed to log
in to any machine – use PAW/tiering!
• Even if an account is hidden in this way, it can still be used to
authenticate. If you document the username and password on
Confluence, in your git repositories, hardcoded in scripts, etc.,
an attacker can still make use of them if they find the creds
• An attacker that obtains a system state backup, IFM copy,
NTDS.DIT etc. may be able to enumerate objects inside

Pitfalls
• This should be a tactic as part of a larger security strategy
• Unprivileged users will not be able to browse to find these objects
• Service accounts are particularly affected. Users need to type in the
account’s name, instead of browsing. Can still use sc.exe, Powershell, etc. to
set service creds.
• IAM tools will fail to enumerate hidden objects unless granted
privileges
• Requires some level of privilege separation. If a regular user account
is a member of a group protected by SDProp, many tools that user
requires will fail when this is implemented.
• Solution – use separate accounts for elevated privileges
• Applications that do silly things to validate they’ve auth’d to AD

Conclusion
Through a combination of AD’s “List Object mode,” ACL
modification, and SDProp, we can raise the bar on our Active
Directory security by hiding highly-privileged accounts, making it
that much more difficult for an attacker to elevate their privileges in
AD.
#SecurityIsNeverDone

Additional Resources
• “An ACE up the Sleeve” PDF available here:
https://www.blackhat.com/docs/us-17/wednesday/us-17-Robbins-An-
ACE-Up-The-Sleeve-Designing-Active-Directory-DACL-Backdoors-
wp.pdf
• @PyroTek3 (Sean Metcalf, https://adsecurity.org)
• Bloodhound https://github.com/BloodHoundAD
• PowerSploit https://github.com/PowerShellMafia/PowerSploit
• Best practices for securing AD https://docs.microsoft.com/en-
us/windows-server/identity/ad-ds/plan/security-best-practices/best-
practices-for-securing-active-directory
• MS-ADTS https://docs.microsoft.com/en-
us/openspecs/windows_protocols/ms-adts

Q&A
@joelmleo

BSides Hawaii 2020: Dude, Wheres My Domain Admins

Recommended

Recommended

More Related Content

Similar to BSides Hawaii 2020: Dude, Wheres My Domain Admins

Similar to BSides Hawaii 2020: Dude, Wheres My Domain Admins (20)

Recently uploaded

Recently uploaded (20)

BSides Hawaii 2020: Dude, Wheres My Domain Admins

Editor's Notes