Retour 
Résumé
Le ransomware Play, également connu sous le nom de PlayCrypt, est un ransomware apparu pour la première fois en juin 2022. Le ransomware a ciblé des secteurs tels que les soins de santé et les télécommunications, ainsi qu'un large éventail de régions telles que l'Amérique latine, l'Europe et l'Amérique du Nord. Le ransomware Play est connu pour accéder aux réseaux par le biais de comptes valides compromis ou en exploitant des vulnérabilités spécifiques. Une fois à l'intérieur du réseau, il utilise un grand nombre d'outils de post-exploitation connus pour poursuivre son attaque. Des outils tels que Bloodhound, PsExec, Mimikatz et AdFind sont des exemples d'outils précédemment utilisés dans des attaques impliquant ce ransomware.
Un autre aspect du logiciel malveillant qui le rend célèbre est la quantité de techniques anti-analyse qu'il utilise dans ses charges utiles, telles que l'utilisation abusive de SEH et l'utilisation de ROP pour rediriger le flux d'exécution. En employant des techniques pour ralentir le processus de rétro-ingénierie, les acteurs de la menace rendent la détection et la prévention des logiciels malveillants plus difficiles.
En 2022, d'autres chercheurs ont publié un excellent article de blog analysant le logiciel malveillant lui-même et certaines des techniques anti-analyse qu'il utilise. Dans cet article de blog, nous reviendrons sur les techniques anti-analyse employées par les récentes variantes du ransomware Play, en expliquant comment elles fonctionnent et comment nous pouvons vaincre certaines d'entre elles à l'aide de scripts d'automatisation.
Programmation orientée retour (ROP)
Lors de la rétro-ingénierie d'un logiciel malveillant, s'assurer que le flux de contrôle n'est pas obscurci est l'une des premières choses à faire pour comprendre correctement le logiciel malveillant.
Pour tenter d'obscurcir son flux de contrôle, le ransomware Play utilise souvent une technique ROP dans sa charge utile. Pour ce faire, il appelle plus d'une centaine de fonctions qui corrigent la valeur située au sommet de la pile et redirigent ensuite le flux d'exécution vers cette valeur. Avant d'expliquer comment le logiciel malveillant procède exactement, examinons le fonctionnement général des instructions d'assemblage CALL et RET.
Lorsqu'un CALL se produit (un near call dans ce cas pour être plus précis), le processeur pousse la valeur du registre du pointeur d'instruction (EIP dans ce cas) sur la pile et passe ensuite à l'adresse spécifiée par l'opérande de la cible de l'appel, qui dans ce cas est un décalage par rapport au pointeur d'instruction. L'adresse du pointeur d'instruction, plus ce décalage, donne l'adresse de la fonction à appeler.
L'instruction RET, quant à elle, indique la fin d'un appel de fonction. Cette instruction est chargée de transférer le flux de contrôle du programme à l'adresse située au sommet de la pile. Et oui, c'est exactement l'adresse initialement poussée par l'instruction call !
Compte tenu de ce qui a été mentionné, dans un scénario idéal, l'adresse mise en évidence dans l'image ci-dessous serait la prochaine instruction à exécuter après un appel à la fonction cible (sub_42a4b9) :
L'image suivante montre comment le logiciel malveillant abuse du fonctionnement des instructions CALL et RET :
Une fois la fonction appelée, l'adresse 0x42a4b4 est poussée sur la pile, et c'est donc elle que pointera ESP. La fonction appelée ajoute alors la valeur 0xA à l'adresse pointée par ESP, puis retourne à l'aide de l'instruction RET. Ces opérations ont pour effet de rediriger le flux de contrôle vers 0x42a4be (0x42a4b4 + 0xa) au lieu de 0x42a4b4.
En appliquant cette technique, le logiciel malveillant rend non seulement l'analyse statique plus complexe, car le flux du programme n'est pas trivial, mais il peut également rendre le débogage plus difficile, car si vous passez sur ce type de fonction, beaucoup de choses peuvent se produire avant que l'instruction suivante ne soit exécutée.
Une autre façon pour le logiciel malveillant de mettre en œuvre cette technique ROP est d'utiliser l'approche illustrée dans le code ci-dessous, qui est très courante dans les shellcodes. Le décalage spécifié par l'opérande cible de l'instruction d'appel est nul, ce qui fait que l'adresse de la fonction à appeler correspond exactement à l'adresse de l'instruction suivante. Cette adresse est ensuite poussée au sommet de la pile et le reste des opérations est exactement le même que dans l'exemple précédent :
Afin de faciliter l'analyse du ransomware Play, Netskope Threat Labs a développé un script, basé sur les travaux antérieurs d'autres chercheurs, pour corriger l'obscurcissement ROP utilisé.
Le script recherche les candidats ROP possibles, collecte le décalage à ajouter au sommet de la pile et corrige les adresses effectuant les appels ROP avec un saut absolu, où la cible est l'adresse de transfert modifiée calculée au moment de l'exécution.
Voici un exemple de l'aspect de la charge utile du logiciel malveillant avant et après l'exécution du script :
Avant :
Après :
Anti-démontage
Une technique d'anti-désassemblage utilisée pour tromper les analystes et les désassembleurs consiste à transférer le flux d'exécution vers des cibles situées au milieu d'autres instructions valides.
Prenons l'exemple de l'appel de fonction à 0x42a4af utilisé dans la section ROP ci-dessus. Les opcodes pour cette instruction CALL sont "E8 05 00 00 00". L'octet 0xE8 est l'opcode de l'instruction CALL elle-même et les 4 autres octets représentent l'opérande cible (le décalage par rapport à EIP).
Comme nous l'avons vu précédemment, l'adresse de la fonction à appeler est la valeur de EIP (0x42a4b4) + le décalage (0x5), ce qui donne l'adresse 0x42a4b9. Cependant, cette valeur tombe dans le dernier octet d'une autre instruction valide à 0x42a4b5 :
En termes d'exécution, ce type de comportement ne change rien car le processeur comprendra les instructions correctement. Cependant, un désassembleur peut ne pas présenter les instructions correctement en fonction de l'approche qu'il utilise (par ex. ), ce qui rend l'analyse statique quelque peu délicate.
Le script que nous avons fourni pour corriger les appels ROP gère également ce scénario pour les cibles ROP. Étant donné que nous utilisons une instruction JMP pour patcher les appels, nous finissons par forcer le désassembleur à comprendre le flux correct à suivre.
Code de la poubelle
Bien qu'il s'agisse d'une technique très simple, elle mérite d'être mentionnée car elle peut définitivement ralentir l'analyse du logiciel malveillant. La technique d'insertion de code junk/garbage est exactement ce que son nom suggère : l'insertion d'instructions inutiles dans le code binaire.
Contrairement aux techniques présentées jusqu'à présent, l'insertion de code indésirable ne tromperait pas le désassembleur, mais elle pourrait faire perdre du temps à l'analyse de code inutile et le ransomware Play l'utilise assez souvent, en particulier dans les cibles des appels ROP.
Traitement structuré des exceptions (SEH)
Une autre technique anti-analyse utilisée par le logiciel malveillant consiste à abuser d'un mécanisme Windows appelé Structured Exception Handling (gestion structurée des exceptions ), utilisé pour gérer les exceptions.
Dans le système d'exploitation Windows, chaque thread possède une structure appelée Thread Environment Block (TEB). Dans un environnement x86, l'adresse du TEB est située dans le registre FS et contient des informations utiles pour le thread lui-même et réside dans l'espace d'adressage du processus. Le premier champ de cette structure est une autre structure appelée Thread Information Block (TIB) et le premier élément de cette structure contient une liste de ce que l'on appelle des "enregistrements d'exception".
Chacun de ces enregistrements est composé d'une structure