Kerberos how it works

 Kerberos is network based authentication protocol that works based on tickets. Using this protocol client and server authenticate each other in a insecure network. Authentication is done by the KDC-key distribution center (which is a domain controller). KDC is trusted by both client and server. If kerberos is not available then windows back to NTLMv2 algorithm. Kerberos works based on hostname. If you use ip it will also go back to ntlm again.

Kerberos use shared secret which is NTLM hash, this is used for encryption and decryption. 

Before you authenticate yourself to any server you first need a TGT - ticket granting ticket and you will get this from only KDC when you type username and password (actually the password at the time of login).  

 1. Client i.e. Tim: Hi KDC, I need a TGT from you because i need to authenticate myself with other server for availing some special service. Using this TGT i will take service ticket TGS from you again. Later i will show the service ticket TGS to the desired server for authenticate myself. Here is my timestamp AS-REQ request encrypted with my NTLM hash, as you also have my NTLM hash so i expect you can easily decrypt my request. As the pre-auth is enabled so user encrypt their timestamp using their password which is NTLM hash in order to prevent replay attacks. Now you can ask how this request goes to KDC? Other server may also receive this request right? In the AS-REQ there is a field called SPN krbtgt. This field directs the message to KDC. Users hash is checked in the KDC by seeing the username of the user in AS-REQ packet.  

2. As KDC also have the user Tim NTLM hash so KDC can decrypt the request. Check the timestamp, 5 minutes gap in between KDC and the requested host (Tim). After successful decryption, Now KDC issue the TGT (encrypted with TGS {krbtgt account hash} where S for secret key) for Tim. This TGT contains PAC - privilege attributes certificate that contains Tim's details information (also encrypted with krbtgt NTLM hash). Also issue client / TGS session key (SKTGS) for Tim (encrypted with Tim's NTLM hash). Actually this same session key is provided in two places; inside of the TGT and separately. The session key that send with inside of TGT is encrypted with krbtgt password or NTLM hash of KDC and whole TGT (TGT+Session key) is further encrypted with the same krbtgt account hash of KDC; nobody knows the password except the KDC. And the one which is send separately is encrypted with users NTLM hash password. This session key will be used when communicate with the KDC (TGS-ticket generating server) next time for availing service ticket. If an attacker get this TGT then he/she cannot use this for request service ticket because the TGT contains users Tim's PAC, also attacker does not have krbtgt password to decrypt TGT. This TGT is cached on the users system (can be extracted from the memory).

 3. Now Tim has the TGT (encrypted with TGS) but Tim cannot decrypt this TGT ticket because Tim does not have krbtgt NTLM hash. This TGT is cached on Tim's computer and will work until Tim's logoff or the ticket expires. The ticket is cached so that user does not need to request for the ticket again and again. But Tim can read the session key which has been send separately because that was encrypted with Tim's password. Now lets say Tim needs to access other service of a server like mail service or web service or sql service. For that Tim needs service ticket. Now what Tim will do is, showing his TGT that he got earlier from KDC, again further request to KDC for service tickets. This request (this request is also encrypted using clients session key which we call authenticator that client got in the last packet from KDC. The request contains not so special data. Contains username and timestamp of Tim) is called TGS-REQ --> ticket granting server. If attacker got the TGT somehow event though attacker cannot do the whole steps because attacker cannot decrypt the session key that is send separately because attacker does not have the users password. And if attacker crafted a fake password claiming that this is users password then also it will not work because the same session key is present inside of TGT. KDC will decrypt the TGT and match the session key within it with the separated one. So it will not match. After sending the TGT that contains the Tim's PAC, KDC will not recalculate it. Rather it will just validate the KDC Long Term key signature which is krbtgt NTLM hash which is in the PAC. TGS=ST ticket granting service/server is equal to service ticket. 

4. Now in the reply of TGS-REP, KDC says ok giving you the service ticket but I am not sure you have the right permission on that server / on that service. I will leave that to decide on that server. I have other things to do. The service ticket has two part. One part is for the server side (encrypted with target server service account long term key which is that accounts NTLM hash) that Tim wants to communicate  Now question is how KDC encrypt the TGS using exact service account ntlm hash? Now SPN concept comes. Using SPN query KDC come to know that which service is mapped with the corresponding service account because in step 3 client already told KDC that client wants to connect sqlserver1.mydomain.local and mysql service. Another part is for Tim that contains new service session key (encrypted with client / TGS session key). This new session key will be used when client show the ticket to its requested server in this case mysql or http server. The new session key is also encrypted with users password hash so that only user can decrypt it. 

5. Now Tim send the server part ticket to the member server and Tim does not know what is inside of the ticket. Because the ticket is encrypted using the member server's service account NTLM password hash. The ticket also contains HMAC signature. Also some other data encrypted with new session key. 

6. Now member server decrypt the ticket using its service account password hash, also decrypt the HMAC signature. Now it will get the new session key. This reveals PAC - privilege attribute certificate to determine whether the user is allowed or not. The PAC is actually protected/encrypted with two signatures, services key (service account password hash) and krbtgt key (only KDC can assign this because only the KDC has the key because its krbtgt NTLM hash password).

Keep this coupon: 

The session key is used for the secure communication between client and the member server. This session key is encrypted with inside of TGT session key. Remember at the beginning of communication with KDC we have got TGT. That TGT has session key so only i (Tim) can decrypt this ticket. 

Ticket: 

The ticket that i send to server is encrypted with servers service account NTLM hash. 

 

Now what is SPN:

SPN is service principle name which is a mapping between the service and its underlying account. Your system does not know or need to know the service account that running the service. The KDC does also need to know this because for correctly encrypt the server portion ticket with proper service account NTLM hash. Setspn.exe is used to map an AD account to a service.

 

Three long term keys:

KDC has its krbtgt password hash which is its long term key.

Client has its password hash.

Server has it service accounts password hash. 

 

Golden ticket:

Golden ticket is the forged ticket that is created by the attacker. Inside of this ticket has custom PAC. Custom made username, group membership etc. The PAC is already signed by the krbtgt NTLM hash. It will checked on the KDC side and as the hash matches so it will pass. 

So what makes golden ticket so special?

It is created without any interaction with the KDC. This is possible because kerberos is a stateless protocol like tcp that is it cannot keep track of previously created TGT. 

 

 

https://smnawaz.blogspot.com/2019/11/kerberos-basic-understanding.html

https://www.tarlogic.com/blog/how-kerberos-works/

https://www.qomplx.com/qomplx-knowledge-golden-ticket-attacks-explained/?_ga=2.260479309.175447430.1635189467-1385078195.1635189467

https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/

https://www.tarlogic.com/blog/how-to-attack-kerberos/

https://cobalt.io/blog/kerberoast-attack-techniques

https://www.youtube.com/watch?v=HHJWfG9b0-E&t=2147s

https://www.youtube.com/watch?v=LmbP-XD1SC8&t=2125s

https://www.youtube.com/watch?v=IBeUz7zMN24

https://www.youtube.com/watch?v=lJQn06QLwEw

 

Now lets see how attacker leverage kerberos vulnerabilities:

1. if the user does not have pre-auth enabled then we can get the TGT and session key from the DC, (skipping step 1 from the actual request) even though we dont have users password. this is called AS-REP roasting. we can crack the users password then using getnpusers.py tool. 

2. the TGT is encrypted using krbtgt account password. if somebody somehow manage to get that password hash, then he can do anything he want in the domain. because now they able to skip step 1 and 2, directly creating the TGT. as we already know in TGT PAC is there. they create fake PAC, put there domain.admin or administrator user and group name so on. create a random session key and combine the TGT and that random session key together as a whole TGT. then attacker already know the users password. that random session key that are inside the TGT will then also be encrypted with the users password. Then it will send that to the KDC in an intention of getting TGS. KDC will decrypt that using its krbtgt password hash. After then all process will happen easily. this attack is called golden ticket attack. golden ticket expiry date can be set to as max as 10 years.

3. kerberoasting attack is cracking service account password. tool is used getusersspn.py 

4. another vulnerability in kerberos is, any user can request any service request. KDC will not verify that. KDC will leave that check to the actual application server. for example the sql or http or smb server. this leads to silver ticket attack. as we know the service ticket password or can crack the service ticket password, we can now make a service ticket encrypted with that service account password. the server (service account) decrypts the ticket. checks the PAC. in PAC the attacker already manipulate the PAC i.e. attacker says i am domain admin in the PAC. service account will see that and say ok you can avail this service. 

so the defense against all these is, use very long complex password against you all account. specially for service account. change krbtgt account pass twice if there is any doubt. 

So one question may arise, we have created a user service account for sql service. and created spn in order to associate with that account. but what about some other services like smb run on a server that accepts kerberos authentication? we access smb share on that server but no dedicated service account we have not created. then what are the spn for those? how AD encrypt their password when some one request for the service? its simple. in every domain joined computer there is a computer account. HOST/smbserver or smb/server1.local

service principle name or service name followed by the machine name

smb/smb1.htb.local 

sql/sql.htb.local

ldap/DC1.htb.local

DNS/DC1.htb.local

when user request that we want to access smb service on this server, then AD took the server name from the request and encrypt with that server's password. computer passwords are very long and complex and AD change that after a cycle of 30 days. 

Avi