Silver Ticket
Similar in concept to a golden ticket, a silver ticket attack involves compromising credentials and abusing the design of the Kerberos protocol. However, unlike a golden ticket — which grants an adversary unfettered access to the domain — a silver ticket only allows an attacker for forge ticket-granting service (TGS) tickets for specific services. TGS tickets are encrypted with the password hash for the service – therefore, if an adversary steals the hash for a service account they can mint TGS tickets for that service.
While its scope may be smaller, it is still a powerful tool in an adversary’s kit, enabling persistent and stealthy access to resources. Since only the service account’s password hash is required, it is also significantly easier to execute than a golden ticket. Techniques like harvesting hashes from LSASS.exe
and Kerberoasting are common ways adversaries obtain service account password hashes.
Threat Summary
Target:
Active Directory
ATT&CK® Tactic:
ATT&CK Technique:
Difficulty
Detect:
Hard
Mitigate:
Hard
Respond:
Medium
How Silver Ticket Works
Hover to see each step
Detect, Mitigate, and Respond
Difficulty: Hard
The normal process of obtaining a ticket-granting service ticket involves asking a domain controller to generate one. After the caller proves their identity, the domain controller with reply with a TGS encrypted with the service account password. But because the adversary has compromised that password, they can mint TGS tickets without communicating with the domain controller.
Thus, detecting silver tickets is only possible on the endpoint and involves examining TGS tickets for subtle signs of manipulation, such as: usernames that don’t exist; modified group memberships (added or removed); username and id mismatches; weaker-than-normal encryption types or ticket lifetimes exceeding the domain maximum (domain default lifetime is 10 hours; mimikatz default is 10 years).
The Windows event log has several audit events that are useful for detecting silver tickets:
Event | Source | Information |
---|---|---|
Audit Group Membership: Event ID 4627 | Member Computers |
|
Audit Logon: Event ID 4624 | Member Computers |
|
Difficulty: Hard
Because silver tickets abuse the intended design of the Kerberos protocol, the risk of their use cannot be entirely eliminated. However, several mitigations exist that can make it harder for an adversary to compromise service account password hashes.
- Adopt strong password hygiene practices for service accounts. Their passwords should be randomly generated, a minimum of 30 characters, and routinely changed.
- Enable PAC Validation. Though it has known limitations, there are some situations in which it may assist with the detection and prevention of silver tickets.
- Remove end-user administrative privileges on member workstations, and adopt controlled privilege elevation solutions.
- Reduce administrative access to member workstations and servers to the least required.
- Use solutions like Microsoft LAPS to create strong, random, and unique passwords for local administrator accounts, and automatically rotate them periodically.
- Apply the recommended mitigations for Kerberoasting.
- Do not allow users to possess administrative privileges across security boundaries. For example, an adversary who initially compromises a workstation should not be able to escalate privileges to move from the workstation to a server or domain controller.
Difficulty: Medium
If a silver ticket is detected, several response actions can be taken:
- Activate the incident response process and alert the incident response team.
- Quarantine any implicated computers for forensic investigation, as well as eradication and recovery activities.
- Reset the password of the compromised service account.