Blog

Lors d’un test d’intrusion, l’auditeur se place dans la peau d’une personne malveillante afin de simuler une attaque contre une entité sur un périmètre précis. Ceci afin d’en rapporter au client une vision claire et factuelle de son niveau de sécurité et des risques métiers associés à l’exploitation des vulnérabilités identifiées.

Dans le cadre d’un test Active Directory, les machines Windows sont attaquées et une façon simple de démontrer à un client qu’il s’expose à de sérieux risques est de compromettre le domaine, et donc toutes les machines qui le composent afin de récupérer de nombreuses informations confidentielles, d’accéder à des serveurs sensibles, etc.

Même si l’abus de mauvaise configuration, de mauvaises politiques de mots de passe, de protocoles dangereux sont des moyens sûrs et efficaces pour l’auditeur d’arriver à ses fins, la façon la plus intuitive de compromettre un service, une machine, un domaine, d’élever ses privilèges et d’élargir son domaine de compromission reste encore le vol de secrets d’authentification.

Par secrets d’authentification, il est entendu ici les mots de passe en clair ou leur condensat NTLM équivalent. Comme le lecteur le sait, le hash NTLM d’un utilisateur suffit à usurper son identité, nul besoin de connaître son équivalent en clair : le mot de passe.

Pour rappel, plusieurs formats de condensats de mots de passe existent :

• Le hash NTLM est la manière dont Windows stocke les mots de passe utilisateur en local.
  • Il peut être utilisé via la technique PassTheHash
  • Il ne peut pas être relayé
  • Il peut être cassé pour retrouver le mot de passe en clair assez simplement
• Le hash NTLMv1/v2 est utilisé pour les authentifications réseaux (c’est le hash que l’on peut capturer à l’aide d’outils comme Responder ou Inveigh).
  • Il ne peut pas être utilisé via la technique PassTheHash
  • Il peut être relayé
  • Il peut être cassé pour retrouver le mot de passe en clair dans un temps raisonnable
• Le hash MSCACHv1/v2 est lié à l’authentification des utilisateurs de domaine.
  • Il ne peut pas être utilisé via la technique PassTheHash
  • Il ne peut pas être relayé
  • Il peut être cassé pour retrouver le mot de passe en clair dans un temps assez long

Mimikatz

L’arrivée d’outils tels que WCE, fgdump ou encore Mimikatz créé par Benjamin Delpy en 2007 ont créé de petites révolutions dans le milieu de la sécurité. Ces outils sont devenus célèbres parce qu’ils permettent entre autres, de venir très simplement extraire de la mémoire des secrets d’authentification (mots de passe, condensats NTLM, etc).

Les éditeurs antivirus ont bien évidemment compris l’intérêt de détecter ce genre de logiciel et sont du coup entrés en guerre contre eux à tel point que le simple fait aujourd’hui d’avoir les mots « mimikatz », « sekurlsa » ou « minidump » suffisent à provoquer une détection antivirale de Mimikatz.

Sont donc apparus au fil des années des moyens de contourner les détections (portage, packer, crypter, obfuscateurs, etc) à la durée de vie limitée.

Minidump

Une des fonctionnalités un peu moins connues de Mimikatz permettant également de récupérer des secrets d’authentification est la technique du minidump. La différence ici est que l’extraction des mots de passe se fait en local sur la machine de l’attaquant à partir d’un dump effectué préalablement sur la machine cible. En effet, seul un dump du processus lsass responsable de l’authentification Windows est effectué sur la machine cible. Le dump est alors récupéré sur la machine de l’attaquant qui peut ensuite le parser à  la recherche d’identifiants.

Réaliser ce dump est même possible à l’aide d’outils parfaitement légitimes, comme ProcDump créé par Microsoft et qui permet de monitorer les applications et de générer des dumps lors de crashs.

Cette technique présente l’avantage non négligeable de limiter l’interaction avec la machine cible au seul dump d’un processus, ce qui est finalement une action assez banale. Un antivirus signalera à la limite le comportement suspect de dumper spécifiquement le processus lsass mais se devra de gérer le cas avec beaucoup de retenue. C’est pourquoi cette technique est de plus en plus utilisée lors de tests d’intrusion interne. Cela explique également pourquoi sa durée de vie devrait a priori être plus longue qu’un classique packer ou crypter.

Le désavantage de cette technique est qu’elle nécessite plusieurs interactions avec chacune des cibles puisqu’il faut se connecter, exécuter le ProcDump, rapatrier le dump, le parser en local et chercher dans les résultats peu clairs des identifiants. Si faire cela sur une machine semble acceptable, le faire sur plusieurs machines devient vite fastidieux.

L’idée a donc naturellement été de scripter un petit outil permettant de réaliser toutes ces étapes en une ligne de commande. Le cahier des charges était d’avoir un outil :

• Simple à installer. Personne n’aime installer d’outils intrusifs (au sens propre) modifiant l’OS.
• Simple à utiliser.
• Permettant de cibler indifféremment des Windows 64 bits et 32 bits et tous les OS Windows (anciens comme récents).
• Présentant de manière claire et simplifiée les secrets d’authentification.
• Pouvant cibler plusieurs machines en même temps.
• Multi-threadé

Spraykatz

Pour répondre à ce besoin, il a été entrepris de coder un petit outil, sans aucune prétention (n’étant pas spécialement initié aux arcanes du développement), permettant de récupérer les secrets d’authentification de machines distantes de manière discrète via l’utilisation de ProcDump. Cet outil a été nommé sobrement Spraykatz en hommage au travail effectué par Benjamin Delpy.

Vous pouvez retrouver le repository ici.

L’outil vérifie d’abord que les identifiants fournis en paramètre ont effectivement des privilèges d’administration sur les machines ciblées. Si tel est le cas, l’architecture de la machine cible est récupérée afin de sélectionner le ProcDump à utiliser sur la machine distante. WmiExec est utilisée pour venir exécuter le ProcDump sur la machine cible, rapatrier le dump résultant de l’opération et supprimer les traces dans la mesure du possible sur la machine distante. Les dumps récupérés sont alors parsés et  les identifiants analysés et présentés à l’utilisateur de manière claire.

L’outil utilise Python3.x et s’appuie sur plusieurs librairies, principalement impacket de SecureAuth pour ce qui est de la gestion du protocole réseau SMB, et pypykatz de Skelsec pour la partie parsing de dump. Certains codes ont dû être adaptés légèrement à Spraykatz et Python3.x (WmiExec d’impacket et Pywerview de Yannick Méheut).

Trois paramètres sont obligatoires pour faire fonctionner Spraykatz :

• Le nom d’utilisateur (-u)
• Le mot de passe ou hash NTLM (-p)
• La ou les cibles (-t)

Trois paramètres sont optionnels :

• Le nom de domaine (-d)
• La non-suppression des dumps après parsing (-k)
• Le niveau debug (-v)

Les cibles peuvent être des IPs, des range d’IPs, ou des noms d’hôtes. Elles peuvent être spécifiées directement en lignes de commande séparées par des virgules ou dans un fichier texte (une par ligne).

Je rappelle que cet outil ne doit pas être utilisé dans un environnement de production.

Amélioration

Plusieurs axes d’amélioration sont envisagés.

Les temps de récupération des dumps peuvent parfois être très longs (plusieurs minutes) et cela semble directement lié à la façon dont Impacket fonctionne puisque le problème est le même lorsque la récupération est effectuée manuellement à l’aide de WmiExec d’impacket. Toute idée sur cette question est la bienvenue.

L’outil utilise du multiprocessing (un par cible) pour effectuer ses opérations (ProcDump). Une fois tous les process terminés, l’outil vient parser l’ensemble des dumps pour présenter les identifiants extraits. Le problème est qu’un dump de processus lsass peut dans certains cas approcher les 100Mo. Si 10 machines sont ciblées en même temps, il est possible de monopoliser 1 Go d’espace disque le temps de l’exécution de Spraykatz. L’idée serait donc de parser au fur et à mesure les dumps.

Edit : Spraykatz parse les dumps à distance désormais, ce qui lui permet de gagner en temps d’exécution et en espace requis sur la machine de l’attaquant (aucun).

Spraykatz a été initialement pensé pour ne jamais toucher le disque dur de la machine cible. Malheureusement, il n’a pas été possible de réaliser cela avec impacket, chose qu’il a été possible de faire avec des serveurs tiers SAMBA et WebDav (corrigeant également la première amélioration ci-dessus). Le choix pour l’utilisateur d’utiliser son propre serveur SAMBA ou WebDav est donc prévu et devrait permettre d’avoir un Spraykatz 100% fileless afin d’aider davantage dans le contournement des détections antivirales.

Le chiffrement des dumps effectués par l’outil serait une amélioration pertinente à l’outil puisqu’il permet d’assurer les arrières de l’auditeur dans le cas ou quelque chose se passe mal et qu’un dump est laissé sur la cible. Nous invitons du coup chacun à être vigilant sur ce point-là.

Actuellement, Spraykatz log les identifiants récupérés dans un simple fichier texte. Ce choix temporaire permet d’avoir le strict minimum en attendant l’implémentation d’une base SQLite permettant de retrouver facilement les identifiants, avec un système d’espace de travail.

Il pourrait également être intéressant d’ajouter une fonctionnalité permettant d’indiquer lors de la présentation des identifiants extraits si certains d’entre eux ont des privilèges d’administration du domaine.

Les lecteurs sont évidemment invités à participer au développement de Spraykatz en soumettant des corrections ou en proposant de nouvelles fonctionnalités.

Remerciements

Développer Spraykatz n’a été possible que grâce à l’important travail de Benjamin Delpy, Skelsec, SecureAuth et Yannick Méheut.

Je remercie spécialement Akerva de m’avoir soutenu et encouragé à développer Spraykatz afin de le mettre à disposition de la communauté.

aas_s3curity, Consultant Sécurité chez Akerva