Utiliser des comptes Administrateur local Windows, Partie I
Utiliser des comptes Administrateur local Windows, Partie II
Utiliser des comptes Administrateur local Windows, Partie III
Avant de nous plonger dans les Groupes restreints, j’ai pensé qu’il serait utile d’examiner de plus près comment les hackers tirent avantage des mots de passe Administrateur. Pour les amateurs de « Pass-the-Hash », ce billet vous montrera comment il est possible d’utiliser le hachage même avec les comptes locaux. J’ai aussi eu une occasion d’essayer la solution Windows Local Administrator Passwords (LAPS). Attention, spoiler : LAPS me donne un peu la chair de poule.
Utiliser la technique « Pass-the-hash »
Après avoir écrit le premier billet, j’ai réalisé que le hachage des comptes de domaine n’est pas forcément utile. En fait, Windows conserve aussi le hachage des comptes locaux dans sa base de données Gestionnaire de comptes de sécurité (SAM). Des outils de dump du hachage tels que crackmapexec et mimikatz vous donnent la possibilité de voir ces hachages.
Tout ceci nous conduit à une technique plus directe de déplacement latéral. Comme je l’ai indiqué la dernière fois, il n’est pas rare que des comptes Administrateurs locaux aient exactement le même mot de passe sur plusieurs machines. Cela voudrait aussi donc dire que les hachages NTLM seraient aussi identiques.
Imaginons qu’un hacker accède à un serveur, qu’il dispose de droits suffisants et utilise mimikatz pour voir si un compte Administrateur local est disponible. Il peut ensuite tenter une expérience et transmettre le hachage Administrateur à , par exemple, psexec, pour ouvrir un shell sur un autre serveur et obtenir là aussi des droits Administrateur.
Vous voyez à quoi je veux en venir ? Si vous supposez que les mots de passe Administrateur sont identiques sur différentes machines, alors vous ne dépendez plus du fait qu’un utilisateur du domaine ait laissé un hachage dans la mémoire LSASS de cette machine. Si cette dernière phrase vous laisse perplexe, ce billet vous en dit plus sur LSASS.
D’un autre côté, les hachages de l’utilisateur local sont toujours là ! Lorsque vous êtes hacker ou testeur d’intrusions, vous êtes sans arrêt en train de tester différentes idées ou de miser sur la chance. Alors, tentons le tout pour le tout !
Revenons à mon domaine Acme. J’ai défini le même mot de passe Administrateur local sur mes serveurs Masa et Taco (ce dernier est aussi mon contrôleur de domaine). Dans ce scénario, je suis déjà sur Masa, j’ai chargé mimikatz et psexec.
Au passage, ces deux outils ayant un code source, il ne serait pas bien difficile de les rendre totalement indétectables en quelques manipulations.
J’étais alors sur masa incognito, mais je n’ai rien pu y trouver d’intéressant. Pour entamer mon déplacement latéral, j’ai chargé mimikatz et effectué un dump des hachages avec la commande lsadump::sam.
J’ai alors supposé que Taco utilisait le même mot de passe Administrateur et utilisé sekurlsa:pth pour lancer psexec et obtenir un shell sur Taco (ci-dessous).
Incroyable !
Lorsque j’ai modifié le mot de passe Administrateur de Taco, la ruse n’a pas fonctionné et psexec n’a pas pu ouvrir de shell.
Ce qu’il faut en retenir : il est utile que les mots de passe Administrateur soient différents.
LAPS et aspirine
Si vous décidez de conserver les mots de passe Administrateur local, vous devez les gérer. Comme je l’ai dit dans mon précédent billet, il est possible de désactiver ces comptes et d’utiliser des Groupes restreints pour déléguer des droits Administrateur à des comptes du domaine.
Dans tous les cas, certaines personnes voudront quand même conserver ces comptes locaux. Microsoft a apparemment entendu l’appel à l’aide des administrateurs informatiques et publié sa Local Administrator Passwords Solution en 2015. Microsoft décrit la solution en ces mots : « …solution au problème posé par l’utilisation d’un compte local courant possédant un mot de passe identique sur chaque ordinateur d’un domaine. LAPS résout ce problème en définissant un mot de passe aléatoire différent pour le compte administrateur local courant sur chaque ordinateur du domaine. »
Cela semble simple. Toutefois, comme nous avons déjà eu l’occasion de le dire, jamais, au grand jamais, Microsoft ne fait les choses simplement.
Le premier conseil concernait l’architecture LAPS (voir ci-dessous).
Hum, il faut prendre en compte les aspects client et serveur. La documentation mentionne aussi des scripts PowerShell à exécuter, et il est aussi question de modifier le schéma Active Directory.
Je me suis courageusement attaqué à LAPS et suis allé aussi loin que possible dans l’installation avant que mon mal de crâne n’ait raison de moi.
Cette installation n’a rien de facile. LAPS est chargé sur votre contrôleur de domaine ainsi que sur les ordinateurs clients que vous voulez gérer. Oui, vous utilisez la Console de gestion de groupe pour pousser LAPS sur les clients.
Si vous effectuez l’installation correctement, vous verrez la fenêtre d’interface suivante lorsque vous vous déplacerez dans l’éditeur GPO jusqu’à Configuration ordinateur>Modèles d’administration>LAPS.
J’avais peur de ce que cela allait donner. En théorie, LAPS génère des mots de passe aléatoires à présent centralisés sur Active Directory dans un nouvel attribut en texte clair, c’est pourquoi vous devez mettre à jour le schéma AD.
Certains professionnels de la sécurité ont souligné le fait que LAPS pourrait avoir, euh…, quelques problèmes. En fait, vous déplacez le problème des ordinateurs locaux vers Active Directory.
Revenons au Groupes restreints
Après mon petit détour par LAPS, j’ai commencé à considérer les Groupes restreints comme le moyen le plus pratique pour gérer les comptes Administrateur local. J’ai entamé cette procédure dans le billet précédent, lorsque j’ai créé un nouveau groupe AD nommé AcmeIT, qui a ensuite été poussé vers l’extérieur et placé sous le groupe Administrateurs locaux de chaque machine du domaine Acme.
C’est une super astuce et les Groupes restreints permettent au service informatique de contrôler de manière centralisée l’accès de l’Administrateur local.
Ce serait encore plus super si je pouvais segmenter mon domaine de façon à ce qu’un groupe d’utilisateurs constitue les Administrateurs locaux d’un sous-ensemble de machines et qu’un autre groupe contrôle un autre sous-ensemble, créant ainsi autant de sous-groupes que nécessaires.
Autrement, je tomberais dans le piège du petit groupe d’utilisateurs autorisé à avoir un accès Administrateur local à tout le domaine ! Pas bon.
Et c’est là qu’entrent en piste les Unités d’organisation (OU). C’est une façon de diviser le domaine pour pouvoir associer des GPO spécifiques à chaque sous-groupe OU.
Pour commencer, vous configurez ces sous-divisions OU dans Utilisateurs et ordinateurs Active Directory (ci-dessous). Pour chaque OU, j’ai affecté un sous-ensemble d’ordinateurs du domaine. Dans mon scénario, Acme-1 est associé aux serveurs Masa et Pimiento, et Acme-2 est associé à Taco, le contrôleur de domaine.
Je devais aussi me rappeler de créer des groupes Active Directory qui seraient associés à chacune de ces OU — Acme-IT-1 et Acme-IT-2.
De retour dans la Console de gestion de groupe, ces OU apparaissent sous le domaine Acme (ci-dessous). J’ai ajouté des stratégies de Groupe restreint sous chaque OU, en m’assurant d’utiliser les groupes AD adéquats.
C’est plus simple qu’il n’y paraît. En bref : Je permets aux membres d’Acme-IT-1 d’être Administrateurs de Masa et Pimiento, et à ceux d’Acme-IT-2 d’assumer le même rôle pour Taco.
Nous conclurons sur ce thème extrêmement passionnant dans le prochain billet et, comme j’en ai l’habitude, je finirais en vous confiant quelques réflexions. Pour l’instant, prenez quelques aspirines, vous en avez bien besoin pour être arrivé aussi loin dans la série.
