Investiguer sur la cyberattaque Tracer avec Zircolite (Hack the Box – Sherlocks)
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 Tracer, de difficulté "débutant". Il s'agit d'investiguer sur les traces d'une cyberattaque ciblant un système d'exploitation Windows.
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 l'outil d'investigation sur les journaux Zircolite, cela vous permettra de voir son utilisation dans un contexte réaliste.
Lien du challenge : Hack The Box - Sherlocks - Tracer
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, PsExec |
| Outils utilisés | Zircolite, jq |
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 :
Nous sommes donc un analyste SOC et avons à disposition différentes traces sur lesquels investiguer. Nous savons que plusieurs alertes concernant l'exécution de l'outil PsExec ont été émises depuis le poste utilisateur en question.
PsExec est un utilitaire de la suite Sysinternals de Microsoft permettant l'exécution de commandes à distance sur des systèmes Windows. Bien qu'initialement légitime, il est souvent utilisé de manière malveillante par les attaquants afin d'accéder à distance à des systèmes, se déplacer latéralement dans un réseau, exécuter des commandes avec des privilèges élevés, ou désactiver des fonctions de sécurité.
Si l'on regarde à l'intérieur de l'archive, nous avons les données suivantes :
$ tree | tail -n 1
8 directories, 398 filesPrès de 400 fichiers répartis dans 8 dossiers ! Cela représente pas mal de travail, en plus de ne pas vraiment savoir quoi chercher, nous ne saurons pas où chercher. En regardant d'un peu plus près, nous avons essentiellement des fichiers ".evtx" et des fichiers ".pf" :
Il est possible de réaliser cette investigation avec l'un ou l'autre des types de fichiers fournis (ou les deux). J'ai pour ma part basé mon analyse sur les fichiers de logs (".evtx"). À présent, si l'on regarde avec attention la liste des fichiers ".evtx" (dans le dossier "C/Windows/System32/winevt/logs"), il y en a 153 ! Notre première mission va donc être de savoir où chercher les types d'évènements et les journaux dans lequel ils sont susceptibles d'être stockés.
Si vous vous rappelez des conclusions de notre article sur l'utilisation de Sysmon pour tracer les activités malveillantes, l'exécution d'un nouveau processus fait apparaitre un évènement "4688" dans le journal "Securité", ce qui est un premier élément. Néanmoins, dans le cas où Sysmon est présent sur le système (et correctement configuré), nous pouvons obtenir des informations beaucoup plus précises sur les actions malveillantes opérées sur le système.
Voyons si c'est le cas ici :
# Recherche de journaux EVTX Sysmon avec la commande find
$ find . -name "*Sysmon*"
./Microsoft-Windows-Sysmon%4Operational.evtxSysmon était présent au moment du prélèvement des journaux. D'un point de vue sécurité et investigation, c'est plutôt une bonne nouvelle.
Dans le cadre d'une investigation numérique, mais aussi lorsque l'on vérifie la sécurité et le durcissement de la configuration d'un système, il est très important de vérifier si les bons journaux sont présents et correctement configurés. La mise en place de Sysmon en fait partie.
Pour mieux comprendre ce qu'est Sysmon et son intérêt en termes de sécurité, je vous oriente vers notre article sur le sujet :
Commençons à présent notre investigation sur la base des premières informations obtenues et des fichiers à disposition.
III. Investigation numérique : le cas Tracer
A. Détecter l'utilisation de PsExec avec Zircolite
- Enoncé - Task 1 : The SOC Team suspects that an adversary is lurking in their environment and are using PsExec to move laterally. A junior SOC Analyst specifically reported the usage of PsExec on a WorkStation. How many times was PsExec executed by the attacker on the system?
Comme je vous l'ai indiqué, nous allons pour cette investigation utiliser autant que possible l'outil Zircolite. Pour installer et apprendre à maitriser cet outil puissant, je vous oriente vers notre article à ce sujet :
Nous devons dans un premier temps identifier combien de fois PsExec a été exécuté sur le poste de l'utilisateur. Je commence donc par exécuter Zircolite sur le journal "Microsoft-Windows-Sysmon%4Operational.evtx" :
# Utiliser Zircolite sur un fichier .evtx avec un jeu de régèle SIGMA précis
python3 zircolite.py -e ~/Downloads/Tracer/C/Windows/System32/winevt/logs/Microsoft-Windows-Sysmon%4Operational.evtx -r /opt
/zircolite/rules/rules_windows_sysmon_full.jsonComme vous pourrez le lire dans l'article dédié à cet outil, Zircolite peut se baser sur n'importe quelle règle Sigma. Je décide d'utiliser le fichier de règle "rules_windows_sysmon_full.json" :
La sortie est très claire, et nous n'avons même pas eu pour l'instant à ouvrir le fichier ".evtx", PsExec a été exécuté 9 fois.
- Enoncé - Task 2 : What is the name of the service binary dropped by PsExec tool allowing attacker to execute remote commands?
Cette étape exige que l'on se penche plus en détail sur le fonctionnement de PsExec :
Je vous oriente vers l'article de Hacktrickz.xyz pour plus de détails sur le fonctionnement de PsExec, ainsi que vers notre article. Mais, il faut retenir qu'il commence par déposer un binaire, puis créer un service en vue de l'exécuter et démarre ce service à distance. En toute logique, nous devrions donc voir des journaux concernant la création de fichiers et de services sur l'hôte ciblé. Pour connaitre l'Event ID d'un évènement produit par Sysmon, rien de mieux que la documentation officielle :
Il y a plusieurs approches pour investiguer plus en profondeur sur les évènements identifiés par Zircolite. Nous pouvons commencer par regarder quels sont les tags qui ont été utilisés pour catégoriser les évènements en relation avec PsExec, ainsi que le nombre d'évènements associés :
Les tags utilisés rapportent notamment le TTP T1569.02, relatifs à l'exécution de service. Nous pouvons nous en servir de filtre supplémentaire dans nos recherches. Nous pouvons à présent lister les fichiers créés (Event ID 11 : File Create) :
# Filtre JQ sur un TTP et un EventID
$ jq -c '.[] | select((.tags[] | contains("attack.t1569.002")) and .matches[].EventID == 11) | {Computer:.matches[].Computer, File:.matches[].TargetFileName}' /opt/zircolite/detected_events.json
{"Computer":"Forela-Wkstn002.forela.local","File":"C:\\Windows\\PSEXESVC.exe"}
{"Computer":"Forela-Wkstn002.forela.local","File":"C:\\Windows\\PSEXESVC.exe"}
{"Computer":"Forela-Wkstn002.forela.local","File":"C:\\Windows\\PSEXESVC.exe"}
{"Computer":"Forela-Wkstn002.forela.local","File":"C:\\Windows\\PSEXESVC.exe"}
{"Computer":"Forela-Wkstn002.forela.local","File":"C:\\Windows\\PSEXESVC.exe"}
Via ce filtre, nous parvenons à identifier les fichiers créés par les processus impliqués dans les évènements en relation avec la création de services suspects sur le poste. Le fichier créé par PsExec se nomme ici "psexesvc.exe".
- Enoncé - Task 3 : Now we have confirmed that PsExec ran multiple times, we are particularly interested in the 5th Last instance of the PsExec. What is the timestamp when the PsExec Service binary ran?
Pour trouver la date et l'heure exacte de la 5ème exécution de PsExec, nous devons appliquer un filtre précis pour avoir une liste contenant uniquement les exécutions de PsExec (elle doit donc contenir 9 items) et compter jusqu'à la 5ème. J'utilise ici le filtre sur l'ID relatif à l'évènement "PsExec Service File Creation" identifié précédemment, soit "259e5a6a-b8d2-4c38-86e2-26c5e651361d" :
# Filtre JQ basé sur l'ID d'une règle et un horodatage
$ jq '[.[] |
select(.id == "259e5a6a-b8d2-4c38-86e2-26c5e651361d") |.matches[]|{TargetFileName, CreationUtcTime}] |sort_by(.CreationUtcTime)' detected_events.jsonIl faut prendre soin de n'afficher que les attributs qui nous intéressent pour que la sortie soit facile à lire. Également, il est important de trier les données de sortie par date afin de pouvoir compter les éléments dans le bon ordre. Voici la sortie obtenue :
La date exacte de la 5ème exécution de PsExec est le 07/09/2023 12:06:54.
B. Visualiser la timeline de l'attaque avec Zircolite
Pour ceux qui suivent la même procédure que moi, c'est-à-dire l'utilisation de jq sur les données produites par Zircolite à partir d'un grand nombre de règles SIGMA, vous vous rendrez surement compte que la syntaxe de jq est certes pratique, mais difficile à appréhender au début. Pour aller plus vite, nous pouvons revoir un peu notre process (toujours en utilisant Zircolite).
Nous allons utiliser Zircolite de façon plus précise afin de cibler des évènements spécifiques et ainsi produire des données de sortie uniquement sur ces évènements recherchés. Cela va passer par la manipulation des règles SIGMA que l'on lui fournit au lieu de la manipulation des données qu'il nous donne en sortie.
Exemple : Je recherche les évènements de création de processus dans le cadre de l'exécution de PsExec. L'avantage des règles SIGMA et qu'elles possèdent un numéro unique : l'UID. Nous avons vu précédemment que l'UID de la règle relative à la détection de l'exécution du service "PsEXEC (PSExec Service file Creation)" est "259e5a6a-b8d2-4c38-86e2-26c5e651361d". En recherchant cette règle, notamment dans la principale base de données de règles SIGMA qu'est le dépôt SigmaHQ/sigma, nous retrouvons facilement cette règle :
# recherche de l'ID d'une règle SIGMA
$ grep "259e5a6a-b8d2-4c38-86e2-26c5e651361d" -ril /opt/sigma/rules
/opt/sigma/rules/windows/file/file_event/file_event_win_sysinternals_psexec_service.ymlÀ noter que nous aurions également pu rechercher cet UID dans le fichier de règle fournit par Zircolite et utilisé à la base, puis isoler cette unique règle dans un fichier dédié.
Ensuite, nous pouvons utiliser Zircolite sur le même jeu de données (notre fichier ".evtx") :
# Analyse Zircolite en utilisant une seule règle SIGMA et l'option --package
python3 zircolite.py -e ~/Tracer/C/Windows/System32/winevt/logs/Microsoft-Windows-Sysmon%4Operational.evtx -r /opt/sigma/rules/windows/file/file_event/file_event_win_sysinternals_psexec_service.yml --packageNotez que j'utilise ici le "--package", qui permet de produire un rapport au format web, qui dans certains cas peut être très utile. Nous pouvons ensuite ouvrir ce rapport web et avoir la vue suivante :
On peut ici très rapidement voir 18 évènements ordonnés par date d'apparition, qui manifestement sont produits par paquets de deux (un event ID 11 et un event ID 23). La timeline nous permet d'isoler 9 paires d'évènements et d'identifier le 5ème facilement. Nous pouvons également opter pour la vue "tableau", qui nous permet de filtrer les évènements :
J'ai effectué un filtre sur l'eventID 11, puis trié les évènements obtenus par date. Ce qui permet de nouveau de visualiser rapidement et facilement le 5ème évènement, mais aussi d'obtenir toutes les informations sur son sujet.
- Énoncé - Task 4 : Can you confirm the hostname of the workstation from which attacker moved laterally?
Nous devons retrouver le nom du système utilisé par l'attaquant. Cette information peut être retrouvée si l'on s'intéresse aux lignes de commandes saisies parmi les Event ID 1 :
Le poste de l'attaquant est "Forela-Wkstn001".
- Énoncé - Task 5 : What is full name of the Key File dropped by 5th last instance of the Psexec?
La question suggère qu'un fichier a été créé lors de la 5ème exécution de PsExec, avec la connaissance de l'EventID Sysmon que génère une création de fichier (11) et l'heure exacte de cette 5ème exécution (07/09/2023 12:06:54), nous pouvons facilement retrouver le fichier en question :
# Filtre JQ basé sur l'EventID 11 et un horodatage approximatif
$ jq '[.[] | .matches[] | select(.EventID == 11 and (.CreationUtcTime | test("2023-09-07 12:*"))) | [.TargetFileName, .CreationUtcTime]]' detected_events.json
[
[
"C:\\Windows\\PSEXEC-FORELA-WKSTN001-95F03CFE.key",
"2023-09-07 12:06:55.054"
],
[
"C:\\Windows\\PSEXEC-FORELA-WKSTN001-C3E84A44.key",
"2023-09-07 12:08:23.345"
],
[
"C:\\Windows\\PSEXEC-FORELA-WKSTN001-415385DF.key",
"2023-09-07 12:08:54.914"
],
[...]
Le fichier créé par cette 5eme exécution est "PSEXEC-FORELA-WKSTN001-95F03CFE.key".
- Énoncé - Task 6 : Can you confirm the timestamp when this key file was created on disk?
La réponse est ici toute trouvée par notre requête jq précédente, le fichier a été créé à 2023-09-07 12:06:55.054.
- Énoncé - Task 7 : What is the full name of the Named Pipe ending with the "stderr" keyword for the 5th last instance of the PsExec?
Dans un premier temps, j'ai remarqué qu'aucune chaine de caractère "stderr" n'était présente dans le fichier "detected_events.json" produit par Zircolite. J'en ai conclu que cet évènement était présent dans les journaux, mais que les règles SIGMA utilisées par Zircolite ne l'avaient pas catégorisé comme suspect. J'ai donc créé une règle sur mesure visant à isoler tous les évènements de création de pipe ciblant des fichiers finissant par "stderr" :
J'ai ensuite exécuté une analyse Zircolite en utilisant uniquement cette règle, ce qui m'a ressorti 18 évènements :
# Utilisation de Zircolite avec une règle SIGMA personnalisée
$ python3 zircolite.py -e ~/Downloads//Tracer/C/Windows/System32/winevt/logs/Microsoft-Windows-Sysmon%4Operational.evtx -r /tmp/custom.yml
[+] Modules imports status: OK
[+] Loading ruleset(s)
[+] Converting Native Sigma to Zircolite ruleset : /tmp/custom.yml 294.69it/s]
[+] Checking prerequisites
[+] Extracting events Using 'tmp-DQP5HL41' directory 1.86it/s]
[+] Processing events 2.41s/it]
[+] Creating model
[+] Inserting data22110.50it/s]
[+] Cleaning unused objects
[+] Executing ruleset - 1 rules
- Named Pipe Creation Ending with stderr [medium] : 18 events 65.52it/s]
[+] Results written in : detected_events.json
[+] Cleaning
Finished in 5 secondsAvec la connaissance exacte de l'heure de la 5ème exécution de PsExec, je suis en mesure de rechercher les évènements en question autour de cette date :
Filtre JQ basé sur un horodatage
$ jq '[.[].matches[] | select(.UtcTime | test("2023-09-07 12:06"))| [.UtcTime,.PipeName]]' detected_events.json
[
[
"2023-09-07 12:06:55.069",
"\\PSEXESVC-FORELA-WKSTN001-3056-stderr"
],
[
"2023-09-07 12:06:55.085",
"\\PSEXESVC-FORELA-WKSTN001-3056-stderr"
]
]Le nom du Pipe créé lors de la 5ème exécution de PsExec est "\\PSEXESVC-FORELA-WKSTN001-3056-stderr".
IV. Notions abordées
Au-delà, de la connaissance basique du fonctionnement des journaux Windows, nous avons fait appel à plusieurs sujets de cybersécurité très importants, que ce soit pour la partie offensive (Red Team) ou la partie défense/détection (Blue Team) :
- Le fonctionnement de PsExec, notamment au travers la création des NamePipe et les traces que son exécution peut faire apparaitre :
- L'utilisation de Zircolite, de manière classique et haut niveau, puis de façon plus précise en passant par la création d'une règle SIGMA correspondant à notre besoin :
- L'utilisation de JQ pour travailler sur des données JSON complexes et des fichiers volumineux
- L'intérêt et les détails des journaux Sysmon, très important pour espérer réaliser une investigation avec les bonnes informations
V. Conclusion
Cet article et la résolution du challenge associé permettent de mettre en pratique l'utilisation de Zircolite et de la commande jq 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.
