Introduction to Kerberos

Understanding Kerberos is an essential know how for an attacker or pentester targeting an AD environment. To understand this we would need some basic understanding of AD environment. So , let us dive into the basic know how of Kerberos.

Kerberos is a network authentication protocol that is used in Active Directory. Kerberos is derived from ‘Cerberus’ — 3 headed dog that guarded the gates to Hades (hell) in Greek mythology. It is the gold standard in network security and sharing secrets over untrusted networks

The 3 heads of Kerberos are:

• Client
• Server
• Authentication Server

These 3 terms are known by different terminologies within the AD context. Within the AD context, Kerberos has several components.

• KDC (Key Distribution Center) or the trusted authority. In AD, this is installed as part of Domain Controller.
• Application /Service: A server providing a service, could be SQL, file server or Web server
• TGT Ticket Granting Ticket or Golden Ticket: Ticket needed for requesting TGS ticket from KDC.
• TGS ticket or silver ticket: Ticket needed for authentication against a particular service.
• Encryption key: This is generated from the password of the target service. This is what is used to encrypt the sealed ticket.
• Session key: Ephemeral and generated for a time instance and communication between a client and a service.
• SPN: SPN is a identifier for each service instance.

Scenario : In the AD environment , an user Alice needs access to a file-printing service.

Kerberos exchange

Step-1: Alice logs into her system:

Even before prompting Alice for a password, a message is sent to the authentication server. The Request is called KRB_AS_REQ and the message contains some details like

• Login name
• Name of the service (authentication service) , here the service will be TGS service. This Request is called KRB_AS_REQ
• Like every other service, TGS service has a password. This password is used to generate the encryption key
• The Authentication server looks up Alice’s login name and service name. Authentication server has access to Alice’s credentials. The Authentication server also generates a random session key for communicating with Alice.
• The “ticket” , also known as TGT , with which it responds to Alice has roughly the following structure — the response is called KRB_AS_REP

Rough structure of the KRB_AS_REP

At this point , Alice enters her password. She is able to decrypt and obtain the Session key. She has no access to the sealed ticket as that is encrypted with TGS password. Alice saves the session key. Alice needs to contact the File server, and now she needs a ticket from TGS. Encrypted with Alice’s password is a loose term, a more accurate description would be an encryption key derived from Alice’s password.

Step-2: Alice needs to request the TGS ticket:

Alice needs access to the File server. For any such request to an application service be honored, Alice needs a TGS ticket. This is a service like File Server, except, Alice needs this as a preliminary requirement, so she authenticates for a TGS ticket. Alice uses the sealed ticket she received above. This is accompanied with an authenticator, the authenticator is encrypted with the session key she saved in the previous step. KRB_TGS_REQ .

Authenticator

Step-3: TGS receives the sealed ticket along with the authenticator

TGS receives the sealed ticket and the authenticator. TGS decrypts the sealed ticket as it is encrypted with TGS password. TGS obtains the session key which alice had. Using this, TGS can now decrypt the authenticator

Step-4: TGS verification

TGS verifies that the username and destination address and service name is valid. Note that, TGS does not check for authorization on the file server by this user in this step. That is left on the file server to decide. Once this is done, TGS looks up the credentials for the file server and generates an encryption key using this. It also generates a new random session key (file server session key). This session key is to be used by Alice only for communication with the file server

Alice is now sent another sealed ticket like she got in step 1. This time instead of the encryption key derived from TGS password, it is done with encryption key derived from file server credentials . It contains the newly generated session key, one within the sealed ticket and one encrypted using TGS session key (which Alice saved in step1 after receiving response) . This response is called KRB_TGS_REP

Rough structure of KRB_TGS_REP

Step-5: Alice communicates with the file server

Alice receives the above and can decrypt the RHS, as she knows the TGS session key. She uses the LHS which is the sealed ticket for communication to the File Server. She now sends the file server KRB_AP_REQ. She sends the sealed ticket she received above (LHS), and she sends an authenticator which she encrypts using the file server session key she obtained.

The file server can get access to the file server session key , as it unlike Alice can decrypt the Sealed ticket having knowledge of it’s encryption key. The file server using this file server session key can decrypt the authenticator. After this to validate certain privileges the file server communicates with the KDC , in the form of KRB_VERIFY_PAC_REQ. The KDC verifies the request and then responds with KRB_VERIFY_PAC_REP