eladshamir/internal-monologueAttaque par monologue interne : Récupération de hachages NTLM sans toucher à LSASS
Mimikatz, développé par Benjamin Delpy (@gentilkiwi), est un outil de post-exploitation bien connu qui permet aux attaquants d'extraire les mots de passe en texte clair, les hachages NTLM et les tickets Kerberos de la mémoire, ainsi que d'effectuer des attaques telles que pass-the-hash, pass-the-ticket ou la construction d'un golden ticket. Sans conteste, l'utilisation principale de Mimikatz est la récupération des identifiants utilisateur depuis la mémoire du processus LSASS pour une utilisation dans les mouvements latéraux post-exploitation.
Récemment, Microsoft a introduit Credential Guard dans Windows 10 Entreprise et Windows Server 2016, qui utilise la sécurité basée sur la virtualisation pour isoler les secrets, et il est très efficace pour empêcher Mimikatz de récupérer les hachages directement depuis la mémoire. De plus, Mimikatz est devenu une cible privilégiée de la plupart des solutions de protection des terminaux, et elles sont très agressives dans leurs efforts pour le détecter et l'empêcher. Bien que ces efforts soient voués à l'échec, ils deviennent de plus en plus gênants.
NetNTLM est le protocole de défi-réponse de Windows qui est principalement utilisé là où Kerberos n'est pas pris en charge. Dans NetNTLM, le serveur envoie au client un nonce aléatoire de 8 octets comme défi, et le client calcule une réponse qui traite le défi avec le hachage NTLM comme clé, qui est le hachage MD4 du mot de passe de l'utilisateur. Il existe deux versions du protocole d'authentification NetNTLM, et les deux sont vulnérables à certaines attaques. Naturellement, la version 1 est significativement plus faible que la version 2, et donc depuis Windows Vista/2008, la version 1 de NetNTLM est désactivée par défaut.
Parce que le hachage NTLM est la clé pour calculer la réponse, un attaquant n'a pas nécessairement besoin d'obtenir le mot de passe en texte clair de la victime pour s'authentifier, donc récupérer le hachage de la mémoire LSASS en utilisant Mimikatz équivaut presque à voler un mot de passe en texte clair. Chris Hummel a publié un article décrivant cette technique en 2009 et l'a nommée « Pass the Hash » [https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219].
À Defcon 2012, Moxie Marlinspike et David Hulton ont présenté une attaque « Diviser pour régner » contre NetNTLMv1 [https://www.youtube.com/watch?v=sIidzPntdCM]. Dans NetNTLMv1, le client reçoit le défi de 8 octets et calcule la réponse en le chiffrant trois fois en utilisant DES avec différentes parties du hachage NTLM comme clé. La longueur de clé pour DES est effectivement de 56 bits, soit 7 octets, tandis que le hachage NTLM fait 16 octets. NetNTLMv1 chiffre d'abord le défi en utilisant les 7 premiers octets du hachage NTLM comme clé, puis chiffre le défi en utilisant les 7 octets suivants du hachage NTLM comme clé, et enfin chiffre le défi en utilisant les 2 derniers octets du hachage NTLM complétés par des octets nuls comme clé. Effectivement, cela signifie que pour récupérer le hachage NTLM à partir d'un défi et d'une réponse NetNTLMv1, un attaquant doit casser deux clés DES de 56 bits, ce qui est exponentiellement plus facile que de casser une seule clé de 128 bits. Moxie et Hulton ont développé du matériel personnalisé pour cette tâche et ont pu forcer brutalement l'ensemble de l'espace de clés DES en moins de 24 heures, ce qui garantit la récupération réussie du hachage NTLM dans un délai raisonnable. Notez que contrairement aux attaques par dictionnaire ou par force brute contre le mot de passe, qui peuvent ne pas être fructueuses, cette attaque garantit la récupération réussie du hachage NTLM.
Comme démontré par ToorCon à https://crack.sh, il est possible de créer une table arc-en-ciel complète pour toutes les réponses NetNTLMv1 possibles à un défi choisi, tel que 0x1122334455667788, ce qui permet de casser le hachage NTLM pour une réponse donnée en quelques minutes. L'implication est que la capture d'une réponse NetNTLMv1 pour le défi choisi peut être traduite presque instantanément en hachage NTLM correspondant, ce qui équivaut presque à obtenir le mot de passe en raison du Pass the Hash.
Mimikatz est généralement exécuté après que l'attaquant a obtenu un accès élevé à la machine cible. À ce stade, l'attaquant peut également modifier les clés de registre, telles que LMCompatibilityLevel, qui spécifie si la machine doit négocier NetNTLMv1 ou NetNTLMv2. L'attaquant peut modifier la valeur à 0, 1 ou 2, ce qui active NetNTLMv1 en tant que client, puis essayer de s'authentifier à un serveur SMB malveillant qui capturera la réponse du client, comme décrit dans l'article du blog d'Optiv [https://www.optiv.com/blog/post-exploitation-using-netntlm-downgrade-attacks].
Deux autres paramètres peuvent empêcher la victime de négocier une réponse NetNTLMv1 :
Dans les environnements sécurisés, où Mimikatz ne doit pas être exécuté, un attaquant peut effectuer une attaque Monologue Interne, dans laquelle il invoque un appel de procédure locale au package d'authentification NTLM (MSV1_0) depuis une application en mode utilisateur via SSPI pour calculer une réponse NetNTLM dans le contexte de l'utilisateur connecté, après avoir effectué un déclassement NetNTLM étendu.
Le flux de l'attaque Monologue Interne est décrit ci-dessous :
J'ai récemment retesté Monologue Interne dans des environnements avec Credential Guard activé et obtenu des résultats négatifs. Je ne suis pas sûr que Credential Guard fonctionnait correctement dans mon environnement de test lors des premiers tests, ou peut-être que quelque chose a changé depuis. J'ai mis à jour l'implémentation pour acquérir dynamiquement un jeton serveur depuis AcceptSecurityContext et le modifier pour éviter le piège d'authentification locale, de sorte que si NetNTLMv1 sans session de sécurité étendue échoue, au moins une réponse de défi-réponse NetNTLMv2 peut être capturée.
L'attaque Monologue Interne est sans doute plus furtive que l'exécution de Mimikatz car il n'est pas nécessaire d'injecter du code ou de vider la mémoire vers/depuis un processus protégé. Étant donné que la réponse NetNTLMv1 est obtenue en interagissant avec NTLM SSP localement, aucun trafic réseau n'est généré et le défi choisi n'est pas facilement visible. Aucun événement d'authentification NTLM réussi n'est enregistré dans les journaux. Les modifications du registre pour le déclassement NetNTLM et le vol de jetons/l'usurpation d'autres utilisateurs peuvent déclencher des indicateurs.
Cet outil est une preuve de concept qui implémente l'attaque Monologue Interne en C#. Le portage du code en PowerShell peut substituer certains journaux d'événements de la piste d'audit par d'autres. Le code de la preuve de concept est loin d'être parfait. Les contributions et améliorations positives sont les bienvenues.
Elad Shamir de The Missing Link Security
