Guillaume Orlando

This blog post is available in english here.

Sommaire

• Introduction
• Reconnaissance
• DarkHydrus APT
• Analysis
  • A) Anti-VM et anti-debug
  • B) Méthodes de persistance
  • C) Exfiltration d’informations
    • 1) Principe de l’exfiltration DNS
    • 2) Exfiltration
  • D) Récolte d’informations systèmes
  • E) C2 Instruction handler
• Indicateurs d’infection

Introduction

Le sample analysé possède le hash suivant:

2f22d521a1945d02380057a636e1032b

Le sample est téléchargeable sur VirusBay.

Disclaimer habituel: le sample est en théorie inoffensif puisque les serveurs de contrôles n’existent plus, et que le malware n’a pas de potentiel destructeur sur un système infecté, mais une grande prudence reste recommandée lors de la manipulation du fichier.

Reconnaissance

Le sample reste encore assez discret, sachant que celui-ci date déjà de plusieurs mois à l’heure de l’écriture du présent article (d’après VirusTotal):

Mention spéciale pour les antivirus ClamAV, Microsoft-Defender et Ikarus qui ont tous trois détectés précisément le malware:

Le binaire ne semble pas packé au vu de l’entropie du fichier:

Point positif pour l’analyse, le malware a été écrit en dans un langage .Net (dans le cas présent en C#): L’avantage d’un malware écrit dans un langage .Net réside dans le fait que ce langage n’est pas compilé, et peut donc être facilement reverse. Il est ainsi possible de retrouver le code source original du programme.

Enfin, le malware n’est ni packé ni obfusqué, ce qui fait que les chaînes de caractères du binaire sont visibles en clair. Ces chaînes permettent de grignoter quelques informations sur les fonctionnalités du malware avant d’entamer l’analyse, mais rien de bien important ou de décisif dans le cas présent.

DarkHydrus APT

Le malware RogueRobin est attribué à un groupe émergent appelé DarkHydrus. Ce groupe, apparu pour la première fois en 2016, possède deux campagnes malveillantes à son actif.

La première réside sur l’outil open-source Phishery, et vise à dérober des identifiants d’entités gouvernementales du moyen orient, via des documents Words malveillants.

La deuxième campagne active du groupe met en avant le malware qui fait l’objet de l’analyse présente. Celle-ci cible des groupes politiques actifs au moyen orient, et date de juin 2018. Le malware étudié s’inscrit donc dans des objectifs géopolitiques, et le groupe DarkHydrus risque de nouveau de faire parler de lui dans un futur proche.

Analysis

A) Anti-VM et anti-debug

Avant toute action, le malware commence par chercher à détecter si l’environnement d’exécution est compromis, à savoir s‘il s’agit d’une machine virtuelle d’analyse.

En premier lieu, c’est via le serial-number du BIOS de la machine, que la malware va chercher à détecter les machines virtuelles.

Le malware se base ici sur des commandes powershell externes pour toute la phase de détection de l’environnement. Dans le cas où l’une des compagnies de virtualisation (VmWare, VirtualBox, BOSH, Qemu ou Xen) est détectée, l’exécution du programme est immédiatement arrêtée:

C’est ensuite au tour du label du fabricant et du modèle de la machine que la détection d’une VM tentera d’être faite, via la commande powershell suivante:

Sur une machine VmWare, le résultat est le suivant par défaut:

Puis, c’est la quantité de mémoire vive disponible qui est scannée par le malware. Si cette quantité n’excède pas les 3Go, le flux d’exécution est stoppé. Bien souvent, les machines virtuelles d’analyse ou les sandbox n’ont pas besoin de beaucoup de performances, et puisque aujourd’hui, il est rare de trouver des machines ayant moins de 3Go de RAM, cette vérification est pertinente: (La variable ‘ulong’ = 2900000000u’)

Pour continuer, le même type de vérification est fait sur le nombre de coeurs du processeur de la machine. Si la machine possède un unique coeur, celle-ci est considérée comme suspecte:

C’est ensuite via les noms d’éditeurs relatifs aux processus en cours que le malware va essayer d’éviter l’analyse. Si un des processus provient de la suite Sysinternals (procmon et procexp par exemple) ou de l’éditeur Wireshark, le malware se ferme:

Pour terminer, le malware vérifie si un débugger est attaché au processus:

Cette dernière vérification clôt la liste des techniques anti-analyses utilisées par le malware RogueRobin.

B) Méthodes de persistance

De façon à passer inaperçu sur le système infecté, RogueRobin se se copie dans le répertoire AppData, sous le nom ‘OneDrive.exe’, afin de ne pas éveiller les soupçons.

Pour survivre à un redémarrage de la machine, le binaire malveillant est ajouté au dossier contenant les exécutables à démarrer au lancement de la session, en créant un raccourci depuis le fichier ‘OneDrive.exe’ précédent:

C) Exfiltration d’informations

Afin de se présenter aux serveurs de contrôles du malware, RogueRobin commence par extraire l’ID du processus malveillant avec la fonction Process.GetCurrentProcess().Id:

Dans mon cas, l’identifiant retourné par la fonction est 3856. Cet identifiant est converti en une chaine de caractère via une fonction qui attribue linéairement une lettre pour chaque chiffre du PID:

La chaine obtenue dans mon cas est donc “kpmn”. A cette chaine de caractère s’ajoute la lettre “a” en début de chaine, et la lettre “c” en fin de chaine. La chaine finale devient donc “akpmnc”:

Cette chaine sera désormais l’identifiant de la machine infectée. Afin de notifier le serveur de contrôle qu’une nouvelle machine est infectée, le malware va chercher à exfiltrer cet identifiant. La particularité du sample RogueRobin réside dans cette fonction d’exfiltration qui ne se fait pas via un simple flux TCP HTTP / HTTPS, mais via un abus du protocole DNS.

1) Principe de l’exfiltration DNS

L’exfiltration via un tunnel DNS consiste à extraire de l’information en abusant du protocole DNS. Le protocole DNS fonctionne sur un système décentralisé, permettant de retourner l’adresse IP d’un serveur en fonction de son FQDN. Pour convertir l’URL “www.exemple.com” en une adresse IP, la machine source va interroger un des serveurs DNS principaux (Top-Level Domain, ou TLD), en lui demandant l’adresse du serveur DNS responsable de la zone “.com”. Celui-ci retournera l’adresse demandé. Le client va ensuite demander l’adresse du serveur DNS responsable de la zone “exemple.com”. Enfin, c’est l’adresse du serveur “www” qui est demandée au DNS de la zone “exemple.com”. De cette façon, un client est capable de traduire une URL en une IP.

L’exfiltration DNS consiste à interroger un serveur DNS compromis pour lui transmettre de l’information. Dans le cas présent, en essayant de retrouver l’IP de l’URL “akpmnc.exemple.com”, par le biais du protocole DNS, le serveur DNS “exemple.com” sera interrogé à propos de la machine “akpmnc”. Même si cette machine n’existe pas, si un adversaire malveillant contrôle le serveur DNS responsable de la zone “exemple.com”, il sera capable de récupérer la chaine “akpmnc”, et donc de lire de l’information extraite de la machine victime.

L’exfiltration DNS a l’avantage d’utiliser un protocole très rarement filtré et surveillé.

2) Exfiltration

Avant toute chose, le cache DNS de la machine est nettoyé avec la commande “ipconfig /flushdns”:

La commande powershell est exécutée de manière transparente pour l’utilisateur de la machine infectée:

Le malware utilise le binaire légitime “nslookup.exe” pour pratiquer l’exfiltration DNS. La commande nslookup est initialisée en fonction du mode de requête DNS souhaité, du timeout, et du domaine d’exfiltration:

Les types de requêtes DNS disponibles sont les suivantes:

Et la liste des domaines à contacter sont les suivants:

Ainsi la première commande effectuée par le malware est la suivante:

A noter qu’une nouvelle technique anti-debug est utilisée avant d’effectuer les commandes d’exfiltration DNS (bien que très sommaire). Si un débugger est détecté par le malware, alors aucun domaine d’exfiltration n’est contacté, et des informations inutiles sont transférées à un domaine légitime de google:

La chaine “676f6f646c75636b” est en fait un message de la part de l’auteur du malware, qui nous est directement destiné. Celui-ci correspond à la chaine hexadécimale “goodluck”:

Si tout se passe bien, la commande d’exfiltration générée plus tôt est enfin exécutée:

Afin de vérifier si la requête a été correctement transmise, le malware analyse le retour de la commande nslookup:

Le malware va continuer de sélectionner un type de message DNS aléatoire associé à l’entièreté de la liste de domaine à contacter, jusqu’à tomber sur un serveur en ligne.

Puisque la liste des serveurs de contrôle est trop vieille à l’heure de mon analyse, j’utilise ici l’outil ApateDNS pour retourner une réponse positive à toutes les requêtes effectuées par le malware:

De ce fait, le malware considère les serveurs de contrôle comme en ligne, en passant la variable “flag” à la valeur “true”:

Le résultat de la réponse DNS de la part du serveur de contrôle est ensuite stockée, de façon à transmettre des ordres au malware.

D) Récolte d’informations systèmes

Le malware récupère quelques informations sur la machine victime avant de les envoyer au serveur de contrôle. Ces informations concernent l’adresse IP de la machine, le nom de la machine, le domaine et le nom d’utilisateur de la session:

La prochaine information récoltée concerne les privilèges utilisateurs avec lesquels le malware a été lancé. A noter qu’une erreur de conception rend cette fonction du programme uniquement opérationnel sur une machine dont le langage est réglé en anglais. La fonction est la suivante:

La fonction retourne donc un des trois cas suivants:

L’erreur de conception de la fonction réside dans le fait que le groupe administrateur d’une machine Windows possède une syntaxe dépendant de la langue d’utilisation, alors que dans le cas présent, le nom du groupe est hardcodé:

Le malware n’est donc pas capable de déterminer les privilèges utilisateurs sur une machine non anglaise.

Ces informations sont concaténées ensemble, en plus de quelques informations supplémentaires, tel que le temps de pause que le malware va utiliser par défaut ou la présence de la méthode de persistance:

La chaine finale contenant les informations à exfiltrer est ensuite convertie en hexadécimale:

Si le malware a été compilé avec le flag “x_mode” à la valeur true, alors RogueRobin va initialiser l’exfiltration au travers d’un document partagé Google Docs, de façon à masquer le flux sortant en le faisant passer pour légitime:

Si le flag “x_mode” n’est pas activé, les informations sont exfiltrées via la technique reposant sur le protocole DNS.

E) C2 Instruction handler

A partir du moment où les informations permettant d’identifier une machine cliente sont transmises au serveur de contrôle, le malware reste en hibernation, et attente d’ordre. Lorsqu’une information est reçue par le malware, celle-ci peut provenir d’une page Google Docs (la même qui sert pour l’exfiltration de données), ou toujours via des réponses à des requêtes DNS.

A l’arrivée d’une commande provenant du serveur de contrôle, les données sont parsés puis converties de l’hexadécimal à l’ASCII. Celles-ci sont ensuite envoyées à la fonction “taskHandler”, qui exécutera l’instruction dans un nouveau thread:

Les instructions proposées sont les suivantes:

• ^kill Un processus en cours est terminé, en fonction de son PID:

• ^\$fileDownload Un fichier local de la machine infectée est envoyé au serveur de contrôle:

• ^\$importModule Exécute une commande ou un script powershell. Cette commande est désormais présente au sein d’une liste de modules, accessibles par la suite:

• ^\$ClearModules La liste des précédentes commandes powershell (modules) est effacée:

• ^\$file_Upload Une ressource provenant du serveur de contrôle est téléchargée dans un répertoire précisé par l’opérateur du malware:

• ^testmode La communication entre le serveur de contrôle et le sample est testée, via une requête DNS dont le contenu correspond à la chaine “testmode”:

• ^exit Le processus parent du malware est terminé:

• ^slp Une nouvelle valeur est attribuée au temps de pause utilisé par le malware entre certaines actions (entre l’envoi de plusieurs requêtes par exemple):

• ^changeConfig Mets à jour certaines informations du malware, notamment la liste des domaines malicieux à contacter:

Mais c’est aussi la taille maximale et minimum des requêtes qui peut être modifiée, tout comme la durée d’attente entre l’envoi de deux messages, la présence ou non de données additionnelles dans les requêtes (attribut ‘hasGarbage’), le type de requête DNS à utiliser pour l’exfiltration de données ou pour contacter le serveur et le nombre de requêtes maximum avant de considérer un domaine ne répondant pas comme étant down.

• ^showConfig Retourne la configuration actuelle du malware, à savoir les valeurs précédemment énumérées :

• ^\$x_mode Active (ou désactive) les capacités de communication au travers d’un fichier GoogleDocs:

Le malware est donc capable de servir de droper (et donc de vecteur d’infection, tous les combos les plus néfastes sont imaginables), mais aussi d’assurer les fonctionnalités basiques d’un trojan, à savoir récupérer des fichiers depuis la machine cible, ou exécuter des commandes distantes. Que ce soit via la possibilitée de communiquer au travers d’un document Google Docs partagé, ou avec la technique d’exfiltration DNS, ce malware est original dans l’exécution de ses fonctionnalités de communication.

Un grand soin a été porté sur la discrétion lors de la conception du programme, ce qui est cohérent au vu des institutions ciblé. L’absence de techniques d’obfuscations ou même d’un simple packer est en revanche très étrange au vu de la complexité des techniques utilisées, et rend la partie anti-debug et anti-vm complètement triviale du point de vue de l’analyse. De même pour le choix d’un langage non compilé … Pourquoi écrire des fonctions censées empêcher l’analyse lorsque celles-ci sont lisibles en clair ?

Indicateurs d’infection

hash du binaire : 2f22d521a1945d02380057a636e1032b

domaines contactés: 0ffice365.agency, 0nedrive.agency, corewindows.agency, microsoftonline.agency, onedrive.agency, sharepoint.agency, skydrive.agency, 0ffice365.life, 0ffice365.services, skydrive.services

Fichier système : %APPDATA%\OneDrive.exe

Fichier système: C:\Users<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\OneDrive.lnk