Nouveauté : la distribution de script selon Nietzsche

Auteurs :

• Jozsef Gegeny, Chercheur senior en sécurité
• Norbert Biro, Chercheur senior en sécurité
• Robert Neumann, responsable, laboratoires Acronis TRU

Au cours de la dernière décennie, le rôle des chaînes de HA est devenu de plus en plus important. Les cybermenaces ont évolué, de la simple livraison d'un e-mail avec une pièce jointe malveillante ou un téléchargement furtif à l'ajout de plusieurs étapes intermédiaires avant de déployer la charge active finale. Ces étapes supplémentaires visent toutes à contourner les solutions de sécurité déployées et à assurer la livraison effective de la charge active. Cependant, leur complexité souvent inutile crée également des risques supplémentaires. Comme pour les chaînes traditionnelles, si elles se brisent à un endroit quelconque, la continuité est perdue à jamais.

Nous avons récemment découvert une chaîne de diffusion complexe utilisant plusieurs langages de script, dans le but ultime de déployer des malwares de grande envergure, tels que DCRat, un malware open source, ou l'infostealer Rhadamanthys.

Notre enquête a commencé par la réception d'un e-mail avec une archive RAR en pièce jointe. L'archive ne contient aucun contenu légitime, mais un fichier de script Visual Basic (VBS) appelé « Citación por embargo de cuenta » (Citation pour saisie sur compte). Le nom de fichier s'adresse clairement à un public hispanophone. Il s'agit d'un avis légal relatif à la saisie ou au gel d'un compte bancaire en raison d'une dette ou d'autres obligations financières. L'intention est claire : le destinataire du message est incité à ouvrir la pièce jointe sans hésiter, ce qui déclenche l'exécution d'une chaîne de diffusion malveillante.

Le fichier VBS malveillant utilise des injecteurs imbriqués, selon un processus de diffusion en plusieurs étapes. Nous avons divisé notre analyse en quatre phases distinctes, comme le montre la figure ci-dessous.

Le script Visual Basic pèse environ 200 Ko, ce qui indique qu'il ne s'agit pas d'un simple script d'automatisation interne. Lorsqu'on y regarde de plus près, il est également évident que nous avons affaire à une opération d'obfuscation. La taille plutôt inhabituelle du fichier est en partie due à l'obfuscation, comme l'analyse ultérieure le montrera. Il contient également une charge active codée, qui ne sera extraite qu'à la phase trois.

Il existe différentes manières de traiter l'obfuscation : on peut la désobfusquer manuellement, tirer parti du support AMSI de Microsoft ou tout simplement l'ignorer, en espérant intercepter la charge active finale au moment de la phase d'exécution. Chez Acronis, nous sommes convaincus de la nécessité d'une approche multicouche de détection des menaces. C'est pourquoi, chaque fois que cela est possible, nous préférons neutraliser le contenu malveillant avant son exécution. En plus du support AMSI, nous utilisons un émulateur de script générique développé en interne, basé sur un concept d'arbre de syntaxe abstraite (AST), pour automatiser la désobfuscation dans des scénarios similaires.

Après déobfuscation, le script devient beaucoup plus lisible pour un être humain. La fonction principale du script VBS initial est de générer un fichier lot Windows (BAT) auquel transférer l'exécution. Le fichier BAT malveillant est placé dans le répertoire du profil de l'utilisateur :

Le script VBS crée également une copie de lui-même dans le même répertoire :

Sans surprise, notre script injecté par lot en phase 2 utilise également l'obfuscation, à l'identique de la couche précédente.

Lorsqu'il est exécuté, le fichier lot construit une chaîne codée en Base64 à partir de nombreuses variables d'environnement, à l'aide de la commande « set ». Cette chaîne Base64 représente un script PowerShell compact qui sera exécuté à l'aide de l'argument « -command », comme une invite de commande Windows PowerShell :

En substance, les données Base64 décodées sont déposées sous forme de script PowerShell dans le répertoire du profil utilisateur :

et s'exécute avec la commande suivante :

Il est intéressant de noter que les acteurs de la menace n'ont pas procédé à l'obfuscation de cette couche, car le texte est en clair et facilement lisible :

Il contient toutefois quelques citations notables, telles que :

La plupart, sinon la totalité, des citations sont du philosophe allemand Friedrich Nietzsche. Les guillemets sont ajoutés sous forme de commentaires dans le script PowerShell et n'ont aucune utilité fonctionnelle. Qui sait, les auteurs de malwares sont peut-être des philosophes.

La fonction principale de ce script est de localiser le fichier aguwDl.bat des phases précédentes dans le répertoire du profil de l'utilisateur, de lire la dernière ligne (très longue) de ce fichier, de supprimer les octets de marque, puis de décoder et de charger la charge active résultante en mémoire :

La charge active enregistrée en mémoire est un exécutable Windows .NET appartenant à une famille très répandue de chevaux de Troie d'accès distant, appelée DCRat.

Compressée à l'aide d'un outil de compression .NET personnalisé, la charge active est fortement obfusquée. L'analyse révèle la présence de deux blobs de données chiffrées dans sa structure de ressources.

Ces blobs utilisent uniquement un chiffrement de base et les données peuvent être facilement déchiffrées à l'aide d'une opération XOR octet par octet avec la clé 0x78. Le décodage de ces ressources révèle deux exécutables supplémentaires :

L'exécutable principal est DCRat, l'autre est une bibliothèque qui prend en charge le module de compression pour charger et exécuter l'échantillon de DCRat en mémoire directement, sans l'écrire sur le disque. Cette technique, connue sous le nom de RunPE, est implémentée dans la bibliothèque d'assistance. Le code binaire principal de DCRat est plutôt obsolète à l'heure actuelle, mais une infection réussie demeure possible grâce à des méthodes de diffusion similaires.

Les chaînes de diffusion de campagnes malveillantes évoluent sans cesse et deviennent de plus en plus complexes. Les auteurs de cybermenaces cherchent des moyens de dissimuler leur charge active finale, même si elle n'est qu'une variante d'une famille de malware connue depuis des années. Ainsi, même des codes binaires de malwares anciens peuvent s'exécuter sans intervention, à moins que la solution de sécurité déployée soit capable de détecter leur présence en mémoire.

Toutefois, plus ces chaînes de diffusion sont complexes, plus elles sont exposées à des risques supplémentaires et à des risques d'interruption à chaque étape, ce qui empêche finalement l'aboutissement attendu de la charge active.

À l'occasion de l'analyse de cette campagne, nous en avons découvert des similaires, avec une chaîne d'infection identique à celle décrite ci-dessus, mais une charge active finale différente. Au lieu de déployer DCRat, les agresseurs ont utilisé l'infostealer Rhadamanthys et un autre cheval de Troie populaire d'accès distant : Remcos.

Acronis Advanced Security + Extended Detection and Response (XDR) détecte avec succès les composants utilisés dans la chaîne d'attaque.