Silver Tickets
Last updated
Last updated
A "silver ticket" is a forged service ticket, signed using the secret material (RC4/AES keys) of a computer account. This is the PSK (Pre-Shared Key) between the Domain and Workstation which is used to sign TGS (Ticket Granting Service) Kerberos tickets. We may forge a TGS for any user to any service on that machine, which is useful for short/medium-term persistence. By default, computer passwords change every 30 days, at which time you must re-obtain the new secrets to continue making silver tickets. Both silver and golden (coming up next) tickets are forged, so can be generated on your own machine and imported into your Beacon session for use.
Generally, as we discussed when speaking of , we saw that when a TGS is requested the user cannot modify the information in the ticket because it's signed with the service user's secret, which the user doesn't know - but if a user managed to compromise a service account the attacker can forge a service ticket from scratch since they can create an arbitrary PAC and encrypt it with the secret stolen. Once this TGS ticket is forged, the attacker presents it to the service. The service can decrypt it because it has been encrypted with its own password, and then it will read the contents of the PAC. As the attacker has forged it, they can embed whatever information they desire, such as being a domain administrator.
This is what a silver ticket might look like
The only problem is that the PAC needs to be signed twice: once with the key of the service account, and a second time with krbtgt's key which, of course, we don't have. However, applications usually verifies only the first signature as service accounts with the SeTcbPrivilege local privilege enabled do not verify the DC's signature which allows an attacker to:
forge a silver ticket without knowing the DC's key
continue to forge tickets even if krbtgt's hash changes, as long as the service account's remains the same
This kind of ticket is less powerful than the TGT (Golden Ticket), as it can only access that single machine. However, when creating a TGT, the attacker needs to approach the Domain Controller to have it generate a TGS ticket before they can access any machines. This creates a unique audit record, which doesn't stand out as malicious, but heuristics can be applied to identify if it is abnormal. When forging a TGS ticket, the attacker can bypass the Domain Controller and go straight to the target, minimizing the number of logs left behind.
To forge a Silver Ticket, an attacker requires the NTLM password's hash or keys for a service or machine account, the SID of the domain, a target host, a service name (its SPN), an arbitrary username, and group information. Silver tickets can be created for any existing or non-existing user account.
The ticket can be forged using Mimikatz or impacket and then get injected into memory to access a target service remotely. A Silver Ticket is a forged TGS ticket, so using one does not require communication with the Domain Controller. Any associated event logs are created on the target host. Therefore, Silver Tickets are more stealthy than Golden Tickets.
Knowing the NTLM hash or AES256 key of a service account we can craft the ticket with Rubeus, Mimikatz or Impacket
Then import the ticket into a sacrificial process
From Linux
Here are some useful ticket combinations:
Technique
Required Service Tickets
psexec
HOST & CIFS
winrm
HOST & HTTP
dcsync (DCs only)
LDAP