Skip to main content
Core Security Logo Core Security Logo
  • Contact Us
  • Support
  • All Fortra Products
  • FREE TRIALS
  • Contact Us
  • Support
  • All Fortra Products
  • FREE TRIALS
  • Cyber Threat

      Products

      • Core Impact Penetration testing software
      • Cobalt Strike Red team software
      • Outflank Security Tooling (OST) Evasive attack simulation
      • Event Manager Security information and event management
      • Powertech Antivirus Server-level virus protection
      • Product Bundles

      Solutions

      • Penetration Testing
      • Penetration Testing Services
      • Offensive Security
      • Threat Detection
      • Security Information and Event Management
    • Penetration Testing Services Security consulting services
  • Identity

      Products

      • Access Assurance Suite User provisioning and governance
      • Core Password & Secure Reset Self-service password management
      • Core Privileged Access Manager (BoKS) Privileged access management (PAM)

      Solutions

      • Privileged Access Management
      • Identity Governance & Administration
      • Password Management
    • See How to Simplify Access in Your Organization | Request a Demo
  • Industries
    • Healthcare
    • Financial Services
    • Federal Government
    • Retail
    • Utilities & Energy
    • Higher Education
    • Compliance
  • Resources
    • Upcoming Webinars & Events
    • Blogs
    • Case Studies
    • Videos
    • Datasheets
    • Guides
    • Ecourses
    • Compliance
    • All Resources
  • CoreLabs
    • Advisories
    • Exploits
    • Publications
    • Articles
    • Open Source Tools
  • About
    • Partners
    • Careers
    • Press Releases
    • Contact Us
  1. Home
  2. Blog
  3. Getting Inside the Mind of an Attacker: After the Breach – Miscellaneous Techniques for Achieving Persistence

Getting Inside the Mind of an Attacker: After the Breach – Miscellaneous Techniques for Achieving Persistence

In the first two parts of this series, we covered how attackers may attempt to gain persistence in Active Directory by forging Kerberos tickets or through domain replication abuse, and also discussed strategies to detect these methods. In this part, we’ll touch on a few more techniques: AdminSDHolder and SDProp abuse, SID History attacks, and skeleton key attacks.

AdminSDHolder Container and SDProp Abuse

The AdminSDHolder container exists in every Active Directory domain as a template to copy reconfigured permissions to protected objects, such as domain admins, administrators, enterprise admin groups, or the KRBTGT account. The access control list (ACL) of these objects, which is very restricted, will be replicated to each protected object every 60 minutes by a process called Security Descriptor Propagator, or SDProp for short.

Attackers may attempt to modify the access control list, leveraging their gained domain admin privileges to add full control privilege over protected groups to their domain accounts. From there, they could then wait for SDProp to be triggered and obtain on-demand domain admin privileges. Blue teamers won't be able to detect this strategy and uncover its root cause if they do not see the change being made to the AdminSDHolder's ACL. Luckily, monitoring audit event 4662, which indicates when an operation was performed on an object, enables security teams to detect modifications to the AdminSDHolder object.

Impatient attackers unwilling to wait for the scheduled execution of SDProp may instead manually trigger the process. They will quickly pay for acting hastily, as the execution of SDProp out of sequence can be easily detected by monitoring the audit event 4780, which indicates that the ACL was set on accounts which are members of administrator groups.

Image
monitoring operators unaware of this persistent technique

The images above show what may occur if monitoring operators are unaware of this persistent technique. An operator would only see that a user is being added to a privileged group, in this case, the Domain Admin groups. While they may later request for this to be reverted, they will likely assume the event is benign, and will not investigate any further.

Image
Event 4662

However, now that your operators know about this attack, they will know to start examining other events, such as the one shown above, to detect the modification of the AdminSDHolder's ACL and identify the offending accounts. In this case, the account is in the subject field, which is the administrator domain account.

SIDHistory Attribute Abuse

Security identifier history is an attribute of every domain account that tracks previous membership to other domains. For example, if a user was a member of domain B and was then migrated to domain A, the security identifier of the user in domain B would then be added to the SIDHistory field of the migrated account. Then, if the migrated account requested access to a resource in domain B, access would be granted as long as it has the correct identifier in the SIDHistory attribute. This behavior is not only valid in an inter-domain setup, but also within the same domain. So, if a user is able to inject a domain admin security identifier within their own SIDHistory field, these privileges will be honored during access evaluation, in spite of their actual group membership.

Going one step further, if a user account includes the SID of an enterprise admin of another domain in the same forest, this will grant the user with admin rights on that domain as well. This doesn't work at the inter-forest level because of SID filtering, which is a feature created specifically to prevent this kind of attack. This feature is enabled by default, although it does have the option of being disabled.

An attacker that successfully gains domain admin privileges would be able to add any target account's SID to the SIDHistory field of another account and grant it with the same privileges as the target account. This can be tricky to pull off, as it requires modifying the domain database. In order to execute such an attack, threat actors would need to patch the NTDS file, which is locked in the domain controller at all times. This operation can only be done by patching this file in the domain controller itself. Such a modification can be easily detected by monitoring both audit event 4765, which indicates that SIDHistory was added to an account, as well as all the other events triggered by the attacker logging into a domain controller.

However, it is possible for an attacker to leverage DCShadow, a technique we discussed in part two, to propagate this change from their machine to the real domain controller in the environment. In this case, a monitoring operator may see events associated to the registration of the rogue DC, but no traces will be left of the SIDHistory attribute modification itself.

Image
Attacker using Mimikatz

The above image shows how an attacker can use Mimikatz to prepare the changes they desire to replicate into the domain database, in this case, the addition of the SID for the Domain Admin group to a regular user.

Image
Push to domain controller

Next, the attacker would push it to the domain controller, as can be seen above. Such an action won't produce any event associated to the modification of the SIDHistory attribute for the affected user account. Instead, there would only be logs related to the registration and deletion of the rogue domain controller.

Skeleton Key Attacks

Lastly, the skeleton key attack consists of injecting a master password in the LSASS process memory space of a domain controller, which could then be used to authenticate as an end user in the domain. A major drawback is that it requires the injection of the skeleton key in every domain controller in order for the attack to be reliable. Additionally, this technique is not particularly sneaky these days, as there are now many third-party products that monitor and prevent process injection to LSASS.

Image
Event 4673

However, if an attacker did manage to pull off the injection, it could be detected by monitoring for the 4673 and 4611 events, which are both LSASS-related. Event 4673 indicates that a privileged service was called, and event 4611 indicates that a trusted logon process has been registered with the Local Security Authority. In the image above, we can see an example of the event 4673 event, triggered when an attacker logged into a domain controller and executed this attack. We can see clear indication of the privilege, the lsass.exe process, being tampered with.

 

Now that we’ve looked at multiple techniques that attackers may use to gain persistence, we have a better idea of what to look out for and precautionary measures we can take. In our last part of the series, we’ll conclude with some final thoughts and advice on how to ensure you can swiftly detect an attacker, before they can cause real damage.

Julio Sanchez
Meet the Author

Julio Sanchez

Senior Cybersecurity Consultant
Core Security, by Fortra
View Profile
Related Products
Penetration Testing Services
Related Content
Getting Inside the Mind of An Attacker Part One Thumbnail
Video
Getting Inside the Mind of an Attacker: After the Breach - Next Steps After Compromising Active Directory
after the breach part 1 thumbnail
Blog
Getting Inside the Mind of an Attacker: After the Breach - Achieving Persistence with Golden and Silver Tickets
Getting Inside the Mind of an Attacker: After the Breach - Achieving Persistence with Domain Replication Abuse
Blog
Getting Inside the Mind of an Attacker: After the Breach - Achieving Persistence with Domain Replication Abuse
Digital lock
Video
Getting Inside the Mind of an Attacker: Going Beyond the Exploitation of Software Vulnerabilities

Learn More About Active Directory Attacks

CTA Text

Find out how attackers initially breach Active Directory, and strategies on how to prevent it from happening to your organization in our first Getting Inside the Mind of an Attacker series.

READ THE SERIES
  • Email Core Security Email Us
  • Twitter Find us on Twitter
  • LinkedIn Find us on LinkedIn
  • Facebook Find us on Facebook

Products

  • Access Assurance Suite
  • Core Impact
  • Cobalt Strike
  • Event Manager
  • Browse All Products

Solutions

  • Identity Governance

  • PAM
  • IGA
  • IAM
  • Password Management
  • Vulnerability Management
  • Compliance
  • Cyber Threat

  • Penetration Testing
  • Red Team
  • Phishing
  • Threat Detection
  • SIEM

Resources

  • Upcoming Webinars & Events
  • Corelabs Research
  • Blog
  • Training

About

  • Our Company
  • Partners
  • Careers
  • Accessibility

Support

Privacy Policy

Contact

Impressum

Copyright © Fortra, LLC and its group of companies. All trademarks and registered trademarks are the property of their respective owners.