Cinq façons de devenir administrateur de domaine avec Metasploit

1. Introduction

1.1 Un environnement Windows : à quoi ça ressemble ?

On peut représenter un domaine Windows de manière simple : il est composé d'un contrôleur de domaine (le fameux Active Directory) et d'équipements appartenant à ce domaine. Le contrôleur de domaine va permettre notamment d'appliquer des Group Policy Object (GPO) sur les différents équipements du domaine (stratégie de mot de passe, stratégie de verrouillage des comptes, stratégie d'audits, etc.). Hormis le contrôleur de domaine, on va se retrouver dans un environnement Windows avec 2 catégories d'équipements (de manière simplifiée) : les postes de travail et les serveurs. Les postes de travail ne représentent pas en général une cible intéressante en test d'intrusion, sauf les postes des administrateurs du domaine bien entendu. Concernant les serveurs, on va retrouver différents types de serveurs qui pourront en cas de compromission contenir des informations intéressantes et qui pourront venir étoffer le rapport de l'auditeur (serveur de fichiers, de base de données, serveurs d'applications, etc.). Le fait que dans un environnement Windows les équipements appartiennent à un même domaine permet d'en faciliter leur administration, mais comme nous le verrons par la suite, cela permet en cas de compromission d'un poste ou d'un serveur de prendre le contrôle de l'ensemble du domaine.

1.2 Un test d'intrusion interne : qu'est-ce que c'est ?

Pour rappel, l'objectif d'un test d'intrusion est de mettre en avant la capacité de malveillance d'un attaquant et ainsi de présenter de manière concrète l'exploitation des faiblesses identifiées.

Dans le cas du test d'intrusion interne, cette capacité de malveillance est simulée selon deux scénarios classiques :

1. Intrus physique : dans ce scénario, l'auditeur simule une intrusion physique réalisée dans les locaux du client disposant de son propre matériel et d'un accès à une prise RJ45 ;
2. Collaborateur malveillant : ici, l'auditeur joue un collaborateur interne de l'entreprise disposant d'un poste de travail et d'un compte de domaine standards.

Dans les deux scénarios, il n'y a que le point de départ qui est différent, mais l'objectif reste identique, à savoir la prise de contrôle du système d'information et l'accès à des données confidentielles de l'entreprise (comptabilité, données RH, savoir-faire, etc.).

2. Scénarios d'attaques

2.1 Énumération des partages réseau et des utilisateurs du domaine

Une des premières choses à faire lors d'un test d'intrusion en interne est d'identifier les partages réseau visibles en lecture, car on y trouve fréquemment quelques perles (logins_prod_BDD.xls, IT_password.xls, etc.).

On peut utiliser le module smb_enumshares afin de lister les répertoires partagés accessibles sur le réseau.

L'idée étant de lancer l'énumération sans aucun compte sur le réseau. Par la suite, si l'on trouve des comptes durant le test d'intrusion, on pourra les utiliser pour obtenir de nouveaux accès et accéder à de nouvelles informations. Enfin, ce qu'il est intéressant de souligner avec ce module (mais qui est vrai pour les autres modules smb_*), c'est que nous pouvons utiliser les condensats LM NTLM de l'utilisateur pour effectuer cette énumération. De mon expérience, il arrive que le module smb_enumshares n'arrive pas à identifier correctement les partages Windows. Il peut être intéressant de corroborer les résultats avec un autre outil tel que Network Scanner [NETSCAN].

Quelles sont les informations que l'on souhaite obtenir dans ces répertoires :

• des fichiers intéressants d’un point de vue business ;
• des fichiers contenant des mots de passe ;
• des dossiers racines d’application web accessibles en écriture ;
• des scripts d'administration ;
• …

Par la suite, si l'on arrive à récupérer un compte sur le domaine Windows, on peut lancer les modules smb_enumusers et smb_enumusers_domain pour énumérer les comptes locaux et comptes de domaine respectivement. La découverte de ces nouveaux comptes nous permettra d'effectuer, par la suite, une attaque par bruteforce. On pourra par exemple utiliser le module smb_login.

2.2 Exploitation de vulnérabilités connues

L'application des correctifs de sécurité reste une tâche encore aujourd'hui difficile à mettre en place de manière régulière sur l'ensemble des actifs d'un domaine. En général, les postes sont à jour et il est rare de trouver une vieille vulnérabilité sur ces actifs. Tandis que pour les serveurs, on trouve un écart assez significatif.

En 2016, sur un domaine Windows, on retrouve au moins un équipement ne disposant pas du correctif MS08-067. Pour rappel, le ver Conficker avait exploité cette vulnérabilité fin 2008 et début 2009. L'exploitation de cette vulnérabilité permet de prendre le contrôle du poste à distance avec les droits SYSTEM.

À l'aide de l'outil Nmap, on peut effectuer un scan sur son réseau afin d'identifier rapidement si un équipement ne dispose pas de ce correctif voire même si le poste est infecté par Conficker :

Par la suite, il nous suffit de dégainer Metasploit et d'utiliser l'exploit ms08_067_netapi :

Avant de lancer l'exploit, il est possible de faire une vérification à l'aide de la commande check afin de s'assurer que l'exploitation est possible sur la cible. Il est à noter que cet exploit peut parfois faire crasher l'équipement. Enfin, avec la commande exploit, nous serons en mesure d'obtenir un accès distant avec les droits SYSTEM sur l'équipement. C'est le quick win parfait, car facile à détecter et facilement exploitable avec Metasploit.

2.3 Microsoft SQL Server : compte « sa » disposant d'un mot de passe faible

Les bases de données sont une cible intéressante lors d'un test d'intrusion interne en raison des données qu'elles peuvent contenir. L'utilisation de comptes par défaut ou disposant d'un mot de passe faible est encore monnaie courante sur ce type d'actifs.

Les bases de données Microsoft SQL Server (MSSQL) sont une cible de choix. En effet, si nous réussissons à retrouver le mot de passe du compte « sa », nous pourrons par la suite utiliser les privilèges de cet utilisateur afin de rebondir sur le système d'exploitation.

Tout d'abord, nous pouvons identifier les bases de données MSSQL à l'aide de Nmap (par défaut, le port d'écoute est TCP / 1433) :

Ensuite, nous effectuons une attaque par bruteforce sur le compte « sa » pour chaque base de données à l'aide du module mssql_login de Metasploit.

Le trio gagnant en ce qui concerne le mot de passe et qui fonctionnera au moins pour une base de données sur le réseau (d'après mon expérience) est : sa, password et <vide>.

Bien sûr, il est possible de fournir un dictionnaire plus important, mais pour une passe rapide sur un grand réseau, ce trio devrait donner des résultats satisfaisants.

Enfin, si nous découvrons un compte « sa » valide, nous pouvons utiliser le module mssql_payload afin d'exécuter un meterpreter sur la machine. Il nous suffit de renseigner le compte de la base MSSQL et l'adresse IP de la machine vulnérable.

Il est également possible d'utiliser un autre module nommé mssql_exec afin d'exécuter des commandes sur le système, par exemple pour créer un compte local disposant des droits d'administration. Cela nous permettra de nous reconnecter sur l'équipement via un autre moyen, par exemple le Bureau à distance ou via  l'utilitaire PsExec. De plus, avec cette technique, nous évitons la détection du payload Metasploit par un antivirus.

Et voilà ! Avec ces 2 façons de faire, nous sommes en mesure d'obtenir les privilèges les plus élevés sur l'équipement.

2.4 Serveurs d'application JBoss et Tomcat

De plus en plus, on retrouve des serveurs d'application utilisés dans le cadre de développements internes ou lors de l'utilisation de certains produits open source ou propriétaires. En général, on constate que la configuration de ces serveurs est laissée par défaut et on se retrouve ainsi avec des comptes par défaut ou des interfaces d'administration accessibles sans aucune authentification.

Dans le cas du service Apache Tomcat, on procède de manière similaire à MSSQL. Tout d'abord, on effectue  une attaque par bruteforce via le module tomcat_mgr_login. Par défaut, on retrouve une instance Tomcat sur le port 8080 ou le port 80. Bien entendu, l'administrateur est libre de mettre en écoute l'instance Tomcat sur n'importe quel port (8888, 8443, 8181, 83, etc.).

Les comptes que l'on rencontre le plus souvent sont : admin/admin, tomcat/admin, tomcat/tomcat, admin/tomcat et tomcat/s3cr3t. Si vous ne trouvez pas une instance disposant de l'un de ces comptes, vous pouvez laisser les options par défaut de ce module et juste spécifier la plage d'équipements à tester. En effet, les dictionnaires fournis par Metasploit sont suffisants pour identifier des comptes par défaut ou avec des mots de passe faibles.

Ensuite, lorsque vous aurez identifié un compte sur une instance Tomcat, il vous suffira d'utiliser le module tomcat_mgr_deploy pour installer une application WAR afin d'exécuter des commandes sur le serveur.

Pour les versions de JBoss 4.3 [REDHAT], un défaut de configuration permet de contourner l'authentification mise en place sur l'interface jmx-console [JBOSS]. En effet, l'authentification est assurée uniquement pour les requêtes HTTP GET et POST. Le module jboss_vulnscan permet d'identifier les instances JBoss vulnérables. Par défaut, ce module utilise la méthode HTTP HEAD pour contourner l'authentification, il est possible de le changer si nécessaire.

Par la suite, tout comme pour Tomcat, nous pouvons utiliser le module jboss_bshdeployer pour déployer une application WAR malveillante nous permettant d'exécuter des commandes sur le système.

En fonction des droits d'exécution de JBoss et Tomcat, nous aurons plus ou moins de privilèges sur l'équipement. En pratique, on constate que sur des systèmes Windows, les services JBoss et Tomcat sont lancés avec les droits SYSTEM.

2.5 Pass the Hash

L'attaque Pass the Hash est une attaque connue depuis longtemps et qui reste fonctionnelle sur les versions de Windows récentes. Le concept est simple, lors d'une authentification Windows, les condensats LM et NTLM sont utilisés afin d'identifier l'utilisateur.

Concrètement, lors de la compromission d'un poste de travail ou d'un serveur, la récupération des condensats LM et NTLM suffit pour s'authentifier sur d'autres équipements ou services. Il n'est donc pas nécessaire de les « casser » afin d'obtenir un accès sur d'autres services.

Si nous reprenons les exemples présentés dans cet article, nous pouvons utiliser un défaut de mise à jour (MS08-067), un compte sa disposant d'un mot de passe faible ou d'une instance JBoss sans authentification pour prendre le contrôle d'un équipement Windows. Si nous disposons des droits SYSTEM ou d'administration sur l'équipement, nous pouvons extraire les condensats des comptes locaux sur l'équipement qui sont dans la base SAM. Voici un exemple à l'aide de meterpreter en utilisant le script smart_hashdump.

Sur un réseau interne, on constate généralement que l'administrateur local est identique sur l'ensemble des machines du réseau ou sur une grande partie, c'est-à-dire que le même mot de passe est réutilisé pour ce compte et sur différentes machines [WINDOWS].

Dans notre exemple, on peut utiliser le compte Administrator afin de nous reconnecter sur d'autres équipements. Pour cela, le module psexec peut être utilisé afin de réaliser l'attaque Pass the Hash et ainsi réutiliser les condensats récupérés.

Enfin, il est possible d'utiliser Mimikatz [GENTILKIWI] afin de récupérer les mots de passe en clair des utilisateurs connectés sur l'équipement (comptes de domaine et comptes locaux).

Conclusion

Lors d'un test d'intrusion interne, dans plus de 90% des cas, un attaquant est en mesure de compromettre l'ensemble du réseau et obtenir les droits d'administration sur le domaine. Cet article avait pour objectif de vous présenter les quick wins qui permettent rapidement de compromettre un domaine Windows à l'aide de Metasploit et que l'on retrouve habituellement dans un réseau interne.

Pour aller plus loin, il est nécessaire d'adopter des techniques d'évasion pour rendre les payloads d'exécution de Metasploit non détectables par les antivirus. En effet, à l'heure actuelle, si vous lancez les modules d'exploitation par défaut, ils sont tous identifiés et bloqués par les antivirus. Il est possible d'utiliser différentes techniques pour rendre les binaires non détectables, notamment le framework Veil Evasion [VEIL] ou bien de voir les solutions proposées par l'autre article dans cet hors-série.

De plus, cet article n'aborde pas également les techniques de post-exploitation présentées également dans cet hors-série.

Remerciements

Je tiens à remercier Marc Lebrun et Emilien Gaspar pour la relecture attentive.

Références

[NETSCAN] https://www.softperfect.com/products/networkscanner/

[REDHAT] https://rhn.redhat.com/errata/RHSA-2010-0379.html

[JBOSS] http://blog.mindedsecurity.com/2010/04/good-bye-critical-jboss-0day.html

[WINDOWS] https://www.ossir.org/jssi/jssi2014/JSSI_2014__Solucom_WinSec_vf.pdf

[GENTILKIWI] http://blog.gentilkiwi.com/mimikatz

[VEIL] https://www.veil-framework.com/framework/veil-evasion/