Forging the Keys to the Kingdom: Understanding Golden & Silver Ticket Attacks

Introduction to Kerberos Authentication and Ticketing

Kerberos is a trusted network authentication protocol originally developed at MIT and implemented in Windows Server to verify user and host identities within Active Directory (AD) domains. In Windows Kerberos, the Key Distribution Center (KDC) is built into each domain controller (DC) and uses AD’s database for security principals. During logon, a client requests a Ticket-Granting Ticket (TGT) from the KDC. The KDC replies with a TGT and session key encrypted with the user’s key (derived from their password). The client stores this TGT for the current logon session.

When the user wants to access a network service (e.g. a file share), the client presents its TGT to the KDC’s Ticket-Granting Service (TGS) along with the service’s name. The KDC validates the TGT and issues a service ticket (TGS ticket) for that resource. The client then sends the service ticket to the target server, which decrypts it and allows access without further credential prompts. This ticket-based approach provides single sign-on: after the initial logon, the client can repeatedly obtain and use service tickets for resources in the AD domain. Kerberos also provides mutual authentication (both client and server verify each other), unlike NTLM.

Kerberos relies on symmetric cryptography. Each DC holds a long-term secret key (the password hash of the special account KRBTGT). All TGTs are encrypted and signed with this KRBTGT key. Similarly, each service account’s password hash is used to encrypt its service tickets. For example, modern Windows domains use AES encryption for Kerberos by default (AES-128/256), though older domains may also accept RC4. During ticket issuance and use, the KDC (via KRBTGT) and the service account keys protect ticket integrity. Compromise of these keys undermines the ticket system: with the KRBTGT hash one can forge any user’s TGT (a Golden Ticket), and with a service account hash one can forge a service ticket (Silver Ticket).

What Are Golden and Silver Tickets?

The terms Golden Ticket and Silver Ticket refer to powerful Kerberos forgery attacks in on-prem AD. A Golden Ticket is a forged TGT that lets an attacker authenticate as any AD user to any service. By learning the KRBTGT account’s password hash (usually via DCSync or memory dumping of a domain controller), an adversary can craft arbitrary TGTs as if signed by the KDC. This effectively gives “unrestricted access to any object in the domain”. A Golden Ticket can specify any username (often a privileged account) and group memberships, and is typically given a very long lifetime (years instead of the normal 10 hours). Golden Tickets are domain-wide with one forged TGT an attacker can then request service tickets for any resource in the forest without touching the KDC again.

In contrast, a Silver Ticket is a forged service ticket (TGS) for one specific target service. It requires the attacker to have the password hash of the service account (the account under which the target service runs, identified by a Service Principal Name, SPN). Using that hash, the attacker can encrypt a fake TGS for that service. Because the attacker never needs to contact the KDC to forge it, Silver Tickets often evade many DC-side controls. However, they only grant access to the particular service (e.g. one webserver, MSSQL instance, etc.), not arbitrary resources across the domain. Silver Tickets are easier to perform (service hashes can be extracted via Kerberoasting or credential dumping) but have a narrower scope than Golden Tickets.

In summary, Golden Tickets exploit the KRBTGT key to impersonate any account on any service, while Silver Tickets exploit a service account’s key to impersonate a user for that service only. Both attack types abuse Kerberos’s symmetric trust model. They represent potent persistence and privilege methods in on-prem AD environments, and they also have implications for hybrid/Entra AD scenarios, as we discuss later.

Technical Foundations and Cryptography of Kerberos Tickets

Kerberos relies on symmetric encryption keys derived from account passwords. When a user logs in, Windows turns the password into a master key by hashing it. The KDC’s own long-term key is the KRBTGT account’s secret (typically an AES key). Each service account also has a key (from its password hash or managed key).

TGT Encryption (KRBTGT key): The TGT is essentially a “ticket for the ticket-granting service.” The KDC creates a session key and embeds it in the TGT, encrypting that ticket with the KRBTGT account’s secret. Only the KDC knows this key, so no one else can forge or decrypt a valid TGT.
Service Ticket Encryption (Service key): When issuing a service ticket, the KDC encrypts the ticket with the target service account’s key. Only that service (or the OS process running it) can decrypt it and verify the user’s identity.
Ticket Authenticators: In normal Kerberos use, after a ticket is issued, the client presents it to the service along with an authenticator (a timestamp encrypted with the session key inside the ticket). The service decrypts the ticket with its key, then uses the session key to validate the authenticator. This proves the client possesses the session key (and thus the ticket is fresh). Forged tickets require skipping this step because attackers typically do not have the actual session keys that were supposed to be in the ticket. Forged tickets generally disable or bypass the authenticator check in the PAC (Privileged Attribute Certificate) to trick the service.
Encryption Types: Newer Windows domains use AES-128 and AES-256 for Kerberos. Legacy modes might still accept RC4-HMAC (essentially NTLM hash) or even older DES. Importantly, if an account key is only AES, an attacker must get the AES hash; if RC4 is allowed, the NTLM hash works too. Many golden/silver ticket tools allow using /aes256, /aes128, or /rc4 with the appropriate hex hash of the target account. For instance, mimikatz’s golden-ticket command takes the domain AES-256 hash of KRBTGT (or the RC4 hash with /ntlm) along with domain/SID/user info.

Because tickets rely solely on these symmetric keys, protecting those keys is critical. Once an attacker obtains the KRBTGT secret or a service account’s secret, they effectively hold the “master keys” to impersonate others. That is why Kerberos forensics often focuses on how those secrets were stolen (e.g. dumping lsass.exe, using DCSync, or Kerberoasting). Likewise, defenders are advised to use strong AES keys (disabling old RC4 ciphers) and long, complex service passwords, so that brute-forcing or extracting those keys is prohibitively difficult.

Attack Workflow for Golden Ticket

The Golden Ticket attack involves two main phases: (1) stealing the KRBTGT account’s hash, and (2) forging a fake TGT. Once forged, the attacker can inject this TGT into a session and then request service tickets for any resource.

KRBTGT Hash Theft: An attacker typically must first achieve Domain Administrator (or equivalent) privileges. Common methods include exploiting a DC vulnerability, getting an admin shell on a DC, or abusing credential theft tools like Mimikatz to dump memory. Alternatively, an attacker with fewer privileges can use the DCSync attack (via mimikatz or Rubeus) to impersonate a DC and replicate the krbtgt account hash from AD. Once the attacker obtains the NTLM (or AES) hash of KRBTGT, they have the KDC’s key.
Forging the Golden Ticket: With the KRBTGT hash in hand, tools like Mimikatz or Rubeus can craft a TGT. Key parameters are needed: the target domain name and domain SID, the AES/RC4 hash of KRBTGT, the victim username (often a privileged account, e.g. Administrator), and optionally the group RIDs to include. For example, Mimikatz’s *kerberos::golden * command takes flags like */domain:corp.local *, */sid:S-1-5-21-... *, */aes256:<KRBTGT-hash> *, */user:DomainAdmin *, */groups:<RID list> *, and */ptt * to “pass the ticket” into the current session. By default these tools often set the ticket’s lifetime to ten years (far beyond the typical 10 hour max) and support negative offsets so the ticket appears valid from a past time. This effectively makes the ticket persist until its expiry.
Using the Forged TGT: Once the Golden Ticket (fake TGT) is injected, the attacker’s machine is effectively logged on as the impersonated user. Now they can request service tickets (TGS) from the KDC for any SPN. Because the TGT is validated by the KDC’s secret (though forged), the KDC will issue valid TGS tickets just as if the user had logged in legitimately. The attacker then presents those tickets to target services. Importantly, the attacker does not need to crack individual service accounts or contact the KDC again, and can remain off-DC thereafter. This workflow was demonstrated in real red-team tests. For example, CISA reported that their Red Team was able to “forge a golden ticket using the krbtgt hash” after compromising AD. Another approach is to capture a real DC-issued TGT via delegation attacks (such as DFSCoerce). Figure 1 illustrates a scenario (from a CISA report) where attackers forced the DC to authenticate to a malicious server, capturing the DC’s TGT. With that TGT, similar techniques could be applied to reuse or forge tickets.
Tools: The most common tool is Mimikatz (from Benjamin Delpy). Its Kerberos module can create Golden Tickets with a command like *kerberos::golden *. Another is Rubeus (by Harmj0y), which can perform both the DCSync to get krbtgt and the ticket forging. Rubeus has commands *asktgt * and *hash * to request/forge tickets. PowerShell variants (e.g. Invoke-Kerberoast scripts) can also leverage these functions. Regardless of tool, the core steps are always: obtain krbtgt, craft TGT, inject it.

Attack Workflow for Silver Ticket

A Silver Ticket attack focuses on forging a service ticket (TGS) for a specific service without needing the KDC. Workflow:

Service Hash Theft: The attacker must obtain the target service account’s password hash. Commonly this is done through Kerberoasting (request many service tickets and crack them offline to get service NTLM hashes) or direct credential dumping of hosts that have those passwords (since many services run on Windows servers, Mimikatz on those servers can reveal the NTLM of the local service account).
Forging the Service Ticket: With the service account hash, the attacker uses tools to create a fake TGS for that specific SPN. In practice, one can use Mimikatz’s *kerberos::golden * (yes, same command name) but supply the service account’s hash as the key and include parameters for the target machine and service. For instance, to target a CIFS share on a server, the command might include */target:FileServer.domain.com /service:cifs /rc4: *. The attacker also supplies a username (often non-existent or low-priv user) and group RIDs. The tool constructs a TGS which appears valid for that service. This does not require contacting the DC at all, it is purely local ticket creation.
Using the Forged TGS: The forged service ticket is injected into the attacker’s session. Now, the attacker can connect to the target service (e.g. *\\FileServer\share *) using the Kerberos ticket. The server, upon receiving the ticket, will decrypt it with the service account’s key (which matches because we used the real hash) and see a valid session. Since the ticket is forged, it can even name a user that doesn’t exist in AD. For example, as Netwrix shows, the attacker forged a CIFS ticket for *NonExistentUser * and successfully connected to a file share.
Tools: Silver Tickets can also be created by Mimikatz and Rubeus. Mimikatz’s Kerberos module ( *kerberos::golden *) is used with the service hash instead of krbtgt, as illustrated above. Rubeus similarly has a *silver * command to forge tickets. Notably, because Silver Tickets never touch the DC, their use won’t generate DC-side event logs for KDC activity, making them stealthier. The trade-off is that if the service account’s password is changed (or the account disabled) on the server, the forged ticket will fail. Attackers often use service tickets to pivot or gather data from that specific server while maintaining anonymity (since the ticket shows a bogus user).

Tool-Based Examples

Tools make these attacks practical.

For Golden Tickets:

Mimikatz: After obtaining the KRBTGT hash, one runs:

kerberos::golden /domain:CORP.LOCAL /sid:S-1-5-21-... /aes256:<KRBTGT_Hash> /user:Administrator /groups:513,512,518,519 /ptt

This creates and injects a TGT for the Administrator, with typical group SIDs (e.g. 513=Domain Users, 512=Domain Admins). The /ptt flag passes the ticket into memory so new logons use it.

Rubeus: As an example, Rubeus can simulate the same flow with commands. One can use Rubeus.exe asktgt /aes256:<KRBTGT_Hash> /domain:CORP.LOCAL /user:Administrator to build a TGT and asktgt /ptt to inject. Rubeus also supports /rc4 if using the NTLM hash. Rubeus can also perform the first step:

Rubeus.exe hash /user:krbtgt /domain:corp.local /dc:dc01.corp.local
Rubeus.exe s4u /user:ADUser /rc4:<NTLM_of_ADUser> /ptt

(These commands illustrate S4U but Rubeus also has a tgtdeleg / golden mode for forging with krbtgt.)

For Silver Tickets:

Mimikatz:

kerberos::golden /user:NonExistentUser /domain:domain.com /sid:S-1-5-21-... /rc4:<ServiceAccountHash> /target:Fileserver.domain.com /service:cifs /ptt

This forges a CIFS service ticket for a fake user. The /groups and /ptt flags function the same.

Rubeus: It can create a silver ticket with something like:

Rubeus.exe silver /user:NonExistentUser /rc4:<ServiceHash> /service:cifs /target:Fileserver /ptt

This will inject a TGS for the CIFS service on the Fileserver using the given hash.

Other scripts or modules (PowerShell Empire, PSKerberos) also leverage these capabilities. The key takeaway is that any tool that lets you specify the key and ticket parameters can generate these forged tickets. Once created, attackers often use lateral tools ( wmiexec, psexec, Invoke-Command, or file access via SMB/DFS) to use the ticketed identities on remote systems.

Detection and Monitoring Challenges

Detecting Golden and Silver Ticket attacks is notoriously difficult. By design, a forged ticket looks like a perfectly normal Kerberos ticket to the target service. There is no failed login or obvious signature, the attacker is simply presenting a valid-looking credential. However, careful monitoring can reveal anomalies:

Unusual Ticket Attributes: For example, Golden/Silver tickets often list a username or groups that don’t match reality (such as a non-existent user or wrong primary group). The encryption type might be weak (e.g. RC4-HMAC) when AES is expected. Critically, forged tickets often have absurd lifetimes (e.g. 10 years) far beyond normal. The domain’s default max TGT lifetime is typically 10 hours, but many tools default to 10 years. Seeing a Kerberos ticket valid for years is a strong red flag.
Event Log Anomalies: Unfortunately, Golden Tickets rarely generate KDC events because the ticket is already “issued” (forged offline). However, when the attacker later uses the ticket to get a TGS, you will see normal TGS events (ID 4769) from the DC indicating the use of TGTs and issuance of service tickets. One must spot that the TGT requested had a 10-year lifetime or unusual properties. Gold or Silver ticket usage may also trigger Windows Audit logs on the target machine: since the service ticket is accepted, events like Event ID 4624 (successful logon) and 4627 (group membership) will record the SID and groups presented by the ticket. If those do not match known good values, it suggests forgery. For instance, Netwrix recommends checking 4627 and 4624 for unexpected SIDs or source IPs during such logons.
Active Directory Auditing: Some attacks, like obtaining the KRBTGT hash via DCSync, produce identifiable AD audit events. Monitoring for Event ID 4662 on the KRBTGT object (a directory services replication event) can indicate a DCSync. Limiting replication permission and watching for it is critical. Also, unusual logon sessions (Event 4624 with logon type 3 or 10) for service accounts at odd times or from odd machines could hint that forged tickets are being used.
Endpoint Detection: Since forged tickets cannot be cryptographically distinguished at the service, often the only detection is on the endpoint that created them. Endpoint security solutions or EDRs can hook calls to Kerberos libraries or monitor the use of tools like Mimikatz/Rubeus in memory, which can raise immediate alerts. For example, if an admin runs kerberos::golden, a security product might detect the abnormal API calls to the local LSA process.

Overall, defenders must correlate many signals. It’s recommended to enforce logging of all Kerberos events (both success and failure) on DCs and servers, centralize them in a SIEM, and build analytic rules for these anomalies. Some specific tips include: flag TGT requests with 10-year lifetimes, flag service logons by machine accounts or unexpected users, and monitor the krbtgt account for unauthorized access or change. Still, in practice detection is challenging – many Golden/Silver incidents are only discovered after the fact when something suspicious triggers (e.g. unauthorized domain admin actions).

Defending Against Ticket Forgery

Harden AD DCs and Accounts: Restrict who can replicate directory changes. The DCSync attack requires the AD permission to replicate directory (Replication-Get-Changes). Grant these only to trusted accounts. Use tiered administration so that users with those rights are not the same as those who can restart DCs, etc. Keep lsass memory safe with Credential Guard or similar (though sophisticated attackers can bypass it).

Regularly Reset KRBTGT: Since a compromised KRBTGT key undermines the whole domain, Microsoft’s guidance is to reset the KRBTGT account password twice in close succession, and repeat this at least every 180 days. Each reset increments the password history, and doing it twice clears the previous two values. This invalidates any existing Golden Tickets (old TGTs will no longer decrypt correctly). Resetting KRBTGT is disruptive (it must replicate to all DCs and may briefly break inter-DC authentication) so it must be done carefully, but it is the ultimate remediation for a Golden Ticket compromise.

Secure Service Accounts: For Silver Tickets, the weak point is often a service account with a poor password. Use Group Managed Service Accounts (gMSA) or privileged access management so that service account passwords are long, random, and rotated automatically. Ensure service accounts do NOT run interactive logins or multi-purpose services. Strong, unique passwords (30+ chars where possible) make Kerberoast and brute-force infeasible.

Use Strong Encryption: Disable legacy RC4 (HMAC) and DES ciphers for Kerberos if all clients and services support AES. This means an attacker needs AES keys (which correspond to NTLM hashes on modern Windows anyway) and can mitigate some NTLM-specific attacks. MITRE explicitly recommends enabling AES-based Kerberos and disabling RC4 where possible.

Kerberos Best Practices:

Enable PAC validation on critical services. Although not foolproof, some Microsoft services support verifying the PAC signature against the DC, which can block some forgeries.
Apply updates: In late 2021, Microsoft released an update that, among other things, ignored any service tickets claiming nonexistent users, making some Silver ticket lifetimes moot. Always keep DCs patched.
Monitor logs: As above, centralize Kerberos logs. Tools like Microsoft ATA/Defender for Identity can help flag unusual Kerberos behavior.
Remove stale SPNs: Clean up service principal names and decommission unused services so there are fewer keys to attack.

Hybrid/Cloud Controls: In a hybrid setup, ensure your Azure AD Connect sync account is protected and its server is locked down (treat it like a DC). Use Azure AD Privileged Identity Management (PIM) with Just-In-Time admin assignments for cloud roles so that even if on-prem creds are stolen, they don’t give persistent cloud admin access.

Incident Response: If you suspect ticket attacks, immediate steps are: change the KRBTGT password (twice, after all DCs replicate), reset service account passwords, and reset any user passwords if necessary (noting the hybrid caveat below). Also, flush all Kerberos tickets on endpoints (users can klist purge) to force re-authentication.

Hybrid Environment Risks

In hybrid AD (on-prem AD synced to Azure AD/Entra via Azure AD Connect or ADFS), Golden and Silver ticket attacks on-prem have extra impact. First, AD Connect creates privileged accounts both on-prem and in the tenant: the MSOL_* account in AD and the Sync_* account in Azure AD. These accounts usually have directory replication rights and (historically) Global Admin privileges. Attackers compromising on-prem AD can exploit AD Connect to obtain Azure credentials.

For example, Microsoft documented a real ransomware case where adversaries “used AADInternals to extract the plaintext credentials of a privileged Azure AD account” from the AD Connect machine, then used those to authenticate in Azure AD. In that incident, the Azure AD Connector account (a cloud admin account) was stolen from AD Connect server and allowed the attackers to elevate to Global Admin in Entra ID. This shows that a Golden Ticket (or DC access) can directly lead to a full cloud compromise via AD Connect abuse.

Moreover, Azure AD Connect’s Password Hash Sync (PHS) can itself be attacked. Research by Sygnia showed that by performing man-in-the-middle or code injection attacks on the AD Connect server, one can intercept and exfiltrate connector credentials and even on-prem NT hashes during the sync process. In other words, even without a domain admin, attackers on the AD Connect box can siphon Azure sync secrets or get new password hashes from AD. This “bridge” between AD and Azure is therefore a high-value target.

There are also identity flow concerns: when an on-prem password is reset, Azure AD may not immediately honor it. Tokens or tickets that were issued on-prem can remain valid in Azure for some time. Indeed, one analyst notes that “Kerberos tickets can still be used after a password change” and AD-to-Azure sync can lag, so an attacker with a stolen TGT or ticket can continue using it in a hybrid setup until expiry. This means you cannot rely on a quick password reset in Azure to kill all on-prem Kerberos sessions.

Finally, newer Azure identity attacks have analogies to Golden/Silver tickets. In pure Azure AD, you cannot forge tokens because Microsoft signs them with keys out of reach. However, attackers use token theft. For example, “silver tokens” in Azure AD (coined by researchers) refer to stolen refresh tokens that let an attacker redeem access tokens at will. Cody Burkard showed that by capturing a user’s refresh token, an attacker can continuously generate new privileged access tokens even when that user activates PIM (Just-In-Time) roles. In this way, a cloud adversary maintains a “silver token” that bypasses MFA or JIT controls.

In sum, hybrid environments have unique risks: an on-prem Kerberos compromise can pivot to Azure via AD Connect and PHS, and stolen on-prem credentials can become cloud admin credentials. Defense-in-depth is critical: isolate and protect the AD Connect server, limit replication rights, use Conditional Access (MFA) on all on-prem and cloud admin accounts, and monitor Azure sign-ins for unusual patterns. In particular, assume that if the on-prem domain is breached, the hybrid linkage may allow the breach to spread to Azure, so segment and control admin roles accordingly.

Real-World Case Studies

Golden and Silver ticket techniques have appeared in several high-profile breaches and exercises:

Sony Pictures (2014): The notorious Sony breach involved attackers (Lazarus Group) who gained domain admin and created Golden Tickets. They extensively abused Kerberos to move laterally. Sony’s incident reminded defenders to consider KRBTGT compromise.
Deloitte (2017): Attackers in the Deloitte breach reportedly forged Golden Tickets to maintain deep domain persistence. This underscores that determined APTs use these tools.
Microsoft/DIRTYCL0UD (2017): Nation-state actors developed tools (“Golden” and “Silver” pools) that may have been used to mint fake Kerberos tickets in targeted intrusions (attributed to ANELAST).
Red Team and Purple Team Engagements: In numerous security assessments, penetration testers routinely demonstrate Golden and Silver ticket hacks to show how an adversary can achieve persistent domain compromise.
Azure/MERCURY Attack (2023): Microsoft’s blog on the MERCURY/DEV-1084 destructive attack describes how adversaries stole Azure AD Admin credentials via the AD Connect server. While the initial attack steps were on-prem, the final goal was cloud sabotage. This case illustrates how on-prem Kerberos/account compromise can lead to catastrophic cloud impact.
Enterprise Penetration (e.g. AD IT environment): Many organizations discover Golden Ticket usage only when unusual access appears. For example, a financial institution’s IR team found a Golden Ticket when they noticed an Administrator TGT with a 10-year lifetime in the DC logs. They were able to tie it to a Mimikatz invocation from months prior.
Internal Testing: Large enterprises often run purple-teams where defenders seed fake tickets (with dummy KRBTGT values) to verify their logging and detection.

These real cases show that Golden/Silver tickets are not just theory: they are used by advanced attackers to evade typical defenses and secure long-term access. Learning from such incidents, recommendations include maintaining out-of-band admin accounts (not cached anywhere), monitoring unusual logins, and practicing frequent KRBTGT resets.

Comparison With Cloud-Based Token Attacks

While Golden/Silver tickets apply to Kerberos on-prem AD, cloud environments use different token protocols (OAuth/JWT tokens in Azure AD, SAML tokens in AD FS). In Azure AD, there is no direct analog to forging a “Golden Ticket” because token signing keys are held by Microsoft. Instead, cloud attackers focus on token theft or abuse.

One emerging concept is the “Silver Token” in Azure AD. Cody Burkard’s blog shows that if an attacker captures a user’s long-lived refresh token, they can repeatedly redeem it to get new access tokens, even during Just-In-Time (JIT) elevation via PIM. Effectively, the stolen refresh token becomes a “silver token”: it enables silent acquisition of high-privilege tokens without the user’s involvement. Unlike Kerberos tickets, these tokens (JWTs) can be validated cryptographically, but their theft provides legitimate credentials. Microsoft itself warns against refresh token theft (e.g., through device compromise or legacy authentication).

Other cloud token attacks involve OAuth consent or misconfiguration. For example, hijacking an App’s client secret or abusing consented scopes can give broad directory access. In AD FS (hybrid SSO), there were attacks known as “Golden SAML” where attackers forge SAML identity tokens, but Azure AD does not allow forging since keys are private. The “Silver/Golden token” terminology is mostly seen in the cloud pen-testing community to describe these analogous attacks (silver = refresh token theft; golden = exfiltration of key material, which is basically impossible in managed cloud).

In short, Kerberos ticket attacks leverage the shared secret nature of AD; Azure AD relies on asymmetric token signing, so forging is not possible. Instead, cloud attackers steal or trick the system into giving them tokens. Therefore, we recommend not only Kerberos hardening on-prem, but also applying strong cloud controls: enable Conditional Access with device/MFA requirements, monitor token issuance logs, and promptly revoke suspicious refresh tokens. Both worlds need defense: on-prem we watch events like 4769/4624; in cloud we watch Azure sign-in logs, MFA failures, and roles activation logs.

FAQs

Q: What’s the difference between a Golden Ticket and Silver Ticket? A: A Golden Ticket is a forged Kerberos TGT signed by the DC’s KRBTGT key, giving the attacker virtually unlimited domain access. A Silver Ticket is a forged service ticket for one specific service, signed with that service account’s key. Gold affects the whole domain; Silver only affects one service. Golden Ticket requires the KRBTGT hash; Silver requires the target service account’s hash.

Q: How do attackers get the KRBTGT hash? A: Typically by DCSync: using tools like Mimikatz or Rubeus, an attacker with domain privileges tells a DC “replicate krbtgt” and the DC hands over the NTLM (or AES) hash from AD. Or by dumping memory on a DC that has krbtgt in memory. In short, only admins or replication privileged users can get it.

Q: Why do forged tickets often have 10-year validity? A: Tools like Mimikatz default to ten-year lifetimes for ease of persistence. This far exceeds the normal 10-hour max in AD. The extremely long lifetime is a giveaway in logs and is for convenience; an attacker could set any expiry when forging. Defenders should alert on any TGT or TGS with multi-year validity.

Q: Can resetting KRBTGT stop Golden Tickets? A: Yes – resetting the KRBTGT account password (twice) effectively rotates the key and invalidates any tickets encrypted under the old key. It’s the recommended remediation if compromise is suspected. However, it’s disruptive and should be done carefully (allowing replication) and ideally in a maintenance window.

Q: Will Azure AD notice a Golden Ticket? A: Not directly. Azure AD uses different token technology. A forged on-prem ticket doesn’t translate to a cloud token. However, if an attacker uses a Golden Ticket to steal privileged credentials on-prem (like the AD Connect service account), they can then break into Azure AD. So the telltale sign of on-prem compromise in Azure would be a login from the AD Connect account with no MFA or unusual location.

Q: Do Golden/Silver tickets work on non-Windows Kerberos? A: Possibly in any MIT Kerberos v5 environment if an attacker can get the key of the KDC or service. But the tools and deployment are specific to AD. Most enterprises run Windows AD, so these attacks are mainly Windows-centric.

Q: How often should we change service account passwords? A: Frequently. MITRE suggests strong (25+ char) passwords and regular rotation. Some orgs tie service passwords to a vault that rotates them daily or weekly. The shorter the password lifetime, the less risk a stolen Silver Ticket remains valid.

Q: Can we detect these attacks with standard antivirus/EDR? A: Often yes, by catching the tools. For example, if someone runs mimikatz kerberos::golden, most EDRs will flag the use of Mimikatz. Also, monitoring for unusual Windows events (as above) can be done with SIEM correlation rules. But pure anomaly detection on the tickets is hard – it requires the behavioral/endpoint angle.

Q: What about Azure “Silver Tokens” in cloud? A: This refers to stolen refresh tokens. As Cody Burkard showed, if an attacker steals a user’s Azure AD refresh token, they can use it (the “silver token”) to continuously get new access tokens for that user’s elevated roles when PIM is activated. It’s conceptually similar: a long-lived credential misuse.

Conclusion and Recommendations

Golden and Silver Ticket attacks exploit fundamental features of Kerberos and AD. They allow attackers to impersonate identities and persist undetected. To protect on-prem environments, organizations must adopt defense-in-depth: strict administration practices, monitoring, and rapid remediation. Key recommendations are:

Limit Exposure: Only grant replication or “DC Sync” privileges to absolutely trusted accounts. Use Dedicated Admin Hosts and tiered administration.
Monitor Aggressively: Log all Kerberos events (AS-REQ, AS-REP, TGS issuance) and watch for anomalies (e.g. 10-year tickets or logons by unexpected users/groups). Also enable AD auditing (4662, 4624).
Secure Secrets: Use long, complex passwords for all privileged and service accounts (consider Group Managed Service Accounts). Enforce AES encryption only to avoid weaker ciphers.
Protect AD Connect: Treat the Azure AD Connect server as sensitive as a DC. Limit who can log on to it, keep it patched, and monitor for unexpected outbound connections or admin activities. Regularly rotate its credentials in Azure.
Regularly Rotate KRBTGT: Follow Microsoft’s guidance to reset the krbtgt password twice (after replication) at least semi-annually. Automate this if possible.
Prepare IR: Have a plan to respond if a Golden Ticket is suspected, include a controlled KRBTGT reset, account lockouts, and full network scan.

The stakes are high: as real cases show, once Kerberos ticket-forgery is in play, adversaries can roam freely. But with vigilant monitoring and strong identity hygiene (especially in hybrid setups), organizations can significantly raise the bar. In practice, combining on-prem and cloud monitoring (e.g. Defender for Identity on-prem, Azure AD Identity Protection in cloud) gives the best coverage. Lastly, treat every anomalous Kerberos event as potentially serious and investigate promptly.