Golden vs Silver vs DCShadow: Which Persistence Wins (Defender’s View 2026)

Last updated: April 26, 2026

Once an attacker reaches Domain Admin, the next question is persistence — how to retain access after the obvious paths are shut down. Three techniques dominate the post-DA persistence playbook: Golden Ticket, Silver Ticket, and DCShadow. Each has a different operational profile. This article compares them from the defender’s lens — what each leaves behind, what detects each, and which one your environment is least prepared for.

The three techniques in 60 seconds each

Golden Ticket

Forge a Kerberos TGT (Ticket Granting Ticket) signed with the krbtgt account’s NT hash. Once forged, the TGT is accepted by every DC in the domain, can be issued for any user (real or fake), and lasts until krbtgt‘s password is rotated twice. Default validity: 10 years.

mimikatz # kerberos::golden /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /user:Administrator /id:500 /ticket:golden.kirbi
mimikatz # kerberos::ptt golden.kirbi

From a Linux box with Impacket: ticketer.py.

Silver Ticket

Forge a Service Ticket (TGS) for a specific service, signed with that service account’s NT hash. Unlike Golden, Silver does not touch the DC at all — the forged ticket is presented directly to the service. Stealthier, narrower scope.

mimikatz # kerberos::golden /domain:corp.local /sid:S-1-5-21-... /target:fileserver.corp.local /service:cifs /rc4:<hash> /user:Administrator /id:500 /ticket:silver.kirbi

DCShadow

Register the attacker’s machine as a “Domain Controller” temporarily, replicate fake changes to a real DC, then de-register. The fake changes appear as if they came from a DC — they bypass most audit policies entirely.

mimikatz # !+
mimikatz # !processtoken
mimikatz # lsadump::dcshadow /object:CN=alice,OU=Users,DC=corp,DC=local /attribute:primaryGroupID /value:512

The above changes alice’s primary group to Domain Admins (RID 512) without any standard group-modification audit event firing. DCShadow does not trip the obvious rules because the change appears to be replication, not modification.

Operational comparison

Detection — what works for each

Golden Ticket detection

Forged TGTs have anomalies if you know what to look for:

• Mismatched lifetimes — default Golden Tickets are issued for 10 years; legitimate TGTs are 10 hours. Event 4769 fields include ticket lifetime; absurd values are forensic gold.
• Account-domain inconsistency — the TGT references a SID that does not exist in the domain. Event 4769 with unknown account names.
• Encryption type — older Mimikatz defaults to RC4-HMAC for Golden Tickets, while modern domains use AES. EncryptionType=0x17 on TGTs from a DC that has been upgraded to AES is suspicious.
• NoPAC anomalies — a forged ticket with mismatched PAC fields (RID, group memberships not corresponding to AD state) is a high-fidelity tell. Microsoft’s KB5008380 (Nov 2021) added PAC validation that catches many cases.

Silver Ticket detection

Harder. The DC sees nothing. Detection has to happen on the destination service:

• Event 4624 logon events on the target service host with Authentication Package = Kerberos but no preceding 4768/4769 on the DC for that account. Cross-correlation between DC and member-server logs.
• Anomalous service ticket use — a service ticket presented to the file server for a user that has no recent business reason to access it.
• The KB5008380 PAC check catches some Silver Tickets where the PAC does not match the SID.

DCShadow detection

The hardest. Designed to bypass most audit policies. Detection requires monitoring the DRS (Directory Replication Service) protocol itself:

• Network-layer detection — DRSUAPI traffic from non-DC source IPs. A workstation IP making DRS calls is impossible in legitimate operation.
• Event 4742 — “A computer account was changed” with high-privilege SPNs being added (DRS replication SPNs). DCShadow registers temporary SPNs that are themselves a tell.
• nTDSDSA object creation — the attack creates a fake DC object in the configuration partition. Auditing this object class catches it.
• ADTimeline / DCSyncMonitor / aclpwn-like tools for retrospective AD-state-diff analysis.

Which one is your environment least prepared for?

Empirically, in most Indian enterprise environments:

• Golden Ticket — 50% of environments have detection rules deployed, often around lifetime anomalies. Half do not.
• Silver Ticket — 15% of environments could detect a Silver Ticket within a week. Most have no cross-correlation between DC and member-server logs.
• DCShadow — under 10% have specific DCShadow detection. The technique was disclosed in 2018 and remains a widespread blind spot.

If you have not specifically tested any of these against your SIEM, assume you cannot detect them.

Structural mitigations

For Golden Ticket

• Rotate krbtgt password twice as part of standard hygiene (annually, plus after any tier-0 incident).
• Enforce KB5008380 PAC validation on all DCs and member servers.
• Reduce Domain Admins group to the smallest practical size; restrict where they can authenticate via Authentication Policies.

For Silver Ticket

• Migrate service accounts to gMSA — the 240-byte rotating password makes ticket forgery impractical.
• Rotate service-account passwords on a defined cadence (quarterly minimum for high-value services).
• Build cross-correlation between DC ticket logs (4768/4769) and member-server logon logs (4624). Discrepancies are tells.

For DCShadow

• Detect at the network layer — DRSUAPI traffic should originate only from known DC IPs.
• Audit nTDSDSA object creation in the configuration partition. There should be zero events outside legitimate DC promotion.
• Enforce tier separation — DCShadow requires temporary Domain Admin / Replication rights; tight tier-0 boundary makes the attack much harder.
• Run periodic AD state diffs — compare current state to a known-good baseline. Anomalous group membership additions or attribute changes are findings.

The strategic point

If an attacker reaches Domain Admin, your incident response is now: did they establish persistence we cannot detect, and if so, how long does it take to find?

The conservative answer for most environments: yes, and we cannot detect Silver Ticket or DCShadow. So the persistence might be there. The only safe response after a confirmed Domain Admin compromise is a full domain rebuild — wipe everything, rebuild from a known-good baseline, migrate users individually with re-verification.

Most organisations cannot afford this and instead “investigate and remediate” — which usually leaves the persistence in place. The attacker comes back six months later through their backdoor.

How to find your next persistence path

For attackers:

• Once DA, rotate krbtgt password yourself before defenders can — denies them the cleanup option.
• Create a low-profile persistence: AdminSDHolder modification, computer-account password persistence, certificate-based golden ticket equivalents.
• Avoid tools with known signatures; write equivalent code yourself for high-value targets.

For defenders:

• Audit krbtgt password age. If > 1 year and you have ever had a tier-0 incident, rotate now (twice, with delay).
• Audit AdminSDHolder ACL. Any non-default entry is suspicious.
• Check for unusual service principal names registered on user or computer accounts.
• Periodically diff AD state against a baseline; investigate anomalies.
• Log and alert on DRSUAPI traffic from non-DC IPs.

Compliance angle

• RBI Cyber Framework — privileged-access management and incident response capability requirements both touch this.
• SEBI CSCRF — MITRE T1558 (Forge Kerberos Tickets) is part of expected detection coverage.
• DPDP §8(5) — a defensible reasonable-security posture must include detection of persistent compromise.

The takeaway

Persistence after Domain Admin is the part of the attack chain most defenders are least prepared for. The three techniques in this article cover 80% of the post-DA persistence the field uses. If you have not specifically validated detection for each, your incident response after a tier-0 compromise will not be enough to evict the attacker. The work to fix this is mostly engineering: rules in the SIEM, audit policies on the DC, baselines you can diff against. Start with whichever you have the least coverage on — for most teams, that is DCShadow.