Forensic et Mat 2/2 (Forensics) - 404CTF2025

Principe:
Recherche, dans les events Windows, la connexion, l'élevation de privilèges, la persistence et la phase d'exécution d'une machine compromise

Infos (cf menu latéral):
🚩 Flaggué! +100 points gagnés — 💾 Téléchargez les fichiers du challenge
404CTF{10.66.77.88-4444-svc-x-WinUpdate_Check_75312-1747245628-Administrateurs}

Le challenge

L'énoncé du challenge

Sans viewer?

Une première piste possible est d'essayer de convertir le fichier d'event en UTF8, histoire de pouvoir le manipuler facilement sans éditeur tiers… mais fail!

Event viewer

On va donc faire plus simple, en utilisant libevtx-utils comme viewer
On peut alors exporter les events Windows, et les analyser
En cherchant quelques mots clefs (flag, payload, attack etc), on trouve un event de création d'une tâche planifiée suspecte
A partir du nom ou du chemin de la tâche, on retrouve l'event de son exécution et on peut voir son moment d'exécution

Étape par étape

Afin de ne pas partir dans tous les sens, revenons au flag demandé: on va en chercher les composants 1 à 1, en remontant ou déroulant les évènements à partir de la tâche planifiée trouvée, dont on a déjà le nom

Un élément en revanche n'est pas clair: timestamp. Mais de lequel? Le moment d'éxécution de la tâche? Sa création? La première compromission de la machine? On verra plus tard si cela s'éclaircit…

Remonter le fil

Dans l'évènement de création de la tâche, on trouve le user qui l'a créée
En remontant les évènements, on trouve la connection distante à ce compte utilisateur

De cela, on tire toutes les informations du flag: IP et port de la machine qui s'est connectée (IP et port distants donc, pas ceux de la machine compromise car ces informations n'ont pas grand intérêt), nom de l'utilisateur sur la machine (là, étonnant d'avoir un - car ce caractère sert aussi de "séparateur" dans le flag, mais bon), nom de la tâche, et groupe auquel l'utilisateur a été rajouté (on retrouve l'information dans un autre évent concernant svc-x)

Il nous manque quand même le timestamp. Pour le coup, j'ai demandé à un admin s'il pouvait clarifier ce point. N'ayant eu qu'une réponse vague, histoire qu'il ne m'aiguille pas, j'ai tenté une première valeur: la date de première compromission sur la machine (la connexion au compte)

Loupé, le flag n'est pas bon

Comme l'admin m'avait évoqué qu'il s'agissait de la "date pivot", je tente alors un autre timestamp: celui de création de la tâche. En effet, cela s'azpproche le plus du "pivot" évoqué. Personnellement, je trouve que le timestamp le plus important aurait été la compromission sur la machine (connexion réussie) puis l'élevation de privilège (2e timestamp important), puis l'exécution du payload en lui-même (3e timestamp important). Je n'aurai placé la persistence qu'en 4e place.

C'est le bon timestamp, et le flag passe!

Flag: 404CTF{10.66.77.88-4444-svc-x-WinUpdate_Check_75312-1747245628-Administrateurs}