Link to this headingKerberos

• Only an Authentication Protocol
• Usually used in Active Directory
  • Gives the service the privileges of each user but the service needs to verify the access
• Used over UDP or TCP (default port 88)

Link to this headingTickets

Key Distribution Center or krbtgt key: which is derivated from the Windows service account krbtgt NTLM hash.
User key: which is derivated from user NTLM hash.
Service key: which is derivated from the NTLM hash of service owner, which can be an user or computer account.
Session key: which is negotiated between the user and Key Distribution Center.
Service session key: to be use between user and service.

Ticket Granting Service: Encrypted Ticket that a user can use to authenticate with a service. This key is encrypted with the service key

Ticket Granting Ticket: Ticket that is presented to the Key Distribution Center to get a Encrypted Ticket. This ticket is encrypted with the Key Distribution Center key.

Link to this headingPrivilege Attribute Certificate

• Contains the privileges of the user and it is signed with the Key Distribution Center key.
• Services can verify the Certificate by querying the Key Distribution Center but it is usually not done.
  • Usually verification is done by checking the signature and not the privileges
• A client can request a ticket without the PAC by adding the KERB-PA-PAC-REQUEST field to the ticket request

Link to this headingMessage Types

KRB_AS_REQ: Used to request the TGT to KDC.
KRB_AS_REP: Used to deliver the TGT by KDC.
KRB_TGT_REQ: Used to request the TGS to KDC, using the TGT.
KRB_TGT_REP: Used to deliver the TGS by KDC.
KRB_AP_REQ: Used to authenticate a user against a service, using the TGS.
KRB_AP_REP: (Optional) Used by service to identify itself against the user.
KRB_ERROR: Message to communicate error conditions.
KERB_VERIFY_PAC_REQUEST: message to send to KDC the signature of PAC, and verify if it is correct.

Link to this headingAuthentication

Link to this headingKRB_AS_REQ

For a user to get a ticket from the server the client sends a KRB_AS_REQ.

KRB_AS_REQ Contains:

• A encrypted timestamp with client key, to authenticate user and prevent replay attacks
  • The encrypted timestamp is only necessary if user requires preauthentication, which is common, except if DONT_REQ_PREAUTH flag is set in user account.
• Username of authenticated user
• The service SPN associated with krbtgt account
• A Nonce generated by the user

Link to this headingKRB_AS_REP

After receiving the request, the KDC verifies the user identity by decrypting the timestamp. If the message is correct, then it must respond with a KRB_AS_REP.

KRB_AS_REP Contains:

• Username
• TGT
  • Username
  • Session key
  • Expiration date of TGT
  • PAC with user privileges, signed by KDC
• Encrypted Data with user key
  • Session key
  • Expiration date of TGT
  • User nonce, to prevent replay attacks

Once finished, user already has the TGT, which can be used to request TGSs, and afterwards access to the services.

Link to this headingKRB_TGS_REQ

TGD Request to server

KRB_TGS_REQ includes:

• Data Encrypted with session key:
  • Username
  • Timestamp
• TGT
• SPN of requested service
• Nonce generated by user

Link to this headingKRB_TGS_RSP

KRB_TGS_REP includes:

• Username
• TGS, which contains:
  • Service session key
  • Username
  • Expiration date of TGS
  • PAC with user privileges, signed by KDC
• Encrypted data with session key:
  • Service session key
  • Expiration date of TGS
  • User nonce, to prevent replay attacks

Link to this headingKRB_AP_REQ

To finish, if everything went well, the user already has a valid TGS to interact with service. In order to use it, user must send to the AP a KRB_AP_REQ message.

KRB_AP_REQ includes:

• TGS
• Data Encrypted with service session key:
  • Username
  • Timestamp, to avoid replay attacks

If the User has the correct user privileges they can access the service. The AP can verify the PAC against the KDC but this is not usually done.

Link to this headingAttacks

Link to this headingPass The Key (PTK)

If an attacker gets the NTLM hash of any user, he could impersonate him against the KDC and then gain access to several services.

Getting a ticket from NTLM Hash:

Using the ticket in attacks:

Link to this headingPass The Ticket (PTT)

If an attacker is able to get the users ticket they can impersonate that user.

This can be gathered through through MitM attack since most are sent unencrypted but since most tickets are only active for 10 hours use it fast.

Location on Linux

On Windows:

Link to this headingGolden Ticket and Silver Ticket

First you need to get the NTLM hash of krbtgt account. Once this is done a ticket can be created for a custom user with maximum permissions. This is still valid if that user changes his or her password. (Ticket Granting Ticket)

Requesting a Golden Ticket:

Using the Golden ticket:

Silver Ticket is very similar but is used against a single service using a Ticket Granting Service. This means its full access but only to a specific service.

Requesting ticket for specific SPN:

Using the ticket in attacks:

Link to this headingKerberoasting

A Ticket Granting Service is encrypted with key derived from the NTLM hash of the service owners account.

Depending on the service different service owners will be attributed to different users. Checking to makes sure that those keys are not derived from a easily crackable password.

Using a valid user and password request Kerberost Hashes:

Cracking Kerberost Hashes:

Link to this headingASREPRoast

If the DONT_REQ_PREAUTH is set in a users account an attacker can make a KRB_AS_REQ to the server as that user without knowing its password. When receiving the KRB_AS_REP the information will be encrypted with the users key that is derivated from the NTML hash of the user. This can be used to crack the users password.

Test Usernames for Non-preauth:

Cracking the Hash:

Link to this headingKerberos brute-force

You can use bruteforcing to test ASREPRoast and get usernames.

kinit_brute.sh

Link to this headingMitagations

• Use strong passwords for all users
• Avoid Pre-Authentication
• Avoid executing services as other user accounts
• Set verify PAC through HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\ValidateKdcPacSignature (DWORD) = 1.
• Change passowrds regularly including the krbtgt account
• Disable Kerberos weak encryption types

Kerberos Info
Kerberos Attacks
Kerberos cheatsheet