Interaction between the client and the Service

Keyword understanding

KDC (Key Distributed Centre): Key distribution center, consisting of the following two parts

AS (Authentication Server): Authentication server, issues TGT after authentication
TGS (Ticket Granting Server): Ticket granting server, issues ST through your TGT

TGT (Ticket Granting Ticket): Granting ticket

ST (Service Ticket): Service ticket

Client: The customer who accesses specific resources

Server: The father who owns specific resources

Specific account

krbtgt is the account of KDC, the password is randomly generated and cannot be logged in

The following statements can be used to query

net user krbtgt

net user username

1661995611_63100a5b8ef0055da247d.png!small?1661995611791

Kerberos authentication process

KDC stores all user accounts and passwords

Interaction between Client and AS

Two-way authentication, AS confirms that the client is not a forged client, and the client confirms that AS is not a forged AS

The client sends its personal information to AS, and AS verifies whether the customer ID is in its KDC database

AS checks that the old iron is fine and then randomly generates a TGS-SessionKey

AS sends two treasures to the client again:

After encrypting the TGS-SessionKey with the client's NTLM HASH, it is sent to the client
AS encrypts and packages the customer's personal information (customer ID, service ID to be accessed, IP address, timestamp, life time, and TGS-SessionKey) with the TGS (krbtgt) key into a TGT and sends it to the customer

1661995620_63100a64f000b69d4e081.png!small?1661995621227

After the client receives the encrypted TGS-Sessionkey, it decrypts it using its own NTLM HASH to obtain the TGS-SessionKey. Since there is no TGS key, the TGT cannot be decrypted

Interaction between Client and TGS

In the second communication, the client sends the TGT intact from the first communication to TGS, along with the Authenticator encrypted with the TGS-SessionKey (including customer ID and timestamp)

TGS decrypts the TGT with its own key, obtains the TGS-SessionKey decrypted from the TGT, and then uses the TGS-SessionKey to decrypt the encrypted Authenticator to obtain the customer ID. Then, it compares whether the customer ID in the Authenticator is equal to the customer ID in the TGT, compares the timestamp from the Authenticator with the timestamp from the TGT (the typical tolerance for differences in the Kerberos system is 2 minutes, but it can also be configured otherwise), checks whether the TGT has expired (through the survival time in the TGT), and checks whether the Authenticator has already been cached in TGS (if not checking the TGS cache, then if there is an Authenticator in the TGS cache, it will cause the Authenticator in the TGS cache to be refreshed, thus tampering with the customer ID and timestamp, leading to a replay attack). After all checks are done, TGS randomly generates a key (including customer ID and timestamp) for encrypting subsequent communication data between the client and the service, which is the Service-SessionKey. This Service-SessionKey is then encrypted with the TGS-SessionKey, and the customer ID, service ID, IP address, timestamp, survival time, and TGS-SessionKey are encrypted and packaged into ST (service ticket) with the service's key, and then both are sent to the client

1661995627_63100a6b0f3d4cd12a3b2.png!small?1661995627420

The client receives the ST, but it cannot be decrypted because only the service has the decryption key. The client has the TGS-SessionKey, so it can decrypt the Service-SessionKey

Interaction between the client and the Service

The client sends the ST and the Authenticator containing personal information encrypted with Service-SessionKey (including customer ID and timestamp) to the Service. Then, the Service uses its own key to decrypt the ST, and then uses the Service-SessionKey in the ST to decrypt the encrypted Authenticator to obtain the customer ID. Then, it compares whether the two IDs are equal, compares the timestamp from the Authenticator with the timestamp from the ST (the typical tolerance for differences in the Kerberos system is 2 minutes, but it can also be configured otherwise), checks whether the ST has expired (judged by the survival time field in the ST), and checks whether the Authenticator has already been cached on the server of the corresponding service (to avoid replay attacks, as mentioned before).

1661995637_63100a758b17ee13be3db.png!small?1661995637790

Up to this point, all the authentication processes have been passed, and the client can complete the identity authentication with the remote service and can proceed with the subsequent information communication.

PAC

PAC (Privilege Attribute Certificate, privilege attribute certificate) is used to distinguish customers with different permissions.

PAC contains two digital signatures PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM, as well as the customer's sid and the group the customer is in. The first PAC_SERVER_CHECKSUM is encrypted by the service's NTLM HASH, and the second PAC_PRIVSVR_CHECKSUM is encrypted by the KDC (krbtgt) NTLM HASH.

In the first step, PAC is placed in TGT and returned to the customer, then in the second step, the customer sends their own TGT to TGS, TGS verifies whether the PAC (which is actually the verification of two digital signatures) has been tampered with, and then reconstructs a new PAC and places it in ST to return to the customer. In the third step, the customer's ST is sent to the service for verification. After the service decrypts ST with its own key, it uses the Service-SessionKey in ST to decrypt the encrypted Authenticator to obtain the customer's ID, then compares the two IDs to see if they are equal. It compares the timestamp from the Authenticator with the timestamp in ST (the typical tolerance for differences in the Kerberos system is 2 minutes, but it can also be configured otherwise), checks whether the ST has expired (judged according to the lifetime field in ST), checks whether the Authenticator has already been cached in the corresponding service server (to avoid replay attacks, as mentioned before), and after the checks are completed, the service needs to pass the customer's information to KDC to determine whether the customer has legitimate permissions. KDC determines the customer's user group information and user permissions based on the customer's information, and then returns the result to the service. The service uses the result (customer's user group information, user permissions, etc.) and compares it with the ACL (Access Control List, permission control list) of the resources requested by the customer to determine whether the customer has the permission to access the resource.

Gold Tickets and Silver Tickets

Gold Tickets

The principle of gold tickets is to use the NTLM HASH of krbtgt (that is, the password (key) of krbtgt) to forge the content of TGT. Modify the ClientID parameter and TGS-SessionKey inside. Make TGS think I am the person I claim to be, of course, I usually claim to be administrator 1661995643_63100a7bd9ce7442d29c5.png!small?1661995644168

The premise is: having the NTLM HASH or plaintext password of krbtgt

Silver Tickets

The principle of silver tickets is to forge ST (Service Ticket, service ticket). The core point of forging ST is to be able to obtain the NTLM HASH of the target service's server (that is, the password (key) of the corresponding resource server)

The premise is: having the NTLM HASH or plaintext password of the target service's server

SPN Attack

SPN (Service Principal Name) is the server principal name. SPN is the unique identifier for a service on the network using Kerberos authentication (put simply, it is the id of the service, used to identify who it is). It consists of service class, hostname, and port.

SPN (Service Principal Name) is divided into two types:

One type is the machine account (Computers) registered in the Active Directory. When a service's permission is Local System or Network Service, the SPN registration is under the machine account (Computers).

Each machine in the domain will register two SPNs: HOST/username and HOST/username.domain

For example: 1661995648_63100a80e002f0fcfc985.png!small?1661995649156

Another is the domain user account (Users) registered in the Active Directory, when the permission of a service is a domain user, the SPN is registered under the domain user account (Users).

SPN format:

<service class>: String to identify the service class
<host>: Host name where the service is located
<port>: Service port (if there is an instance with a default port, it can be omitted)
<service name>: Service name (can be omitted)

For example: MySQL/DC.china.com/MySQL

SPN attack is to find the server where the 'owner' is krbtgt (usually that server is the domain controller). In this way, it can request the TGT encrypted with the NTLM HASH of krbtgt. The encrypted content of this TGT includes customer ID, service ID to be accessed, customer IP address, timestamp, lifetime, and TGS-SessionKey. At this time, brute force technology can be used to crack this TGT. The cracked result contains the relevant information of the customer, which can be regarded as a successful crack. Then get the krbtgt password, and can obtain the entire domain environment with the golden ticket.