Un ami vous demande de l’aide pour déterminer si l’email qu’il vient d’ouvrir au sujet du Covid-19 était malveillant et si c’était le cas, ce qu’il risque. Il prétend avoir essayé d’ouvrir le fichier joint à cet mail sans y parvenir. Peu de temps après, une fenêtre liée à l’anti-virus a indiqué, entre autre, le mot KPOT v2.0 mais rien d’apparent n’est arrivé en dehors de cela.
Après une analyse préliminaire, votre ami vous informe qu’il est probable que ce malware ait été légèrement modifié, étant donné que le contenu potentiellement exfiltré (des parties du format de texte et de fichier avant chiffrement) ne semble plus prédictible. Il vous recommande donc de chercher d’autres éléments pour parvenir à l’aider.
Vous disposez d’une capture réseau de son trafic pour l’aider à déterminer si des données ont bien été volées et lui dire s’il doit rapidement changer ses mots de passe ! SHA256(pws.pcap) = 98e3b5f1fa4105ecdad4880cab6a7216c5bb3275d7367d1309ab0a0d7411475d - 463MB
TL;DR
Un challenge de PCAP assez lourd (~500 Mo). Il faut trouver la connexion du malware au panel de C2, récupérer les bytes chiffrés. En se documentant on sait qu’il est possible de bruteforce la clé assez rapidement et de récupérer le flag.
État de l’art
On commence donc cette épreuve avec un gros PCAP. Le souci des gros PCAP est qu’il est facile de se perdre dedans en suivant de fausses pistes. Pour éviter ça, il faut savoir ce que l’on cherche avant de plonger tête baissée dedans.
Ce qu’on sait:
- Le malware est un KPOT v2.0 modifié.
Ce qu’on cherche:
- Des indices de compromission d’un KPOT v2.0.
Analyse du malware
Dans ma méthodologie, il est possible (et c’est souvent le cas), que le “ce qu’on cherche” demande des connaissances pas encore acquises. En l’occurrence, on connait le malware utilisé et il existe des analyses détaillées:
Proofpoint propose une analyse complète du malware. On peut maintenant affiner le “ce qu’on cherche”:
- Le RTF ou document de macro utilisé pour drop le malware ;
- Des connexions vers “past.ee”;
- Des connexions vers “gate.php”;
- Trouver la clé de chiffrement du XOR;
- Trouver le C2 avec une requête GET puis une requête POST.
Cependant, il ne faut pas oublier que l’énoncé nous dit:
il est probable que ce malware ait été légèrement modifié, étant donné que le contenu potentiellement exfiltré (des parties du format de texte et de fichier avant chiffrement) ne semble plus prédictible
Trouver la connexion suspecte
Le fait de chercher “gate.php” est une bonne piste:
Il y a quelque chose de rigolo: toutes les connexions sont uniques sauf la dernière. Toutes les connexions sont de simple GET avec de la data chiffrées et encodées en b64, mais pas la dernière:
C’est une requête POST avec de la donnée chiffrée brute, serait-ce notre flag tant attendu? On verra ça plus tard.
L’article de Proofpoint nous dit que la clé XOR est hardcodée dans le binaire. Mais il n’y a pas de binaire apparent dans ce PCAP (pour vérifier, un binwalk et “Fichiers -> Exporter objet -> HTTP”).
Donc il faut trouver un autre moyen. On sait que c’est du XOR et on connait le format de la configuration envoyée à “gate.php”. Toujours dans l’exemple de proofpoint:
- Configuration
|
|
- Clé du XOR
4p81GSwBwRrAhCYK
La clé fait 16 bytes, l’espèce de binaire du début de la configuration fait 16 bytes. De plus, la clé a un charset alphanumérique, soit: [A-Za-z0-9]. Il ne reste qu’à bruteforce tout ça pour trouver la clé qui nous intéresse.
Bruteforce de la clé
Le fichier enc_dat est le base64 décodé de la connexion GET au C2.
|
|
Après environ 1 petite minute, on trouve:
|
|
Déchiffrement du message
Yapluka :)
|
|
b’DRAPEAU_P|us2peurQue2M4l! R4ssur3z-Votre-Am1-Et-vo1c1Votredr4peau_FCSC\n{469e8168718996ec83a92acd6fe6b9c03c6ced2a3a7e7a2089b534baae97a7}\n_DRAPEAU'
En l’occurrence, comme l’énoncé le disait, le code du malware a été modifié, ainsi la structure de la connexion POST change et ne propose plus “_FFFILEE_” ou “_SYSINFORMATION_”. Il faut lire avait de râler :D
Flag
FCSC{469e8168718996ec83a92acd6fe6b9c03c6ced2a3a7e7a2089b534baae97a7}