Derbycon - The Unintended Risks of Trusting Active Directory
•
21 likes•37,301 views
Given at DerbyCon 2018, this presentation covers host and Active Directory security descriptor research.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Derbycon - The Unintended Risks of Trusting Active Directory
Similar to Derbycon - The Unintended Risks of Trusting Active Directory (20)
More from Will Schroeder
More from Will Schroeder (19)
Recently uploaded
Recently uploaded (11)
Derbycon - The Unintended Risks of Trusting Active Directory
- 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
- 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
- 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!
- 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