HTB – Resolute – Windows (Medium)

Comme toujours, nous commençons par scanner notre cible pour voir les ports ouverts :

Ce scan nous a permis d’obtenir certaines informations sur le type de machine. Il s’agit d’une machine Windows nommée « Resolute » utilisant Kerberos. Nous avons également obtenu un nom de domaine : « megabank.local ».

Nous pouvons repérer certains ports ouverts intéressants :

– Kerberos sur le port 88
– Windows RPC sur le port 135
– SMB sur le port 445
– Windows Active Directory LDAP sur le port 3268.

Nous allons commencer par le partage SMB, mais dans ce cas, il n’y a pas beaucoup d’informations en dehors de la politique de mots de passe. Cette politique est néanmoins très utile, car elle indique le type de complexité de mot de passe appliqué et s’il y a un verrouillage des comptes en cas de trop nombreuses tentatives ratées. Nous ne voulons pas verrouiller un compte par erreur, nous devons donc garder cela à l’esprit.

L’étape suivante sera le RPC. Il est parfois possible de s’y connecter sans authentification et, ici, c’est effectivement le cas. De cette façon, nous pouvons extraire de nombreuses informations telles que les utilisateurs, les groupes et bien plus encore, commençons par créer une liste d’utilisateurs :

Nous pouvons répéter cette opération pour énumérer le nom de domaine, les groupes et bien plus encore, par exemple pour obtenir des informations plus détaillées sur un utilisateur spécifique. Ce faisant, nous tombons sur un mot de passe lié à l’utilisateur nommé Marko :

Il pourrait très bien s’agir du mot de passe par défaut attribué à chaque création de compte dans cet environnement puisque il est accompagné de la mention « Compte créé ». Nous pouvons essayer d’accéder au compte Marko, mais cela ne fonctionne pas, il semble que le mot de passe a été modifié depuis la création du compte. Pas d’inquiétude, nous pouvons essayer ce mot de passe pour tous les autres utilisateurs, peut-être que certains n’ont pas modifié leur mot de passe par défaut.

Il semble que Melanie utilise toujours le mot de passe par défaut. D’après l’énumération précédente, nous savons qu’elle fait partie du groupe Remote Management Users et qu’elle dispose d’un accès WinRM. Nous pouvons donc utiliser ses identifiants pour obtenir un accès initial à la machine.

Le compte ne dispose pas de droits ou privilèges spécifiques que nous pourrions exploiter pour obtenir davantage d’accès. Peu importe, lors de notre énumération sur la machine, nous avons trouvé un fichier dans un répertoire caché ayant un historique de commandes Powershell.

Ce fichier est très intéressant car il contient un autre mot de passe utilisé par l’utilisateur « Ryan » pour se connecter à un partage de sauvegarde.

Avec ce nouveau mot de passe, nous avons désormais accès à un nouveau compte avec de nouveaux privilèges et de nouveaux droits. Dans ce cas, Ryan fait partie du groupe « Contractors », qui contient lui-même le groupe « DNS Admins », ce qui signifie que nous avons accès et contrôle sur le DNS.

En tant que membre du groupe « DNS Admins », nous avons accès au service DNS, ce qui signifie que nous pouvons tenter d’en abuser en injectant une DLL dans le service lors de son démarrage. Pour ce faire, nous devons ajouter une clé de registre indiquant à notre DNS de rechercher notre DLL. Le service va démarrer en utilisant les droits « NT AUTHORITYSYSTEM » et nous en tirons parti pour exécuter notre propre code via la DLL et, dans ce cas, modifier le mot de passe administrateur.

Nous commençons par créer une DLL à injecter dynamiquement dans le processus :

Au début, j’ai essayé d’importer la DLL directement sur la machine locale, mais cela n’a pas fonctionné car elle a été détectée par Defender. À la place, nous avons pu utiliser un partage SMB distant pour charger la DLL et tenter d’échapper à la détection de cette manière. Nous allons procéder ainsi en hébergeant simplement le fichier sur notre propre partage SMB appelé « DNS » qui fonctionne sur notre propre machine locale.

Ensuite, nous ajoutons la clé de registre appropriée pour indiquer au service DNS d’utiliser notre DLL au démarrage du service :

Nous pouvons vérifier si la clé de registre a été correctement ajoutée :

Une fois que c’est confirmé, nous pouvons redémarrer le service DNS :

Nous pouvons voir que la machine Resolute s’est connectée à notre partage SMB pour extraire notre DLL et exécuter notre code.

Nous avons désormais le contrôle du compte « Administrateur », félicitations !