Kerberos
Kerberos is the default authentication service for Microsoft WIndows Domains. This service typically runs on port 88, and it is key for us to understand how it works before attacking AD.
Terms
There are quite a few different services and tickets that make Kerberos work.
Ticket Granting Ticket (TGT)
Authentication ticket used to request service tickets from the TGs for specific resources from the domain.
Key Distribution Center (KDC)
Service for issuing TGTs and service tickets that consist of the AS and TGS.
Authentication Service (AS)
Issues TGTs to be used by the TGS in the domain to request access to other resources.
Ticket Granting Service (TGS)
Takes the TGT and returns a ticket to a machine on the domain.
Service Principal Name (SPN)
Identifier given to a service account to associate a service instance with a domain service account.
Windows requires that services have a domain service account.
KDC Long Term Secret Key
Encrypts TT and sign PAC
Client Long Term Secret Key
Client key is based on the cline's computer or account.
Used to check the encrypted timestamp and encrypt the session key.
Service Key
The service key is based on the service account.
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, where the user will provide the session key to the KDC along with the TGT when requesting a service ticket.
Privilege Attribute Certificate
Holds all user's relevant information, sent along with the TGT to the KDC and to be signed by the Target and KDC LT Key to validate the user.
Process
At the start of the process, we would have this:
Generally, there are 2 important portions for the Service Tickets as shown above.
The service portion is encrypted with the NTLM Hash of the user.
The User portion is encrypted with the TGT Session Key.
The signing of the key with the Service LT Key and KDC LT Key basically acts like what a signature is in real life, which verifies the ticket is from authorised sources.
AS-REQ
The Client requests a TGT
AS-REP
KDC sends back an encrypted TGT using the Session key
The client would then decrypt on their end, and be able to gain the TGT, which can be used to request the service ticket. The name is hence Ticket Granting Ticket.
TGS-REQ
Client sends this encrypted TGT to the TGS with the SPN of the service that the client wants to access.
This basically tells the TGS something like "Hi, I'm <support account name>, and I want to access the MySQL Database".
TGS-REP
KDC would verify the TGT of the user and that this user has access to the service by checking the privileges of this.
Once verified, it sends back a valid session key and service ticket for the service
AP-REQ
Client takes this session key and ticket and goes to the resource and requests what is wanted.
AP-REP
If all is well, resource server grants access to the client.
Long story short, there are 2 steps in this process, one to check whether the client can decrypt the TGT, and another to check if the client can even retrieve a service ticket for the resource. Hence, this is why it's a 2-way ticket-based mechanism.
The tickets can come in 2 forms, a .kirbi or a .ccache. Mainly .kirbi is used, and it is basically a base64-encoded block of text that can only be decrypted using the client's password. This is because of the fact that it's protected by something we call asymmetric encryption, which basically means there are 2 keys involved.
