Par Bhabesh Raj Rai, Associate Security Analytics Engineer

Le 19 juillet 2021, l’expert en sécurité Lionel Gilles a publié des détails techniques ainsi qu’un outil PoC concernant une vulnérabilité nommée PetitPotam. Cette dernière permet à un utilisateur de domaine de contraindre un contrôleur de domaine à s’authentifier auprès d’un serveur distant à l’aide de l’interface Microsoft Encrypting File System Remote Protocol (MS-EFSRPC) révélant ainsi son hachage d’authentification dans le processus.

Cette vulnérabilité est très dangereuse car les attaquants peuvent la combiner avec une vulnérabilité par relais dans le serveur Active Directory Certificate Services (AD CS) récemment découverte par les chercheurs de Specterops. En effet, les adversaires peuvent transmettre le hachage obtenu concernant une entité à un serveur AD CS et obtenir le certificat de celle-ci. À l’aide de ce certificat, les adversaires peuvent alors usurper l’identité de cette entité et effectivement demander le ticket-granting-ticket (TGT) en leur nom. Pour résumer, les adversaires peuvent compromettre intégralement le domaine via le serveur AD CS et ce sans aucune authentification.

Comme toute autre attaque par relais, les adversaires doivent avoir leur machine dans le même segment LAN ou avoir des privilèges élevés dans le domaine. Les serveurs AD CS avec le Certificate Authority Web Enrollment ou le Certificate Enrollment Web Service activés sont vulnérables.

Microsoft a publié des conseils sur la mitigation de PetitPotam, et ils ont classé la vulnérabilité comme une attaque par relais (relay attack) NTLM classique. Microsoft recommande aux administrateurs d’activer l’EPA (Extended Protection for Authentication) et de désactiver le HTTP sur les serveurs AD CS. De plus, Microsoft a également présenté des mesures de mitigation supplémentaires, telles que la désactivation de l’authentification NTLM dans la mesure du possible et la mise en œuvre de la signature SMB. Les administrateurs système doivent garder à l’esprit que la désactivation du MS-EFSRPC ne permet pas de mitiger les risques liés à cette vulnérabilité.

Détection de la chaîne d’attaque PetitPotam dans LogPoint

PetitPotam ne nécessite aucune authentification, signifiant ainsi que nous pouvons rechercher des connexions NTLM anonymes aux serveurs, en particulier aux contrôleurs de domaine. Nous avons constaté que les adversaires utilisant leur machine pour l’attaque génèrent l’ID d’événement 4624 avec un champ workstation sans valeur que nous pouvons utiliser pour filtrer les faux positifs.

norm_id=WinServer event_id=4624 user="ANONYMOUS LOGON" package=NTLM

event_id=4624

Nous pouvons également rechercher des artefacts PetitPotam dans les logs d’événement d’audit de partage de fichiers. Les administrateurs doivent vérifier qu’ils ont activé l’audit détaillé du partage de fichiers pour que la requête fonctionne.

norm_id=WinServer event_id=5145 share_name=IPC$ access="ReadData (or ListDirectory) WriteData (or AddFile)" relative_target IN ["lsarpc", "efsrpc", "lsass", "samr", "netlogon"] | chart count() by host, user, source_address, relative_target

event_id=5145

Pour faciliter la corrélation, les administrateurs peuvent rechercher les événements de demande de certificat générés par le serveur AD CS et zoomer sur les demandes de certificat émises par les contrôleurs de domaine pendant la période où les artefacts PetitPotam ont eu lieu. Les administrateurs doivent activer l’audit « Issue and manage certificate requests » dans le serveur AD CS pour générer les logs correspondants car l’audit est désactivé par défaut.

norm_id=WinServer label=Certificate label=Request label=Receive | chart count() by host, attributes, requester, message

Issue and manage certificate requests

Enfin, les adversaires récupéreront le TGT d’un contrôleur de domaine à l’aide du certificat précédemment obtenu et mettront en cache le ticket en mémoire. Pour effectuer une telle détection, nous devons rechercher les événements de demande TGT où le contrôleur de domaine est un utilisateur (car le certificat appartient au contrôleur de domaine), mais le champ d’adresse source contient l’adresse IP de la machine contrôlée par l’adversaire. Dans le cas d’une utilisation quotidienne, le compte de la machine du contrôleur de domaine demandera toujours un TGT pour sa propre machine, et donc le champ d’adresse source doit toujours être sa propre adresse IP.

norm_id=WinServer event_id=4768 user IN WINDOWS_DC_HOSTNAMES -source_address IN WINDOWS_DC

WINDOWS_DC_HOSTNAMES est une liste qui contient le nom d’utilisateur de tous les comptes de contrôleur de domaine comme DC01, DC02, etc., tandis que WINDOWS_DC comprend les adresses IP de tous les contrôleurs de domaine.

WINDOWS_DC_HOSTNAMES

Déployez les mesures de mitigation dès que possible

En conclusion, les administrateurs système doivent mettre en œuvre rapidement les mesures de mitigation fournies par Microsoft s’ils ont déployé des serveurs AD CS dans leur environnement. Si les administrateurs reportent le déploiement de ces mesures de mitigation à une date ultérieure pour diverses raisons, ils devront alors mettre en place les détections nécessaires pour intercepter les tentatives d’exploitation. Étant donné que la compromission complète du domaine est possible sans aucune authentification, la faille séduira probablement tous les acteurs malveillants sans que Microsoft ne puisse les bloquer.