What Is Silver ticket? Security Definition

Imagine you work in a large office building with many different rooms, each locked with a special key. Each room has its own lock and key. Now, imagine you are a security guard who has a master list of all the keys for every room. If you secretly copy the key for just the server room, you can get into that room anytime, even if the building manager changes all the other keys. In the computer world, a silver ticket is like that copied key for a single computer or service. An attacker steals the password hash, which is like the key, for a specific computer. They then use that stolen hash to create a fake ticket, which is like a forged entry pass. This pass fools the target computer into thinking the attacker is a legitimate user, giving them access to files, printers, or other services on that one machine. The attacker does not need to know your personal password. They only need that one computer's secret key. This is dangerous because it is very hard to detect, and it lets the attacker access that computer without raising any alarms. It is like a thief using a copied key to enter a single room while everyone else uses their official keys for their own rooms.

To make this even simpler, think of a concert with many different VIP areas. Each VIP area has its own bouncer and its own special wristband. If you steal the bouncer's secret list of wristband colors for one specific area, you can make a fake wristband for that area. You do not need a ticket to the main concert. You just need that one bouncer's list. In a computer network, a silver ticket is that fake wristband for one service. The attacker gets the secret password of the service itself, not your personal password. Then they can access that service's resources anytime. This is a common attack used by hackers after they have already broken into a network, because it allows them to keep accessing important resources without being noticed.

A Silver Ticket attack is a form of Kerberos ticket forgery that occurs in a Microsoft Active Directory environment. It specifically targets the service ticket, which is the Ticket Granting Service (TGS) ticket, used to authenticate to a particular service, such as a file server, web server, or SQL database. Unlike a Golden Ticket attack, which forges the Ticket Granting Ticket (TGT) by compromising the domain controller's KRBTGT account hash, a Silver Ticket attack requires the attacker to obtain the password hash of the target computer account (the service principal name, or SPN) itself. This hash is stored in the Local Security Authority (LSA) secrets of the computer or can be extracted from the domain controller if the attacker has domain admin privileges.

The attack works because the Kerberos protocol relies on a shared secret between the service and the domain controller. When a user wants to access a service, the domain controller issues a TGS ticket that is encrypted with the service's password hash. The service decrypts this ticket to verify the user's identity and permissions. If an attacker obtains this hash, they can forge a TGS ticket offline, without ever communicating with the domain controller. The forged ticket includes arbitrary user principal names (UPNs), group memberships, and authorization data. The target service, when it decrypts the forged ticket, believes the attacker is a legitimate user. This means the attacker can gain access to the service with any privilege they choose, such as domain administrator, if they set the appropriate group SIDs in the forged ticket.

From a technical standpoint, the steps involve using tools like Mimikatz or Rubeus to extract the NTLM hash of the target computer account (or the service account) from memory. The command typically uses the kerberos::golden module in Mimikatz with the /target:<service> and /service:<service type> parameters, along with the /rc4 or /aes256 hash. The forged TGS ticket is then injected into the current logon session. The attacker can then access the target service using tools like PsExec, WMI, or PowerShell remoting. This attack is stealthy because the domain controller is never contacted during the authentication process; the service itself validates the ticket. Therefore, standard domain controller logs do not show the authentication event. Logs only appear on the target service itself, and even then, they may only show a successful logon event without any indication of forgery.

A critical aspect is that the silver ticket only grants access to the specific service whose hash was compromised. It does not grant the attacker the ability to forge tickets for other services or to authenticate to the domain controller. However, it is an extremely effective persistence mechanism because the attacker can maintain access to a critical server even if the user's password is changed. The only way to fully invalidate a silver ticket is to change the password of the target computer account or service account, which then changes the hash used to encrypt the service tickets. This attack highlights the importance of protecting service account passwords and computer account hashes, as well as monitoring for unusual service ticket requests and logon events on critical servers.

The Silver Ticket attack matters because it represents a significant blind spot in standard IT security monitoring. Most organizations focus on detecting brute force logins, unusual domain controller activity, or failed authentication attempts. However, a Silver Ticket attack bypasses the domain controller entirely during the authentication process to the target service. This means that network defenders do not get any alerts from the central authentication system. The only logs generated are on the compromised server itself, and they often appear as normal, successful logon events. This makes the attack extremely difficult to detect, especially if the attacker uses a legitimate user account name in the forged ticket.

From a practical IT perspective, this attack is often used as a persistence mechanism after an initial breach. Once an attacker has administrative access to a single server, they can extract its computer account hash. They then create a silver ticket to maintain access to that server even if their original access is revoked or if the domain detects their presence. This allows them to continue exfiltrating data or launching further attacks from a position of persistent access. For example, an attacker who compromises a file server can create a silver ticket for that file server and then access it again months later, even if the domain has reset all user passwords, as long as the file server's computer account password has not been changed.

the attack highlights a fundamental security principle: the need to protect all secrets, not just high-value ones like domain administrator credentials. The password hash of a single server, while less critical than the KRBTGT hash, can still be used for significant damage. It also emphasizes the importance of changing computer account passwords regularly, using managed service accounts, and implementing privileged access management solutions. For IT professionals, understanding silver tickets is crucial for designing a defense strategy that includes monitoring for unusual Kerberos ticket sizes, TGS requests to the same service from different IP addresses, and the use of tools like Mimikatz. It also reinforces the need to limit the number of users who have administrative access to servers, as those users can extract the hash and create silver tickets.

Silver ticket questions in certification exams typically present a scenario describing a post-exploitation or lateral movement phase. A common question pattern is: 'An attacker has compromised a web server and obtained the server's local administrator password hash. Which type of attack can they perform to gain continued access to that server's file shares without further authentication?' The answer choices might include 'Pass-the-Hash', 'Pass-the-Ticket', 'Silver Ticket', and 'Golden Ticket'. The key clue is that the attacker only has the server's hash, not the domain's KRBTGT hash. The correct answer is Silver Ticket because it forges a service ticket for that specific server.

Another common question type is a scenario-based multiple choice: 'A security analyst notices that a user is accessing a critical database server even though the user's account has been disabled. The domain controller logs show no authentication requests for that user during the time of access. What attack technique is most likely being used?' The answer is a Silver Ticket attack, because the domain controller was never contacted. This tests the understanding that silver tickets bypass the domain controller. A distractor might be 'Pass-the-Hash', which still requires a valid hash and often interacts with the domain for NTLM authentication, or 'Golden Ticket', which would be forged using the KRBTGT hash and would allow broader access.

You might also see config-based questions. For example: 'A security administrator is investigating suspicious activity on a file server. The server logs show a successful logon event for an account that has been deleted from Active Directory. The logon type is 3 (network logon) and the authentication package is Kerberos. Which of the following is the most likely cause?' The answer would be a Silver Ticket, because a deleted account cannot authenticate normally, but a forged ticket can still be validated by the service. Another variation: 'Which of the following hashes would an attacker need to forge a Silver Ticket?' Options: 'The user's NTLM hash', 'The KRBTGT account hash', 'The target server's computer account hash', 'The domain administrator's hash'. The answer is 'The target server's computer account hash'.

Troubleshooting questions might ask: 'After changing a service account's password, an organization discovers that an attacker is still accessing the service. Which attack technique would remain effective after a password change?' The answer is a Silver Ticket if the attacker had previously captured and used the old hash, but actually, a silver ticket becomes invalid after the password change because the service ticket is encrypted with the new hash. However, if the attacker had the old hash, they could create a new silver ticket with the old hash? That is tricky. A better question: 'An attacker has forged a Silver Ticket for a file server. What action would invalidate that ticket and prevent further access?' The answer: 'Changing the computer account password of the file server'. Questions may also ask about detection: 'Which log source is most likely to contain evidence of a Silver Ticket attack?' The answer is 'The security log on the target service computer', because authentication happens there, not on the domain controller.

In a real-world IT environment, understanding Silver Tickets is critical for both blue team (defenders) and red team (attackers). For defenders, the most important takeaway is that protecting every computer account hash is essential. This means enforcing strict local administrator privileges. Only trusted users should have local admin rights on any machine. Use solutions like Microsoft LAPS (Local Administrator Password Solution) to manage local admin passwords, and use Group Managed Service Accounts (gMSAs) for services so that passwords are automatically rotated. Implement 'Credential Guard' on Windows 10/11 and Server 2016+ to protect LSA secrets from being dumped by tools like Mimikatz. For servers, especially critical ones like domain controllers, file servers, and SQL servers, ensure that only the absolute necessary personnel have administrative access.

For attackers, the practical use of a Silver Ticket is a powerful persistence mechanism. Once you have a foothold on a network and have compromised a single server, you can dump the computer account hash. This hash is often not changed until the computer is rebuilt. Therefore, you can maintain access to that server for months or years. The attack works particularly well against file servers because the CIFS (Common Internet File System) service is typically running and accessible. You can also target other services like HTTP (for IIS), LDAP (for domain controller queries), or HOST (for remote PowerShell). The key is to know which service type to specify in the Mimikatz command. For file access, use '/service:cifs'. For remote desktop, use '/service:termsrv'. For PowerShell remoting, use '/service:http' or '/service:wsman'.

What can go wrong? The most common mistake is using the wrong hash. You must use the computer account's NTLM hash, not the user's hash. The user's hash will not work because the service ticket is encrypted with the service's key. Another mistake is forgetting to include the domain SID. If you do not specify the correct domain SID, the ticket's PAC will be invalid and the service may deny access. Also, the ticket has a default lifetime (usually 10 hours in Windows), but you can forge tickets with a longer duration if you specify the '/endin' parameter. However, setting it too long might cause issues with Windows time skew. Finally, if the target service is running on a different port or is protected by additional layers like IPSec, the attack may fail. Always test the forged ticket by using 'klist' to verify it is in the cache, then attempt to access the service.