# Rapport Forensic

## Introduction

Analyste DFIR 1 : Emile Marié
Analyste DFIR 2 : Raphaël Letourneur
Analyste DFIR 3 : Yanis Dauga
Analyste DFIR 4 : Théo Vigreux

Notre mission consiste à réaliser une investigation numérique impliquant trois machines:
- le DC GRAAL Windows Server
- la TAVERNE Windows Server
- et le CAMELOT Linux Gitlab.

Nous disposons des informations suivantes :

- Les dates et heures de référence pour les événements
- L'adresse IP de l'administrateur système
- Le Windows Defender du TAVERNE a détecté un `Trojan:Win32/Wacatac.B!ml` le 6 janvier 2021 à 8h47
- Les fichiers confidentiels du DC GRAAL n'étaient plus accessibles depuis le 6 janvier 2021 à 10h23
- Le schéma réseau logique suivant synthétise les interconnexions des machines.

Dans cette investigation, il sera important de prendre en compte les indicateurs de compromission (IOC) mais également la matrice MITRE pour enquêter sur l'origine de l'attaque et identifier les vecteurs d'attaque éventuels. Il est important de maintenir l'intégrité des éléments tout au long de l'investigation et de suivre une méthodologie cohérente pour garantir la fiabilité des résultats. Les outils d'investigation utilisés pour l'analyse sont Volatility sont Timesktech, Volweb, Autopsy ainsi que la suite d'outils d'Eric Zimmerman.

Nous allons donc dans un premier temps réaliser une analyse de la réponse sur incident pour chacunes des machines, puis nous finirons par la présentation d'un plan d’action et de remédiations contres les attaques subies.

## Début de l'analyse
Nous disposons des dumps des machines concernées par l'analyse forensic. Dans un premier temps, nous allons convertir les fichiers `vmdk` (disques virtuels) en `.raw` afin de faciliter leur traitement:

┌──(parallels㉿kali-linux-2022-2)-[/media/psf/PRIMARY/BROCELIANDE_Sync_Taverne]
└─$ qemu-img convert -f vmdk -O raw BROCELIANDE_Sync_Taverne-disk1.vmdk taverne.dmp 
             
┌──(parallels㉿kali-linux-2022-2)-[/media/psf/PRIMARY/BROCELIANDE_DC_Graal]
└─$ qemu-img convert -f vmdk -O raw BROCELIANDE_DC_Graal-disk1.vmdk dc.dmp         
                     
┌──(parallels㉿kali-linux-2022-2)-[/media/psf/PRIMARY/BROCELIANDE_Gitlab_Camelot]
└─$ qemu-img convert -f vmdk -O raw BROCELIANDE_CI_Camelot-disk1.vmdk gitlab.dmp

Ensuite, nous souhaitons extraire les logs de chaque machine afin de créer une supertimeline. Pour cela, nous allons utiliser `plaso`:

sudo docker run --rm -v /tmp:/tmp log2timeline/plaso log2timeline.py -z US/Pacific --storage-file /tmp/taverne.plaso /tmp/taverne.dmp --workers=4 --partitions all

sudo docker run --rm -v /tmp:/tmp log2timeline/plaso log2timeline.py -z US/Pacific --storage-file /tmp/dc.plaso /tmp/dc.dmp --workers=4 --partitions all

sudo docker run --rm -v /tmp:/tmp log2timeline/plaso log2timeline.py -z Africa/Abidjan --storage-file /tmp/gitlab.plaso /tmp/gitlab.dmp --workers=4 --partitions all

## Camelot

Tout d'abord, nous commençons par le serveur linux.
En effet, le serveur linux héberge un site web exposé sur internet ça semble donc être le point d'entré de notre attaquant.

On peut voir dans l'historique des commandes, que l'utilitaire `ngrok` est utilisé pour exposé le site web sur internet. Cette façon de faire est une très mauvaise pratique.

Ensuite, on inspecte le docker gitlab.


On peut voir que le service qui tourne est `gitlab v12.8.1`. Après une recherche sur internet, on peut voir que ce service est vulnérable à la CVE-2020-10977.

D'après le lien : https://www.hackingloops.com/gitlab-file-read-rce/ un attaquant pourrait executer des commandes à distance.

Afin de confirmer notre hypothèse, nous cherchons dans la mémoire si il n'y aurait pas eu une requête correspondant à cet exploit.


Cela confirme notre hypothèse que c'est cette vulnérabilité qui a été utilisé pour prendre le contrôle du serveur.

En continuant d'investiguer, nous avons pu remarqué qu'un utilisateur `toor` avec des droits root avait été créé sur notre hôte. Son mot de passe est d'ailleurs directement écrit dans le fichier `/etc/passwd` ce qui est une technique de persistence souvent utilisée par les attaquants.

Nous savons donc que notre attaquant à réussi à sortir du conteneur docker.


Nous verrons plus tard que l'attaquant s'est latéralisé vers les autres machines.

## Taverne
Dans un premier temps, nous savons que le **Windows Defender** de Taverne a remonté l'événement suivant:

Ainsi, nous partons à le recherche de cet événement dans Timesketch. À noter que nous avons défini la timezone **US/Pacific** (UTC+8) lors de la création de notre fichier `taverne.plaso`, donc il faudra chercher l'événement non pas à 8:47 mais bien à 16h47.

Et à 16h47 nous trouvons d'abord la création d'un exécutable `copain.exe`:

Et une seconde plus tard, nous retrouvons l'événement Windows Defender:

Parmis les informations pertinentes, nous avons le chemin du fichier malveillant (`C:\Users\arthur\Desktop\copain.exe`).

Ensuite, à 16h53 nous remarquons que `beacon.exe` est lancé sur la machine. Cela ressemble bizarrement au nom d'un exécutable de **Command and Control** bien connu.

Ainsi, avec Timesketch nous allons effectuer une recherche autour de 16h53 dans un range de -1 min et +1 min.

On remarque donc que quelqu'un s'est connecté depuis l'IP `192.168.88.137` (le Gitlab) au serveur de fichiers présent sur la machine. Ensuite, l'exécutable `beacon.exe` a été créé sous `C:\Users\Public` puis un fichier `execute.bat` est créé sous `C:\Windows\Temp`.

En cherchant l'IP en question, nous apprenons que l'attaquant s'était déjà connecté en administrateur à 16:34:

Si l'on suite l'arbre ci-dessus, le service `beacon.exe` devrait être à l'origine du lancement de `mimikatz.exe` à 16h57. Et nous remarquons bel et bien que `mimikatz` est utilisé pour charger le driver `mimidrv.sys` grâce à l'argument `"!+"`. Pour rappel, le fait de charger ce driver dans le noyau permet d'utiliser des fonctions telles que la modification de processus courant ou d'interagir avec d'autres driver.

Puis, à 16h58 `mimikatz` est à nouveau lancé cette fois avec l'argument `!processprotect /process:lsass.exe /remove`. Cette commande permet de retirer la protection du processus `lsass.exe`.

À 16h59, la commande est relancée mais cette fois avec des guillemets.

Enfin, à 16h59:46 l'attaquant va dumper le processus `lsass.exe` qui contient des secrets:

À 17:09, nous remarquons que quelqu'un s'est connecté via la méthode **Pass The Hash** (technique consistant à utiliser le hash du mot de passe pour se connecter à un compte). Pour trouver ce résultat nous avons chercher `seclogo`, il s'agit du service utilisé pour se connecter en **PtH**.


## DC Graal

Lorsqu’on se connecte sur le windows server, un fichier s’ouvre automatiquement : #README_CTRM#.rtf

On observe que le fond d’écran a été modifié:

En parcourant l'arborescence de la machine, on observe un `.exe`.


Ensuite, en utilisant Timesketch, nous remarquons la création d'un répertoire ainsi que d'un des fichiers `CTRM` à 17:11:56.

Puis une connexion au serveur de fichiers depuis l'IP `192.168.88.137` sur le DC avec le compte `msol_0537fce40030` à 17:13:23.

En cherchant l'IP en question, nous remarquons que l'attaquant s'est ensuite connecté en administrateur 15 minutes plus tard:

À 17:39 on remarque que l'exécutable `beacon.exe` est lancé, il s'agit très probablement d'un Command and Control Cobalt Strike:

À 17:41, `mimikatz` est lancé:

On obtient la commande utilisée avec `volweb`:

Cette commande permet d'injecter un clé Skeleton dans le processus LSASS du contrôleur de domaine. La clé Skeleton correspond à un nouveau mot de passe maître accepté pour n'importe qu'elle utilisateur du domaine, y compris les administrateurs. Ainsi, l'attaquant a établi de la persistence à travers cette technique.

La commande est relancée une seconde fois à 17:45.

Concernant le fichier `bytelocker.exe` que l'on a observé auparavant. Sur Timesketch, on lance une recherche sur le nom de ce exécutable pour la machine GRAAL. On obtient plusieurs informations, la première trace de`bytelocker.exe` a lieu à 17:56.

Plus précisément, les entrées indiquent que le fichier Bytelocker.exe a été créé dans le répertoire `C:\Users\Public` à l'heure et la date indiquée, et qu'il a ensuite été supprimé et recréé dans le répertoire `C:\Users\arthur\Documents\confidenìel`.

Les entrées de journal fournissent également des informations sur le fichier, telles que la version du produit, la taille et la date de modification. Il y a également une entrée de journal concernant la fréquence d'utilisation du programme.

En somme, ces informations indiquent que `Bytelocker.exe` a été utilisé sur l'ordinateur en question et ont été enregistrées dans les journaux de Windows.

Virus Total nous confirme qu'il s'agit bel et bien du ransomware `Bytelocker.exe`:

Ensuite, à 18:20, l'exécutable `ATXO3fAc.exe` est créé et exécuté:

D'après les informations que nous avons, l'exécutable semble se baser sur un outils de Sysinternals pour récupérer les handles ouverts, les fermer et donc pouvoir écrire sur le fichier pour le chiffrer.

[\Root\InventoryApplicationFile\atxo3fac.exe|b5ee13d6a86a2631] BinFileVersion: [REG_SZ] 4.11.0.0 BinProductVersion: [REG_SZ] 4.11.0.0 BinaryType: [REG_SZ] pe32_i386 FileId: [REG_SZ] 0000b016316132a6a277c5d8a4d7f3d6e2c769984052 IsOsComponent: [REG_DWORD_LE] 0 IsPeFile: [REG_DWORD_LE] 1 Language: [REG_DWORD_LE] 1033 LinkDate: [REG_SZ] 12/10/2017 21:18:46 LongPathHash: [REG_SZ] atxo3fac.exe|b5ee13d6a86a2631 LowerCaseLongPath: [REG_SZ] c:\users\administrator\documents\atxo3fac.exe Name: [REG_SZ] ATXO3fAc.exe ProductName: [REG_SZ] sysinternals handle ProductVersion: [REG_SZ] 4.11 ProgramId: [REG_SZ] 00067ff8471fb053ab7063e0934c59f2390b00000904 Publisher: [REG_SZ] sysinternals - www.sysinternals.com Size: [REG_QWORD] 185480 Usn: [REG_QWORD] 17295408 Version: [REG_SZ] 4.11

Grâce à Virus Total, nous remarquons que le fichier est bien malveillant:

## Recommandations
Dans un premier temps, nous conseillons fortement de patcher les serveurs exposés sur Internet (Gitlab). Il s'agit du vecteur initial d'accès il est donc primordial de le sécuriser.

Ensuite nous avons vu que `beacon.exe` (Cobalt Strike) et `mimikatz` ont été utilisés sur les serveurs windows, il serait pertinent de créer des règles de détection pour ces exécutables afin que le SOC ait de la visibilité en temps réel.

De plus, si les connexions depuis le serveur Gitlab vers les serveurs Windows ne sont pas autorisés, il faut créer des règles de pare-feu en ce sens.