Active Directory Persistence

After compromising the domain, the attacker’s goal is to not lose access even if passwords change, hosts are reinstalled, or the initial intrusion is detected. AD offers extraordinarily powerful persistence mechanisms because its trust rests on cryptographic keys (krbtgt, service keys, certificates) that are rarely rotated and that allow forging arbitrary authentication. A Golden Ticket or a stolen CA key can give months of invisible access. That’s why cleaning a compromised domain is far harder than detecting the compromise.

Threat model

AD persistence exploits the fact that authentication rests on long-lived secrets. Whoever steals the krbtgt key can forge TGTs for any user indefinitely; whoever steals a service account’s key forges tickets for that service; whoever steals the CA private key forges certificates for anyone. None of these requires re-exploiting anything: the forged credential is valid. Eradication means rotating those secrets, often twice.

Red Team

Golden Ticket (krbtgt)

With the krbtgt account’s hash (from a DCSync), forge a TGT for any user, with any group membership, valid for years. The quintessential domain persistence.

# get krbtgt (DCSync)
secretsdump.py domain/da:pass@<DC> -just-dc-user krbtgt
# forge and inject
ticketer.py -nthash <krbtgt_hash> -domain-sid <SID> -domain domain.local Administrator
mimikatz # kerberos::golden /user:Administrator /domain:... /sid:... /krbtgt:... /ptt

Silver Ticket (service key)

With a service/computer account’s hash, forge a TGS directly for that service (CIFS, HTTP, MSSQL) without going through the DC → stealthy (no traffic to the KDC). Persistent access to a specific service.

Diamond / Sapphire Ticket

Stealthier variants: instead of forging from scratch (Golden), you modify a legitimate TGT (Diamond) or use real accounts’ PACs (Sapphire) to evade detections looking for “impossible” tickets.

DCSync as persistence

Granting a controlled account replication rights (DS-Replication-Get-Changes) lets you re-dump hashes (krbtgt included) whenever you want, without being DA. A discreet, powerful ACL.

DCShadow

Register a controlled machine as a rogue DC and replicate malicious changes into the directory (add SID history, change memberships, seed backdoors) without the normal modification logs. Stealthy directory-level persistence.

AdminSDHolder / ACL backdoors

Modify the ACL of the AdminSDHolder object (the permission template for protected groups): every hour, SDProp reapplies those permissions to all privileged groups → you grant yourself permanent access that “revives” even if removed. Same with seeded ACLs (GenericAll over DA, WriteDacl over the domain for DCSync).

Others

Certificates (AD CS): steal the CA key → Golden Certificate; or keep a privileged-account PFX (see AD CS (Active Directory Certificate Services)). Survives password resets.
Skeleton Key: an in-memory patch on the DC accepting a master password for any user (volatile).
Hidden accounts/SPNs, GPO backdoor (GPO Abuse), seeded Shadow Credentials (Shadow Credentials).

Tools

mimikatz (kerberos::golden, lsadump::dcsync, lsadump::dcshadow, misc::skeleton).
impacket (ticketer.py, secretsdump.py, dacledit.py for ACLs).
Rubeus (golden/silver/diamond), Certipy (golden certificate), PowerView (ACL backdoors).

Impact

Persistent and often invisible access to the domain, resistant to password changes and partial cleanup. It’s what turns an incident into a long-term compromise; its existence forces drastic eradication measures.

Blue Team

Detection

Golden/Silver tickets: TGT/TGS used with no prior AS-REQ (4769 without a matching 4768), anomalous lifetimes (10 years), RC4 encryption, impossible SIDs/groups in the PAC.
DCSync from a non-DC principal (4662 with the replication GUID) — high fidelity.
DCShadow: ephemeral registration of a new nDC/server in the Configuration partition; replication from an unexpected source.
Changes to AdminSDHolder and domain ACLs (5136); new accounts in protected groups that reappear after removal.

Telemetry

Replication auditing (4662), sensitive-object change auditing (5136 over AdminSDHolder/domain), Kerberos (4768/4769 with encryption type and AS/TGS correlation), and specific tooling (Microsoft Defender for Identity, Golden Ticket/DCShadow detection).

Hardening and eradication

Rotate krbtgt TWICE (with an interval for replication) → invalidates all existing Golden Tickets. A mandatory step after a DC compromise.
Restrict replication rights to DCs; audit domain and AdminSDHolder ACLs regularly.
gMSA and long passwords on service accounts (mitigates Silver Tickets by cracking); AES over RC4.
Protect the CA (key in HSM, auditing) to cut Golden Certificates; review Shadow Credentials.
Tiering/PAW, Protected Users, and continuous monitoring with Defender for Identity / persistence detections.

Response (full eradication)

After a domain compromise: rotate krbtgt ×2, reset all privileged and service accounts, review AdminSDHolder and ACLs, reissue/revoke certificates if the CA fell, remove seeded accounts/SPNs/GPOs/Shadow Creds, and rebuild the DCs if there was DCShadow/Skeleton Key. Assume one undetected persistence reopens everything.

CVEs and real-world cases

Golden Ticket, DCSync, DCShadow, Skeleton Key are mimikatz TTPs (MITRE T1558.001 Golden, T1558.002 Silver, T1003.006 DCSync, T1207 DCShadow, T1098 account manipulation).
APT29, APT28, FIN6, ransomware groups use Golden Tickets and DCSync to persist after initial compromise.
Double krbtgt rotation is official Microsoft guidance after an AD incident precisely because of Golden Tickets.

Testing checklist

Golden Ticket with the krbtgt hash (forge + ptt)
Silver Ticket with a service/computer key (stealthy)
Diamond/Sapphire to evade forged-ticket detection
DCSync rights granted to a controlled account
DCShadow to seed changes without normal logs
AdminSDHolder / ACL backdoors (DCSync, GenericAll over DA)
Golden Certificate (CA key) / seeded Shadow Credentials
Blue: was krbtgt rotated ×2 and replication/AdminSDHolder audited?