Skip to main content

Chapitre 4.3 Quiz - Reponse aux incidents et forensique numerique

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Vous acqui sez la memoire d'un hote Windows suspecte d'etre compromis et executez le plugin malfind de Volatility. Il retourne un resultat pour svchost.exe (PID 1234) montrant une region memoire a l'adresse 0x1a0000 avec les permissions PAGE_EXECUTE_READWRITE et les premiers octets 4D 5A 90 00. Qu'est-ce que cela indique, et quelles sont les trois prochaines etapes d'investigation ?

Reveler la reponse

Reponse : Cela indique une injection de PE reflechissante dans svchost.exe.

Explication :

  • PAGE_EXECUTE_READWRITE (RWX) : Une memoire simultanement executable, lisible et inscriptible est un indicateur fort de code injecte. Les sections de code legitimes dans les executables compiles correctement sont soit RX (execution uniquement) soit RW (donnees), jamais RWX simultanement.
  • 4D 5A 90 00 : C'est le header MZ - la signature DOS d'un fichier Windows Portable Executable (PE). Un fichier PE trouve dans la region heap/pile d'un processus en cours (pas dans une section d'image mappee) signifie qu'un executable complet a ete injecte dans la memoire du processus et s'y execute - logiciel malveillant sans fichier sans artefact sur le disque.

Trois prochaines etapes d'investigation :

Etape 1 - Extraire le PE injecte pour analyse

python3 vol.py -f memory.lime \\
  windows.memmap \\
  --pid 1234 \\
  --dump
# Produit : pid.1234.dmp

# Extraire le MZ/PE du dump en partant de l'offset identifie
python3 -c "
with open('pid.1234.dmp', 'rb') as f:
    data = f.read()
mz_offset = data.find(b'MZ')
with open('/evidence/injected_pe.exe', 'wb') as f:
    f.write(data[mz_offset:mz_offset+10485760])  # Extraire jusqu'a 10Mo
"
# Soumettre a VirusTotal / executer via YARA / analyse statique avec strings
strings /evidence/injected_pe.exe | grep -E "http|cmd|powershell|inject"

Etape 2 - Identifier la source de l'injection (chaine de processus parent)

python3 vol.py -f memory.lime windows.pstree
# Trouver PID 1234 (svchost) et son parent
# svchost.exe devrait TOUJOURS etre un enfant de services.exe (PID ~680)
# Si le parent est powershell.exe, cmd.exe ou tout non-services.exe - lanceur malveillant

python3 vol.py -f memory.lime windows.cmdline --pid 1234
# Quelle ligne de commande a ete utilisee pour demarrer ce svchost ? Arguments non standard = injecteur

Etape 3 - Extraire les connexions reseau depuis le processus injecte

python3 vol.py -f memory.lime windows.netstat
# Filtrer pour PID 1234 - a quelles IPs externes est-il connecte ?
# Ce sont des infrastructures C2 - extraire les IPs pour le renseignement sur les menaces,
# les blocages pare-feu et la correlation PCAP

MITRE ATT&CK : T1055.002 (Injection de processus : Injection de Portable Executable), T1055 (Injection de processus)

Question 2

Lors d'une reponse aux incidents, vous constatez que la compromission initiale a eu lieu il y a 3 semaines mais n'a ete detectee qu'aujourd'hui. L'attaquant a ete present dans l'environnement pendant 21 jours. Listez les cinq artefacts forensiques les plus importants a collecter, par ordre de priorite, et expliquez ce que chacun revele sur la periode de persistance de 21 jours.

Reveler la reponse

Reponse :

Priorite 1 - Images memoire de tous les hotes probablement compromis (collecter immediatement)

La memoire est volatile - un redemarrage la detruit. Apres 21 jours, l'attaquant a probablement des points d'appui persistants, mais les sessions C2 actives, le shellcode injecte, les identifiants mis en cache et les donnees de configuration dechiffrees n'existent que dans la RAM.

# Capturer avant toute action de confinement pouvant declencher un redemarrage
# Pour chaque hote probablement compromis :
sudo insmod lime.ko "path=tcp:4444 format=lime"
# Revele : connexions C2 actives, code injecte, identifiants dans la memoire LSASS

Priorite 2 - Journaux SIEM pour la fenetre complete de 21 jours (depuis le stockage central)

Le SIEM dispose deja des donnees - extraire la chronologie complete pour toutes les entites affectees. Cela reconstruit toute la chaine de compromis sans toucher aux endpoints potentiellement compromis.

# Elastic : exporter la fenetre complete de 21 jours pour les hotes affectes
curl -X GET "https://elasticsearch:9200/logs-*/_search" \\
  -d '{"query":{"bool":{"must":[
    {"range":{"@timestamp":{"gte":"now-21d"}}},
    {"terms":{"host.name":["WORKSTATION-01","DC01","FILESERVER"]}}
  ]}},"size":10000}'
# Revele : chronologie complete des TTPs de l'attaquant, tous les comptes touches, tous les hotes accedes

Priorite 3 - Journaux d'audit Active Directory + NTDS.dit (si le DC a ete accede)

21 jours suffisent pour que l'attaquant ait cree des comptes de porte derobee, modifie des appartenances aux groupes ou effectue DCSync. Les journaux AD et NTDS.dit revelent chaque changement de compte.

# Exporter NTDS.dit (hors ligne - monter l'image DC)
# Comparer l'etat AD actuel avec la sauvegarde d'avant la compromission :
# - Nouveaux comptes crees (comparer les horodatages objectWhenCreated)
# - Changements d'appartenance aux groupes (Evenement 4728/4732)
# - Modifications AdminSDHolder (persistance de privileges furtive)

Priorite 4 - Journaux pare-feu/proxy pour l'identification de toute l'infrastructure C2

21 jours de trafic C2 dans les journaux pare-feu/proxy revelent toute l'infrastructure externe utilisee par l'attaquant. Essentiel pour : determiner le volume d'exfiltration de donnees, identifier tous les domaines/IPs C2 pour le blocage, et comprendre la portee complete de la communication sortante.

# Extraire toutes les destinations externes uniques pour les hotes compromis sur 21 jours
# Splunk :
index=firewall src_ip IN (compromised_host_list)
| stats sum(bytes_out) as total_out by dest_ip, dest_port
| sort - total_out
| head 50
# Revele : IPs C2 (connexions repetees), destinations d'exfiltration (volume d'octets eleve)

Priorite 5 - Images disque des points de pivot confirmes et de l'hote de compromission initiale

L'hote de compromission initiale a les artefacts les plus anciens de l'attaquant - le dropper, l'exploit original, le premier mecanisme de persistance. La forensique disque avec Plaso cree une chronologie definitive de l'activite de l'attaquant depuis le premier jour.

# Etablir la chronologie de l'hote de compromission initiale
log2timeline.py --storage-file /evidence/host01.plaso /mnt/host01_image/
psort.py -o l2tcsv -w /evidence/host01_timeline.csv /evidence/host01.plaso
# Revele : methode d'acces initial exacte, outils deposes, persistance etablie,
#          horodatages de mouvement lateral

Contexte MITRE ATT&CK : Le long temps de persistance est particulierement associe aux acteurs APT. La fenetre de 21 jours requiert une determination complete de la portee - supposer que tous les comptes Administrateur de domaine et tous les serveurs auxquels l'attaquant pouvait acceder sont compromis jusqu'a ce que l'investigation forensique les ait claires.

Question 3

Une sortie pstree de Volatility montre cmd.exe (PID 3412) comme enfant de svchost.exe (PID 2100). svchost.exe lui-meme a services.exe comme parent. Expliquez pourquoi cette relation de processus est suspecte, quelle technique de persistance ou d'execution specifique elle suggere, et les deux commandes pour investiguer davantage.

Reveler la reponse

Reponse : cmd.exe comme enfant de svchost.exe est suspect car svchost.exe heberge des services Windows - il execute des DLL de service, pas des shells de commande interactifs. Les processus svchost.exe legitimes ne spawent jamais cmd.exe dans des conditions normales de fonctionnement.

Ce que cette technique suggere :

Ce modele est caracteristique de l'execution de service malveillant (T1543.003) ou de l'execution de commande WMI (T1047). L'attaquant a soit :

  1. Installe un service malveillant qui, lorsque demarre par services.exe, execute svchost.exe qui lance un shell de commande - c'est le modele psexec (cree un service PSEXECSVC qui spawne cmd.exe)

  2. Creation de processus WMI via Win32_Process.Create() - WMI s'execute sous svchost.exe (hebergeant le service WMI) et spawne des processus enfants depuis la

Le svchost.exe parent hebergeant des services legitimes (PID 2100 avec parent services.exe) est normal. Le cmd.exe enfant est l'anomalie.

Deux commandes d'investigation :

# Commande 1 - Obtenir la ligne de commande complete des deux processus
python3 vol.py -f memory.lime windows.cmdline \\
  --pid 2100     # Quel service cette instance svchost heberge-t-elle ?
# svchost.exe -k netsvcs - heberge de nombreux services ; verifier les DLL chargees
# svchost.exe -k WbemSvc - service WMI - suggere fortement l'execution WMI
# svchost.exe -k secsvcs - Centre de securite - inhabituel pour un enfant cmd.exe

python3 vol.py -f memory.lime windows.cmdline \\
  --pid 3412     # Quelle commande cmd.exe execute-t-il ?
# cmd.exe /c net user hacker /add   - creation de compte
# cmd.exe /c powershell -enc ...    - PowerShell etape 2
# Revele la commande reelle de l'attaquant executee

# Commande 2 - Verifier les DLL chargees par le svchost parent (confirmer quel service)
python3 vol.py -f memory.lime windows.dlllist \\
  --pid 2100
# Chercher : DLL inhabituelles depuis des repertoires temporaires, DLL modifiees recemment,
# DLL sans signatures Microsoft
# Une DLL de service malveillante apparait ici aux cotes des legitimes

Corroboler avec l'ID d'evenement 7045 (nouveau service installe) dans le journal d'evenements Securite - si un service a ete cree recemment, son nom et le chemin de son binaire seront la.

MITRE ATT&CK : T1543.003 (Creer ou modifier un processus systeme : Service Windows), T1047 (Windows Management Instrumentation)

Question 4

Lors d'une analyse forensique, vous constatez qu'un fichier sur l'hote compromis a un horodatage de creation $STANDARD_INFORMATION du 2024-01-15 mais son horodatage de creation $FILE_NAME est le 2023-08-03. Qu'est-ce que cette discordance indique, et comment affecte-t-elle votre analyse de chronologie ? Quel outil detecte cela automatiquement ?

Reveler la reponse

Reponse : Cette discordance indique une modification d'horodatage (timestomping, T1070.006) - une technique d'evasion de defense ou un attaquant modifie les horodatages de fichiers pour faire apparaitre les fichiers malveillants plus anciens qu'ils ne le sont, ou pour se fondre avec les fichiers legitimes.

Explication technique :

NTFS maintient les horodatages dans deux structures d'attributs separees par fichier :

  • $STANDARD_INFORMATION (SI) : Les horodatages affiches par l'Explorateur Windows, dir, ls. Facilement modifies par toute application en utilisant des appels API standards (SetFileTime()). C'est ce que les attaquants manipulent.
  • $FILE_NAME (FN) : Horodatages maintenus par le pilote du noyau NTFS lui-meme, mis a jour quand l'enregistrement MFT est modifie. Beaucoup plus difficiles a modifier sans acces noyau ou outils specialises.

Quand les horodatages $SI sont anterieurs aux horodatages $FN, c'est impossible - $FN est defini a la creation du fichier et le fichier ne peut pas avoir ete cree dans le systeme de fichiers avant l'existence de son propre enregistrement MFT. C'est une impossibilite forensique qui prouve la manipulation.

Interpretation dans ce cas :

  • Creation $FN = 2023-08-03 - Le fichier a reellement ete place sur le systeme de fichiers le 3 aout 2023
  • Creation $SI = 2024-01-15 - Un attaquant a change l'horodatage visible au 15 janvier 2024 pour cacher son veritable age

Plus couramment, les attaquants changent $SI a une date plus ancienne pour faire apparaitre un outil recemment depose comme s'il etait la depuis des annees.

Impact sur l'analyse de chronologie : Les horodatages $SI ne peuvent pas etre dignes de confiance pour les fichiers affectes - ils ne representent pas l'activite reelle du systeme de fichiers. Utilisez les horodatages $FN pour la chronologie forensique, car ce sont les donnees de reference.

Outil de detection automatique :

# analyzeMFT - detecte automatiquement les discordances d'horodatages $SI/$FN
pip install analyzeMFT

analyzeMFT.py \\
  -f /mnt/evidence/\\\\$MFT \\
  -o /tmp/mft_analysis.csv \\
  -a                                  # -a : detection d'anomalies (timestomping)

# La sortie inclut une colonne "Possible Timestomp"
# Filtrer pour les anomalies :
grep "Timestomp" /tmp/mft_analysis.csv | head -20

# Verification manuelle avec TSK :
istat -o 2048 /evidence/sda.img INODE_NUMBER
# Comparer les horodatages dans les blocs d'attributs SI vs FN

MITRE ATT&CK : T1070.006 (Suppression d'indicateurs : Timestomp) - cela est specifiquement concu pour contrecarrer l'analyse forensique basee sur les horodatages et est un indicateur fort d'un attaquant sophistique qui anticipait l'investigation forensique.

Fin du Quiz 4.3 - Reponse aux incidents et forensique numerique