Hack The Box – Résoudre la box Manager : outils, méthodes et recommandations pour se protéger
mercredi 20 mars 2024 à 10:00I. Présentation
Dans cet article, je vous propose la résolution de la machine Hack The Box Manager, de difficulté "Medium".
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/attaques abordées | Windows, Kerberos, Active Directory, Brute force, MSSQL, AD-CS |
| Outils utilisés | nmap, kerbrute, impacket, evil-winrm, certipy |
Retrouvez tous nos articles Hack The Box via ce lien :
II. Résolution de la box Manager
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 --max-retries 1 -T4 -sS -A -v --open -p- 10.10.11.236
Nmap scan report for 10.10.11.236
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
|_http-title: Manager
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2023-10-25 18:44:02Z)
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: manager.htb0., 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 ssl/ldap Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
1433/tcp open ms-sql-s Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-info:
| 10.10.11.236:1433:
| Version:
| name: Microsoft SQL Server 2019 RTM
| number: 15.00.2000.00
| Product: Microsoft SQL Server 2019
| Service pack level: RTM
| Post-SP patches applied: false
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp open mc-nmf .NET Message FramingNous voyons ici clairement que nous sommes sur un système d'exploitation Windows sans pare-feu. Nous pouvons également comprendre, grâce aux ports exposés, qu'il s'agit d'un Active Directory. Les Active Directory sont quasiment les seuls systèmes à exposer un service Kerberos (port TCP/88), un service DNS (TCP/53) ainsi que les services RPC et SMB habituels (TCP/135, TCP/139 et TCP/445). Nous voyons également un service de base de données MSSQL sur le port TCP/1433, beaucoup moins commun sur un Active Directory.
Technique d'attaque (MITRE ATT&CK) : T1087.002 - Account Discovery: Domain Account
Un annuaire Active Directory est une cible des plus intéressantes pour un attaquant, c'est LA cible principale puisque sa compromission nous donne accès aux clés du domaine (littéralement). Problème ici, nous n'avons aucun identifiant valide et toutes nos tentatives de trouver une CVE ou un service mal configuré avec un accès anonyme se sont soldées par un échec. Nous allons devoir y aller "à l'aveugle" grâce à une fonctionnalité (et non pas une vulnérabilité) du service Kerberos : l'authentification (AS-REQ).
Lorsqu'un utilisateur souhaite interagir avec le service Kerberos de notre AD, il doit au préalable être authentifié (sauf cas spécifiques avec l'attribut DONT_REQ_PREAUTH, bref). Il se trouve que le service Kerberos permet, nativement, l'énumération des utilisateurs lors de la phase d'authentification (c'est-à-dire avant authentification). Voyons cela de plus près :
Dans la trace réseau ci-dessus, j’envoie un paquet de type "AS_REQ" (Authentication Service Request) au service Kerberos ciblé. Celui-ci me répond avec un message "KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN" (Client not found in Kerberos database). Plutôt explicite, le nom d'utilisateur spécifié n'est pas reconnu par le service Kerberos, il n'existe pas. Voyons ce que cela donne avec un nom d'utilisateur qui existe forcément dans un Active Directory : administrator/administrateur :
La réponse est différente. Nous ne sommes certes pas authentifiés, mais nous avons obtenu une information : le compte administrator existe au sein de l'Active Directory et le service Kerberos nous l'indique indirectement par un changement dans sa réponse.
Nous venons ici de voir ce qu'est une énumération d'utilisateur. Beaucoup plus commune au sein des applications web, l'attaquant est en mesure de savoir, sans être authentifié, si un login utilisateur existe ou n'existe pas. Cela en exploitant un comportement "binaire" du service interrogé qui peut être un message d'erreur, mais aussi un temps de réponse différent.
On ne fait pas grand chose avec cette information, mais l'authentification reposant sur un login et un mot de passe, nous avons ici déjà 50% de l'information à découvrir. Avec du temps et un bon dictionnaire, nous pourrons obtenir une liste de comptes valides, qui deviendront alors des cibles pour nos prochaines attaques.
Cette "faiblesse" est très connue des attaquants et son exploitation est implémentée dans de très nombreux outils visant les Active Directory. Ici, nous allons utiliser l'outil "kerbrute", il se démarque notamment par sa rapidité :
[user@kali-user:/opt/statistically-likely-usernames$ kerbrute userenum -d manager.htb --dc 10.10.11.236 service-accounts.txt -o kerbrute_validUsers_service.txt
2023/10/25 14:20:17 > [+] VALID USERNAME: administrator@manager.htb
2023/10/25 14:20:17 > [+] VALID USERNAME: guest@manager.htb
2023/10/25 14:20:17 > [+] VALID USERNAME: operator@manager.htb]()Je vous dois ici quelques explications. Tout d'abord, le domaine "manager.htb", d’où sort-il ? Nous l'avons en fait obtenu grâce à "nmap" et ses premières opérations d'énumération. Le nom de domaine est divulgué à dessein par l'Active Directory et ses services DNS et LDAP, comment s'authentifier auprès de lui sinon ?
Également, le dictionnaire que j'utilise ici est "service-accounts.txt". Elle provient de l'excellente ressource statistically-likely-usernames. Il s'agit d'une liste de nom (dictionnaires) contenant des noms utilisateur qui, statistiquement, ont de grandes chances de se retrouver dans un Active Directory. Il peut s'agir de nom de services, de noms utilisés pour des tests ou de noms "communs", comme John Smith, Eric Dupont, etc. Encore mieux, les différents dictionnaires proposés sont formatés en fonction des nomenclatures les plus communes. Pour John Smith, on trouvera par exemple le login "john.smith", "j.smith", "jsmith", "john.s". Le seul problème de cette ressource est qu'elle contient majoritairement des noms anglais.
Bref, grâce à "kerbrute", qui a exploité l'énumération utilisateur via l'"AS_REQ" Kerberos et une liste de nom de service statistiquement probable, nous parvenons à identifier le compte "operator".
B. Mot de passe faible et MSSQL
Je renseigne les noms des utilisateurs trouvés dans une liste que je pourrais réutiliser ensuite :
echo "operator" > logins.txt
echo "guest" > logins.txt
echo "administrator" > logins.txtIl nous faut à présent trouver le mot de passe correspondant à ce compte. Nous allons utiliser "netexec" pour effectuer une authentification via SMB en utilisant les logins identifiés :
Technique d'attaque (MITRE ATT&CK) : T1110.001 - Brute Force: Password Guessing
$ netexec smb 10.10.11.236 -u logins.txt -p logins.txt --no-bruteforce
SMB 10.10.11.236 445 DC01 [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.236 445 DC01 [+] manager.htb\operator:operator Ici, nous allons utiliser notre liste de login à la fois comme entrée du paramètre "-u" (username) et "-p" (password). Avec l'option "--no-bruteforce", l'outil saura que l'on souhaite faire une attaque de type user as pass. Autrement dit, tenter une seule authentification par compte, avec comme mot de passe login utilisateur.
Dans un contexte réaliste, il faut être très vigilant lors de la réalisation d'une authentification avec un compte utilisateur. La réalisation de quelques tentatives d'authentification infructueuses peut bloquer le compte utilisateur pendant plusieurs minutes et perturber un service ou l'activité de l’utilisateur. Avant toute opération, il est nécessaire au minimum de connaitre la politique de mot de passe et de verrouillage en place. La difficulté principale étant que cet élément n'est récupérable qu'en étant authentifié.
Via une attaque de type user as pass, nous sommes sûrs de réaliser qu'une seule tentative d'authentification par compte, les chances de verrouillage sont donc bien moindres.
Notre attaque nous a permis de découvrir que le compte "operator" utilise également "operator" comme mot de passe. Cela est loin d'être rare dans un contexte réalise et c'est d'autant plus le cas pour les comptes non nominatifs comme les comptes de tests ou de service ("formation", "scan", "accueil", "test2023", etc.).
Nous sommes à présent authentifiés sur le domaine ! Il s'agit d'une grande avancée puisque cela nous permet de récupérer un (très) grand nombre d'informations à propos de celui et des différents objets qu'il gère. Nous allons à présent tenter de nous authentifier avec ce compte sur tous les services exposés par le système cible :
Technique d'attaque (MITRE ATT&CK) : T1021 - Remote Services
$ impacket-mssqlclient -windows-auth operator:operator@10.10.11.236
SQL (MANAGER\Operator guest@master)>Succès ! Nous avons donc découvert un compte utilisateur du domaine qui a la permission de s'authentifier sur le service de base de données MSSQL. À partir de cet accès, tentons de découvrir les possibilités qui s'offrent à nous. Exploitation d'une version obsolète, vol de données sensibles, exécution de commande ?
Technique d'attaque (MITRE ATT&CK) : T1505.001 - Server Software Component: SQL Stored Procedures
Après plusieurs tentatives d'énumération, je découvre notamment que beaucoup d'instruction permettant classiquement l'exécution de commande ne sont pas autorisées pour mon utilisateur. Une exception apparait cependant parmi les nombreux cas d'usage de ma todo-list: "EXEC xp_dirtree" :
SQL (MANAGER\Operator guest@master)> select @@version;
Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64)
Sep 24 2019 13:48:23
Copyright (C) 2019 Microsoft Corporation
Express Edition (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor)
SQL (MANAGER\Operatorest@master)> EXEC xp_dirtree 'C:\inetpub\wwwroot', 1, 1Cette commande permet de lister le contenu d'un répertoire du système :
Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery
about.html
contact.html
css
images
index.html
js
service.html
web.config
website-backup-27-07-23-old.zipDans le résultat du listing du contenu du répertoire web, on découvre notamment une archive ZIP oubliée (un cas bien plus classique que l'on pourrait le croire). Cela signifie que cette archive est téléchargeable depuis le service web exposé, il suffisait de trouver son nom, ce qui est chose faite à présent.
Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files
$ wget http://10.10.11.236/website-backup-27-07-23-old.zip
$ unzip website-backup-27-07-23-old.zip
$ cat .old-conf.xml
[...]
<user>raven@manager.htb</user>
<password>R4v3nBe5tD3veloP3r!123</password>À l'intérieur de l'archive se trouve notamment un fichier XML contenant des identifiants utilisateur. Encore une fois, il va être important ici de tenter ces identifiants sur tous les services exposés. Il peut s'agir d'un compte ayant des droits d'accès à un nouveau partage SMB, ou au service MSSQL avec l'accès à des commandes ou base de données supplémentaires, etc.
Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management
$ evil-winrm -i 10.10.11.236 -u raven -p 'R4v3nBe5tD3veloP3r!123'
*Evil-WinRM* PS C:\Users\Raven\Desktop> type user.txt
14895a[REDACTED]5846a502Cet utilisateur nous permet l'accès au service WinRM du système !
L'accès au service WinRM est le résultat de l'assignation de permissions spécifiques à cet utilisateur ou de l'appartenance à un groupe de permissions (généralement Remote Management Users). Lors d'une intrusion, l'attaquant cherchera à cibler des utilisateurs avec ce genre de permissions spéciales, car ils seront certains d'obtenir par la suite un accès interactif à des systèmes.
C. ADCS : Manipulation des certificats
Parmi la très longue liste des éléments à étudier pour un attaquant lorsqu'il parvient à obtenir un accès authentifié à un domaine Active Directory figure les templates de certificats et la configuration du service ADCS. De nombreuses attaques et outils d'exploitation ont été rendus publiques en 2021 par SpectorOps à ce sujet.
Active Directory Certificate Services est un service Windows Server facilitant la création, la distribution et la gestion de certificats numériques. Les certificats générés par ADCS sont utilisés pour sécuriser les communications en chiffrant les données, authentifier les utilisateurs, garantir l'intégrité des données, permettre des connexions sécurisées au sein du domaine, etc.
Il s'agit tout simplement de la PKI (Public Key Infrastructure) de votre domaine, en gardant à l'esprit qu'un certificat permet également l'authentification, il s'agit d'une cible de choix pour un attaquant.
Nous pouvons commencer par nous assurer qu'un service ADCS existe bien sur le domaine cible, cela à distance depuis Linux à l'aide de l'outil "netexec" :
Ici, "netexec" nous confirme bien que le serveur "DC01.manager.htb" est également le service ADCS du domaine. À présent, nous pouvons tenter d'énumérer les templates de certificats existants au sein de ce service. L'ADCS permet l'émission de certificats avec des paramètres pré-définis grâce à des objets AD appelés template, ou modèles de certificat. Ces templates sont des ensembles de politiques d'inscription et de paramètres de certificat qui contiennent des informations telles que l'usage pouvant être fait du certificat, son temps de validité, qui peut demander la génération d'un certificat, pour quel type d'objet, etc.
Vous pouvez voir la gestion, création et détention d'un certificat comme le cas des badges d'accès dans un bâtiment sécurisé. Les agents d'accueil peuvent créer des badges pour des visiteurs ? Mais peut-être pas pour tous les étages ? Existe-t-il une borne de self-enrollement pour tous les visiteurs ? À quels étages peuvent-ils eux-mêmes se donner accès ? Est-ce qu'un agent d'accueil peut se créer un badge au nom du PDG ? Qui génère le badge des agents d'accueil ? Toutes ces questions peuvent être mises en parallèle avec les attaques sur ADCS.
L'outil "Certipy" peut notamment être utilisé pour découvrir ces configurations de templates, exemple :
pip3 install certipy-ad
certipy-ad find -u 'raven@manager.htb' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -stdoutVoici un extrait du résultat de la commande "certipy-ad" :
L'outil nous a permis de lister la configuration de 33 templates, dont 11 activés. Nous voyons ensuite un bout de la configuration de l'autorité de certification. Entre autres, nous pouvons nous intéresser à la configuration du template 0, histoire de voir ce que cette configuration peut nous apprendre :
Ce template se nomme "KerberosAuthentication", nous voyons notamment que les certificats générés à l'aide de ce template peuvent être utilisés pour l'authentification client ("Client Authentication : True"), mais aussi pour l'authentification côté serveur ("Extended Key usage: Server Authentication") par exemple. La section "Permissions" nous intéresse particulièrement puisqu'elle permet de savoir qui peut utiliser ce template pour enroller (générer) un certificat. Ici, que des membres des groupes "administrateurs".
Si l'on revient au résultat initial, on peut constater que "certipy-ad" nous a indiqué avoir trouvé une configuration dangereuse lors de l'affichage de la configuration de l'autorité de certification :
Au travers l'analyse automatique de la configuration, il semble que l'attaque ESC7 soit exploitable sur ce service ADCS.
Le terme "ESC" fait ici référence à "Escalation". Il s'agit d'une nomenclature choisie par les SpecterOps pour identifier les différentes faiblesses de configuration, et donc attaques, liées à l'AD-CS. Il en existe aujourd'hui 14 (de ESC1 à ESC14 donc). Pour aller en détail sur chacune des exploitations, je vous oriente vers Hacktrickz
ESC7 est donc le cas d'une configuration trop permissive donnée à un utilisateur ou un groupe d'utilisateurs sur l'autorité de certification elle-même.
Comme tout objet AD, l'autorité de certification possède des ACL (Access-Controle List) afin de gérer les actions réalisables par d'autres objets (utilisateurs, groupes, ordinateurs, etc.). Les deux droits principaux ici sont le droit "ManageCA" (« Administrateur CA » ) et le droit "ManageCertificates" ( « Gestionnaire de certificats ».). Si un attaquant prend le contrôle d'un utilisateur qui possède ces droits (ici : "raven"), il pourra alors approuver les demandes de certificat en attente.
Technique d'attaque (MITRE ATT&CK) : T1649 - Steal or Forge Authentication Certificates
L'exploitation de cette vulnérabilité repose sur le fait que les utilisateurs disposant de ces droits peuvent émettre des demandes de certificat, qui, même s'ils échoueront dans un premier temps, pourrons ensuite être approuvés grâce au droit "ManageCertificates".
Le modèle de certificat "SubCA" est par défaut vulnérable à ESC1, mais seuls les administrateurs peuvent utiliser ce template dans le modèle. Ainsi, un utilisateur peut toujours demander à s'inscrire à la "SubCA", ce qui sera refusé. Nous obtiendrons alors notre demande "en attente", qui nous approuverons ensuite avec l'utilisateur compromis ("raven"), qui possède les droits "ManageCertificates".
L'attaque ESC1 est l'un des cas de figure les plus simples. Il concerne les templates qui autorisent la prise en compte de l'attribut SAN (Subject Alternative Name). Celui-ci permet tout simplement à l'utilisateur à définir, en plus de son nom, d'autres noms pour lesquels le certificat sera valide (à tout hasard, administrateur). L'utilisateur demande alors un certificat qui sera valide pour l'utilisateur demandeur (Mickael) mais il inclut dans sa demande un champ supplémentaire disant : le certificat que tu vas me signer sera aussi valide pour "administrateur".
La simplicité de l'attaque est parfois difficile à cerner ("c'est aussi bateau que ça ?") : la réponse est oui.
Voici les pré-requis de l'attaque :
Nous disposons déjà de la permission "ManageCA" grâce à l'utilisateur "raven". Nous pouvons alors nous ajouter les droits "Manage Certificates" (nous sommes maitres de l'autorité de certification, logique que nous puissions nous ajouter les droits de gérer les certificats) :
$ certipy-ad ca -ca 'manager-DC01-CA' -add-officer raven -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236
Certipy v4.7.0 - by Oliver Lyak (ly4k)
[*] Successfully added officer 'Raven' on 'manager-DC01-CA'Le pré-requis n°2 est également atteint, retournons dans notre énumération des templates pour voir si le pré-requis 3 l'est aussi (template "SubCA" activé) :
Tous nos prérequis sont là. Nous pouvons commencer par demander un certificat basé sur le template "SubCA". Cette demande sera refusée, nous ne sommes pas membres des groupes autorisés à s'enroller (regardez le contenu de l'attribut "Enrollment Permissions"). Mais, nous obtiendrons tout de même une clé privée (générée par nous-même, pour notre demande) et notre ID de demande (notez l'option "-upn" dans laquelle nous indiquons le SAN à ajouter au certificat) :
certipy-ad req -ns 10.10.11.236 -ca 'manager-DC01-CA' -template SubCA -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -upn administrator@manager.htb
Ici, nous venons de demander à l'autorité de certification la création d'un certificat pour l'utilisateur "administrator@manager.htb" (grâce à l'attribut SAN) en utilisant le template "SubCA". Vous noterez que bien que ce template soit activé, notre utilisateur ("raven") n'est pas membre des groupes autorisés à utiliser ce template. La demande est donc refusée. Avec nos permissions "ManageCA" et "ManageCertificates", nous pouvons ensuite approuver la demande de certificat ayant échoué avec la commande suivante :
$ certipy-ad ca -ca 'manager-DC01-CA' -issue-request 14 -u 'raven@manager.htb' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236
Certipy v4.7.0 - by Oliver Lyak (ly4k)
[*] Successfully issued certificateEt enfin, nous pouvons récupérer le certificat émis avec la commande "req" et le paramètre "-retrieve" :
certipy-ad req -ca 'manager-DC01-CA' -target dc01.manager.htb -template SubCA -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -retrieve 14
Nous pouvons à présent récupérer le hash NTLM de l'administrateur du domaine en utilisant ce certificat. Il faut pour cela demander un TGT via PKINIT (extension Kerberos prenant en compte les certificats), une fonctionnalité de "backup" y a été ajoutée pour permettre l'authentification sur les services/OS ne prenant pas en compte Kerberos.
Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management
Avec le hash du compte "administrator", nous pouvons effectuer une authentification via la technique pass-the-hash :
$ evil-winrm -i $IP -u administrator -H ae5064c2f62317332c88629e025924ef
*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt
42fabc6[REDACTED]0ff4dNous sommes désormais administrateur du contrôleur de domaine, nous avons les clés du royaume !
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 Discover | Réalisation d'un scan réseau via "nmap" et découverte de multiple services |
| T1087.002 - Account Discovery: Domain Account | Enumération d'utilisateur via "kerbrute" et la wordlist "statistically-likely-usernames" |
| T1110.001 - Brute Force: Password Guessing | Attaque "user as pass" sur les comptes du domaine découverts via "netexec", découverte d'identifiants valides |
| T1021 - Remote Services | Authentification sur le service MSSQL avec le compte "operator" compromis |
| T1505.001 - Server Software Component: SQL Stored Procedures | Exécution de commande partielle MSSQL |
| T1083 - File and Directory Discovery | Découverte des fichiers locaux du serveur Windows via MSSQL et exfiltration d'une archive ZIP depuis la racine du service web |
| T1552.001 - Unsecured Credentials: Credentials In Files | Découverte d'identifiants de l'utilisateur du domaine "raven" dans l'archive ZIP exfiltrée |
| T1021.006 - Remote Services: Windows Remote Management | Authentification via winRM et LDAP, puis découverte du service AD-CS via "Certipy" |
| T1649 - Steal or Forge Authentication Certificates | Utilisation de Ccertipy" pour forger un certificat valide pour le compte administrateur du domaine via ESC7, puis ESC1 |
| T1021.006 - Remote Services: Windows Remote Management | Authentification avec le compte administrateur du domaine |
IV. Notions abordées
A. Côté attaquant
Les premières étapes de compromission de ce serveur sont (hélas) très réalistes. Il est étonnant de voir que la plupart des vulnérabilités sur un domaine proviennent de négligences humaines. Ce genre d'attaque et d'énumération sont à ne jamais oublier sur un domaine. Il faut également savoir adapter ses dictionnaires (et plus largement ses outils) en fonction du contexte métier ou de la langue de la cible.
Nous avons vu lors de l'exploitation du service MSSQL que connaitre ou savoir se documenter rapidement sur les commandes et fonctionnalités natives qui permettent une exploitation est un atout. Ici la commande utilisée ("xp_dirtree") est totalement native à MSSQL, le fait le compte compromis puisse l'utiliser est une faiblesse probablement due à des droits trop permissifs, mais c'est ce qui nous a permis de compromettre le serveur. Sur chaque service de base de données, voir chaque version, il existe des commandes comme celles-ci qui permettent d'écrire ou lire des données sur le serveur, voire exécuter des commandes. Difficile de tout retenir, il faut plutôt opter pour une documentation personnelle ou une banque de liens externes pour être sûr de rester à jour et d'avoir tout sous la main lorsque l'on en aura besoin.
L'attaque sur ADCS est bien entendu ce qui vaut à cette box la notation "Medium" à mon sens. Il faut ici avoir de bonnes notions de l'aspect métier et fonctionnels d'une PKI pour ensuite comprendre l'attaque à réaliser. Cela nous permet de rappeler qu'avant d'apprendre à attaquer, il faut connaitre les bases de l'administration système, de la cryptographie et du développement. Également, il serait difficile de trouver ce genre de vulnérabilité sur un service aussi spécifique qu'ADCS seul sans y passer des dizaines d'heures. Les attaques sur ADCS ont été rendues publiques en 2021 et il fallait bien entendu assurer sa veille technologique afin d'inclure ses faiblesses dans notre méthodologie d'audit d'environnement AD. Pour la pratique, je vous conseille bien sûr cette box Hack the box, mais aussi le lab Try Hack Me suivant : AD Certificate Templates
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : il est recommandé de mettre en place une politique de mot de passe robuste interdisant notamment les mots de passe faibles avec un seul alphabet ou le "user as pass". L'application de cette recommandation doit notamment se baser sur le document Recommandations relatives à l'authentification multifacteur et aux mots de passe de l'ANSSI. Côté détection, il est recommandé de surveiller les journaux d'authentification pour détecter les échecs de connexion au niveau du domaine. Si les échecs d'authentification sont nombreux sur une courte période de temps, il peut y avoir une tentative de force brute en cours. Le centralisation des logs et l'utilisation d'un SIEM peuvent ici grandement aider.
Recommandation n°2 : nous pouvons également recommander de supprimer l'archive ZIP située à la racine du service web. Les archives contiennent souvent des données sensibles (configurations, mots de passe) et leur place n'est pas sur un service web accessible sans authentification. Il est recommandé de les stocker dans un emplacement sécurisé, accessible uniquement par des utilisateurs authentifiés. Pour aller plus loin, nous pouvons également recommander de stocker les archives de configuration et de code source de façon chiffrée et, en complément, de durcir la configuration du service web pour interdire l'accès aux fichiers de backup (.zip, .tar, etc.) directement dans la configuration Apache.
Recommandation n°3 : il peut être recommandé d'améliorer la sécurité du service ADCS. De multiples bonnes pratiques existent à ce sujet, mais doit en premier lieu être effectuée une revue des ACL sur les templates de certificats et sur l'autorité de certification afin de s'assurer que seuls des groupes légitimes sont autorisés à y effectuer des actions sensibles. De manière générale, il est d'ailleurs toujours recommandé de passer par des groupes pour l'attribution des droits que l'attribution directe à un utilisateur.
Recommandation n°4 : il est recommandé d'appliquer une séparation stricte des usages sur les services du système d'information. Les services de base de données et de gestion des certificats répondent à des fonctions métiers et de sécurité différents et doivent être positionnés sur des serveurs distincts. Cela afin de rendre plus difficile pour un attaquant la propagation de sa compromission d'un service à l'autre. Pour aller plus loin, il est recommandé de consulter le document La défense en profondeur appliquée aux systèmes d’information de l'ANSSI. (Soyons francs, cette recommandation est plutôt pour le principe, les services sont ici mutualisés sur un même serveur, car Hack The Box ne propose qu'une machine à la fois :D. Mais consultez quand même ce document, très intéressant ! ).
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 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
The post Hack The Box – Résoudre la box Manager : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.