Une campagne de malware tente d’exploiter les fichiers binaires des défenseurs

Nous avons investigué une campagne de ransomware qui a exploité les exécutables et DLL Sophos légitimes en modifiant leur contenu d’origine, en écrasant le code du point d’entrée et en insérant la charge virale déchiffrée en tant que ressource : en d’autres termes, en usurpant l’identité de fichiers légitimes pour tenter de s’introduire dans les systèmes. Une vérification préliminaire indique que tous les fichiers Sophos concernés faisaient partie de la version 2022.4.3 de notre produit Windows Endpoint.

Certes, ce type de comportement malveillant n’est (malheureusement) pas nouveau pour le secteur de la cybersécurité, voire même pour tout développeur de logiciels. Au fil des années, nous avons vu d’autres voleurs d’informations (infostealers) se faire passer pour des programmes d’installation ; nous avons vu, pêle-mêle, de nombreux faux utilitaires, notamment des logiciels anti-malware, sans marque précise, être rebaptisés comme protections Sophos légitimes ; nous avons vu des cybercriminels attaquer le code source fermé et le code source ouvert avec la même ferveur. Plus loin dans cet article, nous vous présenterons précisément les avantages que les attaquants pensent en retirer et la manière avec laquelle les défenseurs peuvent réagir.

En général, il ne s’agit que d’une partie du paysage technologique : en fait, au cours de notre enquête sur cette campagne, nous avons également constaté des abus similaires ciblant des fichiers publiés par d’autres défenseurs, notamment AVG, BitDefender, Emsisoft et Microsoft, ainsi que l’utilisation d’une potentielle signature numérique compromise (et définitivement expirée) d’une autre société, ainsi qu’un faux “programme d’installation” prétendant être lié au logiciel d’une autre entreprise, ainsi que des dizaines de téléchargeurs/downloaders malveillants, un programme d’installation MSI et d’autres indicateurs de (tentative) de compromission. Notre investigation s’est donc poursuivie, nous permettant d’alimenter le fichier d’indicateurs de compromission (IoC) sur notre Github ; et les éditeurs concernés ont été contactés en privé.

Les charges virales éventuelles que nous avons vues lors de notre enquête varient : Cobalt Strike, Brute Ratel, Qakbot, Latrodectus, entre autres. Il existe des preuves de l’utilisation par plus d’un groupe cybercriminel, mais une investigation plus approfondie sur l’attribution, ou sur la signature compromise ou le faux programme d’installation mentionné ci-dessus, dépasse la portée de cet article.

Soulignons, toutefois, qu’il est toujours intéressant de s’attarder sur ce type d’évènement lorsqu’il se produit. Dans cet article, nous passerons en revue l’une de nos découvertes et ce que nous avons trouvé en poussant un peu plus loin nos recherches.

Premières découvertes

Le premier événement qui a attiré notre attention concernant cette campagne est venu d’une nouvelle mitigation de Sophos, C2 Interceptor, qui a détecté et signalé une tentative de connexion Brute Ratel C2 depuis le système d’un client début février :

Figure 1 : Notre nom Sophos apparait, certes, mais en bien mauvaise compagnie

La partie la plus surprenante concernait les informations de version du fichier malveillant HealthApi.dll qui, comme le montre la figure 1, prétend qu’il s’agit du composant Sophos légitime lié à ce nom. Nous avons commencé à rechercher des échantillons présentant les mêmes caractéristiques et nous en avons trouvés une poignée qui semblaient avoir été créés par le même acteur malveillant, notamment une version (utilisant la signature numérique potentiellement compromise mentionnée ci-dessus) et remontant à janvier. Comme indiqué ci-dessus, nous avons vu diverses charges virales être utilisées. Dans le cadre de cet article, nous nous concentrerons principalement sur ce que nous avons vu lorsque nous avons analysé les échantillons déployant Cobalt Strike ou Brute Ratel.

Le faux programme d’installation semble être le moyen par lequel les fichiers corrompus ont pu pénétrer dans les systèmes, au moins dans un certain nombre de cas. Concernant l’accès initial, nous avons identifié, dans certains cas, des chargeurs/loaders JavaScript qui semblaient avoir été envoyés à la victime (ou aux victimes) par courrier électronique.

Caractéristiques générales

Dans les cas que nous avons examinés pour cet article, le code au niveau du point d’entrée a été écrasé par le code du chargeur/loader malveillant et la charge virale chiffrée a été stockée en tant que ressource dans la section dédiée aux ressources. Ainsi, la structure du fichier PE d’origine a dû être modifiée pour accueillir la ressource malveillante supplémentaire, comme le montre la figure 2.

Figure 2 : Analyse détaillée du fichier PE modifié de manière malveillante

La mise à jour de la structure PE n’est que partielle, par exemple, la table d’exportation n’est pas fixe. Dans une telle situation, les échantillons DLL auront des exportations avec un code incompréhensible (‘cassé’), puisque le code a été écrasé par le code du chargeur/loader malveillant :

Figure 3 : Le code écrasé

En revanche, les champs d’en-tête nécessaires au chargement correct de l’exécutable (par exemple, la taille de l’image) étaient fonctionnels. Plus particulièrement, la taille de la section des ressources dans la table des sections était modifiée, pour masquer que toutes les ressources du fichier original et non altérée (clean) avaient été remplacées par le fichier de ressource contenant la charge virale chiffrée.

La figure 4 montre une comparaison du SophosFS.exe d’origine avec la version de type cheval de Troie :

Figure 4 : À gauche, le vrai produit Sophos ; à droite, le travail réalisé par l’attaquant potentiel

DllRegisterServer

Dans l’exemple 25e24385719aede7f4e0359b389a9597cc26df20e1b3a6367bbc04d5d4982fe6, le fichier est une DLL et le code de la fonction d’exportation de DllRegisterServer correspond à ce qui a été écrasé. Nous pouvons voir qu’une clé est en cours de développement au niveau de la pile. Une analyse plus approfondie révélera que cette clé est utilisée comme clé XOR pour décoder la ressource PE obfusquée de l’attaquant.

Figure 5 : L’attaquant modifie DllRegisterServer ; la clé est visible en bas à droite

Une fois décodé, on retrouve le shellcode qui permettrait à terme de déchiffrer une autre couche pour être injecté en mémoire, puis exécuté. Cet exemple révèle finalement un exécutable sans son en-tête DOS, dans ce cas, Brute Ratel.

Figure 6 : 2022 a lancé un appel, et il envoie une copie indésirable de Brute Ratel

Pendant ce temps, pour les échantillons Cobalt Strike, la charge virale correspond au shellcode http 64-bits habituel :

Figure 7 : Le shellcode http 64-bits habituel

Ou bien alternativement, l’exécutable de la balise (beacon) Cobalt Strike :

Figure 8 : Signes de l’exécutable de la balise/beacon Cobalt Strike : le déchiffreur de la charge virale finale à gauche et la configuration Cobalt Strike extraite à droite

Dans certains cas liés à Cobalt Strike, nous avons vu le chargeur/loader TitanLdr, qui est un shellcode multifonction assez complexe, effectuer le travail de chargement de la charge virale Cobalt Strike. Dans d’autres cas, un shellcode plus simple gérait le processus de chargement de Cobalt Strike. Nous avons également, comme mentionné ci-dessus, noté des chargeurs/loaders JavaScript, qui pouvaient avoir pénétré dans les systèmes clients par email, et qui ont chargé un programme d’installation MSI, qui à son tour a chargé les faux EXE/DLL.

Découvertes ultérieures

Notre investigation s’est poursuivie et, au moment de la publication de cet article, notre fichier IoC (lien ci-dessous) contenait bien plus de 400 entrées. D’autres découvertes plus étranges ont également été révélées. Par exemple, dans au moins un cas, nous avons trouvé un binaire abusé et signé par un certificat (révoqué). La charge virale était Qakbot. Une vérification sur VirusTotal indiquait qu’il s’agissait du seul fichier signé par cette signature particulière, ce qui peut signifier que l’adversaire l’a enregistrée pour son propre usage.

Mais alors … pourquoi ?

Une personne raisonnable pourrait très bien se demander ce que l’attaquant souhaitait accomplir en menant de telles actions. Après tout, les “modifications” ont cassé assez sérieusement les signatures numériques de ces fichiers, à tel point que la plupart des outils ne pouvaient pas du tout identifier les fichiers comme ayant été signés. En effet, ils ne parviennent pas à tromper les processus qui s’appuient sur ces signatures, et si les protections Sophos s’exécutent sur les machines ciblées, ce type de masquage est tout à fait visible pour nous, et nous le stoppons (et partageons nos découvertes avec d’autres défenseurs).

Mais alors … pourquoi ? Pour résumer, ce genre d’action vise à semer la confusion chez quiconque jetterait un coup d’œil rapide aux fichiers. Les acteurs malveillants ne veulent pas attirer l’attention sur eux, donc les noms “joke” ou “133t” sont des mauvais choix ; les fichiers d’apparence légitime, en particulier ceux provenant d’une société de cybersécurité connue, ont plus de chances de passer inaperçus ou de ne pas attirer l’attention des analystes, en particulier lorsqu’une partie du code restant dans les fichiers modifiés est légitime (chaînes, références sources, etc.).

À ce stade tous ces éléments sont-ils annonciateurs d’une vulnérabilité dans le logiciel ? Non, ce qui est à la fois un soulagement (pas de bug = bon signe) et un non-soulagement (aucun moyen de l’empêcher = mauvais signe). Comme nous le verrons dans la section suivante, les fichiers concernés dans ce cas provenaient d’une version spécifique d’un package particulier, non pas parce que ce package contenait un bug, mais simplement parce que l’attaquant a pu obtenir une copie de ce dernier.

Échantillons

À ce stade, cette enquête a découvert des échantillons affectant plusieurs exécutables ou DLL Sophos ; cela s’est produit plus d’une fois avec deux fichiers, même si pour aucun fichier nous n’avons repéré plus d’une version affectée. Une vérification préliminaire indique que tous les fichiers impliqués faisaient partie de la version 2022.4.3 de notre produit Windows Endpoint (la version en cours de déploiement est la 2023.2).

Nous fournissons dans cette section un échantillon des fichiers trouvés au fur et à mesure du déroulement de cette investigation, quelle fonction légitime remplissent-ils dans les produits Sophos et qu’est-ce que l’attaquant tentait-il de réaliser dans chaque cas. La liste est classée par fichier Sophos concerné.

Nous avons vu plusieurs fichiers ciblés par deux tentatives d’altération distinctes. En voici deux, pour montrer à quoi elles ressemblent :

Détections et protections

Plusieurs protections Sophos détectent ou bloquent ces fichiers modifiés de manière malveillante. Ceux-ci incluent ATK/ScLoad-N, ATK-ScLoad-L, ATK/SCLoad-M, ATK/SCLoad-O, Troj/Cobalt-JA, Troj/Mdrop-JXD et la protection dynamique du shellcode, ainsi que la mitigation de l’intercepteur C2 mentionné au tout début de cet article.

Réponses du secteur

Une telle campagne est bruyante et d’autres défenseurs ont également lancé des chasses aux menaces. Nous notons avec plaisir que Palo Alto Networks, qui constate également le même type d’activité, a également publié des informations relatives à cette campagne, notamment une visualisation du flux d’attaque de celle-ci. De plus, certains observateurs signalent une nouvelle souche de malware provisoirement appelée Oyster/CleanUpLoader qui apparaît parallèlement à cette campagne ; Les clients Sophos sont déjà protégés, mais nous continuons à suivre cette évolution avec intérêt.

Comme indiqué ci-dessus, nous avons contacté les entreprises mentionnées dans cet article ainsi qu’un certain nombre d’autres également concernées ; et à mesure que l’investigation progressait, notre démarche de sensibilisation suivait le même rythme. Dans le cadre de ce processus, Bitdefender (l’une des sociétés dont les fichiers binaires sont concernés) a examiné les données relatives à leurs fichiers et nous demande de relayer les éléments suivants :

Bitdefender a été informé de la modification du binaire utilisé dans ces attaques. Bitdefender a reconnu que, étant donné que les binaires ont été utilisés indépendamment, en dehors des fonctionnalités normales du logiciel, aucune autre action n’est requise. Les produits Bitdefender installés sur un système ne sont pas vulnérables à cette méthode de corruption de binaire.

IoC

Un ensemble d’indicateurs de compromission associé à cette campagne est disponible sur notre GitHub. Comme il s’agit d’une investigation toujours en cours, ce dossier pourrait s’étoffer au fil du temps.

Remerciements

Colin Cowie et Jordon Olness de l’équipe MDR Threat Intel ont contribué à cette recherche.

Billet inspiré de Malware campaign attempts abuse of defender binaries, sur le Blog Sophos.