This will cover the basics of Kerberos and the Windows ticket-granting service.

What is Kerberos?

Kerberos is the default authentication service for Microsoft Windows domains. It is intended to be more “secure” than NTLM by using third party ticket authorization as well as stronger encryption. Even though NTLM has a lot more attack vectors to choose from, Kerberos still has a handful of underlying vulnerabilities.

Common Terminology -

• Ticket Granting Ticket (TGT) - A ticket-granting ticket is an authentication ticket used to request service tickets from the TGS for specific resources from the domain.
• Key Distribution Center (KDC) - The Key Distribution Center is a service for issuing TGTs and service tickets that consist of the Authentication Service and the Ticket Granting Service.
• Authentication Service (AS) - The Authentication Service issues TGTs to be used by the TGS in the domain to request access to other machines and service tickets.
• Ticket Granting Service (TGS) - The Ticket Granting Service takes the TGT and returns a ticket to a machine on the domain.
• Service Principal Name (SPN) - A Service Principal Name is an identifier given to a service instance to associate a service instance with a domain service account. Windows requires that services have a domain service account which is why a service needs an SPN set.
• KDC Long Term Secret Key (KDC LT Key) The KDC key is based on the KRBTGT service account. It is used to encrypt the TGT and sign the PAC.
• Client Long Term Secret Key (Client LT Key)  The client key is based on the computer or service account. It is used to check the encrypted timestamp and encrypt the session key.
• Service Long Term Secret Key (Service LT Key)  The service key is based on the service account. It is used to encrypt the service portion of the service ticket and sign the PAC.
• Session Key - Issued by the KDC when a TGT is issued. The user will provide the session key to the KDC along with the TGT when requesting a service ticket.
• Privilege Attribute Certificate (PAC) - The PAC holds all of the user’s relevant information, it is sent along with the TGT to the KDC to be signed by the Target LT Key and the KDC LT Key in order to validate the user.

AS-REQ w/ Pre-Authentication In Detail

The AS-REQ step in Kerberos authentication starts when a user requests a TGT from the KDC. In order to validate the user and create a TGT for the user, the KDC must follow these exact steps. The first step is for the user to encrypt a timestamp NT hash and send it to the AS. The KDC attempts to decrypt the timestamp using the NT hash from the user, if successful the KDC will issue a TGT as well as a session key for the user.

Ticket Granting Ticket Contents

In order to understand how the service tickets get created and validated, we need to start with where the tickets come from; the TGT is provided by the user to the KDC, in return, the KDC validates the TGT and returns a service ticket.

Service Ticket Contents

To understand how Kerberos authentication works you first need to understand what these tickets contain and how they’re validated. A service ticket contains two portions: the service provided portion and the user-provided portion. I’ll break it down into what each portion contains.

• Service Portion: User Details, Session Key, Encrypts the ticket with the service account NTLM hash.
• User Portion: Validity Timestamp, Session Key, Encrypts with the TGT session key.

Kerberos Authentication Overview

KDC = AS + TGS

AS-REQ - 1.) The client requests an Authentication Ticket or Ticket Granting Ticket (TGT).

AS-REP - 2.) The Key Distribution Center verifies the client and sends back an encrypted TGT.

TGS-REQ - 3.) The client sends the encrypted TGT to the Ticket Granting Server (TGS) with the Service Principal Name (SPN) of the service the client wants to access.

TGS-REP - 4.) The Key Distribution Center (KDC) verifies the TGT of the user and that the user has access to the service, then sends a valid session key for the service to the client.

AP-REQ - 5.) The client requests the service and sends the valid session key to prove the user has access.

AP-REP - 6.) The service grants access.

Kerberos Tickets Overview

The main tickets that you will see is a ticket-granting ticket these can come in various forms such as a .kirbi for Rubeus .ccache for Impacket.

The main ticket that you will see is a .kirbi ticket.

A ticket is typically base64 encoded and can be used for various attacks. The ticket-granting ticket is only used with the KDC in order to get service tickets. Once you give the TGT the server then gets the User details, session key, and then encrypts the ticket with the service account NTLM hash. Your TGT then gives the encrypted timestamp, session key, and the encrypted TGT. The KDC will then authenticate the TGT and give back a service ticket for the requested service.

A normal TGT will only work with that given service account that is connected to it however a KRBTGT allows you to get any service ticket that you want allowing you to access anything on the domain that you want.

Attack Privilege Requirements

• Kerbrute Enumeration - No domain access required
• Pass the Ticket - Access as a user to the domain required
• Kerberoasting - Access as any user required
• AS-REP Roasting - Access as any user required
• Golden Ticket - Full domain compromise (domain admin) required
• Silver Ticket - Service hash required
• Skeleton Key - Full domain compromise (domain admin) required

Kerberoasting Mitigation

• Strong Service Passwords: If the service account passwords are strong then kerberoasting will be ineffective.
• Don’t Make Service Accounts Domain Admins: Service accounts don’t need to be domain admins, kerberoasting won’t be as effective if you don’t makeservice accounts domain admins.

AS-REP Roasting Overview

During pre-authentication, the users hash will be used to encrypt a timestamp that the domain controller will attempt to decrypt to validate that the right hash is being used and is not replaying a previous request. After validating the timestamp the KDC will then issue a TGT for the user. If pre-authentication is disabled you can request any authentication data for any user and the KDC will return an encrypted TGT that can be cracked offline because the KDC skips the step of validating that the user is really who they say that they are.

Skeleton Key Overview

A skeleton key works by abusing the AS-REQ encrypted timestamps, the timestamp is encrypted with the users NT hash. The domain controller then tries to decrypt this timestamp with the users NT hash, once a skeleton key is implanted the domain controller tries to decrypt the timestamp using both the user NT hash and the skeleton key NT hash allowing you access to the domain forest.

The skeleton key will not persist by itself because it runs in the memory, it can be scripted or persisted using other tools and techniques however that is out of scope for this room.

Pass the Ticket Overview

Pass the ticket works by dumping the TGT from the LSASS memory of the machine. The Local Security Authority Subsystem Service (LSASS) is a memory process that stores credentials on an active directory server and can store Kerberos ticket along with other credential types to act as the gatekeeper and accept or reject the credentials provided.

You can dump the Kerberos Tickets from the LSASS memory just like you can dump hashes. When you dump the tickets it will give us a .kirbi ticket which can be used to gain domain admin if a domain admin ticket is in the LSASS memory.

This attack is great for privilege escalation and lateral movement if there are unsecured domain service account tickets laying around. The attack allows you to escalate to domain admin if you dump a domain admin’s ticket and then impersonate that ticket using a PTT attack allowing you to act as that domain admin.

You can think of a pass the ticket attack like reusing an existing ticket we’re not creating or destroying any tickets here were simply reusing an existing ticket from another user on the domain and impersonating that ticket.

Pass the Ticket Mitigation

How to mitigate these types of attacks:

• Don’t let your domain admins log onto anything except the domain controller: This is something so simple however a lot of domain admins still log onto low-level computers leaving tickets around that we can use to attack and move laterally with.

KRBTGT Overview

The difference between a KRBTGT and a TGT is that a KRBTGT is the service account for the KDC this is the Key Distribution Center that issues all of the tickets to the clients. If you impersonate this account and create a golden ticket from the KRBTGT you give yourself the ability to create a service ticket for anything you want.

A TGT is a ticket to a service account issued by the KDC and can only access that service the TGT is from like the SQLService ticket.

Golden/Silver Ticket Attack Overview

A golden ticket attack works by dumping the ticket-granting ticket of any user on the domain, this would preferably be a domain admin, however for a golden ticket you would dump the KRBTGT ticket and for a silver ticket, you would dump any service or domain admin ticket.

This will provide you with the service/domain admin account’s SID or security identifier that is a unique identifier for each user account, as well as the NTLM hash. You then use these details inside of a golden ticket attack in order to create a TGT that impersonates the given service account information.

Silver Ticket

A silver ticket can sometimes be better used in engagements rather than a golden ticket because it is a little more discreet. If stealth and staying undetected matter then a silver ticket is probably a better option than a golden ticket however the approach to creating one is the exact same. The key difference between the two tickets is that a silver ticket is limited to the service that is targeted whereas a golden ticket has access to any Kerberos service.

A specific use scenario for a silver ticket would be that you want to access the domain’s SQL server however your current compromised user does not have access to that server. You can find an accessible service account to get a foothold with by kerberoasting that service, you can then dump the service hash and then impersonate their TGT in order to request a service ticket for the SQL service from the KDC allowing you access to the domain’s SQL server.

Create a Golden/Silver Ticket

1Kerberos::golden /user:Administrator /domain:controller.local /sid: /krbtgt: /id:

This is the command for creating a golden ticket to create a silver ticket simply put a service NTLM hash into the krbtgt slot, the sid of the service account into sid, and change the id to 1103.

An example of creating a golden ticket using mimikatz is in the above image.