The document discusses the complex nature of administrative access in Active Directory and the potential risks associated with misconfigured security descriptors. It highlights the implications of joining Active Directory, emphasizing that it introduces additional access nodes which can expose systems to unintended vulnerabilities. The authors advocate for a comprehensive defense strategy that restricts access to securable objects across systems to mitigate these risks.

1. The Unintended Risks
of Trusting Active
Directory

2. @harmj0y
Red teamer and offensive engineer
at SpecterOps
Adaptive Threat Division alumni
Avid blogger (http://harmj0y.net)
Co-founder of GhostPack, Empire,
BloodHound, Veil-Framework
2

3. @tifkin_
Red teamer, hunter, and
researcher at SpecterOps
Adaptive Threat Division alumni
Forever going after shiny things
Contributor to various
projects/blog posts
3

4. @enigma0x3
Red teamer and security
researcher at SpecterOps
Adaptive Threat Division alumni
Avid blogger
(https://enigma0x3.net/), COM
lover, CVE holder
4

5. What is
“Admin Access” ?
Hint: it’s more complicated
than just “local administrators”!
5

6. The “True” Nature of Administrative Access
▪ Controversial statement: membership in a system’s
local administrators group isn’t what ultimately
matters!
▪ What actually matters is what local/domain groups
have access to specific remote resources (RPC,
remote reg, WMI, SQL, etc.) based on the host
service’s security descriptors
6

7. 7
CIFS
Remote
Registry
WinRM
SCM
WMI
RPC :)
SD
SD
“LOCAL
Administrators”
GENERIC_ALL
“DOMAINuser”
SC_MANAGER_C
REATE_SERVICE
Etc.
SD
SD
SD
SD

8. Wait, Security
Descriptors? ACLs?
What are Those and Why Should I Care?
8

9. Security descriptors are the
Windows mechanism to control
authenticated access to
resources, or “securable objects”
9
PS: lots of caveats here :)

10. What Is a
“Securable Object”?
Why, a Windows object that can have
a security descriptor, of course!
10

11. SECURITY_DESCRIPTOR
11https://msdn.microsoft.com/en-us/library/windows/hardware/ff556610(v=vs.85).aspx

12. From Owners to DACLs to ACEs
▪ An object’s Owner completely controls an object
▪ An object’s Discretionary Access Control List
(DACL) is collection of Access Control Entries
(ACEs)
▫ ACEs – Allow/Deny rules of who can do what to an object
12

13. 13

14. Authorization Checks
▪ Individual services perform authorization checks
when objects are accessed
▪ Services compare the requestor’s user/group SIDs
to the DACL and grant/deny access
▪ Local “Administrators” is a group many services
grant access to by default (but it could be denied)
14

15. OK, That’s “Cool”
but Why Should I
Care, Really?
15

16. Why Care?
▪ It’s often difficult to determine whether a specific security
descriptor misconfiguration was set maliciously or configured
by accident
▫ Existing misconfigurations: privesc/lateral movement opportunities
▫ Malicious misconfiguration changes: persistence!
▪ These changes often have a minimal forensic footprint
▪ Many teams are not aware of these misconfigurations, much
less how to identify, abuse, or remediate them
16

17. Host-based Security
Descriptors
More than just the service control manager yo’

18. Discovering Host Securable Objects
▪ Windows documentation lists about 20-30 securable
objects*
▪ We’ve identified 70+! (There are *many* more)
▪ Microsoft Protocol Specifications
▫ Very useful for RPC servers ;)
▪ Find-RegistrySecurityDescriptors.ps1
▪ @tiraniddo’s NtObjectManager project
18*https://msdn.microsoft.com/en-us/library/windows/desktop/aa379557(v=vs.85).aspx

19. 19

20. Persistent vs Runtime Security Descriptors
▪ Where do objects get their security descriptor?
▫ Persistent - Security descriptor loaded from registry, file, etc.
▫ Runtime - Security descriptor is in memory
▪ Our approach for enumeration:
▫ Locally as an unprivileged user
▫ Locally as a privileged user
▫ Remotely as an unprivileged user
▫ Remotely as a privileged user
20

21. Example: Remote Registry
▪ Imagine this scenario: remotely dumping an
endpoint’s machine account hash as an “unprivileged”
user (i.e. not in local admins)!
▪ Backdoor Process
▫ Remotely backdoor the winreg key with an attacker-
controlled user/group (this key == remote registry access)
▫ Add malicious ACEs to a few specific registry hives/keys so
we can read LSA secrets remotely
21

22. Example: Remote Registry
▪ (Remote) Backdoor Execution
▫ As the backdoor (domain or local) user, connect to the
remote registry service on the backdoored system
▫ Open up specific reg keys linked to LSA and extract their
classes
▫ Combine these class values and compute the BootKey
▫ Use the BootKey to decrypt the LSA key
▫ Use the LSA key to decrypt the machine account hash!
▫ EVERYONE GETS A SILVER TICKET!!
22

23. Active Directory Security
Descriptors
Everything needs an access control model, even AD

24. Active Directory ACL Advantages
24
▪ A big advantage: by default the DACLs for nearly
every AD object can be enumerated by any
authenticated user in the domain through LDAP!
▪ Other advantages of AD ACLs:
▫ Changes also have a minimal forensic footprint
▫ Changes often survive OS and domain functional level
upgrades, i.e. “misconfiguration debt”
▫ Anti-audit measures can be taken!

25. 25
Security
Descriptors:
AD GUI
Edition

26. Generic Rights We Care About
26
GenericAll Allows ALL generic rights to the specified object
GenericWrite Allows for the modification of (almost) all
properties on a specified object
WriteDacl Grants the ability to modify the DACL in the
object security descriptor
WriteOwner Grants the ability to take ownership of the object

27. Object-specific Rights We Care About (abbreviated)
27
Users User-Force-Change-Password or write to
the servicePrincipalName
Groups Write to the member property
Computers None outside of LAPS :(
GPOs Modification of GPC-File-Sys-Path
Domains WriteDacl to add DCSync rights

28. Example: Abusing Exchange
▪ Exchange Server introduces several schema changes,
new nested security groups, and MANY control
relationships to Active Directory, making it a perfect
spot to blend in amongst the noise!
▪ Pre Exchange Server 2007 SP1, this included the
WriteDACL privilege against the domain object itself
with Exchange Trusted Subsystem as the principal
28

29. Active Directory + Host
ACL Abuse
Plugging the Gaps in Attack Chains

30. ▪ Prior to joining active directory, the host is in ultimate
control of who can access its resources
▪ After a machine is joined to AD, a few things happen:
▫ The machine is no longer solely in charge of authentication
▫ A portion of key material for the host is stored in another
location (machine account hash in ntds.dit)
▫ Default domain group SIDs are added to local groups
▫ Management is no longer solely left to the host (i.e. GPOs :)
“Risks” Of Joining Active Directory
30

31. Active Directory: Before and After
31
Workgroup
Security Principals Local users/groups
Access/Permission
Management
Host-based Security
Descriptors
Authentication NTLM (SAM)
Resource
Administration
Manual
Active Directory
+ Domain users/groups
+ Default domain groups
added to local groups
+ Kerberos/NTLM
(NTDS)
+ GPOs

32. Active Directory: Before and After
32
DCOM
Service
Administrators
admin
DOMAINDomain Admins
Distributed
COM Users
DOMAINsrvcacct
DOMAINjohnDOMAINsrvadms
DOMAINlee

33. Security Implications
▪ Host-based security descriptors are the missing
link when thinking about domain attack graphs!
▪ There ARE existing “misconfigurations” in the security
descriptors in some host-based services!
▫ More to come on this in a bit ;)
▪ Host-based security descriptor modifications can be
chained with AD misconfigurations/modifications
▪ “Fills the gap” left by the lack of an AD ACL computer primitive
33

34. tl;dr Security Implications of Joining Active Directory
▪ When you join a system to Active Directory, you’re
introducing additional nodes into the access graph
that may affect the security of other systems
▪ You’re also implicitly trusting the security of a
large number of other nodes in the graph as well
▫ You’re almost certainly exposing your system’s services
to more access than you realize!
34

35. Case Study #1
Picking on Exchange Again :)

36. Case Study: Exchanging Rights
▪ We saw before that the Exchange Trusted
Subsystem group (which contains Exchange servers)
often has a huge number of rights over the domain
▪ So let’s integrate the remote registry host-based
backdoor on an Exchange box!
▫ No changes to the DC or any AD data
▫ Takes advantage of existing misconfigurations!
36

37. 37

38. Case Study #2
Abusing Existing Misconfigurations

39. Ingredient #1: Unconstrained Delegation
▪ If a server is configured for unconstrained
delegation, service ticket requests will include the
requestor’s TGT stuffed into the service ticket
▪ So if you can get a principal to auth to an
unconstrained server you control, you can
extract their TGTs out of memory!
▪ More information: https://adsecurity.org/?p=1667
39

40. Ingredient #2: Effectively Extracting TGTs
▪ Rubeus is a new C# Kerberos abuse toolkit that
includes various ticket extraction capabilities
▪ The monitor action will monitor 4624 logon events
from the event log and extract any new usable
TGT .kirbis from LSASS using LSA APIs
▫ No read handle to LSASS needed!
40https://github.com/GhostPack/Rubeus

41. Ingredient #3: The Printer Bug
▪ Old but enabled-by-default-on-Windows Print
System Remote Protocol (MS-RPRN)
▪ RpcRemoteFindFirstPrinterChangeNotification(Ex)
▫ Purpose: “REMOTESERVER, send me a notification when
____” (e.g. when there’s a new print job)
▪ Implication: *Any domain user* can coerce
REMOTESERVER$ to authenticate to any machine
▫ Won’t fix by Microsoft - “ by design” ☺
41

42. Ingredient #3: The Printer Bug
42
Domain User/Attacker: Please authenticate to OTHERHOST
SERVER
OTHERHOST
Abuse Scenarios
▪ Machine account TGT theft via Unconstrained Delegation
▪ NTLM attacks!!!!
▪ NTLM-relay to ______ protocol
▪ Is SERVER$ local admin anywhere? (Relay and login)
▪ LDAP relay anyone…. ☺
▪ NTLMv1 downgrade attacks - XP/2003 anyone?

43. The Dangerous Recipe
1. Compromise a server configured with
unconstrained delegation
2. Beginning monitoring for delegated TGTs
▫ Start Rubeus’ monitor action with /interval:5
3. Coerce a domain controller to authenticate to the
unconstrained server using SpoolSample
4. Load the extracted ticket, DCSync, profit!
43

44. 44

45. 45
Summary
▪ Access is more than just “local administrators” !
▪ Host based security descriptors (accidentally misconfigured,
configured by default, or maliciously backdoored) can have
far-reaching implications for the security of other
systems in the domain!
▪ Defense should focus on restricting access to ALL securable
objects (host, AD, Exchange, etc.)

46. 46
Questions?
You can find us at @SpecterOps:
▪ @harmj0y , @tifkin_ ,
@enigma0x3
▪ [will,lee,matt]@specterops.io
Credit to @elad_shamir for subsequent
discovery of the printer bug!

47. Appendix: Printer Bug Details
▪ Print System Remote Protocol (MS-RPRN)
▫ All comms are SMB-RPC (TCP 445)
▫ Named Pipe: pipespoolss
▫ RPC UUID: 12345678-1234-ABCD-EF00-0123456789AB
▫ “Discovered” by reading the protocol spec (likely more
RPC servers that do a similar thing)
47

48. Appendix: Printer Bug Details
▪ Opnum 62 or 65
▫ RpcRemoteFindFirstPrinterChangeNotification
▫ RpcRemoteFindFirstPrinterChangeNotificationEx
▪ The RPC server is accessible by all domain users
on Windows >= 8 if the Spooler service is started
(Server & Workstations have it enabled by default)
▫ On Windows < 8 , seems possible if the host has
shared a printer
48

49. Appendix: Coerced Machine Account Authentication
Attack Scenarios
▪ Printer bug isn’t the only way to do this (we’ve already confirmed from
our own research/other that there’s other vectors)
▪ If NTLMv1 enabled? Do an NTLMv1 downgrade and get the machine’s
NTLM hash
▪ NTLM relay
▫ Is a machine account a member of the local Administrators group on any
machine? (Often seen on SCCM and Exchange servers)
▫ NTLM relay to LDAP and grant yourself DCSync rights if LDAP signing not
enforced (see @_dirkjan’s contribution to ntlmrelayx)
▫ Problematic with SMB -> LDAP due to SMB clients setting the signing
bit (thanks @_dirkjan!)
49

50. Hi Lee,
The team has finished its investigation and determined the issue is by-design.
From the NTLM side of things, this is a relay attack, and there are plenty of mitigations that customers can
use to mitigate this particular attack:
1. Restrict NTLM usage
2. Configure/enable Extended Protection for Authentication for all services that support it.
3. Enable SMB Signing or SMB Encryption
4. Do not grant machine accounts administrative privileges to other machine accounts
50

51. Additional Guidance
▪ Impersonating domain machine accounts is by design? ¯_(ツ)_/¯
▫ We don’t think it was, but nonetheless, it’s possible
▪ Restricting access to hosts/networks goes a LONG way
▫ Windows does not require inbound network access in order to work
in Active Directory!
▫ FIREWALLS!! Host-based and network
▫ IPSec
▪ Prevent relaying to LDAP: Set LdapEnforceChannelBinding to 1
51