An ACE Up the Sleeve
Designing Active Directory DACL Backdoors
Andy Robbins and Will Schroeder
SpecterOps
@_wald0
▪ Job: Adversary Resilience Lead at SpecterOps
▪ Co-founder/developer: BloodHound
▪ Trainer: BlackHat 2016
▪ Presenter: DEF CON, DerbyCon, ekoparty,
Paranoia, ISSA Intl, ISC2 World Congress, various
Security BSides
▪ Other: ask me about ACH
@harmj0y
▪ Job: Offensive Engineer at SpecterOps
▪ Co-founder/developer: Veil-Framework,
Empire/EmPyre, PowerView/PowerUp, BloodHound,
KeeThief
▪ Trainer: BlackHat 2014-2016
▪ Presenter: DEF CON, DerbyCon, ShmooCon,
Troopers, BlueHat Israel, various BSides
▪ Other: PowerSploit developer and Microsoft
PowerShell MVP
tl;dr
▪ DACL/ACE Background
▪ DACL Misconfiguration and Abuse
▪ Analysis with BloodHound
▪ Designing ACL Based Backdoors
▪ Case Studies and Demos
▪ Defenses
Disclaimer
▪ There is no exploit/CVE/whatnot here, just
ways to purposely implement Active Directory
DACL misconfigurations
▪ These backdoors are post-elevation
techniques that require some type of
elevated access to the objects you’re
manipulating
Why Care?
▪ It’s often difficult to determine whether a specific AD
DACL misconfiguration was set maliciously or
configured by accident
▪ These changes also have a minimal forensic footprint
and often survive OS and domain functional level
upgrades
□ This makes them a great chance for subtle, long-term
domain persistence!
▪ These may have been in your environment for YEARS!
“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” Matt Graeber
“Abusing Windows Management Instrumentation
(WMI) to Build a Persistent, Asynchronous, and
Fileless Backdoor” - BlackHat 2015
Background
From ACLs to ACEs
1.
https://www.sstic.org/2014/presentation/chemins_de_controle_active_directory/
Previous Work
Previous Work
https://blogs.technet.microsoft.com/pfesweplat/2017/01/28/forensics-active-directory-acl-investigation/
Previous Work
https://bitbucket.org/iwseclabs/bta/
https://habrahabr.ru/post/90990/
Previous (Offensive) Work
SECURITY_DESCRIPTOR
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556610(v=vs.85).aspx
ACLs, DACLs, and SACLs
▪ Access Control List (ACL) is basically shorthand for
the DACL/SACL superset
▪ An object’s Discretionary Access Control List
(DACL) and System Access Control List (SACL) are
ordered collections of Access Control Entries (ACEs)
□ The DACL specifies what principals/trustees have what
rights over the object
□ The SACL allows for auditing of access attempts to the
object
The Access
Control
Mask
(GUI Edition)
DS_CONTROL_ACCESS
▪ AD access mask bit that grants privileges that aren’t
easily expressed in the access mask
▪ Interpreted a few different ways...
▪ If the ObjectAceType of an ACE with
CONTROL_ACCESS set is the GUID of a confidential
property or property set, this bit controls read
access to that property
□ E.g. in the case of the Local Administrator Password
Soltution (LAPS)
DS_CONTROL_ACCESS
and Extended Rights
▪ If the ObjectAceType GUID matches a registered
extended-right GUID in the schema, then
control_access grants that particular “control access
right”
□ User-Force-Change-Password on user objects
□ DS-Replication-Get-Changes and DS-Replication-Get-
Changes-All on the domain object itself
SRM and Canonical ACE Order
DACL
(Mis)configurations
Object Takeover and Abuse
2.
Elevation vs. Persistence
▪ Our work in this area was first motivated by a desire
to find AD misconfigurations for the purposes of
domain privilege escalation
□ I.e. searching for specific ACE relationships that result in a
lesser-privileged object modifying a higher-privileged one
▪ This presentation is about modifying/adding ACEs
(or chains of ACEs) in order to provide persistence in
a domain environment
▪ The two takeover primitives are forcing a password
reset, and targeted Kerberoasting through SPN
modification (to recover creds)
▪ So the additional rights we care about are:
□ WriteProperty to all properties
□ WriteProperty to servicePrincipalName
□ All extended rights
□ User-Force-Change-Password (extended)
▪ Abusable through Set-DomainObjectOwner and Set-
DomainUserPassword
Target: User Objects
▪ The main takeover primitive involves adding a
user to the target group
▪ So the additional rights we care about are:
□ WriteProperty to all properties
□ WriteProperty to the member property
▪ Abusable through Add-DomainGroupMember
Target: Group Objects
▪ If LAPS is enabled:
□ We care about DS_CONTROL_ACCESS or GenericAll to
the ms-MCS-AdmPwd (plaintext password) property
▪ Otherwise, we don’t know of a practical way to
abuse a control relationship to computer
objects :(
□ If you have any ideas, please let us know!
Target: Computer Objects
▪ The main takeover primitive involves granting a
user domain replications rights (for DCSync)
□ Or someone who currently has DCSync rights
▪ So the main effective right we care about is
WriteDacl, so we can grant a principal DCSync
rights with Add-DomainObjectAcl
□ Or explicit DS-Replication-Get-Changes/ DS-
Replication-Get-Changes-All
Target: Domain Objects
▪ The main takeover primitive involves the right to edit
the group policy (that’s then linked to an
OU/site/domain)
□ This gives the ability to compromise users/computers in
these containers
▪ So the additional rights we care about are:
□ WriteProperty to all properties
□ WriteProperty to GPC-File-Sys-Path
▪ GPOs can be edited on SYSVOL
Target: GPOs
AD Generic Rights
▪ GenericAll
□ Allows ALL generic rights to the specified object
□ Also grants “control rights” (see next slide)
▪ GenericWrite
□ Allows for the modification of (almost) all properties on a
specified object
▪ Both are abusable with PowerView’s Set-
DomainObject, and these two rights generally apply
to most objects for takeover
AD Control Rights
▪ Rights that allow a trustee/principal to take control of
the object in some way
▪ WriteDacl grants the ability to modify the DACL in the
object security descriptor
□ Abusable with PowerView: Add-DomainObjectAcl
▪ WriteOwner grants the ability to take ownership of the
object
□ Object owners implicitly have full rights!
□ Abusable with PowerView: Set-DomainObjectOwner
BloodHound Analysis
Arroooooooooo
3.
BloodHound Analysis
▪ BloodHound enables simple, graphical analysis of
control relationships in AD
▪ Defenders can use this for:
□ least privilege enforcement
□ identifying misconfigured ACLs
□ detecting “non-stealthy” ACL-enabled backdoors
▪ Attackers can use this to:
□ identify ACL-enabled escalation paths
□ select targets for highly stealthy backdoors
□ understand privilege relationships in the target domain
Designing Active
Directory DACL
Backdoors
(Stealth) Primitives for Pwnage
4.
Objective
▪ We want to implement an Active Directory
DACL-based backdoor that:
□ Facilitates the regaining of elevated control in the AD
environment
□ Blends in with normal ACL configurations (“hiding in
plain sight”), or is otherwise hidden from easy
enumeration by defenders
▪ Let’s see what we can come up with!
Stealth Primitive:
Hiding the DACL
▪ Effectively hiding DACLs from defenders
requires two steps
▪ Change the object owner from “Domain
Admins” to the attacker account.
▪ Add a new explicit ACE, denying the
“Everyone” principal the “Read Permissions”
privilege.
Stealth Primitive:
Hiding the DACL
▪ Hiding a principal from defenders requires
three steps:
a.Change the principal owner to itself, or another
controlled principal
b.Grant explicit control of the principal to either itself,
or another controlled principal
c.On the OU containing your hidden principal, deny
the “List Contents” privilege to “Everyone”
Stealth Primitive:
Hiding the Principal
Stealth Primitive:
Hiding the Principal
Primitives: Summary
▪ We know which ACEs result in object takeover
▪ We can control who can enumerate the DACL
▪ We can hide principals/trustees that are
present in a specific ACE
Backdoor Case Studies
“If you can dream it…”
5.
A Hidden DCSync
Backdoor
▪ Backdoor:
□ Add DS-Replication-Get-Changes and DS-Replication-
Get-Changes-All on the domain object itself where the
principal is a user/computer account the attacker controls
□ The user/computer doesn’t have to be in any special
groups or have any other special privileges!
▪ Execution:
□ DCSync whoever you want!
AdminSDHolder
▪ Backdoor:
□ Attacker grants themselves the User-Force-Change-
Password (or GenericAll) right on
CN=AdminSDHolder,CN=System,DC=domain,…
□ Every 60 minutes, this permission is cloned to every
sensitive/protected AD object through SDProp
□ Attacker “hides” their account using methods described
▪ Execution:
□ Attacker force resets the password for any adminCount=1
account
LAPS
▪ Microsoft’s “Local Administrator Password
Solution”
▪ Randomizes the a machine’s local admin password
every 30 days
□ The password is stored in the confidential ms-Mcs-
AdmPwd attribute on computer objects
▪ Administered with the AdmPwd.PS cmdlets
□ Find-AdmPwdExtendedRights “Audits” who can read
ms-Mcs-AdmPwd
https://technet.microsoft.com/en-us/mt227395.aspx
Who can read AdmPwd?*
▪ DS_CONTROL_ACCESSS where the ACE
□ applies to AdmPwd and all descendant computers
□ applies to AdmPwd and all descendant objects
□ applies to any object and all descendant objects
□ applies to any object and all descendant computers
▪ Above checks are also necessary for GENERIC_ALL
▪ Object control == Ability to grant the above rights
□ You are the owner
□ You can become the owner:
□ WriteDACL, WriteOwner
* See the whitepaper for more details - the list here is not comprehensive
Shortcomings of Find-
AdmPwdExtendedRights
▪ DS_CONTROL_ACCESSS where the ACE
□ applies to AdmPwd and all descendant computers
□ applies to AdmPwd and all descendant objects
□ applies to any object and all descendant objects
□ applies to any object and all descendant computers
▪ Above checks are also necessary for GENERIC_ALL
▪ Object control == Ability to grant the above rights
□ You are the owner
□ You can become the owner
□ WriteDACL, WriteOwner
▪ Only analyzes OUs and (optionally) computers
Normal user can’t access
ms-mcs-AdmPwd
Privileged attacker adds
backdoor to Servers OU
Domain user can access
AdmPwd! LAPS cmdlet doesn’t
detect it!
Exchange Strikes Back
▪ 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, which was distributed down to ALL securable
objects!
Exchange Strikes Back
▪ Backdoor:
□ Identify a non-protected security group with local
admin rights on one or more Exchange servers
□ Grant “Authenticated Users” full control over this
security group
□ Change the owner of the group to an Exchange server
□ Deny “Read Permissions” on this group to the
“Everyone” principal
▪ Execution:
□ Regain access to the Active Directory domain as any user
□ Add your current user to the back-doored security group
□ Use your new local admin rights on an Exchange server to
execute commands as the SYSTEM user on that
computer.
□ Exchange Trusted Subsystem often has full control of the
domain, so this may include DCSync!
Exchange Strikes Back
Abusing GPOs
▪ Backdoor:
□ Attacker grants herself GenericAll to any user object with the attacker as
the trustee
□ Grant that “patsy” user WriteDacl to the default domain controllers GPO
▪ Execution:
□ Force resets the “patsy” account password
□ Adds a DACL to the GPO that allows write access for the patsy to GPC-
File-Sys-Path of the GPO
□ Grants the attack SeEnableDelegationPrivilege rights in GptTmpl.inf
□ Executes a constrained delegation attack using the patsy account’s
credentials
Defenses
All is (Probably) Not Lost ;)
6.
Event Logs
▪ Proper event log tuning and monitoring is pretty
much your only hope for performing real “forensics”
on these actions
□ But if you weren’t collecting event logs when the
backdoor was implemented, you might not ever know
who the perpetrator was :(
▪ For example:
□ Event log 4738 (“A user account was changed”), filtered by
the property modified
Replication Metadata
▪ Metadata remnants from domain controller
replication can grant a few clues
□ Specifically, when a given attribute was modified, and
from what domain controller the modification event
occurred on
▪ This points you in the right direction, but needs to be
used with event logs to get the full picture
□ More information in a post soon on
http://blog.harmj0y.net
SACLs
▪ SACLs contain ACEs that, “specify the types of
access attempts that generate audit records in the
security event log of a domain controller”
▪ You don’t have to SACL every success/failure action
on every object type and property:
□ A great start- build SACLs for all of the attack primitives
we’ve talked about on the specific target objects we’ve
outlined
□ More information: http://bit.ly/2tOAGn7
▪ We were not able to utilize NULL DACLs or otherwise
manipulate the header control bits (i.e.
SE_DACL_PRESENT)
□ Any attempts to set ntSecurityDescriptor on an object
remotely ignores any header bits, however this warrants
another look
▪ Research additional control relationships
□ Particularly any relationship that allows for computer
object takeover
Future Work
Credits
Special thanks to all the people who helped us
with this research and slide deck:
▪ Lee Christensen (@tifkin_)
▪ Jeff Dimmock (@bluscreenofjeff)
▪ Everyone else at SpecterOps!
▪ Matt Graeber (@mattifestation)
Questions?
Contact us at:
▪ @_wald0 (robbins.andy [at] gmail.com)
▪ @harmj0y (will [at] harmj0y.net)

Ace Up the Sleeve

  • 1.
    An ACE Upthe Sleeve Designing Active Directory DACL Backdoors Andy Robbins and Will Schroeder SpecterOps
  • 2.
    @_wald0 ▪ Job: AdversaryResilience Lead at SpecterOps ▪ Co-founder/developer: BloodHound ▪ Trainer: BlackHat 2016 ▪ Presenter: DEF CON, DerbyCon, ekoparty, Paranoia, ISSA Intl, ISC2 World Congress, various Security BSides ▪ Other: ask me about ACH
  • 3.
    @harmj0y ▪ Job: OffensiveEngineer at SpecterOps ▪ Co-founder/developer: Veil-Framework, Empire/EmPyre, PowerView/PowerUp, BloodHound, KeeThief ▪ Trainer: BlackHat 2014-2016 ▪ Presenter: DEF CON, DerbyCon, ShmooCon, Troopers, BlueHat Israel, various BSides ▪ Other: PowerSploit developer and Microsoft PowerShell MVP
  • 4.
    tl;dr ▪ DACL/ACE Background ▪DACL Misconfiguration and Abuse ▪ Analysis with BloodHound ▪ Designing ACL Based Backdoors ▪ Case Studies and Demos ▪ Defenses
  • 5.
    Disclaimer ▪ There isno exploit/CVE/whatnot here, just ways to purposely implement Active Directory DACL misconfigurations ▪ These backdoors are post-elevation techniques that require some type of elevated access to the objects you’re manipulating
  • 6.
    Why Care? ▪ It’soften difficult to determine whether a specific AD DACL misconfiguration was set maliciously or configured by accident ▪ These changes also have a minimal forensic footprint and often survive OS and domain functional level upgrades □ This makes them a great chance for subtle, long-term domain persistence! ▪ These may have been in your environment for YEARS!
  • 7.
    “As an offensiveresearcher, 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” Matt Graeber “Abusing Windows Management Instrumentation (WMI) to Build a Persistent, Asynchronous, and Fileless Backdoor” - BlackHat 2015
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
    ACLs, DACLs, andSACLs ▪ Access Control List (ACL) is basically shorthand for the DACL/SACL superset ▪ An object’s Discretionary Access Control List (DACL) and System Access Control List (SACL) are ordered collections of Access Control Entries (ACEs) □ The DACL specifies what principals/trustees have what rights over the object □ The SACL allows for auditing of access attempts to the object
  • 15.
  • 16.
    DS_CONTROL_ACCESS ▪ AD accessmask bit that grants privileges that aren’t easily expressed in the access mask ▪ Interpreted a few different ways... ▪ If the ObjectAceType of an ACE with CONTROL_ACCESS set is the GUID of a confidential property or property set, this bit controls read access to that property □ E.g. in the case of the Local Administrator Password Soltution (LAPS)
  • 17.
    DS_CONTROL_ACCESS and Extended Rights ▪If the ObjectAceType GUID matches a registered extended-right GUID in the schema, then control_access grants that particular “control access right” □ User-Force-Change-Password on user objects □ DS-Replication-Get-Changes and DS-Replication-Get- Changes-All on the domain object itself
  • 18.
  • 19.
  • 20.
    Elevation vs. Persistence ▪Our work in this area was first motivated by a desire to find AD misconfigurations for the purposes of domain privilege escalation □ I.e. searching for specific ACE relationships that result in a lesser-privileged object modifying a higher-privileged one ▪ This presentation is about modifying/adding ACEs (or chains of ACEs) in order to provide persistence in a domain environment
  • 21.
    ▪ The twotakeover primitives are forcing a password reset, and targeted Kerberoasting through SPN modification (to recover creds) ▪ So the additional rights we care about are: □ WriteProperty to all properties □ WriteProperty to servicePrincipalName □ All extended rights □ User-Force-Change-Password (extended) ▪ Abusable through Set-DomainObjectOwner and Set- DomainUserPassword Target: User Objects
  • 22.
    ▪ The maintakeover primitive involves adding a user to the target group ▪ So the additional rights we care about are: □ WriteProperty to all properties □ WriteProperty to the member property ▪ Abusable through Add-DomainGroupMember Target: Group Objects
  • 23.
    ▪ If LAPSis enabled: □ We care about DS_CONTROL_ACCESS or GenericAll to the ms-MCS-AdmPwd (plaintext password) property ▪ Otherwise, we don’t know of a practical way to abuse a control relationship to computer objects :( □ If you have any ideas, please let us know! Target: Computer Objects
  • 24.
    ▪ The maintakeover primitive involves granting a user domain replications rights (for DCSync) □ Or someone who currently has DCSync rights ▪ So the main effective right we care about is WriteDacl, so we can grant a principal DCSync rights with Add-DomainObjectAcl □ Or explicit DS-Replication-Get-Changes/ DS- Replication-Get-Changes-All Target: Domain Objects
  • 25.
    ▪ The maintakeover primitive involves the right to edit the group policy (that’s then linked to an OU/site/domain) □ This gives the ability to compromise users/computers in these containers ▪ So the additional rights we care about are: □ WriteProperty to all properties □ WriteProperty to GPC-File-Sys-Path ▪ GPOs can be edited on SYSVOL Target: GPOs
  • 26.
    AD Generic Rights ▪GenericAll □ Allows ALL generic rights to the specified object □ Also grants “control rights” (see next slide) ▪ GenericWrite □ Allows for the modification of (almost) all properties on a specified object ▪ Both are abusable with PowerView’s Set- DomainObject, and these two rights generally apply to most objects for takeover
  • 27.
    AD Control Rights ▪Rights that allow a trustee/principal to take control of the object in some way ▪ WriteDacl grants the ability to modify the DACL in the object security descriptor □ Abusable with PowerView: Add-DomainObjectAcl ▪ WriteOwner grants the ability to take ownership of the object □ Object owners implicitly have full rights! □ Abusable with PowerView: Set-DomainObjectOwner
  • 28.
  • 29.
    BloodHound Analysis ▪ BloodHoundenables simple, graphical analysis of control relationships in AD ▪ Defenders can use this for: □ least privilege enforcement □ identifying misconfigured ACLs □ detecting “non-stealthy” ACL-enabled backdoors ▪ Attackers can use this to: □ identify ACL-enabled escalation paths □ select targets for highly stealthy backdoors □ understand privilege relationships in the target domain
  • 31.
  • 32.
    Objective ▪ We wantto implement an Active Directory DACL-based backdoor that: □ Facilitates the regaining of elevated control in the AD environment □ Blends in with normal ACL configurations (“hiding in plain sight”), or is otherwise hidden from easy enumeration by defenders ▪ Let’s see what we can come up with!
  • 33.
    Stealth Primitive: Hiding theDACL ▪ Effectively hiding DACLs from defenders requires two steps ▪ Change the object owner from “Domain Admins” to the attacker account. ▪ Add a new explicit ACE, denying the “Everyone” principal the “Read Permissions” privilege.
  • 34.
  • 35.
    ▪ Hiding aprincipal from defenders requires three steps: a.Change the principal owner to itself, or another controlled principal b.Grant explicit control of the principal to either itself, or another controlled principal c.On the OU containing your hidden principal, deny the “List Contents” privilege to “Everyone” Stealth Primitive: Hiding the Principal
  • 36.
  • 37.
    Primitives: Summary ▪ Weknow which ACEs result in object takeover ▪ We can control who can enumerate the DACL ▪ We can hide principals/trustees that are present in a specific ACE
  • 38.
    Backdoor Case Studies “Ifyou can dream it…” 5.
  • 39.
    A Hidden DCSync Backdoor ▪Backdoor: □ Add DS-Replication-Get-Changes and DS-Replication- Get-Changes-All on the domain object itself where the principal is a user/computer account the attacker controls □ The user/computer doesn’t have to be in any special groups or have any other special privileges! ▪ Execution: □ DCSync whoever you want!
  • 41.
    AdminSDHolder ▪ Backdoor: □ Attackergrants themselves the User-Force-Change- Password (or GenericAll) right on CN=AdminSDHolder,CN=System,DC=domain,… □ Every 60 minutes, this permission is cloned to every sensitive/protected AD object through SDProp □ Attacker “hides” their account using methods described ▪ Execution: □ Attacker force resets the password for any adminCount=1 account
  • 43.
    LAPS ▪ Microsoft’s “LocalAdministrator Password Solution” ▪ Randomizes the a machine’s local admin password every 30 days □ The password is stored in the confidential ms-Mcs- AdmPwd attribute on computer objects ▪ Administered with the AdmPwd.PS cmdlets □ Find-AdmPwdExtendedRights “Audits” who can read ms-Mcs-AdmPwd https://technet.microsoft.com/en-us/mt227395.aspx
  • 44.
    Who can readAdmPwd?* ▪ DS_CONTROL_ACCESSS where the ACE □ applies to AdmPwd and all descendant computers □ applies to AdmPwd and all descendant objects □ applies to any object and all descendant objects □ applies to any object and all descendant computers ▪ Above checks are also necessary for GENERIC_ALL ▪ Object control == Ability to grant the above rights □ You are the owner □ You can become the owner: □ WriteDACL, WriteOwner * See the whitepaper for more details - the list here is not comprehensive
  • 45.
    Shortcomings of Find- AdmPwdExtendedRights ▪DS_CONTROL_ACCESSS where the ACE □ applies to AdmPwd and all descendant computers □ applies to AdmPwd and all descendant objects □ applies to any object and all descendant objects □ applies to any object and all descendant computers ▪ Above checks are also necessary for GENERIC_ALL ▪ Object control == Ability to grant the above rights □ You are the owner □ You can become the owner □ WriteDACL, WriteOwner ▪ Only analyzes OUs and (optionally) computers
  • 46.
    Normal user can’taccess ms-mcs-AdmPwd
  • 47.
  • 48.
    Domain user canaccess AdmPwd! LAPS cmdlet doesn’t detect it!
  • 49.
    Exchange Strikes Back ▪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, which was distributed down to ALL securable objects!
  • 50.
    Exchange Strikes Back ▪Backdoor: □ Identify a non-protected security group with local admin rights on one or more Exchange servers □ Grant “Authenticated Users” full control over this security group □ Change the owner of the group to an Exchange server □ Deny “Read Permissions” on this group to the “Everyone” principal
  • 51.
    ▪ Execution: □ Regainaccess to the Active Directory domain as any user □ Add your current user to the back-doored security group □ Use your new local admin rights on an Exchange server to execute commands as the SYSTEM user on that computer. □ Exchange Trusted Subsystem often has full control of the domain, so this may include DCSync! Exchange Strikes Back
  • 53.
    Abusing GPOs ▪ Backdoor: □Attacker grants herself GenericAll to any user object with the attacker as the trustee □ Grant that “patsy” user WriteDacl to the default domain controllers GPO ▪ Execution: □ Force resets the “patsy” account password □ Adds a DACL to the GPO that allows write access for the patsy to GPC- File-Sys-Path of the GPO □ Grants the attack SeEnableDelegationPrivilege rights in GptTmpl.inf □ Executes a constrained delegation attack using the patsy account’s credentials
  • 54.
  • 55.
    Event Logs ▪ Properevent log tuning and monitoring is pretty much your only hope for performing real “forensics” on these actions □ But if you weren’t collecting event logs when the backdoor was implemented, you might not ever know who the perpetrator was :( ▪ For example: □ Event log 4738 (“A user account was changed”), filtered by the property modified
  • 56.
    Replication Metadata ▪ Metadataremnants from domain controller replication can grant a few clues □ Specifically, when a given attribute was modified, and from what domain controller the modification event occurred on ▪ This points you in the right direction, but needs to be used with event logs to get the full picture □ More information in a post soon on http://blog.harmj0y.net
  • 57.
    SACLs ▪ SACLs containACEs that, “specify the types of access attempts that generate audit records in the security event log of a domain controller” ▪ You don’t have to SACL every success/failure action on every object type and property: □ A great start- build SACLs for all of the attack primitives we’ve talked about on the specific target objects we’ve outlined □ More information: http://bit.ly/2tOAGn7
  • 58.
    ▪ We werenot able to utilize NULL DACLs or otherwise manipulate the header control bits (i.e. SE_DACL_PRESENT) □ Any attempts to set ntSecurityDescriptor on an object remotely ignores any header bits, however this warrants another look ▪ Research additional control relationships □ Particularly any relationship that allows for computer object takeover Future Work
  • 59.
    Credits Special thanks toall the people who helped us with this research and slide deck: ▪ Lee Christensen (@tifkin_) ▪ Jeff Dimmock (@bluscreenofjeff) ▪ Everyone else at SpecterOps! ▪ Matt Graeber (@mattifestation)
  • 60.
    Questions? Contact us at: ▪@_wald0 (robbins.andy [at] gmail.com) ▪ @harmj0y (will [at] harmj0y.net)