? 2.16.5. Analyse des images
a) Obtention des informations du vidage de la mémoire
La toute première commande à exécuter
lors d'une analyse de mémoire volatile est : imageinfo, elle vous aidera
à obtenir plus d'informations sur le vidage mémoire. Avec -f
spécifiant votre fichier de vidage et imageinfo le plugin de
volatilité que vous souhaitez utiliser. Vous devriez obtenir le
résultat suivant :

Figure 2.21. Informations du Dump
Nous avons maintenant le système d'exploitation de
l'ordinateur d'où provient ce vidage mémoire (WinXPSP2x86).
L'enquête peut maintenant commencer, nous pouvons spécifier
à volatilité le profil de l'OS (--profile=WinXPSP2x86) et essayer
de trouver ce qui s'est passé sur l'ordinateur de la victime.
b) Liste de processus
Voyons quels étaient les processus en cours
d'exécution utilisant le plugin pslist.


Figure 2.22.Liste de processus Dump mémoire
Une alternative au plugin pslist peut être utilisée
pour afficher les processus et leurs processus parents : pstree

Figure 2.23. Affichage de processus Dump avec Arborescence
À première vue, nous pouvons remarquer un
processus étrange nommé "reader_sl.exe" avec le "explorer.exe"
comme processus parent (PPID) qui était l'un des derniers processus en
cours d'exécution sur la machine.
Exécutions une dernière commande avant
d'approfondir ces deux processus. psxview listera les processus qui essaient de
se cacher lorsqu'ils s'exécutent sur l'ordinateur, ce plugin peut
être très utile.

Figure 2.24. Liste de processus Dump cachés
Nous constatons ici qu'aucun processus ne semble être
caché, si c'est le cas, nous aurions vu False dans les deux
premières colonnes (pslist et psscan).
Rentrons à l'enquête car aucun processus ne se
cache. Après avoir vu les processus en cours d'exécution, une
bonne chose à faire est de vérifier les sockets en cours
d'exécution et les connexions ouvertes sur l'ordinateur. Pour ce faire,
nous allons utiliser ces différents plugins : connscan , netscan et
sockets.

Figure 2.25. Liste de processus ayant ouverts les connexions
à l'ordinateur

Figure 2.26. Liste de processus, leurs ports et protocoles
utilisés
Le plugin connscan est un scanner pour les connexions TCP,
tandis que les sockets imprimeront une liste des sockets ouverts et enfin
netscan (qui ne peut pas être utilisé dans notre exemple en raison
du profil utilisé) scannera une image Vista (ou ultérieure) pour
les connexions et les sockets.
Dans notre scénario, deux connexions TCP sont
utilisées par le processus avec le PID 1484 (en regardant nos sorties
d'historique de commandes, nous pouvons facilement lier le PID 1484 au
processus explorer.exe). Nous pouvons voir que l'une de ces connexions TCP est
toujours ouverte, celle utilisant le port 1038 et communiquant avec l'adresse
IP de destination 41.168.5.140.
Voyons maintenant les dernières commandes
exécutées, en utilisant cmdscan, les consoles et les plugins
cmdline.


Figure 2.27. Commandes stockées du Dump
Les deux premiers plugins : consoles (qui extrait l'historique
des commandes en recherchant _CONSOLE_INFORMATION) et cmdscan (qui extrait
l'historique des commandes en recherchant _COMMAND_HISTORY) ne contenaient
aucune information dans leurs tampons.
Cependant, le plugin cmdline qui affiche les arguments de
ligne de commande du processus nous a donné des informations
intéressantes. En effet, nous avons maintenant le chemin complet des
processus lancés avec les PID 1484 et 1640. Le processus «
Reader_sl.exe » devient de plus en plus suspect...
Jusqu'alors, nous savons que ce processus a été
lancé par le processus explorateur, censé être une
application Adobe Reader classique, cependant nous avons observé une
connexion en cours d'exécution vers une IP externe utilisée par
ce même processus...
Avant de conclure, intéressons-nous à
l'exécutable concerné et à l'analyse de ce dernier en
utilisant respectivement procdump et memdump en précisant le -p 1640
(son PID) et --dump-dir (le répertoire où l'on veut extraire ces
dumps).


Figure 2.28. Exécutable du processus suspect
Le premier fichier "executable.1640.exe" est une restitution
de l'exécutable "Reader_sl.exe" et le dump extrait "1640.dmp"
représente la mémoire adressable du processus.
Ensuite, une simple analyse de ces fichiers peut se faire en
utilisant la commande linux « strings », soyez patient en
général les dumps contiennent beaucoup d'informations. Dans notre
scénario, nous recherchons une relation entre l'information
déjà récupérée du dump (notamment la
connexion tcp ouverte vers l'IP 41.168.5.140) et ce processus 1640.
Essayons de voir le fichier "executable.1640.exe" sur le site
de Virustotal, pour en savoir plus :

Figure 2.29. Analyse de l'exécutable obtenu sur virus
total
|