Silver Ticket: The Cyber Strategy to Create Fake Tokens for Specific Windows Server Service Access

To comprehend how a Silver Ticket functions, a solid understanding of the Kerberos authentication flow is required. Kerberos relies on a trusted third party, the Key Distribution Center, which in an Active Directory environment resides on the Domain Controller. The KDC manages authentication through a two-step ticket exchange process.

First, when a user logs in, they authenticate to the Authentication Service portion of the KDC. If successful, the KDC issues a Ticket Granting Ticket. The TGT acts as a master key, proving the user's identity.

Second, when the user subsequently attempts to access a specific service (for example, attempting to access a file share on a server named FILESERVER01), the user presents their TGT to the Ticket Granting Service portion of the KDC. The user requests access to the specific Service Principal Name associated with the file share (e.g., CIFS/FILESERVER01). The TGS verifies the TGT and, if valid, generates a Ticket Granting Service (TGS) ticket.

Crucially, this TGS ticket is encrypted using the password hash of the target service account. This service account could be a specific domain user account configured to run the service, or, if the service is running as the local SYSTEM, the password hash of the computer account itself (e.g., FILESERVER01$). The Domain Controller sends this encrypted TGS ticket back to the user. The user then forwards the TGS ticket directly to the target server (FILESERVER01). The target server decrypts the ticket using its own password hash. Because it successfully decrypts the ticket, the server implicitly trusts the information contained within it—including the username and the group memberships (which determine permissions)—and grants access accordingly.

The vulnerability exploited by a Silver Ticket attack resides precisely at the final step of the Kerberos flow. The target server blindly trusts the contents of the TGS ticket simply because it is encrypted with the server's correct password hash. The Domain Controller does not participate in this final interaction.

To forge a Silver Ticket, an attacker requires two pieces of critical information: the Domain Security Identifier (SID) and, most importantly, the NTLM password hash of the target service account or the computer account hosting the service. If the attacker can compromise the target server through a local vulnerability (like a missing patch or a weak local administrator password), they can extract the computer account's hash directly from the Local Security Authority Subsystem Service (LSASS) memory. Alternatively, if a specific domain user account runs the service, the attacker might extract that account's hash from the Domain Controller or through techniques like Kerberoasting.

Once the attacker possesses the service account's NTLM hash, they no longer need to communicate with the Domain Controller. Using tools like Mimikatz or Rubeus, the attacker manually constructs a fake TGS ticket. They encrypt this fake ticket using the stolen NTLM hash. Within the forged ticket, the attacker maliciously populates the Privilege Attribute Certificate. The PAC is the section of the ticket that lists the user's group memberships. The attacker inserts the SIDs of high-privileged groups, such as the Domain Admins group or the local Administrators group.

The attacker then presents this forged Silver Ticket directly to the target service. The service receives the ticket, successfully decrypts it using its own hash, and reads the forged PAC. The service concludes that the requesting user is a legitimate, highly privileged administrator and grants unrestricted access.

While both attacks involve forging Kerberos tickets, the operational differences between Silver and Golden Tickets are substantial, primarily regarding scope, requirements, and detectability.

A Golden Ticket forges a TGT. This requires the NTLM hash of the krbtgt account, which resides exclusively on the Domain Controller. Obtaining this hash requires Domain Admin privileges. Once a Golden Ticket is forged, it can be used to request TGS tickets for any service on any computer within the entire domain. It grants complete, domain-wide compromise. However, because Golden Tickets are used to interact with the Domain Controller to request subsequent TGS tickets, the KDC logs these requests. If the KDC is configured to validate the PAC (PAC validation), it may detect the forgery.

Conversely, a Silver Ticket forges a TGS ticket directly. It requires the NTLM hash of a specific service account or computer account. Obtaining this hash often only requires local administrator privileges on that specific target machine, a significantly lower hurdle than compromising a Domain Controller. The scope of a Silver Ticket is strictly limited to the specific service for which the hash was stolen. An attacker with a Silver Ticket for CIFS/FILESERVER01 cannot use it to access HTTP/WEBSERVER02.

However, the Silver Ticket's localized nature is its greatest advantage regarding stealth. Because the forged TGS ticket is presented directly to the target server, the Domain Controller is completely bypassed. The KDC logs no authentication request. Furthermore, the target server generally does not validate the forged PAC with the Domain Controller (unless explicitly configured to do so, which causes significant performance overhead). Consequently, traditional SIEM correlation rules that monitor the Domain Controller for Kerberos anomalies will remain entirely blind to a Silver Ticket attack.

The utility of a Silver Ticket is highly dependent on the specific Service Principal Name targeted by the attacker. Different SPNs grant different levels of control over the target machine.

One of the most valuable targets is the HOST SPN. Forging a Silver Ticket for the HOST service grants the attacker access to the target computer's task scheduler (allowing remote code execution), the event viewer (allowing the attacker to clear security logs), and the WMI service. This level of access essentially provides full administrative control over the machine, enabling the attacker to silently deploy malware, extract sensitive data, or pivot further into the network.

Another frequent target is the CIFS SPN, which governs access to file shares. A Silver Ticket for CIFS allows the attacker to bypass all NTFS file permissions, granting them read and write access to every file shared by that server, regardless of the explicit permissions configured by the system administrator. This is particularly devastating if the compromised server hosts sensitive financial records, intellectual property, or human resources data.

Targeting specific application SPNs, such as MSSQLSvc for Microsoft SQL Server, allows the attacker to log into the database with highest privileges (sysadmin), enabling data exfiltration or manipulation. The targeted nature of the Silver Ticket allows an adversary to surgically compromise the specific asset required to achieve their objectives without generating the widespread noise associated with a domain-wide attack.

Detecting Silver Ticket attacks is notoriously difficult because they leverage legitimate protocol functionality and bypass central logging mechanisms. Standard event logs on the Domain Controller will not reveal the forgery. Detection efforts must be focused on the endpoints and the specific services being targeted.

The most effective detection strategy involves monitoring the target servers for anomalous Kerberos TGS requests. While the Domain Controller is bypassed, the target server does log the authentication event (Event ID 4624 - An account was successfully logged on). Security analysts must scrutinize these events, specifically looking for Logon Type 3 (Network Logon) associated with the Kerberos authentication package.

The key indicator of a forged Silver Ticket lies in the discrepancies within the ticket's metadata, particularly the encryption type. Modern Active Directory environments typically utilize AES encryption (AES256_HMAC) for Kerberos tickets. However, attackers utilizing tools like Mimikatz to forge Silver Tickets often default to using the older, weaker RC4 encryption (RC4_HMAC_MD5), primarily because extracting the NTLM hash (which uses RC4) is easier than extracting the AES keys. If a SIEM alerts on a Kerberos network logon (Event ID 4624) where the Ticket Encryption Type field indicates 0x17 (RC4) in an environment that is configured to enforce AES, it is a highly suspicious indicator of a potential Silver Ticket forgery.

Furthermore, behavioral analysis is crucial. A Silver Ticket often involves an attacker impersonating a highly privileged account, such as a Domain Admin. If a service log indicates that the Administrator account is accessing a database server from a standard user's workstation at 3:00 AM, the context strongly suggests anomalous activity, regardless of whether the authentication protocol appeared valid.

Mitigating the risk of Silver Tickets requires a defense-in-depth strategy focused on protecting service account credentials and enforcing stringent configuration standards. The attack is entirely dependent on the adversary acquiring the NTLM hash of the target service. Therefore, preventing credential theft is the primary defense.

First and foremost, organizations must implement robust password policies for service accounts. If a domain user account is used to run a service (e.g., a SQL service account), its password must be exceptionally long (e.g., 25+ characters), randomly generated, and rotated regularly. This prevents attackers from extracting the hash from LSASS and successfully cracking it offline to obtain the plaintext password. Better yet, organizations should migrate to Group Managed Service Accounts wherever possible. gMSAs automatically handle password complexity and rotation, significantly reducing the risk of credential compromise.

For services running under the context of the computer account, the local administrator password must be heavily protected. Organizations should utilize Microsoft's Local Administrator Password Solution to automatically manage and randomize local administrator passwords across all domain-joined computers. LAPS ensures that if an attacker compromises one workstation, they cannot use the local administrator hash to laterally move to other machines or forge Silver Tickets using a shared password.

Finally, to directly counter the reliance on RC4 encryption commonly seen in these attacks, organizations must proactively disable RC4 for Kerberos authentication across the domain. By configuring Group Policy to explicitly support only AES128 and AES256 for Kerberos, the Domain Controller will refuse to issue tickets utilizing RC4, and target servers will refuse to accept them. While an advanced attacker can forge a Silver Ticket using AES keys if they manage to extract them, disabling RC4 significantly raises the difficulty level and forces the attacker to utilize more complex extraction techniques, increasing the likelihood of detection by modern Endpoint Detection and Response solutions.