HTB – Manager – Windows (Medium)

Pour cette machine, il s’agira d’un contrôleur de domaine Windows utilisant un Active Directory avec MSSQL et quelques exploitations ADCS, ce qui s’est avéré très instructif.

Comme d’habitude, nous pouvons commencer par scanner notre cible à l’aide de nmap afin d’obtenir une liste des ports ouverts sur la machine cible.

Comme on peut s’y attendre sur une machine Windows, plusieurs ports sont ouverts, mais certains semblent particulièrement importants dans ce cas précis :

– Port 80 : nous avons un site web qui fonctionne avec Microsoft IIS httpd version 10.0
– Port 88 : Microsoft Windows Kerberos en cours d’exécution
– Port 445 : un service SMB
– Port 1433 : un serveur Microsoft SQL

Nous avons également :

– Un nom de domaine : manager.htb
– Un nom d’ordinateur : DC01

Comme c’est désormais la coutume, notre première étape consiste à ajouter le nom de domaine à notre fichier /etc/hosts.

Nous commençons par jeter un œil au site web, car même s’il n’y a pas de point d’entrée, il n’est pas rare d’obtenir des informations supplémentaires sur la cible. Nous pourrions tomber sur des noms, des adresses e-mail ou toute autre donnée qui pourrait s’avérer utile par la suite. Ici, le site web ne nous a pas été utile et nous n’avons découvert aucun sous-domaine ni dossier caché, retour au SMB.

La prochaine cible potentiellement intéressante que l’on va énumérer est le service SMB, mais nous devons d’abord nous assurer que nous pouvons y accéder.

Le résultat obtenu confirme nos données précédentes issues de nmap concernant le domaine et le nom de l’ordinateur. Il s’agit d’un contrôleur de domaine avec les informations suivantes :

– La version du système d’exploitation : Windows 10.0 Build 17763 x64
– Le nom : DC01
– Un domaine : manager.htb

À partir de là, nous pouvons tenter d’effectuer quelques tâches : énumérer les utilisateurs, les réptertoires partagés ou “shares” et la politique de mot de passe. L’énumérer des utilisateurs n’a pas été un succès sans aucun accès et nous n’avons obtenu aucun résultat ne voulant pas recourir à une attaque par force brute.

Comme nous n’avons obtenu aucun résultat, nous pourrions essayer de brute forcer l’énuération des utilisateurs, mais essayons d’abord de connaitre la politique de mot de passe en place. Nous devons toujours procéder ainsi, car nous pourrions bloquer le compte des utilisateurs en essayant de nous connecter trop souvent avec un mot de passe invalide.

La commande précédente n’a donné aucun résultat, mais nous pouvons essayer autre chose pour obtenir une liste d’utilisateurs à l’aide de la commande suivante qui énumère les utilisateurs en forçant les RID.

Nous avons obtenu une liste d’utilisateurs, dont beaucoup sont des comptes par défaut, mais nous pouvons en voir d’autres plus intéressants. Cependant, nous devons d’abord créer une liste appropriée.

Nous pouvons maintenant faire un peu de ménage et ne conserver que cette liste d’utilisateurs potentiels :

Comme nous disposons d’une liste d’utilisateurs et d’aucun mot de passe, nous pouvons essayer le roasting AS-REP.

Une fois de plus notre tentative échoue car la pré-authentification n’est pas désactiver ce qui nous empêche de faire une demande de ticket. La prochaine étape consiste à essayer le « password spraying », en gardant à l’esprit que nous pouvons être bloqués ou verrouiller le compte d’un utilisateur si nous essayons trop de mots de passe. Par conséquent, nous n’essaierons qu’un seul mot de passe par utilisateur, en utilisant son propre identifiant comme mot de passe.

Parfait, nous avons 4 utilisateurs et mots de passe. Dans ce cas, j’essaie toujours de vérifier si nous pouvons obtenir un shell à l’aide de ces identifiants. Nous pourrions utiliser des outils comme psexec ou evil-winrm, mais pour que cela fonctionne, nous avons besoin d’un accès en écriture à certains répertoires SMB. Malheureusement, dans notre cas, nous ne disposons pas de ce droit, ce qui signifie que nous devons trouver autre chose.

Nous pouvons rediriger notre attention vers un autre service, MSSQL, et essayer certaines des informations d’identification obtenues précédemment. Nous avons obtenu un accès à l’aide du nom d’utilisateur et du mot de passe « operator ».

Il est temps de poursuivre l’énumération. Nous avons les noms des bases de données, les tables et les utilisateurs. Dans notre cas, nous sommes « guest », nous ne pourrons donc pas faire grand-chose avec nos droits limités. Nous commençons par vérifier si « xp_cmdshell » est disponible pour pouvons obtenir rapidement et facilement un shell.

Ce n’est pas le cas ici, nous ne pouvons pas non plus créer de fichier, mais nous pouvons répertorier le contenu de la machine à l’aide de xp_dirtree. Après quelques recherches, nous tombons sur le répertoire racine du site Web actuel hébergé sur la cible.

Il semble que nous ayons manqué une archive nommée « website-backup-27-07-23-old.zip » lors de notre énumération du site web. Cela semble prometteur, il est temps de télécharger l’archive et de l’inspecter.

Dans l’archive, nous découvrons un fichier de configuration nommé « .old-conf.xml » qui contient un mot de passe appartenant à l’utilisateur nommé Raven. Nous pouvons l’utiliser pour obtenir un shell sur notre cible.

La première étape est d’énumérer manuellement la machine avant de passer aux scripts automatisés. Recherchons l’historique Powershell afin de ne pas le compromettre avec nos propres commandes, puis de vérifier si un antivirus est en cours d’exécution. Ensuite, nous passons à une énumération plus approfondie de la machine et de notre utilisateur actuel :

– whoami /all : nous remarquons ici que notre utilisateur fait partie du BUILTINCertificate Service
– Examinez la version Windows pour rechercher une faille connue
– Autres utilisateurs et groupes, à partir desquels nous apprenons que seul l’utilisateur Administrator dispose des droits administrateur
– Commencez à énumérer les services
– Vérifiez les variables d’environnement
– Recherchez des extensions de fichiers spécifiques telles que .sql, .kdbx, .git, etc.
– Vérifier si il y a des tâches planifiées

N’ayant rien découvert permettant d’avancer significativement, nous passons à une méthode plus automatisée en utilisant winpeas, qui ne nous dit pas grand-chose de plus, mais nous voyons à nouveau ceci :

Les précédentes énumérations ne nous donnent pas de moyen d’éléver nos privilèges directement, mais la machine donne quelques indices qui pointent vers AD CS, il est donc temps de se renseigner à ce sujet. Pour résumer, AD CS est un rôle de serveur sous Windows Server qui permet de créer et gérer une infrastructure à clés publiques (PKI), c’est-à-dire des certificats numériques. Ces certificats servent à sécuriser les communications, chiffrer les données, signer des documents ou authentifier des utilisateurs, ordinateurs ou appareils sur un réseau.

Rappelez-vous que notre utilisateur a accès au service de certificats. Il existe peut-être un moyen d’exploiter cela et d’élever nos privilèges de cette manière.

Vous trouverez une description détaillée de toutes les attaques que vous pouvez mener contre AD CS sur HackTricks ainsi qu’un lien vers le livre blanc de la société Spectre Ops. Le livre blanc est assez long, mais vous trouverez un résumé intéressant des conclusions de l’équipe dans un article Medium.

Il existe un outil publié par les auteurs, appelé Certipy. Nous pouvons utiliser cet outil pour vérifier si notre cible est vulnérable à l’une de ces attaques, mais nous devons d’abord nous assurer que notre horloge est synchronisée avec le serveur afin d’éviter tout problème.

L’outil affiche les certificats et nous indique que la cible devrait être vulnérable à l’attaque ESC7 qui, si elle réussit, devrait nous donner les droits d’administrateur. Nous pouvons revenir au livre blanc et lire la description de l’attaque. D’après ce que j’ai compris (n’hésitez pas à me corriger), si un utilisateur dispose des autorisations ManageCA et ManageCertificates, il pourrait à distance :

– Autoriser une spécification SAN dans n’importe quel modèle à l’aide des droits ManageCA et demander un certificat, qui serait refusé car nous ne sommes pas administrateurs
– À l’aide des droits ManageCertificates, il peut ensuite soumettre à nouveau une demande de certificat spécifique en attente ou refusée à l’autorité de certification. Cela entraînerait l’approbation de la demande en attente ou refusée

Pour effectuer tout cela, trois conditions doivent être remplies :

– Avoir l’autorisation ManageCA
– Avoir l’autorisation Manage Certificates
– SubCA (modèle de certificat) doit être activé

L’astuce consiste à utiliser l’autorisation ManageCA pour s’octroyer l’autorisation Manage Certificates et activer SubCA.

Tout d’abord, nous nous accordons le droit d’accès « Gérer les certificats » en ajoutant notre utilisateur Raven en tant que nouvel agent, puisque nous disposons du droit « Gérer CA ».

Deuxièmement, nous activons « SubCA ».

De cette façon, nous pouvons désormais activer les modèles de certificats.

Nous avons désormais rempli les conditions préalables à cette attaque, l’étape suivante consiste à la mettre en œuvre. Nous commençons par demander un certificat basé sur le modèle « SubCA ». Il sera refusé, car nous ne disposons pas des droits d’administrateur, mais cela n’a pas d’importance, car nous allons tout de même obtenir une clé privée et un identifiant de demande que nous devons noter.

Ensuite, nous émettons la demande de certificat ayant échoué :

Enfin, nous pouvons obtenir le hachage NT de l’administrateur à l’aide du fichier .pfx pour demander un ticket TGT à Kerberos.

En tout cas, ce serait la théorie, car même si toutes les commandes étaient correctes lorsque j’ai essayé de les exécuter pour la première fois, elles ont échoué ! Pour être honnête, je ne sais pas vraiment pourquoi. Je n’ai vu aucun avertissement à ce sujet dans le livre blanc pour cette attaque spécifique, mais je peux me tromper. Voici mes hypothèses :

– Une situation de concurrence dans l’outil
– Un problème lié au timing d’accès aux certificats
– Il pourrait simplement s’agir de la machine Hack The Box qui effectue un nettoyage en arrière-plan, ce ne serait pas la première fois

Le problème se produisait à des moments aléatoires et pas à chaque fois avec la même ligne de commande, donc essayons de regrouper toutes ces commandes en une seule et de l’exécuter.

Étonnamment, ça a marché du premier coup cette fois-ci !

Nous n’obtenons pas le mot de passe administrateur, mais le hachage NT suffit pour effectuer une attaque « Pass The Hash », ce qui nous permet de nous connecter en tant qu’administrateur sur la machine.