Vulnlab - Reflection
Reflection est un chaîne composée de 3 machines Windows : MS01 , WS01 et DC01. L’accès initial se fait à partir d’un accès SMB à MS01 qui permet de trouver des identifiants pour accéder à une base de donnée MSSQL. Ces derniers permettent de récupérer le compte de service de la base de donnée et d’accéder avec une attaque NTLM Relay au partage prod du DC qui contient les identifiants du compte abbie.smith un compte du domaine. Comme ce compte possède le droit GenericAll sur MS01, cela permet de lire le mot de passe LAPS et de récupérer les identifiants du compte Georgia.Price sur la machine. Ce compte possède le droit GenericAll sur WS01 ce qui permet de compromettre la machine avec une attaque RCBD et de récupérer les identifiants de Rhys.Garner qui sont réutilisés pour le compte DOM_RGARNER, un compte administrateur du domaine.
Accès BDD
Pour commencer, j’ai commencé par lancer un scan nxc afin d’identifier les machines sur le domaine ce qui m’a permis de constater qu’aucune des machines n’avait SMBv1 et la signature activée
Par la suite, j’ai remarqué que le compte guest n’était pas désactivé sur MS01 et que ce dernier avait des droits en lecture sur le partage staging.
En SMB, lorsque l’on essaie de s’authentifier avec un compte du domaine, si l’authentification échoue, SMB tente automatique de s’authentifier avec un compte local avec le même nom qui dans notre cas est le compte guest.
Lorsque l’on tente de s’authentifier avec un utilisateur qui n’existe pas, la machine nous attribut automatiquement le compte guest s’il est activé.
Ainsi, l’utilisation du compte guest m’a permis d’accéder aux partages de la machine et de récupérer des identifiants d’une base de donnée.
1 | └─$ impacket-smbclient reflection.vl/guest:''@10.10.240.86 |
Avec sqsh (ou impacket-mssqlclient), on peut accèder à la base de donnée
1 | sqsh -S 10.10.240.86 -U web_staging -P 'Washroom510' |
Dans cette BDD, on retrouve des identifiants mais après vérification, aucun d’entre eux n’est valide.
MSSQL Coercition
Avec les identifiants récupéré précédemment, j’ai alors essayé de faire de la coercion avec mssql.
Ce type d’attaque exploite certaines procédures système qui permettent à un serveur SQL d’accèder à des chemins UNC (partages réseau) sur une autre machine.
En effet, SQL Server possède plusieurs procédures comme :
- xp_dirtree
- xp_fileexist
- xp_subdirs
Ces procédures servent àlister des dossiersouvérifier l'existence de fichiers. Ainsi, si on leur fournit un chemin UNC d’un partage réseau, on peut récupérer le hash NTLMv2 du mot de passe du compte de service utilisé par la BDD.
Pour réaliser cela, on peut utiliser le module mssql_coerce de nxc :
1 | ┌──(kali㉿kali)-[~/ctf/vulnlab/reflection] |
Avec ntlmrelayx, on peut relayer l’authentification vers les autres serveurs et obtenir un sock SMB
Récupération de comptes du domaine
Avec les socks établit grâce à l’attaque précédente, j’ai pu lister les partages des autres machines du réseau et j’ai découvert que j’avais des droits en lecture sur le partage prod du DC.
J’ai donc pu accéder à ce partage et récupérer d’autres identifiants de BDD
Cela m’a permis d’accéder à la base de donnée sur le DC et de récupérer des identifiants.
Après vérification, ces identifiants sont ceux de deux comptes du domaine.
LAPS Password
Ensuite, j’ai utilisé les comptes du domaine récupéré pour faire une cartographie du domaine avec bloodhound. J’ai alors identifié que le compte Abbie.smith possédait des droits GenericAll sur la machine MS01. En revanche, comme on ne contrôle pas de compte avec SPN, impossible de faire une attaque RCBD.
En continuant l’analyse du bloodhoun, on peut remarquer que la machine MS01 utilise LAPS.
Comme le compte que l’on controle à le droit de lire n’importe quel attribut du compte machine de MS01, on peut récupérer le mot de passe du compte adminitrateur de la machine en lisant l’attribue ms-MCS-AdmPwd.
Ainsi, cela m’a permis de compromettre la machine.
Enumération de MS01
Par la suite, avec le compte administrateur, j’ai accédé en RDP à la machine et j’ai lancé mimikatz.
J’ai commencé par élevé mes privilèges pour avoir les droits complets sur la machine.
1 | mimikatz # token::elevate |
Ensuite, j’ai listé les mots de passe stockés dans les vault ce qui m’a permis de récupérer le mot de passe du compte georgia.price, un compte utilisé dans une tâche planifiée.
1 | vault::cred /patch |
RCBD attaque
Ensuite, j’ai analysé les droits du compte que je venais de compromettre et j’ai identifié que ce compte avait des droits GenericAll sur WS01.
Ainsi, avec ces droits, j’ai pu faire une attaque RCBD en commencent par ajouter MS01 à la liste de confiance de WS01
1 | impacket-rbcd -delegate-from 'MS01$' -delegate-to 'WS01$' -action 'write' 'reflection.vl/georgia.price:DBl+5MPkpJg5id' -dc-ip 10.10.128.21 |
J’ai alors pu récupérer un ticket me permettant de me faire passer pour l’administrateur du domaine sur la machine WS01
1 | ┌──(kali㉿kali)-[~/ctf/vulnlab/reflection] |
Après avoir importer le ticket à ma session, j’ai pu compromettre la 2ième machine
1 | ┌──(kali㉿kali)-[~/ctf/vulnlab/reflection] |
Password Spraying
Avec l’accès administrateur récupéré, j’ai pu extraire la base LSA de la machine et récupérer le mot de passe du compte Rhys.Garner
J’ai ensuite fait du password spraying sur tous les comptes du domaine ce qui m’a permis d’identifier que le mot de passe récupéré était réutilisé pour le compte dom_ragner, un compte administrateur du domaine.
