Investiguer sur une attaque Kerberoasting via ELK – Hack The Box Sherlocks : Campfire-1

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. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Campfire-1, de difficulté "débutant". Il s'agit d'investiguer sur les traces d'une cyberattaque ciblant un système d'exploitation Windows et un domaine AD.

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 des analystes en cybersécurité. Je vais ici vous détailler la marche à suivre en utilisant le langage KQL du SIEM ELK (ElasticSearch, Logstash, Kibana), cela vous permettra de voir son utilisation dans un contexte réaliste.

Lien du challenge : Hack The Box - Sherlocks - Campfire-1

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

Technologies abordées	Windows, EVTX, prefetch, Kerberos, Rubeus
Outils utilisés	ELK, KQL, PECmd

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Découverte de l'archive et des journaux

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

Nous sommes donc en charge de la réalisation d'une investigation numérique suite à la découverte par un utilisateur de fichiers étranges sur son poste. L'archive fournit contient quelques journaux provenant du contrôleur de domaine et du poste utilisateur au format ".evtx", ainsi que les fichiers prefetch du système concerné :

Pour traiter le contenu des fichiers .evtx efficacement, je les importe dans une instance ELK en suivant la procédure d'écrite dans notre tutoriel :

• IT-Connect - Importer un fichier .evtx dans ELK depuis Linux via Python

Attention, un piège à éviter lorsque l'on utilise cette astuce avec Kibana est la différence de timezone entre le système qui a produit les logs et le nôtre. Par défaut, Kibana va ajuster la timezone en fonction de celle de notre navigateur, ce qui va "fausser" les timestamps de notre analyse dans Kibana. Pour éviter cela, il faut se rendre, AVANT d'importer les logs, dans "Management > Advanced Settings > Time Zone" et, dans le contexte de l'exercice, la paramétrer à "UTC" :

Ici, c'est le "Z" de "2024-05-21T03:12:58.616418Z" dans les timestamps des logs fournit qui nous renseigne sur la timezone à utiliser :

Une fois cela fait, je peux très facilement effectuer des recherches en utilisant le langage KQL du SIEM ELK et visualiser les résultats :

Commençons à présent l'analyse en suivant ses différentes tâches.

III. Investigation numérique : le cas Campfire-1

A. Kerberoasting

• Enoncé - Task 1 : Analyzing Domain Controller Security Logs, can you confirm the date & time when the kerberoasting activity occurred?

Cette première question nous demande d'identifier la date et l'heure de l'attaque Kerberoasting. Pour rappel, cette attaque consiste à demander des TGS pour différents comptes de service du domaine à partir d'un TGT valide. L'attaquant, déjà authentifié, cherche à obtenir des TGS qui sont chiffrés avec un dérivé du mot de passe des SPN correspondants. Si ces mots de passe sont faibles, il tentera de casser le chiffrement des TGS pour obtenir le mot de passe des comptes de service associés. Lorsque l'algorithme de chiffrement RC4 est accepté et autorisé au niveau du KDC (Key Distribution Center), l'attaquant peut augmenter ses chances de succès en demandant un TGS chiffré en RC4 plutôt qu'en AES (cas par défaut).

Nous pouvons pour identifier cette attaque nous basant sur les traces qu'elle laisse classiquement dans les journaux, soit d'après la section "Detection" du T1558.003 :

• Un évènement 4769 relatif à une demande de création d'un TGS (Ticket Granting Service).
• Un chiffrement demandé à RC4 (0x17) souvent utilisé afin de réduire la robustesse de chiffrement du TGT (downgrade) et ainsi casser plus facilement le mot de passe associé.

Je cible également ma requête sur les logs produits par le contrôleur de domaine étant donné que c'est lui qui possède le rôle de KDC au sein d'un domaine. Voici ce que donne un filtre sur ces différents critères en KQL :

# Requête KQL pour identifier les attaques Kerberoast
Event.System.Computer: DC01.forela.local AND Event.System.EventID.#text: 4769 AND Event.EventData.Data.TicketEncryptionType :0x00000017

Nous parvenons grâce à cette requête à identifier précisément un évènement caractéristique d'une attaque Kerberoast :

Cette demande a été réalisée à 2024-05-21 03:18:09.

• Enoncé - Task 2 : What is the Service Name that was targeted?

Toujours à partir du même évènement, nous pouvons retrouver le "Service Name" pour qui a été faite la demande de TGS :

L'attaque par Kerberoasting a ciblé le SPN "MSSQLService".

• Enoncé - Task 3 : It is really important to identify the Workstation from which this activity occurred. What is the IP Address of the workstation?

Enfin, nous pouvons également identifier l'adresse IP ou le FQDN du poste qui a émis la demande, ce qui nous permettra d'en apprendre plus sur l'attaquant et son mode opératoire :

Ici, l'attaque a été réalisée depuis l'adresse IP 172.17.79.129.

B. Analyse de l'activité du poste utilisateur

• Enoncé Task 4 : Now that we have identified the workstation, a triage including PowerShell logs and Prefetch files are provided to you for some deeper insights so we can understand how this activity occurred on the endpoint. What is the name of the file used to Enumerate Active directory objects and possibly find Kerberoastable accounts in the network?

Nous devons ici trouver le nom d'un fichier qui a été utilisé par l'attaquant afin d'énumérer les objets de l'Active Directory. Si l'on regarde les journaux fournit (fichiers), qui ont également été importés dans ELK, on découvre que le Script Block Logging PowerShell a été activé avant l'attaque, cela nous permet donc d'avoir des informations précises sur toutes les commandes saisies grâce aux évènements 4104.

J'utilise la requête KQL pour récupérer ces évènements sur le poste utilisateur :

Event.System.Computer: Forela-Wkstn001.forela.local AND Event.System.EventID.#text: 4104

Pour en savoir plus sur le Script Block Logging PowerShell et les autres méthodes de journalisation des commandes PowerShell sous Windows, je vous propose notre article dédié à ce sujet :

• IT-Connect - PowerShell : activer la journalisation des commandes et scripts

Ensuite, j'utilise l'interface graphique de Kibana pour n'afficher que le contenu des attributs "timestamp", "Event.System.Computer" et enfin "Event.EventData.Data.Path" dans un tableau. Ce dernier attribut contient le chemin du script/binaire utilisé pour chaque commande saisie :

Cela nous permet de découvrir que le module offensif "powerview.ps1" a été utilisé par l'attaquant. Cette première requête KQL nous permet également de répondre à la question suivante.

• Enoncé - Task 5 : When was this script executed?

La première exécution a été journalisée à 2024-05-21 03:16:32.

• Enoncé - Task 6 : What is the full path of the tool used to perform the actual kerberoasting attack?

Un outil spécifique a été utilisé afin de réaliser l'attaque Kerberoast. Nous pouvons, pour retrouver les traces d'exécution d'un binaire sous Windows, nous baser sur les logs (Sysmon, notamment) mais aussi sur les fichiers prefetch.

Les fichiers prefectch sont des fichiers qui sont créés à chaque exécution d'un binaire sur le système. Ils sont stockés dans le dossier "C:\Windows\Prefetch" et servent à améliorer les performances globales en mettant en cache certaines informations qui serviront lors d'un lancement futur du même binaire. En forensic, ils sont utilisés afin de tracer l'exécution des binaires et d'avoir quelques informations (horodatage notamment) sur leur contexte d'exécution.

Je n'ai pas trouvé d'outil fiable pour parcourir les fichiers prefetch fournit dans le challenge depuis un OS Linux, je suis donc passé sous Windows et ai utilisé l'outil d'Eric Zimmerman : https://github.com/EricZimmerman/PECmd

En parcourant manuellement le contenu du dossier, l'élément à remarquer est bien sur le fichier "RUBEUS.EXE-5873E24B.pf" qui indique qu'un binaire du même nom a été utilisé. Difficile à deviner si l'on ne connait pas par avance l'outil, mais il est listé dans le TTP cité plus haut dans le framework MITRE ATT&CK. Rubeus.exe est un outil offensif public et classiquement utilisé pour exécuter plusieurs attaques ciblant l'Active Directory et le protocole Kerberos.

Nous pouvons à présent utiliser "PECmd" pour en savoir plus sur le contexte d'exécution de ce binaire :

.\PECmd.exe -f Z:\TMP\Triage\Workstation\2024-05-21T033012_triage_asset\C\Windows\prefetch\RUBEUS.EXE-5873E24B.pf

Parmi les informations récupérées se trouvent le chemin complet du binaire au moment de son exécution :

• Enoncé - Task 7 : When was the tool executed to dump credentials?

L'heure des exécutions de ce binaire est également présente au sein du fichier prefetch :

Rubeus.exe a été exécuté une seule fois le 2024-05-21 03:18:08 sur le poste de travail analysé.

Et voilà ! Nous sommes arrivés au bout de ce petit exercice.

IV. Notions abordées

Cette analyse nous a permis de nous familiariser avec deux éléments importants :

• L'utilisation du SIEM ELK pour rechercher dans les logs Windows, il s'agit d'un outil incroyablement performant en comparaison aux outils natifs de Windows. Bien qu'ELK ne soit pas la seule solution du marché, elle a l'avantage d'être simple à déployer et relativement abordable d'un point de vue technique. La capacité à pouvoir rapidement utiliser ce type d'outils à partir de différents formats de logs (ici ".evtx") est un élément important lors d'une investigation.
• Les fichiers prefetchs sont très précieux d'un point de vue analyse, ils permettent de tracer de façon très précise les exécutions de binaires sur un système Windows même quand les logs associés à cet évènement ne sont pas activés au moment de l'attaque.

Un autre élément sur lequel nous sommes passés peu rapidement est le framework ATT&CK du MITRE. Dans notre contexte, la section "Detection" du TTP associé à l'attaque principale nous a grandement aidé à construire la requête KQL qui a permis de démarrer l'investigation. Il s'agit d'un outil très intéressant que je vous conseille de garder en favoris, car la plupart des TTP (techniques, modes opératoires) qui y sont référencés possèdent une description, la liste des attaques dans lesquelles cette technique a été utilisée, les outils classiques d'exploitation, une section "Detection", mais aussi "Mitigation" pour aider à s'en protéger.

Enfin, voici les liens vers différents articles IT-Connect portant sur les techniques, outil ou attaques mentionnées dans cet article :

• IT-Connect - PowerShell : activer la journalisation des commandes et scripts
• IT-Connect - Windows : utilisation de Sysmon pour tracer les activités malveillantes
• IT-Connect - Importer un fichier .evtx dans ELK depuis Linux via Python

V. Conclusion

Cet article et la résolution du challenge associé permettent de mettre en pratique l'utilisation d'ELK et de l'outil PECmd dans l'étude des traces d'une cyberattaque réaliste. Il faut cependant garder en tête que nous sommes guidés par les questions et qu'en conditions réelles, il faut commencer avec peu d'information sur les raisons et les impacts de l'attaque. Pensez à 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