The Watchman's Residue

Description : “With help from D.I. Lestrade, Holmes acquires logs from a compromised MSP connected to the city’s financial core. The MSP’s AI servicedesk bot looks to have been manipulated into leaking remote access keys - an old trick of Moriarty’s.“

Pour ce challenge nous avons 3 ressources :

• Un dossier d’artefact KAPE

• Un fichier KDBX (Keepass Database)

• Un fichier de capture réseau .pcapng

Difficulté : 🟩🟧◻️ - Medium

Questions

Pour les premières questions, j’ai analysé la capture réseau msp-helpdesk-ai_day5982_section5_traffic.pcapng avec Wireshark afin d’identifier la machine utilisée par l’attaquant pour interagir avec le chatbot MSP-HELPDESK-AI.

Méthodologie

• Filtre principal dans Wireshark : http — la conversation avec l’IA se fait via requêtes HTTP, ce filtre permet d’isoler rapidement les échanges pertinents.

• On parcourt les requêtes HTTP et on inspecte le contenu (POST/GET, body, en-têtes) : les messages échangés avec le chatbot sont inclus dans le corps des requêtes et s’accumulent d’une requête à l’autre, ce qui facilite le suivi de la conversation.

1 - What was the IP address of the decommissioned machine used by the attacker to start a chat session with MSP-HELPDESK-AI? (IPv4 address)

En cherchant dans les requêtes on tombe sur cette conversation :

Si on continue :

Et ce qui vient confirmer qu’on est sur la bonne voie :

En isolant les paquets HTTP correspondant aux échanges suspects avec le chatbot et en suivant la conversation, on peut extraire l’adresse IP source de la machine initiatrice :

✅ Réponse : 10.0.69.45

2 - What was the hostname of the decommissioned machine? (string)

En appliquant le filtre ip.addr == 10.0.69.45 et en inspectant les paquets (en-têtes HTTP, éventuelles requêtes NetBIOS/MDNS, ou payloads contenant des métadonnées), on retrouve le nom d’hôte transmis par la machine :

✅ Réponse : WATSON-ALPHA-2

3 - What was the first message the attacker sent to the AI chatbot? (string)

Le tout premier message visible dans la première requête HTTP contenant le payload de conversation est :

✅Réponse : Hello Old Friend

4 - When did the attacker's prompt injection attack make MSP-HELPDESK-AI leak remote management tool info? (YYYY-MM-DD HH:MM:SS)

Pour cette question, il est nécessaire d’analyser la conversation entre l’attaquant et l’IA :

L’attaquant s’est servi d’une prompt injection qui est une attaque visant les systèmes d’IA conversationnelle. Elle consiste à insérer, dans un prompt envoyée au modèle, des instructions malveillantes ou détournées qui contredisent les règles initiales définies par les développeurs.

la réponse du bot contenant les identifiants apparaît avec le timestamp suivant :

✅Réponse : 2025-08-19 12:02:06

5 - What is the Remote management tool Device ID and password? (IDwithoutspace:Password)

Les identifiants sont fournis par la réponse de l’IA (cf. question précédente).

✅ Réponse : 565963039:CogWork_Central_97&65

6 - What was the last message the attacker sent to MSP-HELPDESK-AI? (string)

Si on cherche dans les derniers messages on peut tomber sur ça :

✅ Réponse : JM WILL BE BACK

7 - What was the RMM Account name used by the attacker? (string)

Rappel de ce qu’est un RMM pour Remote Monitoring and Management, c’est une solution utilisée pour prendre le contrôle à distance des machines. Quelques exemples connus :

• AnyDesk

• TeamViewer

• ScreenConnect

• Etc..

En recoupant les échanges réseau (Wireshark) et les artefacts KAPE (dossiers/ logs TeamViewer récupérés), le nom d’utilisateur RMM visible dans les artefacts correspond aux premières lettres et au nom utilisé dans le chat :

✅ Réponse : James Moriarty

8 - What was the machine's internal IP address from which the attacker connected? (IPv4 address)

En inspectant le fichier Teamviewer15_Logfile.log (présent dans les artefacts KAPE) et en recherchant les adresses IP privées (filtres 192.168.*, 10.*, 172.16.*), on retrouve l’adresse interne utilisée par l’attaquant :

✅ Réponse : 192.168.69.213

9 - The attacker brought some tools to the compromised workstation to achieve its objectives. Under which path were these tools staged? (C:\FOLDER\PATH)

Toujours dans Teamviewer15_Logfile.log, les entrées indiquent l’envoi/déploiement d’exécutables vers un répertoire temporaire sur la machine compromise :

✅ Réponse : C:\Windows\Temp\safe\

10 - Among the tools that the attacker staged was a browser credential harvesting tool. Find out how long it ran before it was closed? (Answer in milliseconds) (number)

Contexte

L’objectif était d’identifier quel outil l’attaquant avait utilisé pour récupérer des identifiants de navigateurs, puis de déterminer à quel moment il l’a exécuté (ouvert/fermé) — en particulier l’intervalle d’exécution en millisecondes.

Outil identifié

Par recoupement (nom de fichier de configuration retrouvé webbrowserpassview.cfg et documentation publique), l’outil utilisé est WebBrowserPassView (https://www.nirsoft.net/utils/web_browser_password.html) . C’est un utilitaire portable qui récupère et affiche les identifiants enregistrés par les navigateurs. WebBrowserPassView crée/actualise un fichier WebBrowserPassView.cfg à la fermeture de l’application, ce qui permet d’utiliser la présence/horodatage de ce fichier comme indicateur de fermeture.

Méthodologie et étapes

1. Extraction du journal USN ($J) : Le journal USN ($Extend\$UsnJrnl:$J) a été exporté depuis les artefacts KAPE.

2. Pour pouvoir le lire plus facilement on utilise MFTECmd pour le transformer en fichier CSV (https://github.com/EricZimmerman/MFTECmd)

MFTECmd.exe -f "$J" --csv "\Desktop\HTB\HTB_Sherlock\watchman\

3. Analyse temporelle avec TimelineExplorer (https://ericzimmerman.github.io/#!index.md) : Le CSV généré est ouvert dans TimelineExplorer pour visualiser les événements (créations/modifications de fichiers, fermetures etc.). Cela permet d’identifier la mise à jour/création de webbrowserpassview.cfg à un instant précis (indiquant la fermeture de l’application).

Et voila ce que ça donne :

En cherchant WebBrowserPassView.cfg :

On sait maintenant l’heure de fermeture de l’application → 10:09:22 .

4. Il faut maintenant trouver l’heure d’ouverture. Après plusieurs recherches dans tout les fichiers possibles, je suis finalement tombé sur NTuser.dat de l’utilisateur Cogwork_admin

Le fichier NTUSER.DAT est un fichier système de Windows qui contient toutes les informations personnelles et les paramètres propres à un utilisateur. Il enregistre par exemple, les préférences du bureau, les configurations des applications, et l’historique de certaines actions (comme les fichiers récemment ouverts ou les programmes lancés).

Pour pouvoir l’exploiter j’utilise Regripper :

rip.exe -r \TRIAGE_IMAGE_COGWORK-CENTRAL\C\Users\Cogwork_Admin\NTUSER.DAT -f ntuser -a > nt_result.txt

Et dans les résultats :

La clé UserAssist dans le fichier NTUSER.DAT sert à enregistrer les programmes et applications exécutés par un utilisateur depuis l’interface Windows (comme le menu Démarrer, l’Explorateur de fichiers ou les raccourcis). Nous avons donc l’heure de début → 10:09:14

Les preuves temporelles combinées (USN + UserAssist) montrent que l’application a été ouverte à 10:09:14 et fermée à 10:09:22, soit une exécution durant 8 s (8000 ms).

✅ Réponse : 8000

11 - The attacker executed a OS Credential dumping tool on the system. When was the tool executed? (YYYY-MM-DD HH:MM:SS)

Les logs TeamViewer signalent le dépôt/exécution d’un binaire identifié comme mimikatz.exe :

Pour confirmer l’exécution et obtenir l’horodatage précis, j’ai recherché mimikatz.exe dans le CSV généré à partir du journal USN ($J) j’ai corroboré avec l’existence d’un fichier Prefetch (mimikatz.exe-*.pf), qui est mis à jour quand Windows lance un exécutable :

✅ Réponse : 2025-08-20 10:07:08

12 - Before exfiltration, several files were moved to the staged folder. When was the Heisen-9 facility backup database moved to the staged folder for exfiltration? (YYYY-MM-DD HH:MM:SS)

Dans les logs Teamviewer :

En recherchant Heisen-9 dans le CSV généré depuis $J (USN Journal), on récupère plusieurs événements liés au fichier (création, déplacement, modification). Ici, le déplacement vers le dossier staged correspond à une seconde entrée temporelle (la première indiquant sa création antérieure).

✅ Réponse : 2025-08-20 10:11:09

13 - When did the attacker access and read a txt file, which was probably the output of one of the tools they brought, due to the naming convention of the file? (YYYY-MM-DD HH:MM:SS)

On peut voir à différents endroits la mention de dump.txt :

Ou encore :

Le journal USN ($J) contient différents types d’événements (FileCreate, DataExtend, Close, etc.). Pour inférer qu’un fichier a été consulté (ouvert puis fermé, donc lu), l’événement pertinent est Close. Les autres n’indiquent que création/modification :

En recherchant dump.txt dans le CSV $J, la première entrée contenant l’événement Close correspond à l’accès/lecture attendu.

✅Réponse : 2025-08-20 10:08:06

14 - The attacker created a persistence mechanism on the workstation. When was the persistence setup? (YYYY-MM-DD HH:MM:SS)

En cherchant les mécanismes de persistance possibles sur un système Windows, j’ai trouvé :

Démarrage automatique via Winlogon / Shell :

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
Userinit (Winlogon\Userinit) 
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify

Pour pouvoir vérifier on ouvre le fichier SOFTWARE via RegistryExplorer (https://ericzimmerman.github.io/#!index.md) :

On peut voir JM.exe qui est un exécutable envoyé par l'attaquant depuis Teamviewer. Maintenant ce que l'on veut c'est quand winlogon a été modifié, on peut voir ça via l'utilisation de RegRipper sur le fichier SOFTWARE :

rip.exe -r \TRIAGE_IMAGE_COGWORK-CENTRAL\C\Windows\System32\config\SOFTWARE -f software > result_software.txt

CTRL+F dans le fichier texte avec Winlogon :

✅Réponse : 2025-08-20 10:13:57

15 - What is the MITRE ID of the persistence subtechnique? (Txxxx.xxx)

En cherchant la sous‑technique correspondant à la persistance via modification de Userinit / Winlogon, on obtient la page MITRE ATT&CK correspondante :

• https://attack.mitre.org/techniques/T1547/004/ (Boot or Logon Autostart Execution: Winlogon Helper DLL)

✅ Réponse : T1547.004

16 - When did the malicious RMM session end? (YYYY-MM-DD HH:MM:SS)

La fin de la session RMM est repérable dans les logs TeamViewer. L’horodatage correspondant à la terminaison de la session est :

✅ Réponse : 2025-08-20 10:14:27

17 - The attacker found a password from exfiltrated files, allowing him to move laterally further into CogWork-1 infrastructure. What are the credentials for Heisen-9-WS-6? (user:password)

Nous avions dans les fichiers à notre disposition un fichier coffre-fort de mot de passe Keepass. Pour pouvoir extraire le mot de passe, on peut utiliser keepass2john, une extension de John the Ripper :

keepass2john acquired_file_critical.kdbx > hash.txt

On utilise en suite John the Ripper pour tenter de cracker le mot de passe avec une attaque par dictionnaire :

Le mot de passe est cutiepie14 , plus qu’à ouvrir le fichier .kdbx :

✅ Réponse : Werni:Quantum1!

The Enduring Echo

Description : LeStrade passes a disk image artifacts to Watson. It's one of the identified breach points, now showing abnormal CPU activity and anomalies in process logs.

Le challenge fournit un répertoire généré par KAPE, contenant plusieurs artefacts Windows fréquemment utilisés en forensic : journaux d’événements (.evtx), ruche(s) de registre (SAM, SYSTEM, NTUSER.DAT…), historiques de navigation, ainsi que des fichiers Prefetch et AmCache.

Difficulté : 🟩◻️◻️ - Easy

Questions

1 - What was the first (non cd) command executed by the attacker on the host? (string)

Pour commencer l’analyse, je me suis concentré sur les journaux d’événements Windows (.evtx) situés dans C:\Windows\System32\winevt\Logs. Ces fichiers permettent de tracer la création de processus, les connexions et autres actions système utiles pour reconstituer l’attaque.

Dans notre cas, celui qui nous intéresse principalement est security.etvx qui est le journal d’événement où l’on peut retrouver par exemple, les tentatives de connexion, les changements de mot de passe, les modifications de droits et de stratégies, ou encore la création de processus.

Les fichiers de logs evtx sont trouvable dans le répertoire : \C\Windows\System32\winevt\logs .

Une fois le fichier security.etvx ouvert, il y a beaucoup de logs avec des dates différentes, pour cela j’essaye de regarder pour chaque date, les eventID 4688 (Process Creation) qui vont souvent être parlant et permettre de voir des comportements suspects, et en cherchant on tombe rapidement sur ces logs :

On observe l’exécution de cmd.exe via WmiPrvSE.exe (WMI). La commande est lancée en mode silencieux et redirige sa sortie vers un fichier temporaire dans le partage ADMIN$. WMI (Windows Management Instrumentation) est une interface système qui permet d’interroger et de contrôler à distance ou localement des composants Windows (processus, services, registres, événements) via des scripts ou des commandes.

En continuant cette fois via CTRL+F à chercher le processus WmiPrvSE.exe , on peut retracer chronologiquement les commandes effectués :

Cela nous permet de trouver la réponse, la toute première command hors cd .

✅Réponse : systeminfo

2 - Which parent process (full path) spawned the attacker’s commands? (C:\FOLDER\PATH\FILE.ext)

Les entrées 4688 et la traçabilité des appels WMI confirment que les commandes ont été lancées via le service WMI. Le processus parent est :

✅ Réponse : C:\Windows\System32\wbem\WmiPrvSE.exe

3 - Which remote-execution tool was most likely used for the attack? (filename.ext)

La méthode d’exécution (WMI, exécution de commandes à distance via WmiPrvSE.exe) correspond au comportement d’un utilitaire bien connu de la suite Impacket.

• Source : https://www.crowdstrike.com/en-us/blog/how-to-detect-and-prevent-impackets-wmiexec/

✅ Réponse : wmiexec.py

4 - What was the attacker’s IP address? (IPv4 address)

En continuant de suivre la trace des commandes via WmiPrvSE.exe on arrive à trouver celle-ci :

On retrouve aussi cette adresse IP si on filtre les EventID 4624 (An account was successfully logged on) qui confirme que l’attaquant s’est connecté depuis cette adresse IP :

✅ Réponse : 10.129.242.110

5 - What is the first element in the attacker's sequence of persistence mechanisms? (string)

La question est un peu piégeuse : il faut comprendre quel identifiant l’attaquant a donné à son premier mécanisme de persistance, et non rechercher le type de mécanisme en soi.

En filtrant les EventID 4688 (Process Creation) et en suivant la chronologie des commandes, on voit la création d’une tâche planifiée nommée :

Cette tâche exécute un script PowerShell toutes les 2 minutes sous le compte SYSTEM il s’agit donc très probablement du premier mécanisme de persistance mis en place par l’attaquant.

✅ Réponse : SysHelper Update

6 - Identify the script executed by the persistence mechanism. (C:\FOLDER\PATH\FILE.ext)

La commande associée à la tâche planifiée montre explicitement le chemin du script PowerShell exécuté pour assurer la persistance. Le script est C:\Users\Werni\AppData\Local\JM.ps1

Ce fichier a également été collecté via KAPE, ce qui permet d’analyser son contenu (création d’utilisateur, exfiltration, modification du pare-feu, activation RDP, etc.).

✅ Réponse : C:\Users\Werni\AppData\Local\JM.ps1

7 - What local account did the attacker create? (string)

En analysant le contenu de JM.ps1, on constate que le script vérifie l’absence de plusieurs comptes préconfigurés :

Puis crée aléatoirement un compte local si nécessaire :

Ajoute ce compte aux groupes Administrators et Remote Desktop Users :

Enfin, le script active le RDP et ouvre la règle pare‑feu correspondante, ce qui donne un accès à distance persistant avec privilèges élevés. Enfin, le script exfiltre immédiatement le couple user|password encodé en Base64 vers http://NapoleonsBlackPearl.htb/Exchange.

La liste des utilisateurs trouvés dans le script est :

• svc_netupd

• svc_dns

• sys_helper

• WinTelemetry

• UpdaterSvc

En croisant avec les événements EventID 4720 (A user account was created) dans security.evtx, on trouve qu’un seul compte a été créé le 25/08/2025 :

✅ Réponse : svc_netupd

8 - What domain name did the attacker use for credential exfiltration? (domain)

Le domaine vers lequel le script exfiltre immédiatement le couple user:password (encodé en Base64) est visible à la fois dans JM.ps1 et dans les logs security.evtx :

✅ Réponse : NapoleonsBlackPearl.htb

9 - What password did the attacker's script generate for the newly created user? (string)

Cette question est piégeuse à cause des fuseaux horaires : la date/heure relevée dans les logs peut varier selon l’environnement du joueur, il faut donc être attentif à la source temporelle utilisée pour reconstruire le mot de passe.

Contexte et stratégie :

• Le script JM.ps1 crée un utilisateur dont le mot de passe suit la convention :
  Watson_yyyyMMddHHmmss

• Nous connaissons le nom de l’utilisateur créé : svc_netupd.

• En croisant les métadonnées ($MFT) et les logs, la date de création pertinente est le 24/08/2025.

• Il restait donc à trouver l’heure exacte (HHmmss) utilisée lors de la génération du mot de passe.

Plutôt que d’essayer d’inférer l’heure depuis des timestamps ambigus, j’ai extrait le NTLM hash du compte local depuis les fichiers SAM et SYSTEM, puis j’ai bruteforcé la portion horaire du mot de passe avec hashcat.

Extraction du hash NTLM :

À partir des fichiers SAM et SYSTEM (récupérés par KAPE), j’ai utilisé la suite Impacket pour dumper les hashes via impacket-secretsdump -sam ./SAM -system ./SYSTEM LOCAL :

Dans la sortie, le hash NTLM du compte svc_netupd est : 532303a6fa70b02c905f950b60d7da51 (J’ai placé ce hash dans un fichier hash.txt pour la suite.)

Bruteforce de la partie horaire avec hashcat

Le format du mot de passe connu : Watson_20250824HHmmss → 6 chiffres inconnus.
J’utilise donc hashcat en mode bruteforce numérique pour ces 6 positions :

hashcat -m 1000 -a 3 hash.txt 'Watson_20250824?d?d?d?d?d?d'

Le masque ?d force la recherche sur les chiffres 0-9. La recherche s’est terminée très rapidement et a révélé le mot de passe complet.

✅ Réponse : Watson_20250824160509

10 - What was the IP address of the internal system the attacker pivoted to? (IPv4 address)

En poursuivant l’analyse des EventID 4688 et des invocations de WmiPrvSE.exe, on tombe sur une invocation de netsh qui met en place une redirection TCP locale.

netsh est un utilitaire en ligne de commande Windows qui permet de visualiser et configurer les paramètres réseau (interfaces, adresses IP, pare-feu, profils Wi-Fi, forwarding/portproxy, etc.). Si on cherche dans les processus créer par netsh on peut tomber sur ça :

La commande crée une règle qui écoute sur toutes les interfaces au port 9999 et qui relaie le trafic vers l’adresse 192.168.11.101 sur le port 22 (SSH). On en déduit que l’attaquant a pivoté vers :

✅ Réponse : 192.168.11.101

11 - Which TCP port on the victim was forwarded to enable the pivot? (port 0-65565)

La redirection netsh sur la machine victime écoute localement sur le port 9999, qui est donc le port forwarded utilisé pour le pivot.

✅ Réponse : 9999

12 - What is the full registry path that stores persistent IPv4→IPv4 TCP listener-to-target mappings? (HKLM......)

D’après les traces et la documentation sur netsh portproxy, les mappings persistants sont stockés dans la ruche SYSTEM sous la clé PortProxy\v4tov4\tcp. (https://adepts.of0x.cc/netsh-portproxy-code/)

On peut trouver la clé de registre via RegistryExplorer et le fichier SYSTEM :

L’instance attendue par le challenge utilise CurrentControlSet (plutôt que un ControlSet numéroté), donc la clé complète est :

✅ Réponse : HKLM\System\CurrentControlSet\Services\PortProxy\v4tov4\tc

13 - What is the MITRE ATT&CK ID associated with the previous technique used by the attacker to pivot to the internal system? (Txxxx.xxx)

La technique correspondante (port forwarding / proxying pour redirection de connexions) est listée sous la sous-technique Proxy (T1090) : Internal Proxy. (https://attack.mitre.org/techniques/T1090/001/)
L’identifiant exact attendu est :

✅Réponse : T1090.001

14 - Before the attack, the administrator configured Windows to capture command line details in the event logs. What command did they run to achieve this? (command)

Les commandes PowerShell de l’administrateur sont visibles dans C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt. On y trouve la commande qui active l’inclusion de la ligne de commande complète dans les événements de création de processus (EventID 4688) via la valeur de registre ProcessCreationIncludeCmdLine_Enabled :

✅ Réponse : reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Du 22 au 26 septembre 2025, j’ai participé au Holmes CTF 2025, organisé par Hack The Box.
Cet événement, orienté Blue Team, proposait une série de challenges centrés sur des thématiques telles que :

• Threat Intelligence

• Investigation SOC

• DFIR (Digital Forensics & Incident Response)

• Reverse Engineering

Le CTF était structuré en cinq grands challenges, chacun composé de 10 à 20 questions à résoudre pour valider l’ensemble.

Sur le plan des résultats, j’ai réussi à terminer 4 challenges sur 5, soit 60 questions résolues sur 65, ce qui m’a permis d’atteindre la 472ᵉ place au classement général.

Passons maintenant au vif du sujet.

The Card Writeup

Description : Holmes receives a breadcrumb from Dr. Nicole Vale - fragments from a string of cyber incidents across Cogwork-1. Each lead ends the same way: a digital calling card signed JM.

Difficulté : 🟩◻️◻️ - Easy

Questions

❓1 - Analyze the provided logs and identify what is the first User-Agent used by the attacker against Nicole Vale's honeypot. (string)

Pour ce challenge, trois fichiers de logs étaient fournis.

• L’objectif ici est d’identifier le premier User-Agent utilisé par l’attaquant.

En analysant le fichier access.log, on peut rapidement repérer, dès les premières lignes, le User-Agent employé par l’attaquant :

✅ Réponse : Lilnunc/4A4D - SpecterEye

❓2 - It appears the threat actor deployed a web shell after bypassing the WAF. What is the file name? (filename.ext)

En poursuivant l’analyse du fichier access.log, on remarque dans les dernières lignes une activité suspecte indiquant le déploiement d’un fichier PHP.

Pour confirmer cette hypothèse, on peut consulter le fichier waf.log.

On y voit que le fichier temp_4A4D.php est détecté comme un web shell, et que l’attaquant s’en sert pour exécuter des commandes sur la machine compromise.

✅ Réponse : temp_4A4D.php

❓3 - The threat actor also managed to exfiltrate some data. What is the name of the database that was exfiltrated? (filename.ext)

En parcourant l’ensemble des fichiers de logs, on trouve plusieurs mentions d’un fichier de base de données nommé database_dump_4A4D.sql.

Dans waf.log, la règle DATABASE_DOWNLOAD est déclenchée lors du téléchargement de cette base.
Cependant, l’action associée est BYPASS, ce qui signifie que le WAF n’a appliqué aucune protection :

✅ Réponse : database_dump_4A4D.sql

❓4 - During the attack, a seemingly meaningless string seems to be recurring. Which one is it? (string)

En analysant les différents fichiers de logs, on remarque qu’une même chaîne de caractères revient fréquemment, aussi bien dans les noms de fichiers que dans les User-Agents observés.

Cette chaîne est la suivante : 4A4D

✅ Réponse : 4A4D

❓5 - OmniYard-3 (formerly Scotland Yard) has granted you access to its CTI platform. Browse to the first IP:port address and count how many campaigns appear to be linked to the honeypot attack.

En plus des trois fichiers de logs, trois instances Docker étaient également fournies.
Pour cette question, nous devons utiliser la première instance, qui donne accès à une plateforme de Cyber Threat Intelligence.

Via la plateforme on peut comprendre que 4A4D est un code hexadécimal qui se traduit par JM , la bulle au milieu en verte représente donc un acteur de menace qui est relié par plusieurs campagnes d’attaques qui lui sont attribué :

En comptant les liens visibles sur la plateforme, on obtient la réponse.

✅ Réponse : 5

❓6 - How many tools and malware in total are linked to the previously identified campaigns? (number)

D’après la légende du graphe CTI :

• Les malwares sont représentés par des bulles rouge sombre accompagnées de l’émoji 🦠

• Les outils sont représentés par des bulles marron clair accompagnées de l’émoji 🔧

En observant les cinq campagnes associées à l’acteur JM, et en comptant tous les outils et malwares qui leur sont liés, on obtient :

✅ Réponse : 9

❓7 - It appears that the threat actor has always used the same malware in their campaigns. What is its SHA-256 hash? (sha-256 hash)

Sur le graphe CTI, chaque malware est décrit par un IOC (Indicator of Compromise). Ici, il s’agit systématiquement d’un hash SHA-256 :

Pour les cinq campagnes attribuées à l’acteur JM, le même SHA-256 est utilisé, ce qui confirme l’emploi d’un malware identique sur l’ensemble des campagnes.

✅ Réponse : 7477c4f5e6d7c8b9a0f1e2d3c4b5a6f7e8d9c0b1a2f3e4d5c6b7a8f9e0d17477

❓8 - Browse to the second IP:port address and use the CogWork Security Platform to look for the hash and locate the IP address to which the malware connects. (Credentials: nvale/CogworkBurning!)

En accédant à la deuxième instance Docker (la plateforme CogWork Security) et en recherchant le hash SHA-256 indiqué, on obtient les informations réseau associées au malware :

Notamment la section Network Communication :

✅ Réponse : 74.77.74.77

❓9 - What is the full path of the file that the malware created to ensure its persistence on systems? (/path/filename.ext)

Toujours sur la plateforme CogWork, en ouvrant View Details sur la page du malware :

Et en consultant la section File Operations, on observe le fichier utilisé pour la persistance :

✅ Réponse : 4a4d_persistence.sh

❓10 - Finally, browse to the third IP:port address and use the CogNet Scanner Platform to discover additional details about the TA's infrastructure. How many open ports does the server have?

La troisième instance Docker (CogNet Scanner) permet de scanner l’IP malveillante précédemment identifiée (74.77.74.77) :

Le scan révèle que le serveur dispose de 11 ports ouverts.

✅ Réponse : 11

❓11 - Which organization does the previously identified IP belong to? (string)

Dans les résultats de recherche, on clique sur Details pour obtenir les informations complètes relatives à l’adresse IP :

En consultant la section Organization, on peut identifier l’entité à laquelle cette adresse est associée :

✅ Réponse : SenseShield MSP

❓12 - One of the exposed services displays a banner containing a cryptic message. What is it? (string)

Pour la dernière question, on reste dans la section Details :

L’onglet Services permet d’obtenir une vue détaillée des ports ouverts et des bannières associées.
En parcourant la liste, on trouve un service affichant le message suivant :

✅ Réponse :He's a ghost I carry, not to haunt me, but to hold me together - NULLINC REVENGE

Avec cette dernière question, le premier challenge est terminé.
Comme il s’agissait d’un challenge d’introduction, il n’était pas particulièrement difficile, mais il posait efficacement les bases pour la suite des investigations.