Préambule

Durant un cours de Forensic donné par Itarow, nous avons pu utiliser différents outils comme Hayabusa et TimelineExplorer. Nous avons réalisé le challenge SOC Simulator du FCSC 2024 afin de mettre en pratique ces outils. Un Write-up détaillé est disponible sur le blog d’Itarow.

Je vous présente donc ici mon write-up personnel en français.

SOC Simulator 1/5 - Vecteur initial

1
2
3
4
5
6

Durant l’été 2022, un opérateur d’importance vitale (OIV) alerte l’ANSSI car il pense être victime d’une cyberattaque d’ampleur. Le security operation center (SOC) de l’OIV envoie à l’ANSSI un export de sa collecte système des derniers jours. Vous êtes chargé de comprendre les actions réalisées par l’attaquant.

Note : Les 5 parties sont numérotées dans l’ordre chronologique de l’attaque mais il n’est pas nécessaire de les résoudre dans l’ordre.

Fichiers : 
soc_events.zip

Nous avons donc un fichier soc_events.zip, avec de nombreux fichiers .evtx :

1
2

ls *.evtx | wc -l
450

Dans un premier temps, nous allons utiliser l’outil Hayabusa. Cet outil permet de générer une timeline de l’ensemble des événements, ainsi que de parser ces événements à l’aide des règles SIGMA.

L’objectif est donc d’affiner notre analyse en triant les événements à la fois par chronologie et par criticité, en s’appuyant sur les règles SIGMA. Pour cela, nous utilisons Hayabusa :

Nous avons, au préalable, trié nos événements afin de les répartir par date, puis généré des fichiers CSV en fonction de la date des événements. Les noms des fichiers étant de la forme 20220704T172606.evtx, il est facile de les trier rapidement.

Nous allons à présent utiliser l’outil TimelineExplorer d’Eric Zimmerman, qui permet de visualiser des fichiers CSV et Excel, ainsi que de filtrer les données selon les colonnes ou d’autres critères.

L’événement qui nous intéresse est censé ressortir avec un niveau de sévérité critique. Cependant, cela dépend des règles SIGMA utilisées. Nous allons donc essayer avec la version 2.13 (cohérente avec des logs datant de 2022), qui utilise un répertoire de règles SIGMA différent. Il est donc important de garder à l’esprit que vos analyses basées sur des règles SIGMA peuvent parfois ne pas faire ressortir certains événements critiques, selon les règles utilisées. Dans notre cas, les fichiers .evtx datent des 04, 05 et 06 juillet 2022.

Après coup, j’ai compris mon erreur. Elle est due au fait qu’Hayabusa, pour des raisons de performance, applique par défaut un filtrage des règles. Voici ce que la documentation précise : As of Hayabusa v2.16.0, we enable a Channel-based filter when loading .evtx files and .yml rules. The purpose is to make scanning as efficient as possible by only loading what is necessary. […] If you want to use these two rules and scan all rules against loaded .evtx files then you will need to add the -A, –enable-all-rules option in the csv-timeline and json-timeline commands. In our benchmarks, the rules filtering usually gives a 20% to 10x speed improvement depending on what files are being scanned and of course uses less memory.

Nous devons donc utiliser l’option --enable-all-rules afin d’obtenir une analyse la plus pertinente possible.

La commande correspondante est la suivante :

1

hayabusa-3.2.0-lin-x64-gnu csv-timeline --enable-all-rules -d ./06/ -o events_hayabusa_lastversion_updatedrules_allrules_06_rules5.csv

Avec les paramêtres suivants :

L’outil nous fait donc des remontées comme ci-dessous :

Concernant les événèments du 2022-07-04 :

Concernant les événèments du 2022-07-05 :

etc…

On remarque plusieurs alertes critiques qui vont particulièrement nous intéresser, ainsi qu’un grand nombre d’alertes de niveau high et medium.

Nous allons maintenant utiliser l’outil TimelineExplorer, un visualiseur de fichiers CSV, afin d’examiner plus en détail les deux événements critiques identifiés.

Dans le cas où ces événements n’auraient pas été remontés comme critiques, TimelineExplorer nous aurait tout de même permis d’avoir une meilleure visualisation de l’ensemble des événements.

En analysant les données jour par jour, nous identifions ainsi quatre alertes critiques.

Celles du 07/04 sont les suivantes :

Les événements critiques des 07/05 et 07/06 sont similaires, ce qui suggère fortement une remontée effectuée par un agent ou un autre mécanisme automatisé.

En effet, les timestamps des deux alertes sont quasiment identiques. Nous allons donc nous renseigner sur la CVE-2021-31207.

En effectuant une recherche rapide, on tombe sur cet article,

Cela nous permet de mieux comprendre l’attaque, et en effet, on retrouve bien la même payload que celle présentée dans l’article :

New-MailBoxExportRequest – Mailbox john.doe@enterprise.corp -FilePath \\127.0.0.1\C$\path\to\webshell.aspx

Les attaquants ont donc exploité la vulnérabilité ProxyShell le 2022-07-04 à 15:36:43, puis de nouveau à 15:44:43 le même jour.

Flag : FCSC{ProxyShell|2022-07-04T15:36}

SOC Simulator 2/5 - Vol de secret 1

1
2
3

Après l’action vue dans la partie 1, l’attaquant vole les identifiants système en mémoire. Retrouver le GUID du processus effectuant ce vol et le nom du fichier où il écrit les secrets volés.

Format du flag (insensible à la casse) : FCSC{6ccf8905-a033-4edc-8ed7-0a4b0a411e15|C:\Windows\Users\toto\Desktop\fichier.pdf}

Nous allons donc nous concentrer sur les événements précédant le timestamp indiqué dans le premier challenge. Plus précisément, nous allons rechercher en mémoire un éventuel processus qui aurait pu être exécuté par l’attaquant.

Nous connaissons également la machine ciblée par l’attaque, ce qui nous permet d’appliquer les filtres suivants :

En appliquant le filtre suivant : [Computer] = 'exchange.tinfa.loc' And Contains([Details], 'Cmdline')

Note : Il était possible d’optimiser le filtre en croisant les timestamps. Cependant, je n’ai découvert cette méthode que par la suite, que je présente dans la suite de ce write-up.

On retrouve très rapidement les événements ci-dessous :

En examinant les titres des règles :

• “Suspicious System User Process Creation”
• “Potentially Suspicious PowerShell Child Processes”
• “Process Memory Dump Via Comsvcs.DLL”
• “Suspicious SYSTEM User Process Creation”

On remarque qu’il faudrait s’intéresser de près à cette fameuse Comsvcs.DLL.

Effectivement, c’est plutôt suspect : on retrouve bien une DLL dont la fonction est de Dump Lsass.exe process memory to retrieve credentials,, autrement dit, extraire des credentials via un dump mémoire de lsass.

Dans les détails de l’événement, on retrouve donc :

1

Cmdline: "C:\Windows\system32\rundll32.exe" C:\Windows\System32\comsvcs.dll MiniDump 652 attr.exe full ¦ Proc: C:\Windows\System32\rundll32.exe ¦ User: NT AUTHORITY\SYSTEM ¦ ParentCmdline: powershell ¦ LID: 0x3e7 ¦ LGUID: {b99a131f-8de7-62c2-e703-000000000000} ¦ PID: 17400 ¦ PGUID: {b99a131f-0d4b-62c3-ce03-00000000db01} ¦ ParentPID: 4688 ¦ ParentPGUID: {b99a131f-0ca8-62c3-c903-00000000db01} ¦ Description: Windows host process (Rundll32) ¦ Product: Microsoft® Windows® Operating System ¦ Company: Microsoft Corporation ¦ Hashes: SHA1=A40886F98905F3D9DBDD61DA1D59CCB4F4854758,MD5=80F8E0C26028E83F1EF371D7B44DE3DF,SHA256=9F1E56A3BF293AC536CF4B8DAD57040797D62DBB0CA19C4ED9683B5565549481,IMPHASH=F27A7FC3A53E74F45BE370131953896A

On récupère ainsi le GUID {b99a131f-0d4b-62c3-ce03-00000000db01} et nous savons que le fichier de sortie est attr.exe. Mais qu’en est-il du chemin ?

J’ai cherché dans tous les CSV générés s’il y avait une mention de attr.exe pouvant révéler le chemin, mais sans succès :/

Spoiler d’Itarow, allez voir son write-up encore une fois ;)).

Une méthode possible est donc d’utiliser ripgrep sur l’exécutable dans nos fichiers .evtx, puis d’analyser les résultats avec un viewer d’événements Windows.

1
2

rg -i "attr.exe" --binary -E UTF-16 ./
./20220704T175527.evtx: binary file matches (found "\0" byte around offset 10)

En filtrant sur l’Event ID 1 et en regardant l’horaire de l’événement en UTC+2 affiché dans TimelineExplorer, on obtient ce que l’on cherche.

Ou simplement : strings -el ./20220704T175527.evtx | grep -C 5 "attr.exe"

C:\Windows\System32\inetsrv\ est donc le répertoire courant.

Flag : FCSC{b99a131f-0d4b-62c3-ce03-00000000db01|C:\Windows\System32\inetsrv\attr.exe}

SOC Simulator 3/5 - Exfiltration

1
2
3

Dans la continuité de ce qui été vu précédemment, l’attaquant a collecté une quantité importante de données métier. Retrouver la commande qui a permis collecter de tous ces éléments.

Format du flag : FCSC{sha256(<commande en UTF8 sans saut de ligne>)}

Après être tombé dans le même rabbit hole très bien détaillé par Itarow, en déobfusquant des commandes PowerShell pour récupérer le second stage de l’attaque, je repars du bon pied en analysant de nouveau mes événements.

Je réalise cependant que la sortie générée par Hayabusa ne contient pas tous les événements avec l’ID 4104. Cet ID, que j’avais déjà observé au cours de mon analyse, est particulièrement intéressant de par sa définition et les remontées qu’il génère :

ID d'événement de sécurité Windows 4104 : journalisation de ScriptBlock La journalisation automatique des scripts est activée par défaut et enregistre le code de script PowerShell contenant des termes suspects.

⚠️ En comparant mes données avec celles du write-up d’Itarow, je remarque qu’il me manque certains événements, comme mentionné ci-dessus. J’ai donc dû générer à nouveau un CSV.

J’ai donc comparé les règles SIGMA entre les différentes versions, j’ai essayé de comprendre pourquoi certaines alertes n’étaient pas générées, alors qu’elles étaient bien présentes dans les versions les plus récentes. C’est à ce moment-là que j’ai consulté la documentation d’Hayabusa et découvert qu’il fallait ajouter l’option –enable-all-rules sur les dernières versions.

Je conseille donc de bien observer la valeur Total lines affichée en bas de TimelineExplorer et de vérifier sa cohérence.

En générant un nouveau CSV avec la dernière version d’Hayabusa, et en filtrant sur les events ScriptBlock :

On retrouve rapidement cette commande :

foreach ($Mailbox in (Get-Mailbox -ResultSize Unlimited)) {New-MailboxExportRequest -Mailbox $Mailbox.DisplayName -FilePath ""\\exchange\C$\windows\system32\xwin\($Mailbox.Alias).pst""}

En demandant à ChatGPT il nous dit la chose suivante : La commande PowerShell suivante est destinée à exporter toutes les boîtes aux lettres Exchange vers des fichiers .pst, en les plaçant dans un chemin réseau localisé sur \\exchange\C$\windows\system32\xwin\.

Nous pouvons donc parler d’exfiltration de données à mon avis ;)

Flag : FCSC{2ee0ab1d44c759b09159ef21900c9826239a7b63e25c0e5935f200d30348b588}

SOC Simulator 4/5 - Latéralisation

1
2
3

Sur une courte période de temps, l’attaquant a essayé de se connecter à de nombreuses machines, comme s’il essayait de réutiliser les secrets volés dans la partie 2. Cela lui a permis de se connecter à la machine Workstation2. Retrouver l’IP source, le compte utilisé et l’heure UTC de cette connexion.

Format du flag (insensible à la casse) : FCSC{192.168.42.27|MYCORP\Technician|2021-11-27T17:38:54}.

D’après l’énoncé, l’attaquant a dû énumérer un grand nombre de machines avant de se connecter à la machine Workstation2. Nous pouvons donc utiliser cette information pour affiner notre filtre.

Ce qui nous donne le filtre suivant : [Event Id] = 4624 And [Computer] = 'Workstation2.tinfa.loc' Or [Event Id] = 4625

En scrollant rapidement on remarque un pattern de résultat qui nous saute aux yeux.

On observe une vague de brute force suivie de deux connexions réussies sur Workstation2.tinfa.loc à 13:26:55 et à 13:26:57.

On remarque que la vague de bruteforce cible l’utilisateur TgtUser: Administrator, ce qui confirme que la connexion qui nous intéresse est celle de 13:26:57. En effet, la connexion de 13:26:55 est associée à TgtUser: ANONYMOUS LOGON.

Flag : FCSC{172.16.20.20|WORKSTATION2\Administrator|2022-07-06T13:26:57}

SOC Simulator 5/5 - Vol de secret 2

1
2
3

Sur la machine identifiée en partie 4, l’attaquant vole de nouveau les secrets du système. Retrouver le GUID du processus effectuant ce vol et le nom du fichier où il écrit les secrets volés.

Format du flag (insensible à la casse) : FCSC{6ccf8905-a033-4edc-8ed7-0a4b0a411e15|C:\Windows\Users\toto\Desktop\fichier.pdf}.

Nous disposons de la date et de l’heure de la connexion, ce qui nous permet d’appliquer des filtres plus précis, par exemple : timestamp > 13:26:57 (heure de la première connexion réussie).

[Timestamp] >= #2022-07-06# And DateDiffHour(#2022-07-06#, [Timestamp]) >= 13 And DateDiffMinute(#2022-07-06 13:00:00#, [Timestamp]) >= 26

Cela va nous retourner l’ensemble des événements survenus après le 2022-07-06 13:26:00. Par défaut, les filtres timestamp de TimelineExplorer ne permettent pas de spécifier les minutes ou les heures précisément, donc le filtre par défaut sera positionné à 2022-07-06 13:00:00. Cependant, les fonctions DateDiffMinute et DateDiffHour nous permettent de corriger cette imprécision.

On peut affiner le filtre de la manière suivante :

[Timestamp] >= #2022-07-06# And DateDiffHour(#2022-07-06#, [Timestamp]) >= 13 And DateDiffMinute(#2022-07-06 13:00:00#, [Timestamp]) >= 26 And [Computer] = 'Workstation2.tinfa.loc' And Contains([Details], 'Cmdline')

En triant ensuite par criticité, nous trouvons directement les alertes suivantes :

Les détails indiquent le GUID du processus : {b7e8a6b7-b2e8-62c5-e911-00000000d301}. Les détails de l’alerte nous donne l’information suivante : C:\Users\Administrator\AppData\Local\Temp\3\lsass.DMP. Bingo, cela correspond fortement au nom d’un fichier dans lequel un attaquant écrirait son dump lsass.

Cela nous permet de valider le challenge.

Flag : FCSC{b7e8a6b7-b2e8-62c5-e911-00000000d301|C:\Windows\system32\taskmgr.exe}

Conclusion

Ce challenge s’est révélé particulièrement intéressant, car il m’a permis de mettre en pratique plusieurs outils comme Hayabusa, Chainsaw et TimelineExplorer. Globalement, j’ai préféré Hayabusa à Chainsaw, notamment pour la pertinence de ses analyses et le format de ses fichiers de sortie.

TimelineExplorer, bien qu’un peu daté, reste un outil extrêmement utile pour l’analyse des événements. Néanmoins, certaines améliorations pourraient réellement enrichir l’expérience utilisateur : par exemple, la possibilité de créer des groupes de filtres personnalisés et d’associer une couleur à chacun. Cela permettrait, dans un cas comme celui du challenge sur le bruteforce, de visualiser immédiatement les connexions réussies en bleu et les échecs en rouge, ce qui rendrait l’analyse bien plus intuitive.

En résumé, ce challenge m’a permis d’approfondir mes connaissances sur l’analyse des fichiers d’événements Windows, sur les outils Hayabusa et Chainsaw, ainsi que sur TimelineExplorer, le tout au travers d’un challenge très bien construit et agréable à analyser.

Merci ribt pour le challenge, et Itarow pour le Write-up sur lequel j’ai pu m’appuyer.