This chapter covers Golden Ticket and Silver Ticket attacks, two of the most dangerous post-exploitation techniques in Active Directory environments. These attacks allow penetration testers to forge Kerberos tickets and gain persistent, unauthorized access to domain resources. For the PT0-002 exam, questions on Kerberos attacks appear frequently (approximately 5-10% of the exam), often in the context of post-exploitation and lateral movement. Understanding the mechanics, detection methods, and mitigation strategies is critical for both the exam and real-world penetration testing.
Jump to a section
Imagine a large office building with many departments. The building has a master key that opens every door, including executive offices, server rooms, and supply closets. This master key is held only by the building manager. Now, suppose an attacker somehow gets a copy of that master key. They can walk into any room at any time, and no one questions them because they have the master key. This is a Golden Ticket attack: the attacker forges a Kerberos Ticket Granting Ticket (TGT) that acts as the master key to the entire Active Directory domain.
Now, consider a different scenario. An attacker doesn't have the master key but manages to steal the key to a specific supply closet. With that key, they can access that supply closet and its contents, but they cannot enter the executive office or the server room. This is a Silver Ticket attack: the attacker forges a service ticket (TGS) to access a specific service, like a file server or SQL database, but cannot access other resources. The service trusts the ticket because it's signed with the service account's NTLM hash, which the attacker has compromised. The attacker doesn't need to interact with the domain controller; they just present the forged ticket directly to the service.
Overview of Kerberos in Active Directory
Kerberos is the primary authentication protocol in Active Directory domains. It uses tickets to prove identity and authorize access to resources. The key components are:
Key Distribution Center (KDC): Runs on domain controllers, issues tickets.
Authentication Service (AS): Issues Ticket Granting Tickets (TGTs).
Ticket Granting Service (TGS): Issues Service Tickets (TGS) for specific services.
Ticket Granting Ticket (TGT): A ticket that proves the user has authenticated and can request service tickets.
Service Ticket (TGS): A ticket that grants access to a specific service (e.g., CIFS, HTTP, LDAP).
Privilege Attribute Certificate (PAC): Contains user authorization data (SID, groups) and is embedded in tickets.
What is a Golden Ticket Attack?
A Golden Ticket attack is a post-exploitation technique where an attacker forges a Kerberos TGT. This allows the attacker to impersonate any user (including domain administrators) in the domain. The attacker can then request service tickets for any resource, effectively gaining domain admin privileges. The key requirement is the KRBTGT account's NTLM hash, which is used to sign and encrypt TGTs. Once obtained, the attacker can create a TGT with arbitrary user identity and group memberships.
How a Golden Ticket Attack Works
Obtain KRBTGT Hash: The attacker must first compromise a domain controller or obtain the KRBTGT hash through other means (e.g., DCSync attack using Mimikatz). The KRBTGT account is a built-in domain account used by the KDC to encrypt/sign TGTs.
Forge the TGT: Using a tool like Mimikatz, the attacker creates a TGT with:
- User principal name (UPN) of a privileged account (e.g., domain admin).
- Domain SID.
- User RID (relative identifier) and group SIDs (e.g., Domain Admins group SID).
- KRBTGT hash to sign the ticket.
- Validity period (default 10 years in Mimikatz if not specified).
3. Inject the TGT: The forged TGT is injected into the current logon session using Mimikatz's kerberos::ptt command.
4. Request Service Tickets: The attacker can now request service tickets for any service using the forged TGT. The TGS on the DC will issue service tickets because the TGT is valid (signed with KRBTGT).
5. Access Resources: The attacker presents service tickets to services, which trust them because they are signed by the service account's password hash or the machine account's password.
Key Details for Golden Tickets
KRBTGT Hash: The only secret needed. It is the NTLM hash of the KRBTGT account. Mimikatz extracts it with lsadump::dcsync /user:krbtgt.
Domain SID: Obtained via whoami /user or from the KRBTGT account.
User RID: Typically 500 for Administrator, but can be any.
Group SIDs: Must include the Domain Admins SID (S-1-5-21-<domain>-512) for full privileges.
Ticket Lifetime: By default, TGTs have a maximum lifetime of 10 hours (configurable via domain policy). Forged tickets can have arbitrary lifetimes, but Mimikatz defaults to 10 years.
Detection: Golden tickets are difficult to detect because the TGT is valid and signed with the legitimate KRBTGT hash. However, anomalous TGT lifetimes (e.g., >10 hours) can be flagged. Event ID 4768 (TGT request) will not be generated because the forged ticket is not requested from the DC.
What is a Silver Ticket Attack?
A Silver Ticket attack forges a service ticket (TGS) to access a specific service without needing to interact with the domain controller. The attacker compromises the NTLM hash of the service account (or the machine account if the service runs as SYSTEM) and creates a forged service ticket. The service will accept the ticket because it is encrypted with the service account's password hash. The attacker does not need a valid TGT; they can present the forged service ticket directly to the service.
How a Silver Ticket Attack Works
Obtain Service Account Hash: The attacker extracts the NTLM hash of the service account (e.g., SQL Server service account) or the computer account (if the service runs as SYSTEM) from a compromised host using Mimikatz or other tools.
Forge the Service Ticket: Using Mimikatz, the attacker creates a service ticket with:
- Target service SPN (e.g., MSSQLSvc/sqlserver.contoso.com:1433).
- User identity (any user, including domain admins).
- Domain SID and user RID/group SIDs.
- Service account NTLM hash to encrypt the ticket.
3. Inject the Service Ticket: The forged ticket is injected into the session using kerberos::ptt.
4. Access the Service: The attacker presents the ticket to the target service. The service decrypts the ticket using its own password hash, verifies the PAC (if checked), and grants access.
Key Details for Silver Tickets
Service Account Hash: The NTLM hash of the account under which the service runs. For services running as SYSTEM, it's the computer account hash.
SPN: The Service Principal Name of the target service (e.g., CIFS/fileserver, HTTP/web, HOST/computer).
No KDC Interaction: The attacker never contacts the domain controller, avoiding event logs on the DC (e.g., 4768, 4769).
PAC Validation: Some services (e.g., domain controllers) enforce PAC validation. If the PAC is invalid or not signed correctly, access may be denied. However, many services (e.g., file servers) do not validate the PAC.
Lifetime: Silver tickets can have arbitrary lifetimes, but services may enforce maximum ticket lifetimes (default 10 hours).
Comparison: Golden vs. Silver
| Feature | Golden Ticket | Silver Ticket | |---------|---------------|---------------| | Secret Needed | KRBTGT hash | Service account hash | | Scope | Entire domain | Single service | | KDC Interaction | No (forged TGT used to request TGS) | No (directly to service) | | Detection | Hard (no DC event for TGT) | Hard (no DC event for TGS) | | Privilege | Domain admin | Varies (depends on service) | | PAC Validation | Validated by KDC (but TGT is signed) | Validated by service (often not) |
Tools for Golden/Silver Ticket Attacks
Mimikatz: The most common tool. Commands:
- Golden: kerberos::golden /user:Administrator /domain:contoso.com /sid:S-1-5-21-... /krbtgt:<hash> /ptt
- Silver: kerberos::golden /user:Administrator /domain:contoso.com /sid:S-1-5-21-... /target:fileserver.contoso.com /service:CIFS /rc4:<hash> /ptt
- Impacket: Python scripts like ticketer.py for forging tickets.
- Rubeus: .NET tool for Kerberos attacks, including ticket forging.
Mitigation and Detection
Protect KRBTGT Hash: Limit access to domain controllers. Use privileged access workstations (PAWs). Regularly change the KRBTGT password (twice to invalidate existing tickets).
Monitor for Anomalous TGTs: Look for TGTs with lifetimes >10 hours (Event ID 4768 with unusual lifetime).
Enable PAC Validation: Ensure services validate the PAC (e.g., by enabling ValidateKdcSignature on domain controllers).
Use Managed Service Accounts (gMSA): Reduces the need for service account passwords.
Audit Service Account Usage: Monitor for unusual service ticket requests (Event ID 4769).
Implement Credential Guard: Protects against hash extraction.
Network Segmentation: Limit lateral movement opportunities.
Exam Relevance
For PT0-002, be prepared to:
Identify the difference between Golden and Silver tickets.
Know the required hashes (KRBTGT vs. service account).
Understand that Golden tickets provide domain-wide access, while Silver tickets are service-specific.
Recognize that Silver tickets do not require communication with the DC.
Know that Mimikatz is the primary tool for both attacks.
Understand that changing the KRBTGT password twice invalidates existing Golden tickets.
Extract KRBTGT Hash
The attacker must first gain administrative access to a domain controller or execute Mimikatz with sufficient privileges on a compromised domain-joined machine. Using Mimikatz's `lsadump::dcsync` module, the attacker requests the KRBTGT account's NTLM hash from a domain controller via the Directory Replication Service (DRS) protocol. The command `lsadump::dcsync /user:krbtgt` retrieves the hash without requiring code execution on the DC itself. This step is critical because the KRBTGT hash is the master key for signing all TGTs in the domain. Without it, forging a valid TGT is impossible.
Forge the Golden Ticket
Using the extracted KRBTGT hash, the attacker runs Mimikatz's `kerberos::golden` command. They specify the target user (e.g., Administrator), domain name, domain SID (obtained via `whoami /user` or from the KRBTGT dump), and the KRBTGT hash. The `/ptt` flag injects the forged ticket into the current logon session. Mimikatz constructs a TGT with the specified user's identity and group memberships (including Domain Admins). The TGT is encrypted with the KRBTGT hash, making it indistinguishable from a legitimate TGT issued by the KDC. The default ticket lifetime is 10 years, but this can be overridden.
Request Service Tickets
With the forged TGT injected, the attacker can now request service tickets for any resource in the domain. When the attacker attempts to access a file share (e.g., \\fileserver\share), the Kerberos client on the attacker's machine sends a TGS request to the domain controller using the forged TGT. The KDC decrypts the TGT with the KRBTGT hash, extracts the user's identity and group memberships, and issues a service ticket (TGS) encrypted with the target service account's hash. Because the TGT is valid, the KDC trusts it and generates the service ticket. The attacker then presents this service ticket to the file server, which grants access.
Access Domain Resources
The attacker now has the same privileges as the impersonated user (e.g., Domain Administrator). They can access any domain resource, including file servers, databases, domain controllers, and applications. The attacker can also create new accounts, modify group memberships, or deploy malware. Because the attacker holds a valid TGT, they can continue to request new service tickets as needed without re-authenticating. The attack is persistent until the KRBTGT password is changed or the forged ticket expires (which could be years).
Forge a Silver Ticket
Alternatively, the attacker may forge a Silver ticket for a specific service. First, they obtain the NTLM hash of the service account (e.g., the SQL Server service account) from a compromised host using Mimikatz's `sekurlsa::logonpasswords` or from the registry. Then, they run Mimikatz's `kerberos::golden` command with the `/target` and `/service` parameters to specify the service SPN and the service account hash. The forged service ticket is injected with `/ptt`. The attacker can now access that specific service (e.g., SQL Server) directly, without ever contacting a domain controller. This avoids generating event logs on the DC, making detection even harder.
Enterprise Scenario 1: Financial Institution Post-Compromise Lateral Movement
A penetration tester gains initial access to a workstation in a financial institution's Active Directory environment. After escalating privileges to local admin, the tester uses Mimikatz to extract the KRBTGT hash via DCSync from a domain controller that is not properly hardened. With the KRBTGT hash, the tester forges a Golden Ticket for the domain administrator account. This allows the tester to access the core banking database server, the file share containing sensitive customer data, and the domain controller itself. The tester can then exfiltrate data and maintain persistence. The organization had not implemented privileged access workstations (PAWs) or monitored for DCSync activity. The Golden ticket remained valid until the KRBTGT password was changed (which had not been done in years). Detection was only possible after the tester's activity triggered an alert on the database server (unusual admin logon from a non-DC), but the Golden ticket itself left no trace on the DC.
Enterprise Scenario 2: Healthcare Provider Silver Ticket Attack
During an internal penetration test of a healthcare provider, the tester compromises a web server running under a dedicated service account. The tester extracts the NTLM hash of the web service account. The web server is configured to use Kerberos authentication for a backend SQL database. The tester forges a Silver ticket for the SQL Server service (SPN: MSSQLSvc/db.healthcare.local:1433) using the web service account's hash. The forged ticket grants the tester access to the SQL database as a domain admin (the tester sets the user to Administrator in the forged ticket). The tester then queries patient records directly from the SQL database. The database server does not validate the PAC, so the forged ticket is accepted. The domain controller never sees any Kerberos request, so no logs are generated on the DC. The attack is discovered only when the database administrator notices unusual queries from the web server's IP address during normal business hours.
Common Pitfalls and Misconfigurations
Not changing KRBTGT password regularly: Many organizations never change the KRBTGT password, leaving Golden tickets valid indefinitely.
Service accounts with weak passwords: Silver tickets are easier to forge if service accounts have weak or reused passwords.
Disabled PAC validation: Some services, especially legacy ones, do not validate the PAC, making Silver tickets trivial.
Overly permissive service accounts: Service accounts often have more privileges than necessary, increasing the blast radius of a Silver ticket attack.
Lack of monitoring for DCSync: DCSync (DRS replication) is a high-privilege operation that should be monitored. Event ID 4662 (Directory Service Access) can indicate DCSync attempts.
What PT0-002 Tests on This Topic
The PT0-002 exam covers Golden and Silver ticket attacks under Objective 3.4 (Exploit weaknesses in Kerberos). Candidates must understand:
The difference between Golden and Silver tickets (scope, required hash, interaction with KDC).
The tools used (primarily Mimikatz, but also Impacket and Rubeus).
The commands and parameters for forging tickets (e.g., /krbtgt, /rc4, /service, /target).
Detection and mitigation strategies (e.g., changing KRBTGT password, enabling PAC validation).
Common Wrong Answers and Why Candidates Choose Them
1. "Silver tickets require the KRBTGT hash." - *Why wrong*: Silver tickets use the service account hash, not KRBTGT. Candidates confuse the two because both involve ticket forging. 2. "Golden tickets only work for the user whose hash was used." - *Why wrong*: Golden tickets can impersonate any user because the attacker specifies the user identity when forging the TGT. The KRBTGT hash is used to sign, not to identify. 3. "Silver tickets must contact the domain controller." - *Why wrong*: Silver tickets are presented directly to the service without KDC interaction. This is a key distinction. 4. "Both attacks require domain admin privileges." - *Why wrong*: While obtaining the KRBTGT hash often requires DA, the service account hash can be obtained from a non-DA compromised host. Silver tickets can be forged with lower privileges.
Specific Numbers and Terms to Memorize
KRBTGT: The account whose hash is used for Golden tickets.
NTLM hash: The hash type used to sign/encrypt tickets in both attacks.
Default TGT lifetime: 10 hours (configurable). Forged tickets default to 10 years in Mimikatz.
Mimikatz commands: kerberos::golden for forging; kerberos::ptt for injection.
DCSync: Method to extract KRBTGT hash (Event ID 4662).
PAC: Privilege Attribute Certificate; can be validated or not.
Edge Cases and Exceptions
PAC validation: On domain controllers, PAC validation is enforced. Silver tickets against a DC will fail unless the PAC is correctly signed (requires the KRBTGT hash, making it a Golden ticket).
Service running as SYSTEM: The hash is the computer account hash, which can be obtained from the local machine.
Managed Service Accounts: Hashes are rotated automatically, making silver tickets less persistent.
Cross-domain: Golden tickets are domain-specific; to access another domain, you need the other domain's KRBTGT hash.
How to Eliminate Wrong Answers
If a question mentions "domain-wide access," it's a Golden ticket.
If it mentions "no communication with DC," it's a Silver ticket.
If it asks for the required hash, KRBTGT for Golden, service account for Silver.
If it asks about detection, Golden tickets can be detected by anomalous TGT lifetimes; Silver tickets are harder to detect because they don't touch the DC.
Golden Ticket: Forge a TGT using KRBTGT hash; gain domain admin privileges.
Silver Ticket: Forge a service ticket using service account hash; gain access to a specific service.
Mimikatz command for both: `kerberos::golden` (yes, both use the same command).
Golden tickets require KRBTGT hash; Silver tickets require service account hash.
Silver tickets do not contact the domain controller; Golden tickets do (to get service tickets).
Changing KRBTGT password twice invalidates existing Golden tickets.
PAC validation on domain controllers prevents Silver tickets against them.
Default TGT lifetime in domain is 10 hours; Mimikatz defaults to 10 years.
DCSync (Event ID 4662) is used to extract KRBTGT hash.
Silver tickets are harder to detect because they generate no DC events.
These come up on the exam all the time. Here's how to tell them apart.
Golden Ticket
Requires KRBTGT account NTLM hash
Provides domain-wide access (any service)
Forges a TGT (Ticket Granting Ticket)
Must request service tickets from KDC (but TGT is forged)
Detection: Event ID 4768 (TGT request) not generated; anomalous TGT lifetime
Silver Ticket
Requires service account NTLM hash
Provides access to a single service
Forges a TGS (Service Ticket)
No KDC interaction; ticket presented directly to service
Detection: No event on DC; only on target service (if audited)
Mistake
Golden tickets require the NTLM hash of a domain admin account.
Correct
Golden tickets require the NTLM hash of the KRBTGT account, not any user account. The KRBTGT is a built-in domain account used by the KDC. With this hash, you can forge a TGT for any user, including domain admins.
Mistake
Silver tickets provide the same level of access as Golden tickets.
Correct
Silver tickets only grant access to a specific service (e.g., CIFS on a file server). They do not grant domain-wide access. Golden tickets provide access to all services in the domain.
Mistake
Both Golden and Silver tickets require the attacker to interact with the domain controller.
Correct
Golden tickets require the attacker to request service tickets from the KDC (but the forged TGT is never issued by the KDC). Silver tickets are presented directly to the target service without any KDC interaction. The attacker never contacts the DC for a Silver ticket.
Mistake
Changing the KRBTGT password immediately invalidates all existing Golden tickets.
Correct
Changing the KRBTGT password once does not invalidate existing Golden tickets because the old key is still trusted for decryption. The KRBTGT password must be changed twice in quick succession to invalidate all tickets (due to key version numbers).
Mistake
Silver tickets cannot be used against domain controllers.
Correct
Silver tickets can be used against domain controllers, but they will likely fail because domain controllers enforce PAC validation. The PAC in a forged Silver ticket must be signed with the KRBTGT hash, which the attacker does not have. Therefore, Silver tickets against a DC are ineffective unless the PAC is not validated.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The main difference is scope and required secret. A Golden ticket forges a TGT using the KRBTGT hash, granting domain-wide access to any service. A Silver ticket forges a service ticket using the target service account's hash, granting access only to that specific service. Golden tickets require interaction with the KDC to request service tickets, while Silver tickets are presented directly to the service without contacting the DC.
The KRBTGT hash can be extracted using Mimikatz's `lsadump::dcsync` command, which requests the hash from a domain controller via the DRS protocol. This requires administrative privileges on the domain or a compromised account with replication rights. Alternatively, if you have code execution on a domain controller, you can use `lsadump::lsa /patch` or `lsadump::lsa /inject`.
Technically yes, but it will likely fail because domain controllers enforce PAC validation. The PAC in a service ticket must be signed with the KRBTGT hash, which the attacker does not have when forging a Silver ticket. Therefore, the domain controller will reject the ticket. However, if PAC validation is disabled (uncommon on DCs), it could work.
Detection is difficult because the forged TGT is never requested from the KDC, so no Event ID 4768 is generated. However, you can look for TGTs with anomalous lifetimes (e.g., >10 hours) in Kerberos logs on the DC (Event ID 4768 with unusual lifetime). Also, monitor for DCSync activity (Event ID 4662) which indicates hash extraction. Finally, look for unusual logon patterns (e.g., a user logging in from multiple workstations simultaneously).
The best mitigation is to protect the KRBTGT hash by limiting access to domain controllers and using privileged access workstations. Regularly change the KRBTGT password (twice) to invalidate existing Golden tickets. For Silver tickets, use managed service accounts (gMSA) with automatic password rotation, and enable PAC validation on services. Also, implement monitoring for DCSync and anomalous Kerberos tickets.
Mimikatz is the most common tool. It can extract hashes, forge tickets, and inject them into memory. The commands are `kerberos::golden` for forging and `kerberos::ptt` for injection. Other tools include Impacket's `ticketer.py` and Rubeus.
No. The service account can be any account, including a local service account or a domain user. The forged ticket will grant access to the service, but the privileges within that service depend on the service account's permissions. For example, if the service account is a domain user with limited access, the forged ticket will only grant that level of access.
You've just covered Golden Ticket and Silver Ticket Attacks — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?