Hack the Box – Sherlocks : Investiguer sur la cyberattaque Unit42 avec Zircolite et jq

I. Présentation

Dans cet article, nous allons résoudre l’un des challenges d’investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Le Sherlocks Unit42 est un challenge très simple fait pour les débutants en cybersécurité et qui vise à démystifier le forensic au travers un cas d’usage assez simple, mais tout de même réaliste.

Cet article sera notamment l’occasion de comprendre comment peut se dérouler concrètement une cyberattaque et une investigation numérique, et quels sont les modes opératoires des attaquants et analystes en cybersécurité. Nous allons plus précisément étudier des journaux d’évènement Windows (.evtx) contenant les traces d’une cyberattaque.

Cet article et le challenge Sherlocks associé sont avant tout de très bons moyens de mettre en pratique ce que nous avons appris dans les articles suivants :

Plusieurs méthodes existent pour arriver à bout de cet exercice, j’ai notamment choisi ici d’utiliser un système Linux, aidé par « Zircolite » et « jq » pour le résoudre. Je vous recommande de tenter l’exercice avant de lire la solution 🙂 .

Lien du challenge : Hack The Box – Sherlocks – Unit42

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, Sysmon
Outils utilisés	Zircolite, jq, Yara

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 à disposition :

Nous obtenons ici des premières informations concernant la cyberattaque sur laquelle nous devons mener notre investigation. Il s’agit d’une campagne d’attaque ciblée autour du service UltraVNC (service d’accès à distance), une version « backdoorée » de ce service aurait été utilisée par les attaquants afin de maintenir un accès à l’un de nos systèmes.

En cybersécurité, une backdoor est une porte dérobée. Les attaquants s’en servent pour maintenir un accès distant, non autorisé et discret à un système compromis. Bien souvent, les backdoors sont mises en place après une première compromission, leur permettant de revenir à tout moment sans être détectés. Un grand nombre de moyens de persistance existent et sont listés sur le framework du MITRE ATT&CK (TAA – Persistence)

Il existe aussi des backdoors ajoutées dans des logiciels par les attaquants directement dans leur dépôt (GitHub par exemple), qui n’ont plus qu’à attendre que la version infectée soit installée. On parle alors de Supply Chain Compromise (T1195).

Ce sont une partie des journaux de ce système que nous avons à disposition :

$ ls -al ~/Downloads/Microsoft-Windows-Sysmon-Operational.evtx
-rw-r--r-- 1 mdo mdo 1118208 Feb 14 04:43 /home/mdo/Downloads/Microsoft-Windows-Sysmon-Operational.evtx

Les fichiers « .evtx » sont le format standard dans lesquels sont stockés les journaux Windows. Tous les fichiers « .evtx » d’un système Windows se trouvent par défaut dans « C:\Windows\System32\winevt\Logs« . Nous avons ici à notre disposition un journal un peu spécial, issue de l’outil Sysmon.

III. Investigation numérique : le cas Unit42

A. Repérer un eventID dans les logs

• Énoncé – Task 1 : How many Event logs are there with Event ID 11?

Nous disposons ici d’un fichier « .evtx« , format de fichier des journaux Windows difficilement lisible depuis Linux. Heureusement, nous sommes armés de Zircolite qui permet de parser des fichiers « .evtx » et d’y appliquer des règles Yara.

Cette première étape nous demande combien d’eventID 11 sont présents dans le journal à étudier. J’ai ici choisi de créer une règle Yara filtrant les eventID 11 :

title: EventID 11
id: 558eebe5-f2ba-4104-b339-36f7902bcc1a
status: test
description: |
Detect eventID 11
author: OgmaSec
date: 2022/08/12
modified: 2022/10/25
logsource:
  category: sysmon
  product: windows
detection:
   selection1:
    EventID: '11'
  condition: selection1
level: low

J’utilise ensuite Zircolite pour appliquer cette règle sur le fichier de log « .evtx » fournit :

Zircolite m’indique avoir identifié 56 évènements, j’ai donc autant d’eventID 11 dans mon journal.

B. Identifier un processus malveillant

• Énoncé – Task 2 : Whenever a process is created in memory, an event with Event ID 1 is recorded with details such as command line, hashes, process path, parent process path, etc. This information is very useful for an analyst because it allows us to see all programs executed on a system, which means we can spot any malicious processes being executed. What is the malicious process that infected the victim’s system?

Nous devons lister les processus qui ont été exécutés sur le système grâce à l’eventID 1 de Sysmon et identifier un processus malveillant. Je me rends vite compte ici que les détections faites par Zircolite et ses règles Yara « par défaut » ne suffiront pas. Lorsque l’on commence à investiguer sur une cyberattaque, on ne peut pas forcément se permettre d’uniquement se reposer sur un jeu de règles préconçues. Il faut parfois commencer par avoir une vue d’ensemble de tous les évènements.

Pour ce faire, je décide de détourner un peu l’utilisation classique de Zircolite, et de m’en servir comme simple convertisseur « .evtx » vers « .json, » sans utiliser sa fonctionnalité de « tri » d’évènements suspects grâce aux règles Yara.

Je commence par créer une règle Yara qui va matcher avec tous les eventID. Autrement dit, il va considérer comme suspect tous les évènements :

title: Match all EventID
id: 558eebe5-f2ba-4104-b339-36f7902bcc1a
status: test
description: |
Match all EventID
author: OgmaSec
date: 2022/08/12
modified: 2022/10/25
logsource:
  category: sysmon
  product: windows
detection:
   selection1:
    EventID: '*'
  condition: selection1
level: low

Ensuite, j’applique cette règle à mon fichier « .evtx« , Zircolite va alors me convertir tous les logs au format « .json » :

python3 zircolite.py --evtx ~/Downloads/Microsoft-Windows-Sysmon-Operational.evtx -r /tmp/eventIDall.yml

On se retrouve donc avec un fichier « .json » qui contient la totalité des évènements présents dans le journal Windows, mais dans un format beaucoup plus accessible pour un OS Linux et des commandes comme « jq« . J’effectue, par exemple, un filtre sur les eventID 1 sur le fichier « .json » produit par Zircolite :

jq '.().matches() | select(.EventID == 1)' detected_events.json

Voici le résultat attendu, on retrouve ici l’ensemble des informations sur l’évènement relatif à la création d’un process :

Nous pouvons filtrer les attributs affichés pour une meilleure lisibilité de l’ensemble :

jq '.(0).matches() | Image: .Image, EventID: .EventID, ParentImage: .ParentImage |select (.EventID == 1)' detected_events.json

Nous avons alors une liste de tous les processus créés :

Le seul exécutable qui semble sortir de l’ordinaire est celui nommé « C:\Users\CyberJunkie\Downloads\Preventivo24.02.14.exe.exe« .

C. Lister les connexions réseau et requêtes DNS avec Sysmon

• Énoncé – Task 3 : Which Cloud drive was used to distribute the malware?

Notre objectif est d’identifier une plateforme Cloud que l’attaquant aurait été susceptible d’utiliser pour la distribution de son malware. Nous pouvons rechercher dans les journaux les évènements relatifs à des connexions réseau. La documentation des évènements Sysmon peut nous aider :

Nous pouvons également nous intéresser aux eventID 22, relatifs aux requêtes DNS effectuées :

Nous devons donc rechercher les eventID 3 et 22 dans le fichier « .json » créé par Zircolite avec la commande « jq » :

jq '.(0).matches() | select (.EventID == 22 or .EventID == 3)' detected_events.json

Les résultats obtenus nous ressortent notamment des requêtes DNS qui sont assez explicites :

C’est le service de stockage Dropbox qui a été utilisé par l’attaquant.

D. Identifier un changement de date de création d’un fichier

• Énoncé – Task 4 : The initial malicious file time-stamped (a defense evasion technique, where the file creation date is changed to make it appear old) many files it created on disk. What was the timestamp changed to for a PDF file?

Nous devons partir à la recherche des opérations menées en vue de falsifier ou modifier la date de création d’un fichier. Cette technique est utilisée par les attaquants afin de brouiller les pistes lors d’une investigation. Elle est très bien décrite et référencée dans le framework MITRE ATT&CK : T1070.006 – Indicator Removal : Timestomp

Ici, il faut identifier dans la documentation Sysmon l’event ID spécifique à cette opération : Event ID 2: A process changed a file creation time. Cette première commande « jq » nous permet de compter combien d’eventID 2 nos logs contiennent :

$ jq '(.(0).matches() | select(.EventID == 2)) | length' detected_events.json
16

16, il va donc falloir être plus précis dans notre requête si l’on souhaite avoir la bonne information. La question posée nous oriente notamment sur un fichier PDF. Nous pouvons donc utiliser cette information en tant que filtre sur le nom du fichier ciblé par la modification du temps de création :

jq '(.(0).matches() | select(.EventID == 2 and select(.TargetFileName |endswith(".pdf"))))' detected_events.json

Nous parvenons grâce à cette requête à isoler un seul évènement :

Cet évènement nous permet de retrouver notamment la date initiale de création du fichier, ainsi que la date que l’attaquant a souhaité positionner : 2024-01-14 08:10:06.

E. Travailler avec l’eventID 11 : Création d’un fichier

• Énoncé – Task 5 : The malicious file dropped a few files on disk. Where was « once.cmd » created on disk? Please answer with the full path along with the filename.

Nous devons nous intéresser aux évènements relatifs à la création de fichiers sur le système, vous connaissez à présent la démarche : il nous faut trouver l’eventID correspondant dans la documentation Sysmon :

L’eventID 11 permet de journaliser les créations de fichier, c’est précisément ce qui nous intéresse ici. Utilisons la commande « jq » afin d’effectuer un filtre sur cet eventID en n’affichant que les attributs principaux :

jq '(.(0).matches() | EventID: .EventID, UtcTime: .UtcTime, TargetFileName:.TargetFileName |select(.EventID == 11 and select(.TargetFileName | endswith("once.cmd"))))' detected_events.json

Cette requête nous permet d’identifier deux évènements qui correspondent à notre contexte de recherche :

Grâce à notre filtre sur le nom du fichier et à l’horodatage des évènements, nous pouvons voir que le fichier a été créé d’abord dans : « C:\Users\CyberJunkie\AppData\Roaming\Photo and Fax Vn\Photo and vn 1.1.2\install\F97891C\WindowsVolume\Games\once.cmd« .

F. Lister les requêtes DNS avec les logs Sysmon

• Énoncé – Task 6 : The malicious file attempted to reach a dummy domain, most likely to check the internet connection status. What domain name did it try to connect to?

Comme vu précédemment, nous pouvons utiliser un filtre sur l’eventID 22 de Sysmon afin de lister l’ensemble des requêtes DNS journalisées. Nous allons ici sélectionner seulement certains attributs pour une meilleure lisibilité :

jq '.(0).matches() | EventID: .EventID, UtcTime: .UtcTime, QueryName: .QueryName| select (.EventID == 22)' detected_events.json

Le « dummy domain » mentionné dans la question est sans nul doute « www.example.com » :

Il est toutefois étonnant de voir que l’attaquant a fait cette vérification après avoir téléchargé sa charge malveillante depuis Dropbox.

G. Lister les connexions réseau dans les logs Sysmon

• Énoncé – Task 7 : Which IP address did the malicious process try to reach out to?

Nous devons identifier une adresse IP que le processus malveillant de l’attaquant aurait cherché à joindre, nous avons déjà vu précédemment que l’eventID 3 permettait de journaliser les connexions réseau :

jq '.(0).matches() | select (.EventID == 3)' detected_events.json

Nous n’avons qu’un seul évènement en réponse :

La seule connexion réseau qui a été journalisée vise l’adresse IP « 93.184.216.34« . Il s’agit de l’une des IP obtenue en réponse à la requête DNS vers « www.example.com » :

H. Repérer les fins de processus dans les journaux

• Énoncé – Task 8 : The malicious process terminated itself after infecting the PC with a backdoored variant of UltraVNC. When did the process terminate itself?

Toujours à partir de la documentation Sysmon, nous pouvons nous intéresser aux évènements relatifs à la fin d’un processus, c’est-à-dire les Event ID 5: Process terminated.

Nous reconnaissons le nom du processus incriminé et pouvons récupérer l’heure exacte à laquelle il s’est terminé : 2024-02-14 03:41:58.

IV. Pour aller plus loin : la timeline Zircolite

Nous avons notamment un peu détourné l’usage classique de Zircolite en l’utilisant comme simple outil de conversion « .evtx » vers « .json« . Comme mentionné au début de l’article, il existe plusieurs solutions à ce challenge. Nous aurions pu, par exemple, utiliser uniquement l’Observateur d’évènements Windows pour investiguer sur le fichier « .evtx« , utiliser Zircolite sous Windows en complément, écrire des règles Yara pour chacune de notre recherche plutôt que des filtres « jq« , ou enfin envoyer tous nos logs sur un ELK pour réaliser nos recherches avec des requêtes KQL, bref :).

Pour aller au-delà des questions de l’exercice, nous pouvons aussi utiliser Zircolite et effectuer une investigation rapide afin de comprendre le déroulement exacte de la cyberattaque. Nous allons pour cela nous baser sur les jeux de règles par défaut de Zircolite concernant les évènements Sysmon et l’option « –package » de l’outil qui permet d’avoir une vue graphique, utile pour une analyse rapide :

python3 zircolite.py --evtx ~/Downloads/Microsoft-Windows-Sysmon-Operational.evtx -r /opt/Zircolite/rules/rules_windows_sysmon_full.json --package

Zircolite va donc produire une archive ZIP contenant une mini arborescence web et un fichier « index.html » :

Très rapidement, nous pouvons voir les différentes actions suspectes :

1. Téléchargement depuis un site de partage de fichier.
2. Suppression de la « Mark of the web » du fichier, qui restreint notamment son exécution.
3. Déplacement d’un fichier portant le nom d’un exécutable Windows commun dans un répertoire inhabituel.
4. Exécution d’un process par un autre.

Comme expliqué dans notre article sur Zircolite, nous pouvons aussi cliquer sur chacun de ces évènements pour avoir des détails :

Pour des informations encore plus précises, il faut se rendre dans le fichier JSON contenant les détails de chaque évènement suspect relevé par Zircolite et ses règles Yara. Ce que nous avons fait pour répondre aux différentes tâches de l’exercice.

V. Rappel des notions abordées

Nous allons à présent mettre en avant les principales notions et les apprentissages de cet exercice. Côté analyste, les connaissances et réflexes à avoir pour résoudre ce challenge étaient les suivants :

1. Connaitre les subtilités et le format des journaux « .evtx » de Windows.
2. Sélectionner les bons outils, ceux qui correspondent le mieux à nos besoins et/ou ceux que l’on maitrise le mieux
   • J’ai fait le choix de m’orienter sur l’outillage Yara/Zircolite/jq alors que d’autres étaient également valables (Observateur d’évènement Windows ou Yara/Zircolite/ELK)
3. Savoir se documenter rapidement pour repérer les bons event ID en fonctions des recherches à mener.
   • Le but principal de l’exercice ici était d’apprendre à identifier les event ID correspondant à la recherche à mener, cela en utilisant la documentation officielle de Sysmon.