Challenge Volatility

Responsable : Jp Gelas

Objectif : Analyser un dump mémoire d'un système Ubuntu suspect.

Préambule

Pour réaliser ce TP nous aurons besoin de l'outil Volatility 2. Notez qu'il existe une version 3 de Volatility beaucoup plus rapide mais qui n'offre pas à ce jour le même nombre de plugins/fonctionnalités que Volatility 2.

Tutoriel d'installation de Volatility

Nous avons fait pour vous un dump mémoire de la machine suspecte avec l'outil avml de Microsoft. Le fichier est au format Lime supporté par Volatility.

Nous avons également créé pour vous le fichier profile qui permettra à Volatility de correctement parser les données du dump mémoire. A Linux Profile is essentially a zip file with information on the kernel's data structures and debug symbols, used by Volatility to locate critical information and how to parse it once found.

  • Télécharger le dump de la RAM dump.mem (md5sum 156cac5da2fde637158a44cb583f2e3b)
  • Télécharger le fichier profile de la machine suspecte (md5sum 2782f1b74f44c4b6f1131e3fe1d52709)

Pour vous assurer que le profile est bien pris en compte tapez la commande suivante.

$ vol.py --plugins=. --info | grep -i ubuntu
Volatility Foundation Volatility Framework 2.6.1
LinuxUbuntu_4_15_0-197-generic_profilex64 - A Profile for Linux Ubuntu_4.15.0-88-generic_profile x64

Le format des commandes est généralement le suivant :

$ ./vol.py --plugins=. -f dump.mem --profile=LinuxUbuntu_4_15_0-197-generic_profilex64 linux_COMMANDE

Remarque : Vous pouvez ignorer les messages "Failed to import volatility.plugins..."

Questions

  1. Déterminez quel était la version précise du système sous Linux en fonctionnement (linux_banner)
  2. Déterminez quel était le nombre de processeurs alloué à ce système (linux_cpuinfo)
  3. Déterminez quel était l'adresse IPv4 du système en fonctionnement (linux_ifconfig)
  4. Déterminez la liste des ports en écoute (linux_netstat)
  5. Déterminez la liste des addresses IP connectée à la victime (linux_netstat) L'adresse 134.214.142.198 est celle de la machine utilisée pour se connecter à la victime et faire le dump mémoire (linux_arp).
  6. Parmi toutes les commande se cache un flag au format UCBL{...} il y a également une commande suspecte nommée meterpreter (linux_bash)
  7. Constatez que cette commande meterpreter apparait bien dans la liste des processus (linux_pslist, linux_pstree, linux_psaux)
  8. Sur quel device la racine du systeme de fichiers est montée ? (linux_mount)
  9. La commande linux_dmesg révèle le chargement d'un module. Quel est son nom ?
  10. Est-ce que ce module apparait ? (linux_lsmod)
  11. linux_hidden_modules le fait-il apparaitre ? (ignorez resetafter et qni)
  12. A quoi sert la commande linux_check_modules ?
  13. linux_moddump -D ./out -b 0xffff... (adresse du module) ne fonctionne pas mais devrait permettre de récupérer le code machine du rootkit pour le désassembler et analyser son fonctionnement avec Ghidra par exemple.
  14. Le processus meterpreter spawn un shell. Dumpez la mémoire de ce shell et retrouvez les quelques commandes qui ont été saisies (mv, sudo, ...) (linux_procdump -p PID -D ./out)
  15. Quel est le PID du processus flagbox ?
  16. Si dans un binaire des données sont stockées suite a un malloc, alors les données sont sur le tas (heap). Déterminez l'adresse du tas (heap) de ce processus (linux_proc_maps -p PID)
  17. Dumpez cette zone mémoire avec linux_dump_map -p PID -s 0x000startaddress -D ./out
  18. Extraire les chaines de caractères lisibles (string). Quel est le flag ?