Les auteurs de ransomware ajoutent un nouvel EDR Killer à leur arsenal (EDRKillShifter)

Les analystes de Sophos ont récemment découvert un nouvel utilitaire de type EDR Killer déployé par un groupe cybercriminel qui tentait d’attaquer une organisation avec un ransomware appelé RansomHub. Bien que l’attaque de ransomware ait finalement échoué, l’analyse post-mortem de cette dernière a révélé l’existence d’un nouvel outil conçu pour bloquer les logiciels de protection endpoint. Nous appelons cet outil EDRKillShifter.

Depuis 2022, nous avons constaté une augmentation de la sophistication des malwares conçus pour désactiver les solutions EDR sur un système infecté, à mesure que les clients adoptent de plus en plus les outils EDR pour protéger les systèmes endpoint. Sophos a déjà publié une étude sur AuKill, un outil de type EDR Killer découvert par Sophos X-Ops l’année dernière et vendu commercialement sur les marchés cybercriminels.

Lors de l’incident du mois de mai dernier, les acteurs malveillants (nous estimons avec une confiance modérée que cet outil pourrait être potentiellement utilisé par plusieurs attaquants), ont tenté d’utiliser EDRKillShifter pour bloquer la protection Sophos sur l’ordinateur ciblé, mais l’outil a échoué. Ils ont ensuite tenté de lancer l’exécutable du ransomware sur la machine qu’ils contrôlaient, mais cette tentative a également échoué lorsque la fonction CryptoGuard de l’agent endpoint a été déclenchée.

Comment fonctionne EDRKillShifter ?

L’outil EDRKillShifter est un exécutable de type “chargeur (loader)”, un mécanisme de diffusion pour les pilotes légitimes qui est vulnérable à d’éventuels abus (également connu sous le nom “Bring Your Own Vulnerable Driver” ou BYOVD).  En fonction des exigences de l’acteur malveillant, il peut fournir une large gamme de différentes charges virales de pilote.

Le processus d’exécution de ce chargeur/loader comporte trois étapes. L’attaquant doit exécuter EDRKillShifter avec une ligne de commande incluant une séquence de type “mot de passe”. Lorsqu’il est exécuté avec le mot de passe correct, l’exécutable déchiffre une ressource intégrée nommée BIN et l’exécute en mémoire.

Le code BIN décompresse et exécute la charge virale finale. Cette dernière, écrite avec le langage de programmation Go, supprime et exploite l’un des nombreux pilotes vulnérables et légitimes pour obtenir des privilèges suffisants afin de déverrouiller la protection d’un outil EDR.

Présentation générale du processus d’exécution du chargeur/loader

Neutralisation de la première couche

Une analyse superficielle révèle que tous les échantillons partagent les mêmes données de version. Le nom de fichier d’origine est Loader.exe et son nom de produit est ARK-Game (certains membres de l’équipe de recherche ont émis l’hypothèse que l’acteur malveillant tentait de faire passer la charge virale finale pour un jeu vidéo populaire nommé ‘ARK : Survival Evolved’).

La langue du binaire est le russe, indiquant ainsi que l’auteur du malware a compilé l’exécutable sur un ordinateur avec des paramètres de localisation russes.

Informations sur la version d’EDRKillShifter telles qu’affichées dans l’explorateur CFF

Tous les exemples nécessitent un mot de passe unique de 64 caractères transmis à la ligne de commande. Si le mot de passe est erroné (ou n’est pas fourni), l’exécution échouera.

L’exécution échoue si l’utilisateur ne fournit pas le mot de passe correct au niveau de la console lors de l’exécution du programme

Une fois exécuté, EDRKillShifter charge en mémoire une ressource chiffrée nommée BIN, intégrée à l’outil lui-même. Il copie également ces données dans un nouveau fichier nommé Config.ini et place ce dernier au même endroit dans le système de fichiers où le binaire a été exécuté.

Le code du chargeur/loader alloue ensuite une nouvelle page mémoire à l’aide de VirtualAlloc et écrit le contenu chiffré dans la page nouvellement allouée. Le malware supprime ensuite le fichier Config.ini et procède au déchiffrement de l’ensemble suivant de charges virales : à savoir le pilote vulnérable à d’éventuels abus et un binaire Go. Le chargeur/loader utilise un hachage SHA256 du mot de passe d’entrée comme clé de déchiffrement des charges virales de la deuxième couche.

Pseudocode de la routine de déchiffrement de la deuxième couche du malware EDRKillShifter

Si le malware parvient à déchiffrer les charges virales de la deuxième couche, il crée alors un nouveau thread et lance son exécution au niveau de ce dernier.

Chargement de l’EDR Killer final en mémoire

La deuxième étape est obfusquée grâce à l’utilisation d’une technique de code auto-modifiable. Pendant l’exécution, la deuxième couche modifie ses propres instructions. Étant donné que les instructions réellement exécutées ne sont révélées que lors de l’exécution elle-même, des outils ou une émulation supplémentaires sont nécessaires pour l’analyse.

La figure ci-dessous illustre davantage la technique en question. La première section montre le début de la couche de code auto-modifiable. Toutes les instructions avant le premier appel lors du désassemblage n’ont aucun sens à ce stade. Si nous revisitons le même bloc d’instructions après avoir exécuté le premier appel, nous voyons un ensemble d’instructions différent. Le premier appel modifie le jeu d’instructions suivant, qui modifie ensuite le jeu d’instructions suivant, et ainsi de suite.

L’EDRKillShifter utilise un code auto-modifiable pour modifier chaque instruction ultérieure

Le seul objectif de la couche finale décodée est de charger dynamiquement la charge virale finale en mémoire et de l’exécuter.

Analyse de la charge virale ultime

Tous les échantillons que nous avons analysés exécutaient une variante différente de l’EDR Killer en mémoire. Ils sont tous écrits en langage Go et obfusqués (éventuellement grâce à l’utilisation d’un outil open source nommé gobfuscate). Les obfuscateurs sont des outils conçus pour empêcher l’ingénierie inverse. Il peut y avoir des raisons légitimes pour lesquelles les ingénieurs logiciels masquent le logiciel, par exemple pour empêcher les concurrents de voler la propriété intellectuelle. Cependant, les auteurs de malwares utilisent également des obfuscateurs pour rendre plus difficile l’analyse des malwares par les experts en sécurité.

La plupart des ingénieurs spécialistes en reverse engineering s’appuient sur ces données obfusquées lors de l’analyse des malwares écrits en langage Go, mais dans ce cas, ces données clés sont masquées dans le code compilé. Certaines de ces informations comprennent les éléments suivants :

• Des chaînes chiffrées qui seront déchiffrées lors de l’exécution (runtime).
• Des informations sur la version Go qui ont disparu. De nombreux outils d’ingénierie inverse open source s’appuient sur ces informations de version Go pour reconstruire les structures lors du désassemblage.
• Des informations utiles sur les packages, ou chemins d’accès aux packages, chiffrées ou supprimées du malware final.

Cependant, nous avons pu extraire des informations précieuses à l’aide de l’outil GoReSym de Mandiant.

Similitudes entre les charges virales finales

Tous les EDR Killers désassemblés intègrent un pilote vulnérable dans la section .data. Leur comportement est simple, comme celui des autres EDR Killers que nous avons analysés[1][2][3]. La seule différence majeure entre les deux variantes que nous avons examinées est le pilote vulnérable chargé et exploité.

Lors de l’exécution, les deux variantes acquièrent les privilèges nécessaires pour charger un pilote et déposer le fichier système exploitable dans le dossier AppDataLocalTemp. Le malware génère un nom de fichier aléatoire pour le pilote à chaque exécution.

Un log Process Monitor montre que le malware dépose le pilote vulnérable dans le dossier TEMP

Une fois que le malware a créé un nouveau service pour le pilote, démarré ce dernier et chargé le pilote, il entre dans une boucle sans fin qui énumère en permanence les processus en cours, mettant fin aux processus si leur nom apparaît dans une liste de cibles hardcodée. Ce comportement est constant pour les deux variantes.

Il convient également de noter que les deux variantes exploitent des pilotes légitimes (bien que vulnérables), en utilisant des exploits de type proof-of-concept (preuve de concept) disponibles sur Github. Nous pensons que les acteurs malveillants ont copié des parties de ces preuves de concept, les ont modifiées et ont migré le code en langage Go. Il s’agit d’une tendance courante que nous avons également observée chez d’autres EDR Killers, tels que Terminator.

Même chargeur/loader mais avec des charges virales finales différentes

L’échantillon avec la fonction de hachage SHA256 suivante :

451f5aa55eb207e73c5ca53d249b95911d3fad6fe32eee78c58947761336cc60

abuse d’un pilote vulnérable qui a également été ciblé lors d’attaques ultérieures et se fait appeler RentDrv2. Une preuve de concept pour l’exploitation de ce pilote est disponible sur Github.

La variante peut également recevoir un argument de ligne de commande supplémentaire “–list“, permettant aux adversaires de transmettre une liste supplémentaire de noms de processus comme cibles.

La première variante peut également accepter des arguments de ligne de commande supplémentaires en entrée, notamment une liste personnalisée de processus à cibler

En revanche, la variante avec la fonction de hachage SHA256 suivante :

d0f9eae1776a98c77a6c6d66a3fd32cee7ee6148a7276bc899c1a1376865d9b0

abuse d’un pilote vulnérable connu sous le nom “ThreatFireMonitor“, un composant d’un package de surveillance du système devenu obsolète. Une preuve de concept pour ce pilote spécifique est également disponible sur Github.

Mapping d’EDRKillShifter dans le paysage plus large des menaces

La charge virale finale intégrée dans le chargeur/loader change d’un incident à l’autre (et, vraisemblablement, d’un auteur de malware à l’autre). Si nous essayons d’adapter EDRKillShifter au paysage plus large des menaces, il est également plausible que le chargeur/loader et les charges virales finales soient développés par des acteurs malveillants distincts.

Vendre des chargeurs/loaders ou des obfuscateurs est une activité lucrative sur le dark net. Sophos X-Ops soupçonne que le seul objectif du chargeur/loader est de déployer la charge virale BYOVD finale et que ce dernier pourrait avoir été acquis sur le dark net. Les charges virales finales de type EDR Killer sont ensuite simplement diffusées par le chargeur/loader lui-même, qui comprend les couches 1 et 2 que nous avons décrites dans notre analyse ci-dessus.

Exemple de publicité pour un outil obfuscateur en vente sur un forum cybercriminel du dark net.

Il convient de noter que nous ne sommes pas en mesure de confirmer cette hypothèse pour le moment.

Mitigations et conseils

Sophos détecte actuellement EDRKillShifter sous le nom Troj/KillAV-KG. De plus, les règles de protection comportementale qui protègent contre l’évasion de la défense et l’élévation de privilèges bloquent le passage de ces appels système. Les entreprises et les particuliers peuvent également prendre des mesures supplémentaires pour protéger leurs machines contre l’abus de pilotes :

• Sophos X-Ops vous suggère fortement de vérifier si votre produit de sécurité endpoint implémente et active la protection antialtération. Cette fonctionnalité fournit une couche solide contre ce type d’attaque. Si vous utilisez des produits Sophos mais que la protection antialtération n’est pas actuellement activée, activez-la dès aujourd’hui.
• Adoptez une bonne hygiène pour les rôles de sécurité Windows. Cette attaque n’est possible que si l’attaquant élève les privilèges sous son contrôle ou bien s’il peut obtenir les droits administrateur. La séparation entre les privilèges utilisateur et administrateur peut empêcher les attaquants de charger facilement les pilotes.
• Gardez votre système à jour. Depuis l’année dernière, Microsoft a commencé à proposer des mises à jour qui décertifient les pilotes signés connus pour avoir été abusés par le passé.

Billet inspiré de Ransomware attackers introduce new EDR killer to their arsenal, sur le Blog Sophos.