Toortik Triflexation [1/2]
Catégorie: Analyse forensique - Difficulté: Difficile
Description:
Solution:
Pour ce challenge, nous allons devoir analyser la capture mémoire avec Volatility3. Ne connaissant pas le modèle de la machine a analyser, je vais utiliser un outil bien utile, Volinux (que j'ai développé avec un ami) ou directement avec une commande Volatility 3 :
vol3 --remote-isf-url https://github.com/Abyss-W4tcher/volatility3-symbols/raw/master/banners/banners.json -f toortik_triflexation.elfNous allons d'abord analyser les process lancés afin de voir si nous voyons quelque chose d'intriguant :
Rien de très choquant ici, nous allons donc continuer à investiguer. Pour faire cela automatiquement et passer du temps sur d'autres challs, j'ai créé un petit script afin de lancer toutes les commandes Volatility3 automatiquement et de m'exporter les résultats dans des fichiers :
Maintenant, nous avons juste à analyser ces output afin de trouver notre première piste.
L'un des plugins les plus intéressants pour nous ici est le plugin linux.hidden_modules.Hidden_modules qui répertorie tous les modules kernel qui tentent de se cacher dans la mémoire. Nous avons de la chance, il n'y a qu'un seul résultat ici :
Nous avons donc le nom du module kernel : chall.
Maintenant, il faut trouver tout le reste et pour essayer simple (ce qui est souvent le cas en CTF où en réponse à incident en général), checker les répertoires usuels des utilisateurs. Pour ce faire, nous allons utiliser le plugin linux.pagecache.Files : Nous avons aucun résultats intéressant sur "chall"...
Nous allons essayer avec les strings et un grep -a chall toortik_triflexation.elf sur le dump mémoire.
Avec ça, nous avons plus de résultats intéressants :
Il y a également une commande intéressante à prendre en compte :
Nous allons donc orienter nos recherches vers firefox (et son dossier), car c'est tout à fait plausible de se cacher derrière un nom de programme connu (et inoffensif en temps normal) :
Dans l'output du plugin linux.pagecache.Files, nous trouvons ces résultats :
Nous avons donc le dossier qui contient le binaire exécuté : /snap/firefox/.config/config-firefox
Pour aller plus loin, nous allons dumper (récupérer) ces fichiers depuis le dump : vol3 --remote-isf-url https://github.com/Abyss-W4tcher/volatility3-symbols/raw/master/banners/banners.json -f toortik_triflexation.elf linux.pagecache.InodePages --inode 0x8fffe22a9cb8 --dump
En examinant ces fichiers, nous avons plusieurs choses intéressantes :
.parameters :
config-firefox : Un binaire - Le fameux module kernel qui s'exécute
.bash_history : <Vide>
logs
Nous voyons donc une sort de keylogger, grâce aux _MAJ_ qui correspond donc à la touche majuscule pour avoir le signe 6 (Maj + 6 ⇒ 6).
Nous voilà donc avec nos 3 infos :
Chemin du binaire : /snap/firefox/.config/config-firefox
Nom du module kernel : chall
Type de spyware : keylogger
Il nous manque la période entre chaque exécution, et nous allons chercher ça :
Pour se faire, nous allons vérifier si des tâches cron ne sont pas définies afin de lancer le binaire à périodes fixes. Afin de chercher ça, je n'ai pas trouvé de module Volatility, donc je me suis basé sur les strings du dump. J'ai donc cherché via le chemin du binaire et paf, un résultat très intéressant arrive à nous :
Le binaire est donc exécuté toutes les 10 minutes selon la cron définie. Nous avons donc tout ce qu'il nous faut pour valider le challenge.
Last updated
Was this helpful?