Cette série d’épreuve est issue du FCSC 2025 organisé par l’ANSSI :) Merci aux challs makers & à l’organisation !!

1/5 - Exfiltration

Avant de démarrer les challenges, je lance VolWeb pour m’aider dans la visualisation des données.

Dans le plugin netscan :

On voit rundll32.exe qui initie une connexion vers l’extérieur, ce qui est un comportement absolument anormal. On en déduit donc le flag FCSC{rundll32.exe:1800:100.68.20.103:443:TCP}

2/5 - Origine de la menace

On souhaite ici savoir le PPID de rundll32.exe (PID 1800). On voit ici dans le Process tree le processus parent de rundll32.exe : svchost.exe. On remarque aussi que ce processus semble légitime au vu des autres enfants de svchost.ext.

On obtient donc le flag FCSC{svchost.exe:936}

3/5 - Où est le pansement ?

Ça se corse!! On a compris dans le challenge précédent que svchost.exe (PID 936) est légitime mais a été vérolé d’une manière ou d’une autre. L’attaquant a probablement pu injecter du code exécutable dans svchost.exe pour changer son comportement. On doit donc retrouver le thread qui a “empoisonné” notre svchost.exe

Fun fact, il y a très peu de ressources sur internet à ce sujet ;)

Je me retrousse les manches et j’y vais :

Je me suis focus sur ces modules là, bien évidemment disponible sur volatility3.

On sait que c’est le processus parent (svchost.exe PID 936) qui a enfanté de rundll32.exe PID 1800. Ce sont donc les deux processus sur lesquels je vais concentrer mon attention.

Je filtre les threads sur le PID 936 :

Et j’aperçois une StartAddress qui diffère des autres, bingo, non? Alors, pas vraiment.

Je lance MemProcFS (./MemprocFS -forensic 1 -device analyse-memoire.dmp) et j’ouvre le fichier M:\pid\936\threads.txt dans TimelineExplorer.

Dans TimelineExplorer, on retrouve notre StartAddress un peu suspecte

Ma première hypothèse était que le thread avec l’ID 620 était vérolé au vu de la différence de StartAdress. Quand on regarde la doc de MemProcFS (RTFM??), on s’aperçois que le champs Win32StartAddress n’est même pas référencé… On remarque que même VolWeb ne référence pas non plus Win32StartAddress.

Pas le choix, je fut obligé d’aller sur des forums de reverser….

Doc de microsoft :

On comprend vaguement dans la dernière capture que Win32StartAddress correspond à l’adresse mémoire de début du thread (argument de CreateThread) uniquement du point de vue de l’application, mais qu’elle est différente de StartAddress qui elle, est du point de vue de l’OS.

On peut faire le lien avec cette indication dans l’énoncé :

Et c’est à ce moment là que l’on peut s’arrêter quelques secondes sur les adresses dans Win32StartAddress :

Il semblerait que l’on ai notre thread malveillant (TID 940) et notre adresse virtuelle du point de vue du processus 0x7ff717e652e0. Pas si vite ! On cherche l’adresse du début de la page mémoire au format 0x%016x. Il n’y a plus qu’à chercher….

On tombe sur cette doc de Microsoft qui nous explique comment traduire des adresses mémoires. La doc est plus ou moins claire mais on apprend que :

Les pages font 4096 octets , soit 0x1000 en hexadécimal.

Après une bonne aprèm de lecture de doc kernel (coup dur), j’ai compris que pour aligner l’adresse de mémoire virtuelle du thread (0x7ff717e652e0) avec le début de sa page, sachant qu’une page fait 4096 bits donc 0x1000 en hexadécimal, il fallait faire un AND logique pour retrouver son adresse de départ. C’est ce que le dernier screen tente de nous dire :p

Dooonc (en bash, pas zsh) :

ADDR=0x7ff717e652e0
printf "0x%016x" $((ADDR & 0xfffffffffffff000))

Ce qui nous donne : 0x00007ff717e65000. On obtient enfin notre flag : FCSC{940:0x00007ff717e65000}. First blood baby :p

4/5 - Un échelon de plus dans la chaîne

On continu dans le corsé : L’attaquant a probablement laissé un device persistant sur le système. Ce device continue d’émettre vers le C2 malgré une réinstallation complète du système d’exploitation. On se retrousse les manches et on y va :

Ces quatre plugins Volatility seront d’une grande aide. J’ai commencé par lister les devices dans devicetree

Je ne connais pas tous les devices légitimes sur un système d’exploitation Windows, alors j’ai commencé par chercher ceux avec un nom bizarre, et, si on est chanceux, il sera au début de la liste car il est chargé au tout début du démarrage.

On repère assez vite, si on sait que c’est là qu’il faut chercher, le nom Dummy qui fais un peu tache au milieu des noms très sérieux comme DeviceApi ou WindowsTrustedRT.

Après des recherches Google, rien sur internet ne référence un Device/Driver Windows nommé Dummy à proprement parlé.

Si on jette un oeil dans le plugin DriverIrp (pour I/O Request Packet), on voit que notre suspect dispose de beaucoup de permissions pour un device/driver nommé Dummy.

Si on change de plugin pour DriverModule, on retrouve encore une fois notre suspect :

Et pour finir, on retrouve encore et toujours notre suspect dans DriverScan :

Avec cette fois un nom qui dénote, il ne démarre pas avec un \ comme les autres.

Tout cela nous mène à la conclusion que le device name recherché est HarddiskVolume9, qui est lié au DriverName Dummy :

Flag : FCSC{HarddiskVolume9}

5/5 - Le commencement

Le dernier ptit gars, allons y : On obtient un nouveau fichier csv extrait grâce à DFIR-ORC. On sait aussi que le Secure boot et l’UEFI était activé, ce qui devrait empêcher un driver comme celui du challenge précédent d’agir comme cela. Il doit utiliser une vulnérabilité encore peu connue pour altérer la séquence de démarrage.

Une petite dork s’impose :

C’est prometteur. Si on regarde le troisième lien, on tombe très vite sur un nom de fichier spécifique à cet exploit : cloak.dat

Et bingo, notre fichier est présent dans le CSV.

Pour finir cette très belle série de challenge, le dernier flag : FCSC{CVE-2024-7344:cloak.dat}.

Conclusion

C’était loin d’être aussi simple que dans le write-up!!! De nombreuses heures ont été gaspillées à errer sur internet à la recherche d’info sur les threads notamment. De même pour les devices, je n’avais pas vu le Dummy au départ et j’ai donc passé 1h30 dans le vent à chercher tous les noms des devices sur internet voir s’ils étaient légitime. Merci aux challs makers et bravo le FCSC :)