# **TP 2 Digital Forensic**
*Groupe 6 : CHAUVIN Baptiste & JEUSSET Malo*


1- A l'aide de la commande "volatility -f bsi.win.mem imageinfo", on obtient :


On peut ainsi en déduire que le profil le plus probable est le "Win4SPx64" car c'est le plus connu/basique de tous ceux proposés.
Le service pack est alors le 1 en 64 bits.


2- A travers la capture, on peut observer la date de quand l'image a été acquise, c'est-à-dire le 5 août 2019 à 17h12 et 32 sec : 



1- Au moment de l'acquisition, on retrouve 34 processus actifs (la commande nous indique 36, mais on enlève les deux premières lignes):


2- Un seul processus était terminé à ce moment là :


3- Nous avons trouvé quatre processus n'appartenant pas à Microsoft : 

 PID : 472
 PID : 692
 PID : 2080
 PID : 1060


Aucunes des zones données à la sortie du plugin malfind ne contiennent des entêtes commençant d'Exécutable Portable (MZ en début de zone). Quelques exemples ci-dessous



1- Comme nous pouvons le constater sur la capture ci-dessous, une ligne nous a interpellé.
2- Elle nous semble suspecte car tout simplement, elle exécute bw.bin alors que Python n'est pas censé l'exécuter.



1- Aucune connexion nous semble anormale.
2- Une adresse IP nous semble suspecte. Celle-ci est une IPv6 (destination) qui est indiquée comme étant "CLOSED". En effet, de toutes les IPs indiquées, c'est la seule affichant cet état.


3- Si l'on se fie aux PIDs vus auparavant, aucun PID ne correspond aux applications précédemment, et donc aucune connexion active.


1- Lors de l'analyse de la mémoire persistante, nous avions des doutes sûr le programme update.exe. On retrouve des informations ici :



1- En utilisant la commande grep, on peut retrouver le nom de domaine, le nom d'utilisateur, l'IP de l'utilisateur via une tentative de connexion à un serveur local : 


2- En cherchant dans le 2080.dmp, on peut retrouver des informations liées au code source, notamment avec une requête HTTP POST.


3- cf question 1. On peut voir que l'utlisateur cherche à joindre le serveur 192.168.10.20.

4- On va rechercher des informations en rapport avec bw.bin (cf ci dessous). 




1- D'après la capture ci-dessous, on retrouve l'adresse du début soit "0x000000013f1d0000", et l'adresse de fin "0x000000013f1d9fff".
2- Il faut convertir les deux adresses en octets pour ensuite soustraire celle de fin à celle de début. On obtient alors "47707200000" pour l'adresse du début et "47707317777", puis 47707317777 - 47707200000 qui vaut 117 777.
   La taille en octet de la zone est alors de 117 777 octets.
3- En reprenant le résultat de la question précédente, et en sachant qu'une page équivaut à 4086 octets, nous avons juste à faire : 117 777 / 4096 = 28,75
   On obtient alors un résultat d'environ 28,75 pages pour cette zone.



1- Pour ce qui est du binaire, Yara trouve une seule correspondance. Quant au dump, il en trouve quatre (cf capture ci-dessus).
2- Le plugin yarascan ne détecte rien.


1- Les recherches effectuées sur la mémoire vive de la machine permettent de poursuivre les recherchent faites sur la mémoire persistente, tout en allant un peu plus loin dans la recherche. C'est-à-dire que l'on approfondit nos recherches afin d'en apprendre davantage sur l'attaque.

2- En cherchant plus loin, on peut remarquer qu'un service contient les mêmes fonctions que celles de python (PID 2080). Cela nous interpelle car étant donnée que python n'est pas fiable, il se pourrait que conhost.exe ne le soit non plus.


3- On peut donc affirmer que toutes les données dans le dump du processus de python ne lui appartiennent pas seulement, elles appartiennent aussi au processus conhost.exe.