# Prérequis - Environnement Windows - Compréhension basique de la cryptographie - [Introduction Active Directory](ad-intro) # Hello ! o/ Kerberos est le protocole d'authentification en Active Directory. Ce protocole sert à avoir accès aux services de l'AD. Il est divisé en plusieurs étapes : - Authentification auprès d'une autorité - Réception d'un ticket pour accéder à d'autres tickets - Demande à l'autorité un ticket pour accéder à un service spécifique - Réception du ticket pour le service spécifique - Montrer le ticket au service spécifique - Accéder au service spécifique Vous pouvez le voir comme un parc d'attraction vraiment chelou : vous avez plusieurs stands un peu partout dans le parc qui vous permettent d'avoir un ticket pour accéder à des tickets pour les attractions. Donc vous revenez au même stand de tickets pour demander un ticket pour une attraction grâce au ticket qu'on vous a donné juste avant. On vous donne un nouveau ticket pour accéder à l'attraction : vous vous hâtez avant qu'il ne soit plus valide, vous le donnez au mec qui gère l'attraction, il le vérifie et enfin vous laisse accéder à l'attraction.

Ces étapes sont en réalité définies comme ceci : - Authentication Service (AS) - Kerberos Authentication Service Request (KRB_AS_REQ) - Kerberos Authentication Service Reply (KRB_AS_REP) - Ticket-Granting-Service (TGS) - Kerberos Ticket-Granting-Service Request (KRB_TGS_REQ) - Kerberos Ticket-Granting-Service Reply (KRB_TGS_REP) - Authentication Protocol (AP) - Kerberos Authentication Protocol Request (KRB_AP_REQ) - Kerberos Authentication Protocol Reply (KRB_AP_REP)

Source: Obtaining a Service Ticket

Source: Kerberos Network Authentication Service (V5) Synopsis

Pour référence à cet article, munissez-vous de la [RFC 4120](https://tools.ietf.org/html/rfc4120). # Authentication Service (AS) La phase AS de Kerberos permet de s'authentifier auprès du KDC/DC. Ensuite, le KDC/DC offre au client un TGT (Ticket-Granting-Ticket) et une clé de session. C'est du TCP donc on a le classique "3 handshakes" SYN-SYNACK-ACK sur le port 88 (TCP/88). ## Kerberos Authentication Service Request (KRB_AS_REQ) En premier lieu, le client se connecte sur le réseau en tapant son login et son mot de passe. Le client Kerberos sur la machine de l'utilisateur [convertit le mot de passe utilisateur en clé de chiffrement symétrique](https://tools.ietf.org/html/rfc3961). On peut aussi utiliser une clé publique en guise de mot de passe, c'est un autre mécanisme d'authentification comme [pkinit (RFC 4556)](https://tools.ietf.org/html/rfc4556) (donc par une clé PKI). Votre client Kerberos envoie donc une demande de TGT au KDC avec comme [payload](https://tools.ietf.org/html/rfc4120#section-5.4.1): - as-req - pvno - msg-type - req-body - kdc-options - cname \[OPT] - realm - sname \[OPT] - from \[OPT] - till - rtime \[OPT] - nonce - etype - addresses \[OPT] | Champ | Description | | ----- | ----------- | | pvno | Version du protocole Kerberos, actuellement 5 | | msg-type | Type de message, ici KRB_AS_REQ | | kdc-options | Flags | | cname | *Client/User Principal Name* (CPN / UPN) (exemple : utilisateur@domain.com) | | realm | *Kerberos Principal Name* (KPM) / nom de domaine Windows | | sname | *Service Principal Name* (SPN), ici "krbtgt" | | from | Timestamp, c'est le starttime dont on parle dans la RFC | | till | Temps d'expiration de KRB_AS_REQ | | rtime | Temps d'expiration pour un ticket RENEWABLE | | nonce | Nombre random de type *uint32_t* généré par le client | | etype | Encryption Types : c'est les méthodes de chiffrement acceptées par notre client | | addresses | Adresse du client, contient d'autres adresses si on passe par un proxy |

Source: Kerberos Authentication - HackTricks

## Kerberos Authentication Service Reply (KRB_AS_REP) Le serveur d'authentification (KDC) reçoit donc les données. Il vérifie le cname et en extrait les clés respectives, car oui il peut y avoir plusieurs clés. Dans ce cas, il prend celles définies par le champ *etype* de KRB_AS_REQ pour sélectionner la méthode de chiffrement à utiliser pour protéger une partie de KRB_AS_REP. Si il y a plusieurs valeurs dans *etype*, on prend la première valide. Il est à noter que si votre Kerberos en AD utilise un système de chiffrement symétrique faible, il sera faillible à plusieurs attaques informatiques. Vous avez plusieurs [méthodes de chiffrement disponibles](https://docs.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos): - DES_CBC_CRC (< Windows Server 2008 R2) - DES_CBC_MD5 (< Windows Server 2008 R2) - RC4_HMAC_MD5 (Faillible Kerberoast) - AES128_HMAC_SHA1 - AES256_HMAC_SHA1 Le KDC renvoie plusieurs éléments de réponse : - la clé de session - le TGT - nom d'utilisateur - période de validité - clé de session - le *Privilege Attribute Certificate* (PAC) En plus détaillé, ça fait : - as-rep - pvno - msg-type - padata \[OPT] - crealm - cname - ticket: TGT - tkt-vno - realm - sname - enc-part - flags - key - crealm - cname - transited - tr-type - contents - authtime - starttime \[OPT] - endtime - renew-till \[OPT] - caddr \[OPT] - authorization-data \[OPT] - enc-part - key - last-req - lr-type - lr-value - nonce - key-expiration \[OPT] - flags - authtime - starttime \[OPT] - endtime - renew-till \[OPT] - srealm - sname - caddr \[OPT] | Champ | Description | | ----- | ----------- | | padata | Pre-Authentication Data | | crealm | Contient le nom du realm où le client s'est authentifié initialement | | ticket | Structure de donnée pour un ticket/authenticator | | tkt-vno | Version du format du ticket | | realm | Quel realm a fourni le ticket | | enc-part | Encrypted Part, chiffré symétriquement et uniquement lisible par le KDC | | key | Clé de session pour être passée du Kerberos à l'AP et au Client | | transited | Kerberos realms qui ont participé à l'authentification du client | | authtime | Timestamp de l'auth initiale | | starttime | Timestamp à partir duquel le ticket est valide | | endtime | Timestamp à partir duquel le ticket est invalide | | renew-till | Si RENEWABLE. Indique le maximum endtime pour un renouvellement, peut-être considéré comme le endtime absolu | | caddr | Adresses qui peuvent utiliser le ticket, si vide, n'importe quelle adresse peut utiliser le ticket | | authorization-data | Le PAC, c'est la liste des restrictions du ticket | | enc-part | Chiffré symétriquement et lisible par KDC et Client | | last-req | Timestamp de la dernière requête pour un TGT dans un contexte spécifique | | lr-type | last-req type, aide pour interpréter lr-value (contexte) | | lr-value | last-req value, timestamp | | key-expiration | Timestamp à partir duquel la clé secrète du client expire |

Source: Kerberos Authentication - HackTricks

# Ticket-Granting-Service (TGS) Maintenant que notre client a son TGT avec ses droits inscrits dessus, il peut demander au KDC d'accéder aux services du réseau en demandant un TGS (Un ticket qui donne accès à un service) sous la forme d'un couple Clé de session/TGS. ## Kerberos Ticket-Granting-Service Request (KRB_TGS_REQ) Le client Kerberos de l'utilisateur demande donc au KDC sous la forme d'un KRB_TGS_REQ un TGS. Grosso modo, le message consiste à donner : - quel service le client veut accéder (SPN) - le TGT - un *authenticator* qui contient surtout le *cname* et un *ctime* Définition de l'authenticator : - authenticator - authenticator-vno - crealm - cname - cksum \[OPT] - cusec - ctime - subkey \[OPT] - seq-number \[OPT] - authorization-data \[OPT] | Champ | Description | | ----- | ----------- | | authenticator | Chiffré avec la clé de session | | authenticator-vno | Version de l'authenticator | | ck-sum | checksum | | cusec | Client USeconds (micro secondes) du timestamp | | ctime | Timestamp du client | | subkey | Clé à utiliser pour KRB_TGS_REP, si vide : clé de session du TGT | | seq-number | Détecter les requêtes rejouées, agit un peu comme l'ACK de TCP | | authorization-data | Restrictions additionnelles par rapport à celles du TGT | Ce qui change dans la requête c'est le flag *ENC-TKT-IN-SKEY* qui permet de dire au KDC qu'on ajoute le TGT à la requête dans le champ *additional-tickets*, ainsi qu'un champ optionnel *enc-authorization-data*. - tgs-req - pvno - msg-type - padata: PA-TGS-REQ - req-body - kdc-options: ENC-TKT-IN-SKEY - cname \[OPT] - realm - sname: \[OPT] - from \[OPT] - till - rtime \[OPT] - nonce - etype - addresses \[OPT] - enc-authorization-data - additional-tickets - TGT - authenticator | Champ | Description | | ----- | ----------- | | enc-authorization-data | PAC désiré, chiffré avec la clé de session (sinon clé TGT) | | additional-tickets | Tickets additionnels à la requête |

Source: Kerberos Authentication - HackTricks

## Kerberos Ticket-Granting-Service Reply (KRB_TGS_REP) Le KDC reçoit le KRB_TGS_REQ. Il est traité de la même manière que KRB_AS_REQ, mais avec plus de checks, ce qui est logique... s'il y a plus de données, il y a plus de checks à faire. Par exemple, on va comparer le TGT et l'Authenticator... histoire de voir si le TGT appartient bien au client, donc on va comparer *cname* et *key*. Ensuite, on check si le client a bien le droit d'accéder au *sname* grâce au PAC (*authorization-data* du ticket TGT). La requête détaillée se trouve ci-dessous : - tgs-rep - pvno - msg-type - padata \[OPT] - crealm - cname - ticket: TGS - ... - enc-part - enc-part | Champ | Description | | ----- | ----------- | | ticket:enc-part | Chiffré symétriquement et lisible par KDC et le service/AP | | enc-part | Chiffré symétriquement et lisible par KDC et le Client | C'est son ticket d'entrée pour rentrer dans le service ! Hooray \o/ !

Source: Kerberos Authentication - HackTricks

# Authentication Protocol (AP) On y est ! Désormais le but est de créer une communication sécurisée avec le service et nous. Le service pourra déchiffrer notre TGS grâce à sa propre clé. On rappelle que le TGS permet d'authentifier le client sur le service. ## Kerberos Authentication Protocol Request (KRB_AP_REQ) Notre client doit faire le premier pas vers le service. Par conséquent, grâce à la KRB_TGS_REP, nous avons accès à la clé de session du service. On va donc générer nos nouveaux authentifiants pour le service : un *authenticator* chiffré avec la clé de session du service. On enverra à la suite notre TGS qu'on ne peut pas lire (mais le service oui). - ap-req - pvno - msg-type - ap-options - ticket: TGS - authenticator | Champ | Description | | ----- | ----------- | | authenticator | Chiffré avec la clé de session du service |

Source: Kerberos Authentication - HackTricks

## Kerberos Authentication Protocol Reply (KRB_AP_REP) Enfin, si tout est bon, c'est-à-dire après comparaison entre le TGS et l'authenticator, le client peut accéder au service. Attention cependant, le service peut demander confirmation du PAC au KDC. Dans le cas où le bit *mutual-required(2)* est mis dans *ap-options*, le service renverra bien un KRB_AP_REP. # Merci pour votre lecture :) # Liens utiles - [Kerberos en Active Directory (Hackndo)](https://beta.hackndo.com/kerberos/) - [Kerberos Authentication](https://book.hacktricks.xyz/windows/active-directory-methodology/kerberos-authentication) - [Obtaining a Service Ticket](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/3dcc917c-4d41-447d-9d8d-62ea64bc5cda) - [Authentication Service Exchange](https://docs.microsoft.com/en-us/windows/win32/secauthn/authentication-service-exchange) - [Kerberos Network Authentication Service (V5) Synopsis](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13) - [Kerberos Explained](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb742516(v=technet.10)?redirectedfrom=MSDN) - [Kerberos (protocole)](https://en.wikipedia.org/wiki/Kerberos_(protocol)) - [Are there any reasons for Kerberos being based on symmetric cryptography?](https://security.stackexchange.com/questions/227241/are-there-any-reasons-for-kerberos-being-based-on-symmetric-cryptography) - [Kerberos authentication explained](https://www.markwilson.co.uk/blog/2005/06/kerberos-authentication-explained.htm) - [RFC 4120](https://tools.ietf.org/html/rfc4120) - [RFC 4120 FR](http://abcdrfc.free.fr/rfc-vf/rfc4120.html)

Active Directory - Kerberos

Share this research