Analyse d’un ransomware sous Linux – Le cas du challenge Sherlocks Lockpick de Hack the Box

I. Présentation

On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Lockpick, de difficulté "Facile".

Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et analystes en cybersécurité.

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".

Technologies abordées	Linux, ransomware, chiffrement, syscall, sandbox
Outils utilisés	strace, strings, jq

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Découverte de l'archive

Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :

Un cryptolocker (ou ransowmare) a chiffré une partie de nos serveurs Linux et nous devons trouver un moyen de déchiffrer les fichiers, on ne peut pas faire plus actuel comme contexte ! L'archive fournie contient un dossier contenant des fichiers avec des extensions étranges (.24bes et .24bes_note.txt), ainsi qu'une seconde archive ZIP :

La seconde archive ZIP est protégée par un mot de passe fourni dans le fichier DANGER.txt :

Il s'agit d'un binaire ELF (pour les systèmes d'exploitation UNIX), probablement notre cryptolocker. Si l'on s'intéresse au contenu des fichiers ayant une extension .24bes_notes.txt, nous obtenons le fameux message de rançon :

Si l'on s'intéresse aux fichiers ayant une extension .24bes, la commande file n'y détecte aucun format de fichier connu :

Nous pouvons en conclure qu'il s'agit d'une version chiffrée de nos fichiers.

III. Investigation numérique : le cas Lockpick

A. Retrouver l'accès aux données chiffrées

• Énoncé - Task 1 : Please confirm the encryption key string utilised for the encryption of the files provided?

Notre première opération consiste à retrouver la clé de chiffrement utilisée par le cryptolocker pour chiffrer nos fichiers. L'analyse de malware n'est pas vraiment mon domaine d'expertise, mais nous sommes là pour apprendre !

L'une des premières opération généralement effectuée lors de l'étude d'un malware est l'utilisation de la commande string pour tenter d'extraire des chaînes de caractères intelligibles présents dans le fichier étudié (texte en clair, base64, etc.) :

$ strings bescrypt3.2
[...]                                                                                                  
Error opening file: %s                                                                                           
%s.24bes                                                                                                         
%s_note.txt                                                                                                      
This file has been encrypted by bes24 group, please contact us at [email protected] to discuss payment for us 
providing you the decryption software..                                                                          
Error creating note file: %s                                                                                     
Error deleting original file: %s                                                                                 
Error opening directory: %s                                                                                      
%s/%s                                                                                                            
.txt                                                                                                             
.sql
.pdf
.docx
.xlsx
.csv
.json
.xml
Encrypting: %s
bhUlIshutrea98liOp
/forela-criticaldata/
;*3$"
GCC: (Debian 12.2.0-13) 12.2.0
Scrt1.o
__abi_tag
[...]

Nous retrouvons plusieurs chaînes de caractères intelligibles, probablement des valeurs écrites en dur dans le code du malware : des extensions, des messages d'erreur et le texte annonçant la rançon. Si l'on s'intéresse à la chaîne de caractère juste après "Encrypting: %s" (probablement une information affichée sur le terminal lors de l'exécution), nous avons les chaînes de caractère bhUlIshutrea98liOp, puis /forela-criticaldata/. Ce nom de dossier est celui qui nous a été fourni et qui contient les fichiers chiffrés. Visiblement, il s’agissait d'un dossier situé à la racine du système attaqué, l'attaque semble donc avoir été préparée à l'avance, pour chiffrer un dossier bien précis. Il est également intéressant de noter la présence d'une liste d'extensions.

La chaîne de caractère bhUlIshutrea98liOp pourrait donc être le mot de passe utilisé.

• Énoncé - Task 2 : We have recently received an email from [email protected] demanding to know the first and last name we have him registered as. They believe they made a mistake in the application process. Please confirm the first and last name of this applicant.

Ici, on nous demande d'aller chercher des informations au sein des fichiers chiffrés. Il faut donc parvenir à les déchiffrer. Nous avons vu qu'un dossier précis semblait être ciblé par le ransomware : /forela-criticaldata/. Plusieurs méthodes d'analyse sont ici en options :

• L'analyse statique : elle consiste à analyser le code et les métadonnées du malware sans jamais l'exécuter. Nous utiliserons les différentes informations récupérées pour identifier son comportement global.
• L'analyse dynamique : elle consiste à exécuter le malware dans un environnement restreint et surveillé afin d'analyser en direct son comportement (accès aux fichiers, échanges réseau, etc.).

Dans le cadre d'une analyse dynamique, il est très important d'utiliser un environnement restreint et maîtrisé. Il n'est pas question que le malware effectue des échanges vers Internet ou puisse infecter notre poste ou le réseau sur lequel on se situe. Ces environnements maîtrisés sont généralement appelés sandbox (bac à sable). Il s'agit d'un sujet complexe que n'aborderons pas en profondeur ici, mais sachez que ces sandbox sont généralement des machines virtuelles déconnectées de tout réseau et équipés d'outils d'analyses comportementaux.

Nous avons ici réalisé une mini-analyse statique à l'aide de la commande string. Pour l'analyse dynamique, je décide de cloner ma VM Kali Purple et de supprimer toutes les cartes réseaux et répertoires partagés de ce clone. J'exécute ensuite le malware :

Visiblement, le malware cherche le dossier /forela-criticaldata/ et cesse tout simplement de s'exécuter s'il ne le trouve pas. Pour aller un peu plus loin dans le détail des actions réalisées, nous pouvons utiliser la commande strace qui va nous afficher les syscalls utilisés par notre binaire.

Les syscalls (appels système) sont des interfaces entre les programmes utilisateur et le noyau du système d'exploitation. Ils permettent aux applications d'effectuer des opérations spécifiques, telles que la gestion des fichiers (open, read, write, close), la gestion de la mémoire (malloc, free), des communications réseau, etc. Les langages de programmation fournissent des abstractions qui facilitent le développement logiciel en masquant la complexité des syscalls.

Nous obtenons le même résultat, mais il est intéressant de constater tout ce que fait un simple binaire qui affiche un message d'erreur. Nous voyons notamment l'utilisation du syscall openat sur le dossier /forela-criticaldata/. Voyons ce qu'il se passe si ce dossier existe sur ma sandbox et qu'il contient un fichier texte :

Mon fichier texte a été chiffré ! Regardons de plus près l'activité de ce malware avec la commande strace :

Le binaire accède au dossier ciblé puis affiche le message "Encrypting ...", il accède au fichier monfichier.txt en lecture seule (O_RDONLY), probablement pour récupérer son contenu. Il ferme ce fichier (close) puis le réouvre avec les flags suivants :

• O_WRONLY : Ouvre le fichier en mode écriture seulement.
• O_CREAT : Crée le fichier s'il n'existe pas.
• O_TRUNC : Tronque (efface) le fichier à zéro octet s'il existe.

C'est à ce moment-là que le contenu du fichier est supprimé et réécrit par son équivalent chiffré. Enfin, le message de rançon est écrit dans un fichier avec l'extension 24bes-note.txt.

Suite à cette découverte, je décide de mettre les fichiers chiffrés récupérés dans le dossier attendu et de réexécuter le malware. Il ne s'agit pas de la méthode la plus scientifique, mais mon hypothèse est que le chiffrement utilisé est un simple XOR ou chiffrement symétrique (présence d'un mot de passe en clair, et non d'une clé quelconque), le fait de re-chiffrer les fichiers nous permettra donc en principe de retrouver leur version initiale (en clair) :

Nous venons déchiffrer nos fichiers, le binaire utilise bien un algorithme de chiffrement symétrique, le fait de re-chiffrer la même donnée avec la même clé nous permet de retrouver sa version en clair. Cela nous permet de rechercher l'information demandée : le nom et prénom de l'utilisateur s'étant enregistré avec l'e-mail [email protected].

$ grep "wbevansn1" /forela-criticaldata/*
/forela-criticaldata/forela_uk_applicants.sql.24bes.24bes:(830,'Walden','Bevans','[email protected]','Male','Aerospace Manufacturing','2023-02-16'),

L'utilisateur correspondant est Walden Bevans.

B. Retrouver les traces de l'attaquant

• Énoncé - Task 3 : What is the MAC address and serial number of the laptop assigned to Hart Manifould?

À partir des fichiers en clair, nous pouvons facilement retrouver les informations demandées :

$ cat /forela-criticaldata/it_assets.xml.24bes.24bes | sed s/record/\\n/g |grep "Manifould"
><asset_id>501</asset_id><MAC>E8-16-DF-E7-52-48</MAC><asset_type>laptop</asset_type><serial_number>1316262</serial_number><purchase_date>8/3/2022</purchase_date><last_patch_date>1/6/2023</last_patch_date><patch_status>pending</patch_status><assigned_to>Hart Manifould</assigned_to><location>Room 1156</location></

L'adresse MAC associée à l'utilisateur Hart Manifould est E8-16-DF-E7-52-48.

• Énoncé - Task 4 : What is the email address of the attacker?

L'adresse e-mail de l'attaquant est l'une des premières informations que nous avons vues, elle est tout simplement indiquée dans le message de rançon :

mdo@kali-purple:/media/sf_VMR_unsafe/4_Other/Sherlocks/lockpick$ strings bescrypt3.2  |grep "@"
This file has been encrypted by bes24 group, please contact us at [email protected] to discuss payment for us providing you the decryption software..

• Énoncé - Task 5 : City of London Police have suspiciouns of some insider trading taking part within our trading organisation. Please confirm the email address of the person with the highest profit percentage in a single trade alongside the profit percentage.

Des suspicions d'opérations financières anormales ont été détectées. La première étape pour résoudre cette tâche consiste à identifier dans quel fichier se trouve ce type d'information. Si l'on regarde les attributs JSON du fichier trading-firebase_bkup.json, on remarque la présence d'un profit_percentage :

J'utilise ensuite jq pour filtrer les entrées qui m'intéressent, et notamment les pourcentages de profits supérieurs à 30 :

mdo@kali-purple:/media/sf_VMR_unsafe/4_Other/Sherlocks/lockpick/decrypted/forela-criticaldata$ cat trading-firebase_bkup.json.24bes.24bes | jq '. | to_entries | sort_by(.value.profit_percentage) | reverse | .[] | select(.value.profit_percentage > 30)' | head -n 20

[email protected], 142303.1996053929628411706675436

• Task 6 : Our E-Discovery team would like to confirm the IP address detailed in the Sales Forecast log for a user who is suspected of sharing their account with a colleague. Please confirm the IP address for Karylin O'Hederscoll.

Un utilisateur est suspecté d'avoir partagé son compte, qui devrait donc avoir plusieurs adresses IP de connexion différentes pour un même compte. Il s'agit ici de retrouver la dernière IP de connexion de l'utilisateur indiqué. Nous devons pour cela ouvrir le fichier :

L'IP suspecte est 8.254.104.208.

• Énoncé - Task 7 : Which of the following file extensions is not targeted by the malware? (.txt, .sql,.ppt, .pdf, .docx, .xlsx, .csv, .json, .xml)

Il s'agit ici de parvenir à identifier les extensions ciblées par notre ransomware.

Le fait de faire le tri parmi les fichiers à chiffrer est très courant pour un ransomware. D'une part, il serait idiot pour l'attaquant de chiffrer la totalité des fichiers du système (incluant DLL, exécutables système et fichiers de configuration) puisque cela rendrait le système inopérant (donc pas de paiement de la rançon). D'autre part, cela permet d'aller plus rapidement et de chiffrer des données vitales avant toute intervention d'un utilisateur.

L'attaquant va uniquement cibler les données "métier" de l'entreprise (pdf, fichiers Office, etc.) afin d'impacter lourdement et rapidement sa cible, la convaincant alors de payer une rançon. Ce mécanisme est bien décrit dans le TTP 1486 - Data Encrypted for Impact

https://attack.mitre.org/techniques/T1486/

L'analyse statique réalisée en début d'investigation nous a déjà donné une liste d'extensions, elles sont inscrites en clair dans le binaire :

$ strings bescrypt3.2 |less

.txt
.sql
.pdf
.docx
.xlsx
.csv
.json
.xml

En comparant la liste fournit dans l'énoncé, on remarque que l'extension .ppt n'est pas ciblée, on peut donc dire qu'ils sont hors de danger dans le contexte de ce ransomware !

C. Intégrité des fichiers déchiffrés

• Énoncé - Task 8 : We need to confirm the integrity of the files once decrypted. Please confirm the MD5 hash of the applicants DB.
• Énoncé - Task 9 : We need to confirm the integrity of the files once decrypted. Please confirm the MD5 hash of the trading backup.
• Énoncé - Task 10 : We need to confirm the integrity of the files once decrypted. Please confirm the MD5 hash of the complaints file.

Maintenant que nous avons les fichiers en clair, nous pouvons vérifier leur intégrité grâce à leur empreinte.

Une empreinte (ou hash) résulte de l'application d'un algorithme de hachage sur une donnée. La valeur obtenue pour une donnée est unique et même une petite modification dans les données d'entrée produira une valeur de hachage complètement différente. Ainsi, le fait que deux fichiers aient la même empreinte permet de confirmer qu'il s'agit d'une copie exacte.

Exemple : le hash MD5 de la chaîne de caractère "hashcat" est 8743b52063cd84097a65d1633f5c74f5. Celle de "hashcat1" est a13b856f261e2a517ed184e777a6128a.

Ici, nous pourrions, par exemple, avoir à fournir les empreintes des fichiers afin de les comparer à des backups et savoir exactement à quel moment les données ont été chiffrées. Les hashs sont également fortement utilisés pour identifier formellement les IOC (Indicator of compromission) et notamment les malwares. Si deux malwares ont le même hash, on peut confirmer qu'il s'agit du même (malgré un nom différent) et que l'attaquant est donc potentiellement le même (par exemple) :

Et voilà, nous sommes arrivés au bout de l'exercice !

IV. Notions abordées

A. Côté analyste

Il s'agissait d'une découverte pour moi aussi, car l'analyse d'un malware sous Linux s'éloigne un peu de mon domaine d'expertise quotidien. Cependant, j'ai pu constater qu'avec une bonne connaissance des systèmes Linux, des méthodologies des attaquants et de quelques ressources disponibles sur Internet, on peut dégrossir la chose assez rapidement. L'analyse avancée d'un vrai malware à coups de radare2 et d'analyse assembleur reste tout de même une activité complexe. Dans les très grandes lignes, l'analyse d'un malware passe par les étapes suivantes :

• Collecte d'informations
• Identification du type de malware
• Analyse statique
• Analyse dynamique
• Déobfuscation et désassemblage
• Reconstruction du code source
• Analyse des artefacts
• Analyse de la charge utile
• Documentation et rapport
• Corrélation et partage

Nous voyons que nous n'avons fait qu'effleurer le sujet lors de cette investigation.

La sandbox utilisée dans cet article n'était qu'un clone déconnecté d'une VM Kali Purple. Dans la réalité, il est important de disposer d'une sandbox digne de ce nom, déconnectée de tout réseau (pour éviter toute propagation du malware analysé) et équipée d'outils de surveillance permettant d'analyser, enregistrer et retracer le comportement du malware lors de l'analyse dynamique. Il existe également des sandbox en ligne, plus ou moins gratuites. La plateforme www.hybrid-analysis.com permet, par exemple, d'avoir un aperçu du résultat d'une analyse statique et dynamique sur un binaire :

B. Côté défense

Nous n'avons pas de recommandation spécifiques à faire dans le cadre de cette investigation puisque nous ne savons pas comment la compromission a été réalisée.

Il est cependant intéressant de noter qu'il existe des EDR (Endpoint Detection and Response) et EPP (End-Point Protection) qui créent et surveillent des fichiers canary sur le système de fichier. Il s'agit de fichiers "piégés" : si ces fichiers sont modifiés, alors l'EDR en déduit qu'il s'agit forcément d'un ransomware, il émet une alerte critique et tue le processus lié à la modification. Cela permet d'alerter les équipes de sécurité et de limiter l'impact d'un ransomware.

Exemple avec la solution VMware Carbon Black Cloud Endpoint :

C. Côté attaquant

Côté attaquant, le fait de cibler un répertoire précis sur le système de fichiers est certainement souhaité. En temps normal, les ransomware vont d'abord chiffrer les fichiers présents dans le répertoire de l'utilisateur (Téléchargement, Bureau, Documents), d'autres un peu plus poussés vont également s'intéresser aux répertoires partagés montés sur le système compromis ou accessibles sur le réseau avec les droits de l'utilisateur, ce qui peut être beaucoup plus impactant.

Également, l'utilisation d'un algorithme de chiffrement symétrique avec un mot de passe en clair dans le malware est le point faible de l'attaque. L'absence d'obfuscation du malware et des chaînes de caractères qui s'y trouvent expose le mot de passe et nous permet de rapidement déchiffrer les données. Un algorithme de chiffrement plus robuste nous aurait bien plus ralentis dans notre démarche.

Les algorithmes asymétriques, en particulier, impliquent l'utilisation de paires de clés (publique/privée), ce qui complique la tâche pour quiconque tente de casser le chiffrement sans la clé privée correspondante.

L'obfuscation des chaînes de caractères du malware aurait complexifié la tâche de l'analyste. Il s'agit d'une technique qui consiste à rendre illisible pour un humain un programme ou une information, tout en le gardant pleinement fonctionnel. Le code logique suivant :

k = "bhUlIshutrea98liOp"

Aurait, par exemple, pu être remplacé par celui-ci :

x = "ea98"
a = "shutre"
vector = "pass"
datacenter = "mdqslkdm"
wave = "bh"
hello = "UlI"
k = wave + hello + a + x 

V. Conclusion

J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis ! 🙂

Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy