Comment exploiter la base SAM pour obtenir un Hash NTLM

La base SAM (Security Account Manager) est la base de donnée utilisée par Windows pour stocker les informations des comptes locaux et notamment les mots de passes sous forme de Hash NTLM ou NT Hash. C’est également un des composants de la base de registre.

Cette base est stockée dans le répertoire C:\Windows\System32\Config

SAM path

Seul le compte SYSTEM possède les autorisations requises pour accéder à son contenu. La commande PsExec peut être utilisée pour ouvrir le registre avec les privilèges appropriés.

SAM – Compte local

Pour extraire les Hash NTLM de la base SAM localement on peut utiliser Mimikatz (à condition d’obtenir un accès administrateur sur la machine et bypasser l’antivirus ou tout autre mécanisme de protection).

Mimikatz – lsadump::sam

On peut également utiliser Lazagne.

Lazagne

L’algorithme de génération d’un Hash NTLM est assez simple. Il suffit de convertir le mot de passe au format Unicode Little-endian et d’y appliquer l’algorithme de hachage MD4.

On peut faire un test sur le site NTLM HASH Generator et voir que le NT Hash du compte Administrator correspond bien au mot de passe Azerty59.

NTLM Hash Generator

Une fois le Hash NTLM obtenu deux possibilité s’offre à nous :

  1. Tenter une attaque de type brute force ou dictionnaire pour obtenir le mot de passe en clair
  2. Tenter une attaque de type Pass The Hash (Pth) pour se connecter sur une autre machine

Pour la première attaque on va utiliser John pour essayer de cracker le NT Hash avec un dictionnaire (une simple liste de mot de passe). Pour cela Il faut créer un premier fichier formaté avec le NT Hash du compte Administrator et un un deuxième avec la liste de mots de passe à tester.

NTLM Hash
Password list

john.exe –format=NT –wordlist=Password-List.txt .\NTLM-Hash.txt

John NT format

Si vous ne trouvez aucun mot de passe, il reste la possibilité d’effectuer une attaque par force brute. Cependant, cela nécessitera une machine suffisamment puissante et dépendra de la faiblesse ou non du mot de passe.

Pour la deuxième attaque on peut utiliser Mimikatz pour créer une nouvelle session en tant qu’Administrateur avec le Hash NTLM et ainsi pouvoir se connecter sur une machine distante via le protocole NTLM.

Dans mon exemple une fois la session créée par Mimikatz une nouvelle fenêtre cmd est automatiquement ouverte avec les identifiants du compte Administrateur chargées en mémoire. Cela me permet ensuite à l’aide de PsExec d’ouvrir un session à distance depuis la machine CL01 (10.0.0.15) sur le contrôleur de domaine DC-01 (10.0.0.2) le tout sans jamais connaitre le mot de passe.

Mimikatz – Pass the hash

En analysant le trafic réseau avec Wireshark on constate bien que le protocole utilisé pour l’authentification est NTLM.

Wireshark – NTLMSSP

On peut également réaliser cette attaque depuis une machine linux avec impacket-psexec. Pas besoin de mot de passe, l’important est juste connaitre le nom du compte et son NT Hash.

Bien évidemment cette attaque n’est possible que si le mot de passe du compte local usurpé est le même que sur la machine distante, peu importe que l’identifiant du compte soit le même ou pas. Dans mon cas, le compte local est Administrator et le compte distant correspond à l’utilisateur Administrateur du domaine, ce qui ne pose aucun problème, car le mot de passe (et donc le Hash NTLM) est le même. Il est donc possible de tenter une authentification NTLM avec un même NT Hash sur plusieurs compte différent afin de vérifier si ces comptes partagent le même mot de passe.

Pour atténuer au maximum le risque de vol et d’exploitation des identifiants de la base SAM il est recommandé de :

  • Restreindre le trafic NTLM entrant et sortant au niveau des machines via GPO (il faut bien sur réaliser un audit préalable)
  • Mettre en place une politique de mot passe robuste (même en cas de vol une tentative de brute force sera inutile)
  • Configurer un mot de passe différent pour le compte Administrateur local sur chaque machine (Mettre en place LAPS permet de régler ce problème)

Toutes les informations et techniques présentées sur ce blog sont strictement à des fins éducatives. L’utilisation de ces connaissances pour des activités illégales ou non autorisées est interdite.

Interdire l’ouverture de session sur les stations de travail pour les comptes à privilèges

Pour empêcher l’exposition et la dissémination des identifiants des comptes à privilèges sur les stations de travail une solution simple consiste à interdire l’ouverture de session pour ces comptes à l’aide d’une GPO.

4 paramètres sont disponibles dans Computer > Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments :

  • Deny log on locally
  • Deny log on as a batch job
  • Deny log on as a service
  • Deny log on through Remote Desktop Services
GPO Deny log on

Il est également possible d’utiliser les GPO LoginRestrictions du modèle HardenAD.

HardenAD LoginRestrictions

Désactiver la mise en cache des identifiants Windows

Par défaut Windows met en cache les identifiants des 10 derniers comptes du domaine qui ont ouvert une session sur une machine.

Cette fonctionnalité est très utile car elle permet de se connecter à une machine même lorsque le contrôleur de domaine n’est pas disponible.

Cependant, elle présente aussi un risque : un attaquant pourrait en profiter pour voler ces identifiants et tenter de les craquer par brute force.

Pour désactiver la mise en cache sur vos serveurs vous pouvez créer une GPO ou utiliser celle qui est fournie par le projet Harden AD.

HAD-Logon-Cache-0

La GPO HAD-Logon-Cache-0 s’applique à la racine du domaine. Pour l’appliquer sur l’un de vos serveur il suffit de l’ajouter dans le groupe APPLY correspondant.

Pour une station de travail il faut laisser au moins 2 valeurs en cache pour ne pas être bloqué lorsque l’on travaille en dehors du réseau.

Après application de la GPO il ne reste plus que 2 identifiants en cache :

Comment exploiter le cache de Windows pour obtenir un mot de passe

Lorsqu’un utilisateur ouvre une session sur un ordinateur intégré à un domaine Active Directory le contrôleur de domaine le plus proche est interrogé pour réaliser son authentification. Si les identifiants fournis sont valides, ils sont mis en cache localement, ce qui permet à l’utilisateur de continuer à s’authentifier même s’il n’est plus connecté au réseau et que le contrôleur de domaine n’est pas accessible.

L’évènement 4624 consultable depuis le journal de la machine permet de déterminer si une authentification a été réalisée à l’aide des identifiants mis en cache ou si le contrôleur de domaine a été interrogé.

Lorsque l’ordinateur est connecté au réseau et que le contrôleur de domaine est interrogé, le type de connexion (LogonType) a la valeur 2

Logon Type 2 : Interactive

En revanche, si l’ordinateur n’est pas connecté au réseau, c’est le cache qui est utilisé, et le LogonType prend la valeur 11

Logon Type 11 : CachedInteractive

Le cache des identifiants du domaine est accessible via le registre à l’emplacement HKEY_LOCAL_MACHINE\SECURITY\Cache.

Seul le compte SYSTEM dispose des autorisations nécessaires pour accéder à son contenu. On peut utiliser la commande PsExec pour ouvrir le registre avec les privilèges nécessaires.

Dans notre exemple, nous pouvons voir la ligne correspondant à notre compte T2A-aharden. Par défaut, les 10 derniers comptes utilisés pour se connecter sont stockés.

Contrairement au format NT Hash utilisé pour stocker les mots de passe des comptes locaux dans la base SAM, le format utilisé pour les comptes de domaine est MsCacheV2.

Il existe deux version de MsCache ou DCC (Domain Cache Credential) :
– MsCacheV1 pour Windows Server 2003 et Windows XP
– MsCacheV2 à partir de Windows Server 2008, Windows Vista et plus récent

Alors qu’il est possible de mener des attaques de type Pass The Hash avec le NT Hash, cela n’est pas possible avec le MsCache. Ce dernier peut uniquement être cracké par des méthodes de force brute, des attaques par dictionnaire ou par des rainbow tables pour pouvoir être exploité.

Il est possible de récupérer le hash du mot de passe d’un compte stocké en cache à l’aide de Mimikatz à condition de posséder un accès administrateur sur la machine.

Mimikatz lsadump::cache

Nous allons réaliser une attaque par dictionnaire à l’aide de John pour tenter de craquer le mot de passe. Pour cela il faut préparer un fichier formaté avec le nom et le MsCacheV2 du compte et un deuxième fichier qui sera une liste de mot de passe à tester.

MsCacheV2

Dans notre cas j’ai volontairement choisi de créer une liste de mot de passe limitée pour le test mais il y’a des listes beaucoup plus conséquentes disponibles en téléchargement sur internet.

Liste de mots de passe

Il suffit ensuite de lancer la commande et voir si une correspondance a été trouvée.

john.exe --format=mscash2 --wordlist=Password-List.txt MsCacheV2.txt
John crack mscash2

Si aucun mot de passe n’est trouvé, il reste la possibilité d’effectuer une attaque par force brute. Cependant, cela nécessitera une machine suffisamment puissante et dépendra de la faiblesse ou non du mot de passe.

Pour atténuer au maximum le risque de vol et d’exploitation des identifiants mis en cache il est recommandé de :

Toutes les informations et techniques présentées sur ce blog sont strictement à des fins éducatives. L’utilisation de ces connaissances pour des activités illégales ou non autorisées est interdite.