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.
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 :
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.
PsExec -i -s regedit.exe
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.
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 :
Ajouter les comptes à privilèges dans le groupe Protected Users (Attention cette fonctionnalité n’est prise en charge qu’à partir de Windows 8.1 et Windows Server 2012 R2)
Mettre en place une politique de mot passe robuste (même en cas de vol une tentative de brute force sera inutile)
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.
