Investiguer sur une attaque ASREPRoast via ELK – Hack The Box Sherlocks : Campfire-2
Sommaire
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-2, 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-2
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, Active Directory, Kerberos |
| Outils utilisés | ELK, KQL |
Retrouvez tous nos articles Hack The Box via ce lien :
II. Découverte de l'archive et des journaux
Dans le cadre de l'investigation, un contexte et une archive sont mis à notre disposition :
Dans la continuité de l'analyse Campfire-1, notre service de sécurité a détecté l'utilisation d'un compte administrateur qui n'est pas censé être utilisé. Une attaque de type ASREPRoast est suspectée et nous devons en savoir plus.
L'attaque nommée ASREPRoast est le sujet d'un article dédié qui traite de l'attaque et de son impact, mais aussi des conseils de remédiations et possibilités de détection. Nous allons lors de cette analyse largement nous baser sur le contenu de cet article que je vous conseille de consulter :
Si l'on regarde l'intérieur de l'archive récupérée, nous avons simplement les journaux de sécurité de l'Active Directory, ce qui est largement assez pour investiguer sur ce type d'attaque :
J'utiliserai ici une procédure simple d'envoi des logs (fichier ".evtx") sur un ELK local afin de disposer de toute la puissance d'indexation et de recherche de ce SIEM. La procédure technique permettant d'envoyer le contenu d'un ".evtx" vers un ELK est décrit dans cet article :
III. Investigation numérique : le cas Tracer
A. Détecter une attaque ASREPRoast
- Enoncé : Task 1 - When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user?
L'énoncé nous demande de retrouver la date exacte d'exécution de l'attaque ASREPRoast auprès de notre Active Directory
Pour rappel, l'ASREPRoast repose sur la capacité de l'attaquant à récupérer des réponses AS-REP pour les comptes AD non protégés par la pré-authentification Kerberos (défaut de configuration). Cela permet à l'attaquant de lancer un brute-force offline sur la partie chiffrée de cette réponse, qui utilise un dérivé du mot de passe de l'utilisateur cible. L'objectif est alors de récupérer le mot de passe en clair correspondant au compte attaqué.
Dans les journaux de sécurité, cette attaque génère un événement 4768, qui présente la spécificité d'avoir un paramètre PreAuthType à "0" (absence de la pré-authentification), ce qui confirme que l'attaquant a tiré parti de cette faiblesse. Également, les attaquants "downgrade" (abaissent) volontairement le niveau de robustesse cryptographique du ticket en demandant un chiffrement avec l'algorithme RC4 (lorsque autorisé dans la configuration de l'AD) au lieu d'AES, ce qui facilite la procédure de cassage du chiffrement.
On peut réutiliser la commande de recherche des traces d'une attaque ASPREPRoast de notre article. Bien qu'il soit nécessaire de l'adapter du fait de l'import des données dans ELK qui modifie le nom des attributs sur lesquels nous effectuons nos recherches :
# Recherche des eventD 4768 avec un TicketEncryptionType à 17 (RC4) et PreAuthType à 0
Event.System.EventID.#text:4768 AND (Event.EventData.Data.TicketEncryptionType: 0x17 OR Event.EventData.Data.PreAuthType: 0)
La recherche nous permet de retrouver un seul événement qui match avec nos critères. Nous pouvons retrouver la date exacte de cette action via le timestamp de l'évènement et affirmer que l'attaque a eu lieu à 2024-05-29 06:36:40.
- Enoncé : Task 2 - Please confirm the User Account that was targeted by the attacker.
Nous allons toujours nous intéresser au même évènement, qui en plus de l'heure et de la date, contient les détails relatifs à la demande de ticket TGT :
Nous retrouvons le nom de l'utilisateur pour lequel la demande de TGT a été faite, mais aussi son SID (Security Identifier) ainsi que l'adresse IP du poste source de la demande. Ce qui est intéressant pour remonter la chaîne de l'attaque.
L'utilisateur ciblé par la demande de TGT en ASPREPRoast est "arthur.kyle".
- Enoncé : Task 3 - What was the SID of the account?
Le Security Identifier (SID) de l'utilisateur "arthur.kyle" est "S-1-5-21-3239415629-1862073780-2394361899-1601".
- Enoncé : Task 4 - It is crucial to identify the compromised user account and the workstation responsible for this attack. Please list the internal IP address of the compromised asset to assist our threat-hunting team.
Enfin, l'adresse IP source de la demande est "172.17.79.129".
B. Recherche d'information sur le poste compromis
- Enoncé : Task 5 - We do not have any artifacts from the source machine yet. Using the same DC Security logs, can you confirm the user account used to perform the ASREP Roasting attack so we can contain the compromised account/s?
Nous pouvons regarder au niveau des logs du contrôleur de domaine si un évènement d'authentification provenant du poste incriminé a eu lieu. L'authentification au sein d'un domaine étant centralisée, un utilisateur qui s'authentifie sur un poste connecté laisse forcément une trace dans les journaux. Pour ce faire, j'effectue une requête avec un filtre sur l'adresse IP du poste identifié :
# Requête KQL avec un filtre sur l'adresse IP Source
Event.EventData.Data.IpAddress:172.17.79.129
Cela permet de voir plusieurs évènements, dont un EventID 4769 (A Kerberos service ticket was requested.), relatif à une demande de TGS Kerberos. Les informations concernant cette demande permettent de retrouver le compte utilisateur "happy.grunwald".
Cette procédure n'a ici rien à voir avec l'attaque qui a été réalisée précédemment, mais nous permet de constater que l'utilisateur en question s'est connecté sur ce poste dans la plage horaire de l'attaque, et donc qu'il a probablement été compromis.
IV. Notions abordées
Cette investigation assez courte, car orientée autour d'une seule technique d'attaque, nous a tout de même permis de voir concrètement à quoi ressemble une attaque de type ASREPRoast classique dans les journaux d'évènement d'un Active Directory. Pour comprendre en détail les attaque par ASREPRoasting, je vous oriente vers notre article dédié à ce sujet :
Si vous avez tenté de résoudre ce challenge à l'aide de l'Observateur d'évènement Windows, l'opération a certainement été moins agréable. Je vous recommande de vous pencher sur des outils tels que Zircolite ou ELK pour ce genre d'opération :
- IT-Connect - Importer un fichier .evtx dans ELK depuis Linux via Python
- IT-Connect - Comment effectuer une investigation numérique sur les journaux d’évènements Windows avec Zircolite ?
- IT-Connect - Investiguer sur la cyberattaque Tracer avec Zircolite (Hack the Box – Sherlocks)
V. Conclusion
Cet article et la résolution du challenge associé permettent de mettre en pratique les apprentissages concernant la détection d'une attaque ASREPRoast, il s'agit d'un cas simple, mais réaliste, de recherche sur ce type d'attaque.
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
