# Investigation Numérique

---

LETOURNEUR Raphaël - e2004663 / DAUGA Yanis - e2004785
*14/10/2022*

---

## Score

## Schéma Réseau

## 1- Introduction
> Quelle est l'IP du serveur mis sous interception ?


Nous regardons dans le champs `layer.ip_scr`. Nous retrouvons notre IP du serveur mis sous interception → **172.16.32.24**

## 2- Ports ouverts
> Quel(s) port(s) applicatif(s) sont ouvert par défaut sur le serveur sous interception ?


Nous regardons le champs `layers.tcp_srcport`. Nous remarquons que seul le port **22** est à la fois un port applicatif et un port présent dans nos logs.

## 3 - Administration
> Quelle est l'adresse IP de l'attaquant ?

Pour trouver l'IP de l'attaquant, nous commençons par filtrer les logs en demandant seulement ceux où le port de destination est **22** →`index="tp_ecole" "layers.tcp_dstport"=22`


On retrouve l'IP → **172.16.37.71**

## 4 - Heures d'activités

> Une période d'activité de l'attaquant semble se dessiner. Quelle est cette plage (en UTC) horaire ?

Pour pouvoir reconnaître la plage horaire, nous allons calculer le volume de données échangées par heure via les champs `date_hour` et `layers.frame_len`.

`index="tp_ecole" "layers.tcp_srcport"=22 | stats sum(layers.frame_len) by date_hour | sort date_hour`


Nous retrouvons une plage allant de **7h à 15h UTC** soit **9h 17h GMT+2(FR)**.

## 5 - Nombre d'IP en sortie
> Combien d'adresses IP distinctes le serveur malveillant contacte il ?

Lors de l'initiation d'une connexion TCP entre un client et un serveur, 3 paquets sont envoyés. Un paquet **SYN**, un **SYN-ACK** et un **ACK**.


Nous nous concentrerons, ici, sur les paquets **SYN-ACK** car les paquets **SYN** et **ACK** sont utilisé tout le temps et ne sont donc pas adaptés à notre besoin. Dans notre cas, nous cherchons les **SYN-ACK** dont l'IP destination est celui de notre serveur infecté.

Pour ce faire, nous utiliserons la recherche suivante: `index="tp_ecole" "layers.ip_dst"="172.16.32.24" | regex _raw="(.*)\[SYN, ACK\]"`
Ici, nous commençons par filtrer les logs avec notre IP **172.16.32.24**. Nous utilisons, ensuite, une regex permettant de ne récupérer que les requêtes correspondant à un **SYN-ACK**.


Avec plusieurs dizaines de minutes de traitement, nous trouvons 11 IPs distinctes.

*(Nous remarquons rapidement qu'une IP sort du lot. En effet, l'IP **172.16.64.28** a été contactée 110 727 fois contre 59 fois pour la deuxième IP la plus contactée. Celle-ci doit donc être intéréssante pour la suite de notre investigation.)*

## 6 - Intérêt de l'attaquant
> Une adresse IP semble intéresser l'attaquant... Quel est le nom de domaine associé à cette adresse IP ?

Nous avons remarqué précédement que l'adresse IP **172.16.64.28** a été tapée à de multiples reprises.

Pour trouver le nom de domaine, nous allons nous intérésser aux requêtes DNS.

Pour ce faire, utilisons le champs`dns_a`. Ce champs contient l'IP que l'on souhaite reverser *(Obtenir le nom de domaine via une IP)*.


Suite à cela, le champs `layers.dns_qry_name` nous donne l'information du domaine correspondant à l'IP 172.16.64.28. Celui-ci est **boussolecorp.com**.

## 7 - Outil utilisé
> Quel est le 1er outil utilisé par l'attaquant ?

Nous sommes partie du postulat que le premier outil utilisé par un attaquant était **NMAP**.

Nous allons donc le vérifier. Pour ce faire, nous cherchons, via la recherche suivant `index="tp_ecole" nmap`, si les requêtes contiennent le mot NMAP. Et effectivement, nous remarquons que le champs `layers.http_user_agent` contient bien le string **NMAP**


## 8 - Traceroute ?

Le principe de fonctionnement de Traceroute consiste à envoyer des paquets UDP (certaines versions peuvent aussi utiliser TCP ou bien ICMP ECHO Request) avec un paramètre Time-To-Live (TTL) de plus en plus grand (en commençant à 1). Chaque routeur qui reçoit un paquet IP en décrémente le TTL avant de le transmettre.


Ici, nous insérons dans notre requête l'IP source et l'IP destination. Par la suite, nous affichons le champs `layers.ip_ttl` permettant de récupérer les TTL (Time To Live).

Voici la requête en question: `index="tp_ecole" "layers.ip_src"="172.16.32.24" "layers.ip_dst"="172.16.64.28" | stats count by layers.ip_ttl`


Ici, le nombre maximal de saut est **30**.

## 9 - Recon
> Après avoir scanné le réseau, l'attaquant semble s'intéresser au site web. Le 21 au matin, il a scanné les pages se trouvant sur le serveur web.
>Trop de pages ont été scannées, mais combien de pages a-t-il trouvé ? (les pages sont par exemple url/index.php et non url/)

Dès à présent, nous allons voir quelle site à repondu avec un code de retour 200. Pour cela, nous allons faire une recherche sur les champs `layers.http_response_for_uri` et `layers.http_response_code`

Requête =>

`index="tp_ecole" layers.ip_src="172.16.64.28" layers.ip_dst="172.16.32.24" layers.http_response_for_uri="http://boussolecorp.com/*.*" layers.http_response_code="200" | stats count by layers.http_response_for_uri`


## 10 - CVE !
Après avoir regarder les fichiers existants, nous remarquons la présence du fichier `/wpdiscuz/readme.txt`.

En faisant quelques recherches sur internet, nous remarquons qu'il existe une faille sur la version 7.0.4. La CVE est numérotée **CVE-2020-24186**

*https://www.exploit-db.com/exploits/49967*