Silver Tickets
How the Attack Works
In Kerberos authentication, the application on the server executing in the context of the service account checks the user's permissions from the group memberships included in the service ticket. However, the user and group permissions in the service ticket are not verified by the application in a majority of environments. In this case, the application blindly trusts the integrity of the service ticket since it is encrypted with a password hash that is, in theory, only known to the service account and the domain controller.
Privileged Account Certificate (PAC) validation is an optional verification process between the SPN application and the domain controller. If this is enabled, the user authenticating to the service and its privileges are validated by the domain controller. Fortunately for this attack, service applications rarely perform PAC validation.
Example
If we authenticate against an IIS server that is executing in the context of the service account iis_service, the IIS application will determine which permissions we have on the IIS server depending on the group memberships present in the service ticket.
With the service account password or its associated NTLM hash at hand, we can force our own service ticket to access the target resource with any permissions we desire. This custom-created ticket is known as a silver ticket and if the service principal name is used on multiple servers, the silver ticket can be leveraged against all of them.
Creating a Silver Ticket
In general, these three pieces of information are required to create a silver ticket:
SPN password hash
Domain SID
Target SPN
If our user is a local Administrator on the machine where a service has an established session, we can use Mimikatz to retrieve the SPN password hash (NTLM hash of the service), which is the first piece of information we need to create a silver ticket.
SPN Password Hash
Once the NTLM hash of the service account is obtained, next we need to obtain the domain SID. You can use whoami /user to get the SID of the current user. Alternatively, you could retrieve the SID of the SPN user account from the output of Mimikatz.
Domain SID
For this attack, we are only interested in the Domain SID, so the RID of the user can be omitted (the last 4 digits of the SID)
Final piece of information needed is the target SPN. (For this example it will be a web page running on IIS on the web04 domain HTTP/web04.corp.com:80)
Once we have loaded the service ticket for the SPN into memory, and Mimikatz set appropriate group membership permissions in the forged ticket, the current user will be both the built-in local administrator and a member of several highly-privileged groups, including the Domain Admins group from the perspective of the IIS service application.
We can confirm the ticket is ready to use in memory with the klist command:
Last updated