Un challenge classique d’analyse mémoire. On commence par regarder les chaînes contenues pour déterminer le noyau utilisé :
PRETTY_NAME="Ubuntu 20.04.2 LTS"
(Linux 5.8.0-44-generic; x86_64) IPP/2.0
On utilise ces informations pour monter une VM équivalente et créer un profil volatility (notez qu’à l’époque, j’avais utilisé volatility, premier du nom).
Mais dans l’immédiat, on va continuer à faire des recherches dans les chaînes du fichier. Par exemple, en cherchant flag.txt, on trouve pas mal d’occurrences du chemin complet du fichier en question : /home/forensics/Bureau/flag.txt.
Et en regardant les chaînes autour des occurrences, on tombe notamment sur ce bloc :
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwPxLPVboxnBlLuh/r78u
wv5z5Bm492Qovec4E8S2Z15AxF0aPwKAsKhfMWk0/Y1Fp9W+QPnGl4C+7qX+617/
VgqFI+vbrRX2Wrj4tOL1OMH71Sa4Y54mYsEmnemAX3CoNAdWctmn90BSMw9PnZ2C
Bjf1B/xTNyape+YPlXUmn4PNrhFENSR+9oB79pNPjNs0iHBSLYZ5cqGbCQITxAEq
2QSMNRKytli7QNmbAU4mdrHs7CqGBagvQ6kLDLqQYxtBvJcJDb1RrGpoy4PjYyul
wk2mrbqrzLQJ3HJhM1kGPu20pPtvxxhM2/8DgdrOX3qVN+W5UdNX35EuAA9z97mL
gRRsrSceS9w1Dqx7g9Cg8E4pHLr4y1KoipsKvnOWwTVnYHxUKL2VIgt8nvJyZZSC
mBLQbtckouMTvM7WFeg3XRoFBgnAc3UUELe6sRHfYt5w/2albkm/CMi2CFfpSwel
/R7OX1vyshpsBO11tCnNlVaVLNE1AUVdH/MkpSXOuGwfpo4QATVRZXhxFDoNywkA
zgNUM3+sItP2U6EYOksP3TWpEYCZFK8kQ0ItbFtdWl2AaHru9iYc1Ozgd/ZqtA20
pEVoIzESHbdQYhVnRk3TsgNWot7inQAXAG7r+4QcS+5GGDFLEQQpFkK8Pd3FYYwK
MKDkvL7BzCm+zxCc6oFZyz8CAwEAAQ==
-----END PUBLIC KEY-----
x86_64
Option non reconnue. Utilisation : ./c2 [--client [-d domaine | -i ip] | --serveur]
i:d:cs
Vous ne pouvez utiliser --client et --serveur en m
me temps
Vous ne pouvez utiliser --serveur et -d ou -i en m
me temps
Vous ne pouvez utiliser -i et -d en m
me temps
-i ip ou -d domain manquant
Vous devez avoir --client ou --serveur
client
serveur
%02x
?/home/
/Bureau/flag.txt
/keys/
.priv
.pub
pass:
openssl
On a donc :
- une clef publique.
- la documentation d’un binaire appelé c2 (command & control ?)
- une référence à openssl. On peut raisonnablement pensé qu’on a notre rançonlogiciel.
Quand on cherche les process lancés sur la machine avec linux_pslist, un nom interpelle :
0xffffa044b17f5e00 ???? 1811 1799 1000 1000 0x0000000034338000 2021-03-15 20:35:15 UTC+0000
Impossible de le dumper, il semble vraiment se cacher. On arrive quand même à récupérer l’environnement par linux_psenv :
??? 1811 SHELL=/bin/bash SESSION_MANAGER=local/fcsc2021:@/tmp/.ICE-unix/1454,unix/fcsc2021:/tmp/.ICE-unix/1454 QT_ACCESSIBILITY=1 COLORTERM=truecolor XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg XDG_MENU_PREFIX=gnome- GNOME_DESKTOP_SESSION_ID=this-is-deprecated GNOME_SHELL_SESSION_MODE=ubuntu SSH_AUTH_SOCK=/run/user/1000/keyring/ssh DESKTOP_SESSION=ubuntu SSH_AGENT_PID=1406 GTK_MODULES=gail:atk-bridge PWD=/home/forensics/Bureau LOGNAME=forensics XDG_SESSION_DESKTOP=ubuntu XDG_SESSION_TYPE=x11 GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 XAUTHORITY=/run/user/1000/gdm/Xauthority GJS_DEBUG_TOPICS=JS ERROR;JS LOG WINDOWPATH=2 HOME=/home/forensics USERNAME=forensics IM_CONFIG_PHASE=1 LANG=fr_FR.UTF-8 XDG_CURRENT_DESKTOP=ubuntu:GNOME VTE_VERSION=6003 GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/cb620eba_e16c_40db_aafd_68b7a7f1307c INVOCATION_ID=fb19ee8eb70d451caf9c8efbfdb3188a MANAGERPID=1195 GJS_DEBUG_OUTPUT=stderr LESSCLOSE=/usr/bin/lesspipe %s %s XDG_SESSION_CLASS=user TERM=xterm-256color LESSOPEN=| /usr/bin/lesspipe %s USER=forensics GNOME_TERMINAL_SERVICE=:1.90 DISPLAY=:0 SHLVL=1 QT_IM_MODULE=ibus XDG_RUNTIME_DIR=/run/user/1000 JOURNAL_STREAM=8:33361 XDG_DATA_DIRS=/usr/share/ubuntu:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin GDMSESSION=ubuntu _=/bin/1
On voit que le binaire réel semble être /bin/1 et si on le recherche dans les chaînes, on trouve une ligne intéressante :
forensics@fcsc2021:~/Bureau$ /bin/1 --client -i 192.168.56.103
La syntaxe correspond à la documentation bizarre que l’on avait remarqué plus tôt. Cela semble bien être le process cherché. Maintenant qu’on a la ligne de commande complète et le nom d’utilisateur (Cf. USER dans le résultat du linux_psenv plus tôt), il reste le nom d’hôte à récupérer. Une manière possible est de jeter un œil au dmesg (commande linux_dmesg) :
[1608194800.1] systemd[1]: Set hostname to <fcsc2021>.
Reste à calculer le condensat sha256 de la chaîne forensics:fcsc2021:/bin/1 --client -i 192.168.56.103 pour obtenir le flag :
FCSC{34aa0f2895fc61bdfb26c47708d78c6b99db30dddaecaa93cf5a4ab5acb76923}