Une campagne malveillante récemment découverte par des chercheurs en sécurité de ReversingLabs tire parti de l’incapacité de la plupart des outils d’analyse des vulnérabilités de ne pas lire le code compilé.
Les attaquants qui ciblent les dépôts de paquets open source tels que PyPI (Python Package Index) ont mis au point une technique pour dissimuler leur code malveillant aux scanners de sécurité, aux examens manuels et à d’autres formes d’analyse de sécurité. Dans un cas, les chercheurs ont trouvé un code malveillant caché dans un fichier PYC (Python bytecode) qui peut être exécuté directement, contrairement aux fichiers de code source qui sont interprétés par le moteur d’exécution Python. « Il pourrait s’agir de la première attaque de la chaîne d’approvisionnement à tirer parti du fait que les fichiers bytecode Python peuvent être directement exécutés, et elle survient au milieu d’un pic de soumissions malveillantes à l’index des paquets Python », ont déclaré les chercheurs de la société de sécurité ReversingLabs dans un rapport. « Si c’est le cas, cela pose un nouveau risque pour la chaîne d’approvisionnement, car ce type d’attaque risque de ne pas être détecté par la plupart des outils de sécurité, qui n’analysent que les fichiers de code source Python ».
La grande majorité des paquets trouvés sur des dépôts publics tels que npm pour JavaScript, PyPI pour Python et RubyGems pour Ruby consistent en des fichiers de code open source qui sont empaquetés dans des archives. Ils sont faciles à décompresser et à lire, et c’est pourquoi les scanners de sécurité de ces dépôts ont été conçus pour gérer ce type de paquet. Les attaquants livrent une bataille constante avec les sociétés de sécurité pour échapper à la détection, et la technique d’évasion la plus courante lorsqu’il s’agit de code en clair est l’obscurcissement. Cette technique consiste à utiliser les caractéristiques du langage de programmation lui-même, telles que le codage, le décodage ou l’évaluation, pour rendre le code illisible mais fonctionnel. Par exemple, l’encodage d’un code malveillant en base64 est une technique couramment utilisée, mais les outils de sécurité peuvent traiter ce type d’encodage.
Des charge utiles difficiles à détecter…
Dans l’écosystème PyPI, les cybercriminels à l’origine du logiciel malveillant W4SP Stealer sont connus pour utiliser des techniques telles que l’encodage base64, la compression LZMA et la minification (suppression des espaces et des commentaires dans le code pour le rendre plus compact, mais aussi plus difficile à lire). Pour ce faire, le groupe utilise des outils open source tiers tels que pyminifier, Kramer ou Hyperion. Dans une variante des attaques W4SP, le code malveillant obscurci dans les fichiers était déplacé au-delà des bords de l’écran par défaut, de sorte qu’une personne examinant manuellement le fichier de code source ne le verrait pas. Cependant, les fichiers PYC sont différents car ils ne sont pas lisibles par l’homme comme les scripts PY en texte clair. Les fichiers PYC sont générés lorsque l’interpréteur Python importe ou exécute un script de ce type. Comme il s’agit d’un code déjà interprété (compilé), il peut être exécuté directement par l’interpréteur Python sans réinterpréter le script d’origine. Cela améliore les performances car les temps d’exécution sont plus rapides. L’utilisation la plus courante de ces fichiers est la distribution de modules Python.
Dans la plupart des cas de logiciels malveillants PyPI, le code obfusqué malveillant est destiné à atteindre une URL externe et à télécharger le logiciel malveillant – généralement un stealer – ce qui constitue une autre occasion pour les outils de sécurité de détecter un comportement suspect. Dans le dernier incident en date, un paquet appelé fshec2 contenant un fichier PYC malveillant, sa charge utile complète peut être cachée dans le fichier et il est beaucoup plus difficile de la détecter si l’outil de sécurité n’est pas conçu pour la décompiler. « Les scripts de chargement tels que ceux découverts dans le paquet fshec2 contiennent une quantité minimale de code Python et exécutent une action simple : le chargement d’un module Python compilé », expliquent les chercheurs de ReversingLabs. « Il se trouve qu’il s’agit d’un module malveillant.
Inspector, l’outil par défaut fourni par l’équipe de sécurité de PyPI pour analyser les paquets PyPI, ne permet pas, pour l’instant, d’analyser les fichiers binaires pour repérer les comportements malveillants. Le code compilé du fichier .PYC a dû être décompilé afin d’analyser son contenu ». Le paquet fshec2 trouvé par ReversingLabs présentait un comportement supplémentaire qui visait probablement à échapper à la détection. Normalement, un module est importé d’un script Python à l’aide de la directive import. Cependant, dans ce cas, le module PYC malveillant a été chargé à l’aide d’importlib, un package qui met en œuvre la fonctionnalité d’importation et qui n’est utilisé que dans des cas particuliers, par exemple lorsqu’une bibliothèque importée est modifiée dynamiquement lors de l’importation. Dans ce cas, le PYC malveillant n’a pas été modifié, il n’y a donc aucune raison technique d’utiliser importlib, si ce n’est pour éviter d’utiliser la directive d’importation normale, probablement pour échapper à la détection.
… et poussées en tant que script Python
Une fois exécutée sur une machine, la charge utile malveillante fshec2 recueille des informations sur le système, telles que les noms d’utilisateur, les listes de répertoires et les noms d’hôte, puis met en place une tâche CRON sous Linux ou une planifiée sous Windows pour exécuter des commandes récupérées sur un serveur distant. Ces dernières donnent la possibilité au malware de se mettre à jour automatiquement, les attaquants étant en mesure de fournir une nouvelle version, ainsi que des charges utiles supplémentaires sous la forme de scripts Python.
Les chercheurs de ReversingLabs ont analysé le serveur de commande et de contrôle et ont trouvé des configurations erronées qui leur ont permis de jeter un coup d’œil sur certaines informations. Par exemple, ils ont constaté que les machines victimes recevaient un ID incrémentiel et ont pu confirmer que le logiciel malveillant avait bien été exécuté par plusieurs victimes. « Le nombre de ces erreurs pourrait nous amener à conclure que cette attaque n’est pas le fait d’un acteur bénéficiant d’un soutien étatique ni d’une menace persistante avancée (APT) », ont déclaré les chercheurs. « Bien que mon équipe n’ait pas recueilli suffisamment d’éléments pour prouver cette hypothèse d’une manière ou d’une autre, le fait de récolter les noms de fichiers en incrémentant l’ID du fichier nous a permis de déterminer que l’attaque avait réussi dans certains cas. Nos chercheurs ne sont toujours pas en mesure de dire qui étaient les cibles ou ce qu’elles étaient. Cependant, nous pouvons confirmer que des développeurs ont installé le paquet PyPI malveillant et que leurs noms de machine, noms d’utilisateur et listes de répertoires ont été récoltés en conséquence ». Certains des noms de fichiers trouvés sur le serveur suggèrent que les attaquants ont déployé une fonctionnalité de keylogging sur certaines des machines. « Historiquement, npm a été le leader malheureux et PyPI a également fait la course pour voir quelle plateforme open source attire le plus d’attention de la part des auteurs de logiciels malveillants », ont déclaré les chercheurs. « Toutefois, au cours des six derniers mois, ReversingLabs et d’autres ont observé une nette augmentation du volume de logiciels malveillants publiés sur PyPI. En fait, en mai, la création de nouveaux comptes d’utilisateurs et de projets sur PyPI a été temporairement suspendue pendant quelques heures en raison d’un volume élevé d’activités malveillantes ».
Aller au-delà de l’analyse statique du code
ReversingLabs a signalé ce dernier vecteur d’attaque à l’équipe de sécurité de PyPI, qui a supprimé le paquet et déclaré n’avoir jamais vu cette technique d’attaque auparavant. Cela n’exclut pas la possibilité que d’autres paquets similaires fassent leur apparition dans le dépôt. Pour faire face à ces menaces modernes qui pèsent sur la chaîne d’approvisionnement logicielle, les entreprises ont besoin d’aller au-delà des solutions d’analyse statique du code. Elles doivent recourir à des outils capables de surveiller les systèmes de développement sensibles pour détecter la création de processus suspects, l’exécution de fichiers, l’accès non autorisé à des URL, les commandes de collecte d’informations et l’utilisation de fonctions faciles à abuser telles que get_path ou importlib.
Mandiant a lancé une alerte sur un malware nommé Cosmicenergy. Créé par un éditeur russe en cybersécurité, il pourrait être utilisé contre des réseaux électriques d’autres pays.
Au cours des dernières années, les cyberattaquants épaulés par des Etats ont renforcé leurs capacités à frapper les infrastructures critiques, comme les réseaux électriques, pour provoquer de graves perturbations. Cet arsenal s’est enrichi d’une boîte à outils qui semble avoir été mise au point par une société russe de cybersécurité pour des exercices red team. Baptisé Cosmienergy par les chercheurs de Mandiant, le malware peut interagir avec des unités terminales distantes (RTU) et d’autres dispositifs de technologie opérationnelle (OT) qui communiquent via le protocole spécialisé IEC 60870-5-104 (IEC-104) et sont couramment utilisés pour l’ingénierie électrique et l’automatisation de la production d’énergie. « Cosmicenergy est le dernier exemple en date de logiciels malveillants spécialisés dans l’OT, capables de provoquer des impacts qui sont rarement découverts ou divulgués », expliquent les chercheurs de Mandian dans leur rapport. « L’analyse du malwware et de ses fonctionnalités révèle que ses capacités sont comparables à celles employées dans des incidents et des programmes antérieurs, tels que Industroyer et Industroyer.V2, deux variantes déployées dans le passé pour avoir un impact sur la transmission et la distribution d’électricité via la norme CEI-104 ».
Egalement connu sous le nom de Crashoverride, Industroyer est un logiciel malveillant qui a été utilisé en 2016 contre le réseau électrique ukrainien et a privé d’électricité un cinquième de Kiev, la capitale du pays, pendant une heure. Le malware atteignait les RTUs sur le réseau OT via des serveurs MS-SQL puis émettait des commandes On/Off via la CEI-104 pour impacter les interrupteurs et les disjoncteurs des lignes électriques. La création et l’utilisation d’Industroyer sont attribuées à Sandworm, un groupe APT qui serait une unité de cyberguerre au sein du GRU, le service de renseignement militaire russe. En 2022, Sandworm a tenté une nouvelle attaque contre le réseau électrique ukrainien en utilisant une version actualisée du malware, baptisée Industroyer.V2.
Caché derrière une offre red team d’un éditeur
La dernière trousse à outils Cosmicenergy découverte par Mandiant a été téléchargée sur un service public d’analyse de logiciels malveillants en décembre 2021 par une personne en Russie. Une analyse du code suggère qu’il a été créé pour les exercices red team hébergés par une société russe de cybersécurité appelée Rostelecom-Solar ayant des liens avec le gouvernement russe. « Bien que nous n’ayons pas identifié de preuves suffisantes pour déterminer l’origine ou l’objectif de Cosmicernergy, nous pensons qu’il a peut-être été développé par Rostelecom-Solar ou une partie associée pour recréer des scénarios d’attaque réels contre des actifs du réseau énergétique », ont déclaré les chercheurs. « Il est possible que le programme ait été utilisé pour soutenir des exercices tels que ceux organisés par Rostelecom-Solar en 2021 en collaboration avec le ministère russe de l’énergie ou en 2022 pour le Forum économique international de Saint-Pétersbourg (SPIEF) ».
Rostelecom-Solar a reçu des fonds du gouvernement russe pour former des experts en cybersécurité et mener des exercices de perturbation du réseau électrique et de réponse aux situations d’urgence. Un module de la boîte à outils du logiciel malveillant contient une référence à Solar Polygon et les personnes qui recherchent ce terme le relient à Rostelecom-Solar. Selon Mandiant, malgré ses liens apparents avec des exercices red team, il est possible que ce kit de logiciels malveillants ait été ou puisse être réutilisé pour des attaques réelles, y compris par des acteurs étatiques russes qui ont déjà fait appel à des entrepreneurs privés pour développer des outils.
Charge utile de logiciel malveillant à double détente déployée manuellement
Cosmicernergy se compose de deux éléments, l’un écrit en Python et l’autre en C++. Le premier, que Mandiant a baptisé PIEHOP, est conçu pour se connecter à des serveurs MS-SQL et télécharger des fichiers ou émettre des commandes. Une fois connecté, il déploie le second composant, baptisé LIGHTWORK, qui est conçu pour émettre des commandes On/Off aux RTU connectés via IEC-104 sur TCP. « Il utilise des messages configurables IEC-104 Application Service Data Unit (ASDU) pour modifier l’état des adresses d’objets d’information (IOA) des RTU en les activant ou en les désactivant », expliquent les chercheurs. « LIGHTWORK utilise des entrées de ligne de commande pour le dispositif cible, le port et la commande IEC-104. Les IOA correspondent aux entrées et sorties des RTU, qui, selon la configuration et le déploiement, peuvent correspondre à des disjoncteurs ou à des interrupteurs de lignes électriques ». Cependant, selon Mandiant, les mappings des IOA peuvent varier d’un fabricant de RTU à l’autre, d’un appareil à l’autre et même d’un environnement à l’autre, ce qui signifie que les attaquants doivent disposer d’informations de reconnaissance préexistantes sur le déploiement qu’ils ciblent. L’échantillon analysé de LIGHTWORK comportait huit IOA codés en dur, mais il est difficile de déterminer quelle était l’intention des attaquants lorsqu’ils ont émis des commandes sans connaître les actifs ciblés exacts.
En outre, le composant PIEHOP et le logiciel malveillant lui-même ne disposent d’aucune capacité de découverte de réseau intégrée, ce qui signifie que les attaquants doivent déjà disposer d’informations sur les serveurs MSSQL et les RTU ciblés, telles que les identifiants et les adresses IP, pour déployer les composants avec succès. Il s’agit donc d’une boîte à outils post-intrusion. Bien que Cosmicenergy ne partage aucun code avec les outils malveillants OT précédents, il emprunte des techniques à plusieurs d’entre eux, outre Industroyer : l’utilisation de Python pour le développement de logiciels malveillants OT a également été observée avec IRONGATE et TRITON ; l’utilisation de bibliothèques open source qui mettent en œuvre des protocoles OT propriétaires et abaissent la barre pour le développement de telles menaces ; et l’utilisation abusive de protocoles qui ne sont pas sécurisés de par leur conception, tels que IEC-104, et qui manquent de mécanismes d’authentification ou de chiffrement.
Atténuer et détecter les attaques Cosmicernergy
Bien qu’il n’y ait aucune preuve que Cosmicernergy ait été utilisé dans des attaques sauvages, la possibilité ne peut être écartée et, à tout le moins, il peut inspirer d’autres développeurs de malwares OT, tout comme Industroyer a servi à inspirer ses créateurs. L’enquête de Mandiant contient des indicateurs de compromission et des hachages de fichiers, mais l’entreprise recommande également aux organisations de mener une chasse active aux menaces. Les voici :
1/ Mettre en place la collecte et l’agrégation des journaux basés sur l’hôte pour les systèmes de la couronne tels que les interfaces homme-machine (HMI), les stations de travail d’ingénierie (EWS) et les serveurs clients OPC au sein de leurs environnements et examiner les journaux afin de prouver l’exécution de scripts Python ou de codes non autorisés sur ces systèmes ;
2/ Identifier et enquêter sur la création, le transfert et/ou l’exécution d’exécutables Python non autorisés (par exemple, PyInstaller ou Py2Exe) sur des systèmes d’OT ou des systèmes ayant accès à des ressources d’OT ;
3/ Surveiller les systèmes ayant accès aux ressources de l’OT pour détecter la création de dossiers temporaires légitimes, de fichiers, d’artefacts et de bibliothèques externes nécessaires pour prouver l’exécution de scripts Python, par exemple la création d’un dossier PyInstaller temporaire “_MEIPASS” ,
4/ Surveiller les serveurs MSSQL ayant accès aux systèmes et réseaux d’OT afin de détecter les éléments suivants : activités de reconnaissance et d’énumération des serveurs MSSQL et des informations d’identification, connexions réseau non autorisées aux serveurs MSSQL (TCP/1433) et authentification irrégulière ou non autorisée, activation et utilisation de procédures stockées SQL étendues pour l’exécution de commandes shell Windows et le transfert, la création, la mise en scène et le décodage d’exécutables codés en base64.
Ciblant les systèmes utilisant des VPN pour obtenir un accès indésirable et installer une porte dérobée, le groupe de cybercriminels par ransomware Cactus sort du lot. Sa technique débouche sur de gros risques en termes de sécurité informatique pour les entreprises.
Un groupe de cybercriminels compromet les réseaux d’entreprise depuis deux mois pour déployer un ransomware jusqu’alors inédit dénommé Cactus. Dans les attaques observées jusqu’à présent, les attaquants ont obtenu un accès en exploitant des vulnérabilités connues de systèmes VPN avant d’effectuer des déplacements latéraux pour déployer des outils de surveillance et de gestion à distance (RMM) afin de réussir à persister sur le réseau. Le nom de ce rançongiciel se retrouve dans la note de rançon des cybercriminels (cAcTuS.readme.txt) mais est aussi un « nom auto-déclaré », ont expliqué les chercheurs de Kroll Cyber Threat Intelligence dans un dernier rapport pas encore rendu public mais consulté par Bleeping Computer. « Les fichiers chiffrés sont accompagnés de l’extension .cts1 », bien que Kroll note que le nombre à la fin de l’extension varie selon les incidents et les victimes. Le fournisseur a observé l’exfiltration de données sensibles et l’extorsion de victimes via le service de messagerie peer-to-peer connu sous le nom de Tox, mais aucun site connu de fuite de victimes n’a été identifié au moment de l’analyse, ont précisé ces chercheurs en sécurité.
Dans tous les cas étudiés par Kroll, les attaquants ont mis un pied dans un système VPN en utilisant un compte de service, puis déployé une porte dérobée SSH qui se connectait à leur serveur de commande et de contrôle (C2) et exécutée par le biais d’une tâche programmée. Cette activité a été immédiatement suivie d’une reconnaissance du réseau à l’aide d’un scanner de réseau Windows du marché fabriqué par la société australienne SoftPerfect. Des commandes et des scripts PowerShell supplémentaires ont été utilisés pour énumérer les ordinateurs du réseau et extraire les comptes d’utilisateurs du journal des événements de Windows Security. Un autre script de balayage du réseau basé sur PowerShell, appelé PSnmap.ps1, a également été observé dans certains cas. Le groupe a ensuite été en mesure de déverser les informations d’identification LSASS et rechercher les fichiers locaux susceptibles de contenir des mots de passe pour identifier les comptes qui pourraient leur permettre d’accéder à d’autres systèmes via le protocole de bureau à distance (RDP) et d’autres méthodes. Pour maintenir la persistance sur les systèmes qu’ils ont compromis, les attaquants déploient des outils RMM tels que Splashtop, AnyDesk et SuperOps, ainsi que l’implant Cobalt Strike ou le proxy SOCKS5 Chisel. L’utilisation abusive d’outils RMM légitimes est une technique courante chez les acteurs de la menace. « Chisel aide à tunneliser le trafic à travers les pare-feux pour fournir des communications cachées au C2 de l’acteur de la menace et est probablement utilisé pour tirer des scripts et des outils supplémentaires sur le point de terminaison », ont déclaré les chercheurs de Kroll. L’un de ces scripts utilise l’outil Windows msiexec pour tenter de désinstaller des programmes anti-virus courants. Dans un cas, les attaquants ont même utilisé l’outil de désinstallation de Bitdefender.
Le flux d’exécution du ransomware Cactus. (crédit : Kroll)
Des données exfiltrées dans le cloud
Une fois que le groupe a identifié les systèmes contenant des données sensibles, il utilise l’outil Rclone pour exfiltrer les informations vers des comptes de stockage cloud et se prépare à déployer le programme de ransomware. Pour ce faire, il utilise un script appelé TotalExec.ps1 qui a également été utilisé par les cybercriminels à l’origine du ransomware BlackBasta. Tout d’abord, les attaquants déploient un script batch appelé f1.bat qui crée un nouveau compte d’utilisateur admin sur le système et ajoute un script secondaire appelé f2.bat à la liste d’exécution automatique du système. Ce script extrait le binaire du ransomware d’une archive 7zip et l’exécute. L’outil PsExec est également utilisé pour lancer le binaire sur des systèmes distants. Ce dernier a trois modes d’exécution : installation, configuration et chiffrement.
En mode configuration, il crée un fichier appelé C:ProgramDatantuser.dat qui contient des données de configuration chiffrées pour le ransomware. Il crée ensuite une tâche planifiée qui exécute le ransomware. Lorsqu’il est exécuté avec l’option de chiffrement, le binaire du ransomware extrait et déchiffre une clé publique RSA codée en dur. Il commence ensuite à générer des clés AES pour le chiffrement des fichiers, et ces clés sont ensuite chiffrées avec la clé publique RSA. Le processus s’appuie sur l’implémentation Envelope de la bibliothèque OpenSSL, ce qui signifie que le fichier chiffré résultant contiendra également la clé AES chiffrée qui a été utilisée pour chiffrer le fichier. Pour récupérer la clé AES, l’utilisateur a besoin de la clé RSA privée, qui est entre les mains des attaquants.
Des recommandations à suivre
Le rapport de Kroll comprend une analyse des tactiques, techniques et procédures (TTP) selon le cadre MITRE ATT&CK, ainsi que des indicateurs de compromission. Les chercheurs recommandent de maintenir à jour les systèmes accessibles au public, tels que les appliances VPN, de mettre en œuvre des gestionnaires de mots de passe et une authentification à deux facteurs, de surveiller les systèmes pour l’exécution de PowerShell et de consigner son utilisation, d’auditer les comptes d’administrateur et de service, de mettre en œuvre les principes de moindre privilège et de revoir les stratégies de sauvegarde afin d’inclure au moins une sauvegarde isolée du réseau de l’entreprise.
Le malware Rilide incite les victimes à révéler leur authentification à double facteur pour retirer de façon silencieuse des monnaies virtuelles grâce à une extension de navigateur web malveillante.
Plusieurs cybergangs utilisent une extension malveillante, baptisée Rilide, pour les navigateurs basés sur Chromium incluant Google Chrome, Microsoft Edge, Brave et Opera. Objectif : voler des actifs en crypto-monnaie à partir de plusieurs sites web et portefeuilles en ligne. Cet add-on fonctionne en injectant un code piégé dans des pages web depuis le navigateur installé sur le poste d’un utilisateur afin de déjouer l’authentification double facteur (2FA) et supprimer les alertes automatisées des messageries électroniques. « Rilide n’est pas le premier logiciel malveillant que SpiderLabs a observé en utilisant des extensions de navigateur malveillantes », ont déclaré les chercheurs de Trustwave SpiderLabs dans un rapport. « Ce qui différencie ce malware, c’est qu’il a une capacité efficace et rarement utilisée de s’appuyer sur de fausses boîtes de dialogue pour tromper les utilisateurs et les amener à révéler leur authentification double facteur, puis à retirer des crypto-monnaies en arrière-plan. Au cours de notre enquête sur les origines de Rilide, nous avons découvert que des extensions de navigateur similaires étaient proposées à la vente. En outre, nous avons découvert qu’une partie de son code source avait récemment été divulguée sur un forum clandestin à la suite d’un litige de paiement ».
Les chercheurs de Trustwave ont identifié d’autres programmes malveillants utilisant Rilide sur des ordinateurs compromis. Il semble donc qu’il soit utilisé comme charge utile secondaire ou comme module de compromission dans le cadre d’attaques plus vastes. Des pirates emploient Ekipa RAT, un cheval de Troie d’accès à distance vendu sur des forums du dark net, et ont été vus en train de déployer l’extension Rilide via un chargeur basé sur Rust. Le malware Ekipa RAT a été distribué sous la forme d’un fichier Microsoft Publisher contenant des macros malveillantes. L’année dernière, Microsoft a commencé à bloquer l’exécution des macros Office dans les fichiers téléchargés depuis le web. Toutefois, Publisher ne faisait pas partie des applications Office concernées par ce changement. Cette erreur a été corrigée en février dernier. Les chercheurs de Trustwave pensent que la distribution de Rilide via Ekipa RAT a été temporaire et qu’elle résulte probablement du fait que les attaquants à l’origine de l’extension ont testé différentes plateformes et options de distribution de logiciels malveillants. En effet, peu de temps après, l’extension a commencé à être distribuée par le biais d’un programme de vol d’informations appelé Aurora.
Camouflé en programme légitime
Aurora est écrit en Go et est exploité comme une plateforme de logiciels malveillants à la demande (as a service), et poussé sur les forums de cybercriminalité en langue russe. Le malware est capable de voler des données et des identifiants à partir de plusieurs navigateurs web, de portefeuilles de crypto-monnaies et d’autres applications locales. Aurora a récemment été distribué par le biais d’une publicité frauduleuse via la plateforme Google Ads, où il s’est fait passer pour un programme d’installation pour Teamviewer ou le site de téléchargement de micrologiciels pour cartes graphiques Nvidia Drivers. Aurora est un logiciel malveillant modulaire. L’une de ses caractéristiques observées dans les échantillons récents contenait une URL pour télécharger un fichier exécutable à partir d’un serveur distant.
Ce fichier était le même chargeur écrit en Rust vu dans la campagne RAT Ekipa et conçu pour télécharger et déployer l’extension Rilide. Le chargeur basé sur Rust y parvient en modifiant les raccourcis normaux (LNK) des navigateurs ciblés sur le système infecté afin de lancer les navigateurs avec le paramètre « load-extension » pointant vers l’add-on malveillant. En effet, les browsers basés sur Chromium ne prennent pas en charge l’installation d’extensions qui ne sont pas hébergées dans les boutiques d’extensions officielles par défaut, mais il est possible d’y déroger en utilisant ce paramètre spécifique lors de la phase de démarrage.
Retraits furtifs de crypto-monnaies avec contournement 2FA
Une fois chargée par le navigateur, l’extension Rilide se fait passer pour une autre qui paraît légitime pour Google Drive. Cependant, en arrière-plan, elle surveille les onglets actifs à la recherche d’une liste de sites web ciblés, dont plusieurs portefeuilles de crypto-monnaies populaires ainsi que des fournisseurs de messagerie tels que Gmail et Yahoo. Lorsque l’un de ces sites est chargé, l’extension supprime alors les en-tête des règles de sécurité du contenu (CSP) fournies par le site web légitime et injecte son propre code malveillant pour effectuer diverses manipulations de contenu. La suppression de la règle de sécurité du contenu est importante car il s’agit d’un mécanisme que les sites web peuvent utiliser pour indiquer aux navigateurs les scripts qui doivent être autorisés à s’exécuter dans un contexte web. L’un des scripts injectés dans les sites peut prendre des captures d’écran des onglets ouverts et informer un serveur de commande et de contrôle lorsque l’un d’eux correspond à l’un des sites web ciblés. D’autres scripts automatisent la suppression d’actifs en arrière-plan tout en présentant à l’utilisateur une fausse boîte de dialogue pour saisir son code d’authentification à double facteur. Lorsque de telles actions sont effectuées, de nombreux sites web envoient des courriels automatisés contenant des codes que l’utilisateur doit saisir pour autoriser la transaction. L’extension est aussi capable de remplacer ces courriels dans les interfaces web de Gmail, Hotmail ou Yahoo par des courriels qui semblent avoir été envoyés pour autoriser un nouveau dispositif d’accès à un compte, ce qui est également un processus qui utilise le même flux de travail d’authentification à deux facteurs.
Il est probable que les utilisateurs aient déjà été invités à réautoriser leurs navigateurs pour accéder à leurs comptes en recevant des codes 2FA par courrier électronique et en les saisissant à nouveau sur les sites web. Il s’agit d’un processus standard déclenché pour des raisons de sécurité, car les sessions authentifiées expirent et les statuts 2FA enregistrés sont périodiquement réinitialisés. Les pirates ont donc bien compris que les utilisateurs ne se méfieraient pas si on leur demandait de le faire pour autoriser des transferts ou des retraits. Même si cette technique de détournement de l’authentification double facteur est utilisée dans ce cas pour soutenir le vol d’actifs détenus dans des portefeuilles de crypto-monnaies, elle peut facilement être adaptée à tous les autres types de sites web qui utilisent l’authentification multifactorielle basée sur les courriels. C’est une autre raison pour laquelle les organisations devraient choisir des méthodes plus sûres lorsqu’elles déploient l’authentification multifactorielle, même sur des services tiers, comme les applications d’authentification mobile générant des codes sur un terminal à part ou des dispositifs physiques basés sur une clé USB. « La surcharge d’informations peut réduire notre capacité à interpréter les faits avec précision et nous rendre plus vulnérables aux tentatives d’hameçonnage », ont déclaré les chercheurs de Trustwave. « Il est important de rester vigilant et sceptique lorsque l’on reçoit des courriels ou des messages non sollicités, et de ne jamais supposer qu’un contenu sur Internet est sûr, même s’il semble l’être ».
Pour faire monter en gamme leurs campagnes malveillantes, les éditeurs de logiciels espions combinent plusieurs exploits zero day à des failles déjà connues. Afin de limiter les dégâts les équipes d’analystes cybersécurité de Google préconisent d’accélérer le déploiement de correctifs pour les terminaux mobiles.
Des éditeurs de logiciels espions ont développé et utilisé des exploits zero day contre des utilisateurs de terminaux iOS et Android tout au long de 2022. Rien de vraiment nouveau en soit sauf que sur l’année écoulée, ces chaines d’exploitation s’appuyaient aussi sur des failles connues pour fonctionner, expliquent dans un dernier rapport des chercheurs en sécurité de l’équipe Threat Analysis Group (TAG) de Google. « Les exploits zero day ont été utilisés en même temps que d’autres attaques (n-days) et ont profité de l’écart important entre la publication du correctif et son déploiement complet sur les terminaux », indique l’enquête. « Nos conclusions soulignent l’ampleur de la prolifération, par les éditeurs de systèmes de surveillance, de capacités historiquement utilisées uniquement par les gouvernements disposant de l’expertise technique nécessaire pour développer et mettre en œuvre des exploits ».
Cette situation souligne plus que jamais l’importance pour les utilisateurs et les fabricants de terminaux d’accélérer l’adoption des correctifs de sécurité dont la réactivité reste toutefois à géométrie variable. Par exemple, étant à la fois le seul fabricant de matériel pour les terminaux iOS et le concepteur du logiciel qui tourne dessus, Apple a une emprise beaucoup plus étroite sur son écosystème mobile que ne peuvent l’avoir ceux construisant des mobiles Android. Ainsi, les iPhone et les iPad ont toujours eu un taux d’adoption des correctifs bien supérieur à celui d’Android. Car si Google crée le système d’exploitation de base, des dizaines de fabricants le personnalisent pour leurs propres produits et maintiennent donc chacun leurs propres micrologiciels distincts.
Une campagne malveillante combinée pour les corrompre tous
En novembre 2022, Google TAG a détecté une campagne d’attaques par SMS ciblant les utilisateurs iOS et Android en Italie, en Malaisie et au Kazakhstan utilisant une combinaison d’exploits pour les deux plateformes. La campagne impliquait des URL raccourcies bit.ly qui, lorsqu’elles étaient cliquées, dirigeaient les utilisateurs vers une page web contenant les exploits, puis les redirigeaient vers des sites web légitimes, tels qu’un portail de suivi d’expédition de la société logistique italienne BRT ou un site d’actualités populaire en Malaisie. La chaîne d’exploitation iOS combinait alors une vulnérabilité d’exécution de code à distance qui était inconnue et non corrigée à l’époque dans WebKit, le moteur de rendu des sites web d’Apple utilisé dans Safari et iOS. Cette faille, désormais répertoriée CVE-2022-42856, a été corrigée en janvier après signalement à Apple de Google TAG.
Cependant, une telle vulnérabilité d’exécution de code à distance dans le moteur du navigateur web ne suffit pas à compromettre un terminal, car les OS mobiles comme iOS et Android utilisent des techniques de sandboxing limitant les privilèges du navigateur. L’attaquant a donc combiné cette zero day avec une faille d’évasion de la sandbox et d’élévation de privilèges (CVE-2021-30900) dans AGXAccelerator, un composant des pilotes GPU corrigée par Apple dans iOS 15.1 en octobre 2021. Cette chaîne d’exploit a aussi utilisé une technique de contournement, corrigée en mars 2022, observée dans des exploits utilisés par un éditeur de logiciels espions visant un opposant politique égyptien en exil, et contre un journaliste égyptien. En réalité, ces deux procédés avaient une fonction très spécifique baptisée make_bogus_transform, suggérant un lien commun. Dans la campagne de novembre observée par Google TAG, la charge utile finale de la chaîne d’exploit était un simple logiciel malveillant signalant périodiquement aux attaquants la position GPS des systèmes infectés, mais leur donnait également la possibilité de déployer des fichiers .IPA (iOS application archive) dessus.
Zoom sur la chaine d’exploit Android
Les utilisateurs d’Android ont été confrontés à une combinaison similaire mêlant une faille d’exécution de code dans le moteur du navigateur de Chrome, avec échappement de sandbox et élévation des privilèges. La faille d’exécution de code était la CVE-2022-3723, une vulnérabilité de confusion de type fonctionnant en condition réelle par des chercheurs d’Avast, et corrigée dans la version 107.0.5304.87 de Chrome en octobre 2022. Celle-ci a été mixée avec un contournement du bac à sable du GPU Chrome (CVE-2022 -4135), corrigé quant à lui dans Android en novembre 2022, ainsi qu’à une autre zero day affectant des pilotes GPU ARM Mali (CVE-2022-38181) corrigée par ARM en août 2022. Cette chaîne d’exploitation a fonctionné contre les utilisateurs de systèmes Android avec des GPU ARM Mali et une version de Chrome aux mises à jour antérieures à la v106.
Le principal problème de cette situation a été le délai nécessaire entre la publication par ARM des correctifs de code et celui des fabricants de terminaux pour les intégrer dans leur propre firmware suivi par leurs propres mises à jour de sécurité. Une situation qui souligne une nouvelle fois à quel point il est important pour les fournisseurs d’accélérer l’intégration les correctifs de sécurité critiques et, pour les utilisateurs, de maintenir à jour les applications de leurs systèmes, en particulier critiques (navigateurs, clients de messagerie, etc.).
Les terminaux Samsung aussi dans le viseur
Une campagne distincte, découverte en décembre 2022, a par ailleurs aussi ciblé spécifiquement les utilisateurs du navigateur Internet Samsung par défaut sur les terminaux Android du constructeur coréen et basé sur le projet open source Chromium. Cette campagne utilisait également des liens envoyés par SMS aux utilisateurs des Émirats Arabes Unis, mais la page de destination qui livrait l’exploit était identique à celle TAG précédemment observée pour le framework Heliconia développé par le fournisseur de spywares Variston. Cet exploit combinait plusieurs failles exploitant le navigateur Internet Samsung ou son micrologiciel. L’une des vulnérabilités, CVE-2022-4262 (confusion de type) débouchant sur de l’exécution de code dans Chrome a été corrigée en décembre 2022. Celle-ci avait été combinée avec une autre d’échappement de bac à sable (CVE-2022-3038) comblée en août 2022 dans Chrome version 105. Cependant, le navigateur web de Samsung au moment de la campagne d’attaque était basé sur la version 102 de Chromium et n’incluait donc pas ces dernières atténuations… montrant une fois n’est pas coutume la capacité des attaquants à tirer partie de toutes les opportunités liées à la lenteur des mises à disposition des patchs.
A noter aussi que cette chaîne d’exploit s’appuyait aussi sur d’autres failles:une d’escalade de privilèges (CVE-2022-22706) au niveau du pilote du noyau GPU ARM Mali, corrigé par ARM en janvier 2022. Lorsque les attaques ont eu lieu en décembre 2022, la dernière version du micrologiciel sur les systèmes Samsung n’avaient pas encore incorporé de correctif. Une autre de type escalade de privilèges zero day (CVE-2023-0266) dans le sous-système audio du noyau Linux donnant aux attaquants un accès en lecture et en écriture au noyau, ainsi que plusieurs fuites d’informations au niveau du noyau que Google a signalées en tant que zero day tant à ARM que Samsung. « Ces campagnes continuent de souligner l’importance des correctifs, car les utilisateurs ne seraient pas affectés par ces chaînes d’exploitation s’ils utilisaient un terminal entièrement mis à jour », ont déclaré les chercheurs de Google TAG. « Les atténuations intermédiaires comme PAC, V8 sandbox et MiraclePTR ont un impact réel sur les développeurs d’exploits, car ils auraient eu besoin de bogues supplémentaires pour contourner ces atténuations ».
Rapidement corrigée, une faille dans l’environnement de développement cloud Gitpod ouvre la voie à de la prise de contrôle de comptes dans le CDE et de l’exécution de code à distance.
Des chercheurs de la société de sécurité cloud Snyk ont récemment découvert une vulnérabilité qui aurait permis aux attaquants d’effectuer une prise de contrôle complète du compte et une exécution de code à distance (RCE) dans Gitpod, un environnement de développement cloud (CDE) populaire. Ces derniers sont recherchés, car ils sont plus faciles à déployer et à entretenir que les environnements locaux et promettent une meilleure sécurité. Cependant, les entreprises doivent évaluer correctement les risques de sécurité propres aux architectures CDE peuvent amener, d’autant plus qu’ils n’ont pas fait l’objet d’un examen minutieux de la part de la communauté de la sécurité. « De nombreuses questions restent sans réponse avec l’adoption d’environnements de développement basés sur le cloud : que se passe-t-il si un espace de travail IDE cloud est infecté par des logiciels malveillants ? Que se passe-t-il lorsque les contrôles d’accès sont insuffisants et permettent un accès entre utilisateurs ou même entre entreprises aux espaces de travail ? Que se passe-t-il lorsqu’un développeur malhonnête exfiltre la propriété intellectuelle de l’entreprise à partir d’une machine hébergée dans le cloud hors de la visibilité du logiciel de prévention des pertes de données ou de sécurité des points finaux de l’organisation ? », ont expliqué les chercheurs de Snyk dans leur rapport, qui fait partie d’un projet plus vaste visant à enquêter sur la sécurité de CDE.
Les environnements de développement intégrés (IDE) traditionnels qui sont déployés localement sur des postes de travail de développeur individuels peuvent également présenter pléthore de problèmes de sécurité et de vulnérabilités. En fait, les CDE constituent à bien des égards une grande amélioration par rapport aux IDE traditionnels : ils peuvent éliminer la dérive de configuration qui se produit au fil du temps avec les postes de travail/ordinateurs portables des développeurs et éviter les collisions de dépendance qui se produisent lorsque les développeurs travaillent sur différents projets. Mais aussi réduire la fenêtre des attaques car ces environnements de travail sous forme de container peuvent être à durée limitée. Lorsque des failles sont détectées, le fournisseur CDE peut probablement déployer un correctif plus rapidement qu’une entreprise pourrait le faire sur tous ses postes de travail et ordinateurs portables de développeur exécutant un IDE traditionnel. Bien sûr, les temps de réponse de sécurité peuvent varier d’un fournisseur de CDE à l’autre. Les sociétés doivent donc choisir leur fournisseur avec soin si elles lui confient leur infrastructure de développement, y compris le code, les jetons d’accès, les secrets de production et d’autres propriétés intellectuelles.
Le piratage WebSocket intersite souvent mal compris
La vulnérabilité découverte par Snyk, que l’équipe Gitpod a résolue en une journée, est identifiée comme CVE-2023-0957 et entre dans une catégorie de problèmes connus sous le nom de cross-site WebSocket hijacking. Un mécanisme de sécurité de base intégré aux navigateurs connu sous le nom de Same Origin Policy (SOP), empêche le code exécuté sur un site de lire les informations d’un autre site auquel un visiteur est connecté. Étant donné que les requêtes du navigateur vers un site – par exemple, le site A – incluent généralement les cookies de session d’un utilisateur, sans SOP, un site malveillant B visité par l’utilisateur pourrait charger une ressource du site A et être en mesure de voler le cookie de session d’un utilisateur avec emplacement A. Le problème est que ce mécanisme de défense n’existe que pour HTTP mais pas WebSocket, une technologie de communication bidirectionnelle pour qu’un navigateur échange des données avec un serveur en utilisant une connexion persistante. « Lorsqu’une poignée de main WebSocket repose uniquement sur des cookies HTTP pour l’authentification, un site Web malveillant est capable d’instancier une nouvelle connexion WebSocket à l’application vulnérable, permettant à un attaquant d’envoyer et de recevoir des données via la connexion », ont expliqué les chercheurs de Snyk. En d’autres termes, si un utilisateur visite un site web malveillant et que ce site ouvre une connexion WebSocket en son nom à un autre serveur auprès duquel il est authentifié, le site malveillant peut envoyer des commandes malveillantes via la connexion et recevoir des réponses en se superposant au cookie de l’utilisateur. C’est pourquoi les connexions WebSocket doivent être implémentées avec une authentification supplémentaire.
L’architecture Gitpod se compose de plusieurs microservices déployés dans un environnement Kubernetes, avec des espaces de travail utilisateur déployés sous forme de pods éphémères. Les espaces de travail Gitpod se composent d’un composant serveur écrit en TypeScript et d’une application web pour le tableau de bord construite avec React qui communique via WebSocket avec une API JSONRPC exposée par le serveur. Le tableau de bord est l’interface avec laquelle le développeur interagit et où il peut importer un référentiel à partir d’un fournisseur de gestion de code source comme GitHub. Une fois configuré, l’espace de travail est également rendu accessible via SSH et HTTP à l’aide de sous-domaines dédiés sous le domaine gitpod.io.
Comment les chercheurs ont exploité la faille Gitpod désormais corrigée
Les chercheurs de Snyk ont vérifié que l’implémentation de Gitpod WebSocket n’utilisait pas d’authentification supplémentaire et qu’un attaquant pouvait ouvrir une connexion WebSocket à l’espace de travail à partir d’une origine différente. Cependant, un mécanisme différent récemment mis en œuvre dans les navigateurs, appelé cookies SameSite, est entré en jeu, rendant leur attaque inefficace. Les cookies SameSite sont conçus comme une défense contre les attaques de falsification de requêtes intersites (CSRF), où un site peut forcer le navigateur d’un utilisateur à émettre une requête vers un autre site au nom de l’utilisateur. Cependant, contrairement au SOP, qui vérifie le schéma d’origine + hôte (y compris les sous-domaines) + port, la politique SameSite vérifie uniquement que le domaine est le même. SameSite s’applique à tous les cookies, y compris ceux envoyés via WebSocket, ce qui signifie que pour lancer une attaque cross-site WebSocket hijacking contre Gitpod, un attaquant devrait utiliser une page web malveillante également hébergée sur gitpod.io. Étant donné que chaque espace de travail se voit attribuer son propre sous-domaine, les chercheurs de Snyk ont dû trouver un moyen de diffuser une page web malveillante à partir d’un espace de travail Gitpod qu’ils ont configuré. L’éditeur de code par défaut dans les espaces de travail Gitpod est VS Code (Visual Studio Code) et il est exposé via une interface web. Ainsi, les chercheurs de Snyk ont tenté de tuer le processus VS Code dans l’espace de travail à l’aide de l’interface de ligne de commande et de lier un serveur web basé sur Python au port précédemment utilisé par VS Code pour servir leur fichier HTML malveillant. Cela n’a pas fonctionné, car un processus « superviseur » qui surveille l’espace de travail a redémarré l’espace de travail.
Finalement, les chercheurs ont observé que s’ils ne tuaient que le processus VS Code, mais ne liaient pas le port à un autre, le superviseur tenterait uniquement de redémarrer VS Code et non l’ensemble de l’espace de travail. Cela leur a donné l’idée d’arrêter VS Code et de le remplacer rapidement par une version corrigée qu’ils ont créée et qui a servi leur exploit via le point de terminaison de l’API /version, qui ne renvoie normalement que le numéro de version de VS Code. « Nous l’avons modifié pour que le bon Content-Type de text/html et le contenu d’un fichier HTML soient renvoyés », ont déclaré les chercheurs. « Maintenant, nous avons mis fin au processus vscode, permettant à nos modifications nouvellement introduites de se charger dans une instance de processus VS Code nouvellement générée ».
Possédant un lien avec leur page web malveillante s’exécutant sur un espace de travail à l’intérieur de Gitpod et sur un sous-domaine Gitpod, les chercheurs n’ont donc plus eu qu’à l’envoyer à un utilisateur Gitpod visé connecté à son propre espace de travail pour activer l’exploit en ouvrant une connexion WebSockets à l’espace de travail de la victime et émettre des méthodes JSONRPC telles que getLoggedInUser, getGitpodTokens, getOwnerToken et addSSHPublicKey. La dernière méthode permet à un attaquant d’ajouter sa propre clé SSH dans l’espace de travail de la victime, d’assurer un accès distant persistant via SSH dans l’espace de travail. Les chercheurs de Snyk ont félicité Gitpod pour son temps de réponse rapide et son correctif, mais ont ajouté que « les espaces de travail des développeurs cloud devenant de plus en plus populaires, il est important de prendre en compte les risques supplémentaires qui sont introduits ».
Des chercheurs en sécurité du cabinet Horizon3.ai ont détecté une faille affectant la solution d’accès réseau zero trust de Fortinet. Cette dernière autorise des utilisateurs sans droits particuliers à écrire des fichiers arbitraires sur le système et déboucher sur un exploit.
Un PoC de code d’exploitation disponible pour une vulnérabilité critique affectant la solution FortiNAC de Fortinet est actuellement dans les mains d’attaquants ayant déjà commencé à l’utiliser. Les utilisateurs concernés sont donc très fortement invités à patcher dès que possible leurs systèmes. FortiNAC est une appliance d’accès réseau zero trust qui peut être déployée à la fois en tant que périphérique matériel ou en tant qu’appliance de machine virtuelle. Il est utilisé pour la segmentation du réseau, la visibilité et le contrôle des terminaux et des utilisateurs connectés au réseau. En tant que tel, il peut être déployé en bordure de réseau (edge), ce qui en fait une cible plus facile pour les attaques basées sur Internet. Selon les analyses Shodan, plus de 700 000 systèmes Fortinet sont connectés à Internet dans le monde.
La vulnérabilité, identifiée comme CVE-2022-39952, a été divulguée et corrigée par Fortinet la semaine dernière. Le fournisseur conseille aux utilisateurs de mettre à niveau vers FortiNAC version 9.2.6 (ou supérieure), 9.1.8 ou plus et 7.2.0 ou plus, selon la version prise en charge qu’ils utilisent.
Ce trou de sécurité permet à des attaquants non authentifiés d’écrire des fichiers arbitraires sur le système, ce qui peut entraîner l’exécution de code ou de commande. La faille a été découverte en interne par un membre de l’équipe de sécurité des produits Fortinet ; elle est notée 9,8 sur 10 sur l’échelle de gravité CVSS. Les chercheurs du cabinet de conseil en sécurité Horizon3.ai ont effectué une comparaison des versions d’appliance FortiNAC corrigées et vulnérables et ont pu localiser et confirmer la vulnérabilité. Elle se trouve dans un fichier appelé keyUpload.jsp qui permet le téléchargement de fichiers qui sont ensuite enregistrés localement à l’emplacement /bsc/campusMgr/config.applianceKey. Le système d’exploitation exécute ensuite un script bash qui exécute une commande de décompression sur le fichier stocké. Initialement, cela faisait référence à une vulnérabilité potentielle de path traversal, grâce à laquelle les attaquants pourraient créer une archive qui, une fois décompressée, écrit des fichiers en dehors du chemin prévu. Cependant, ce n’est pas le cas pour unzip, qui supprime les chemins relatifs et protège donc contre les problèmes de traversée de chemin, ont déclaré les chercheurs. Le script bash qui appelle unzip dans ce cas change d’abord le répertoire de travail actuel en “/” qui, sur les systèmes Linux, est la racine de la partition.
Une autre faille critique également corrigée en janvier
« Unzip permettra de placer des fichiers dans n’importe quel chemin tant qu’ils ne traversent pas le répertoire de travail actuel », ont déclaré les chercheurs. « Parce que le répertoire de travail est ‘/’, l’appel unzip à l’intérieur du script bash permet d’écrire n’importe quel fichier arbitraire ». En d’autres termes, les attaquants peuvent créer un fichier zip qui décompresse son contenu dans n’importe quel chemin de fichier sous toute la partition. Pour démontrer un exploit militarisé, les chercheurs d’Horizon3.ai ont exploité la vulnérabilité pour écrire une charge utile malveillante sous /etc/cron.d/ qui est le mécanisme de tâche planifiée sous Linux. Cette tâche s’exécute toutes les minutes et lance un reverse shell à l’attaquant. Abuser de cron.d n’est qu’un moyen d’exploiter cette faille et d’exécuter du code à distance. Les attaquants pourraient également choisir d’écraser tout fichier binaire sur le système qu’ils savent que le système d’exploitation exécutera, ou ils pourraient ajouter leur propre clé SSH à un profil d’utilisateur, permettant un accès à distance à cet utilisateur via SSH. « Malheureusement, l’appliance FortiNAC n’autorise pas l’accès à l’interface graphique à moins qu’une clé de licence n’ait été ajoutée, donc aucun journal d’interface graphique natif n’était disponible pour vérifier les indicateurs », ont déclaré les chercheurs. « Cependant, l’exploitation du problème était observable dans les journaux du système de fichiers situés dans /bsc/logs/output.master. Plus précisément, vous pouvez rechercher la ligne Running configApplianceXml tant que l’attaquant n’a pas effacé ce fichier journal ».
CronUp, une société de cybersécurité basée au Chili, a signalé des attaques exploitant la vulnérabilité FortiNAC. Tout d’abord, ils ont vu des tentatives qui ont créé des reverse shells comme dans le PoC d’Horizon3.ai. Ensuite, les attaquants sont passés au déploiement de webshells – des scripts de porte dérobée basés sur le web qui permettent l’exécution à distance de commandes. Deux webshells observés jusqu’à présent ont été déployés sous bsc/campusMgr/ui/ROOT/fortii.jsp et bsc/campusMgr/ui/ROOT/shell.jsp sur des installations vulnérables. GreyNoise, un service qui suit le trafic malveillant sur Internet, a ajouté la capacité de détecter les attaques ciblant cette vulnérabilité et a commencé à voir des tentatives d’exploitation.
Ce n’est pas la première fois que des attaquants ciblent les produits et les appliances de sécurité Fortinet. En janvier, le fournisseur américain a averti les utilisateurs que les attaquants exploitaient une vulnérabilité critique dans FortiOS SSL-VPN qui a été corrigée en décembre pour déployer un implant Linux sophistiqué.
Plus d’un tiers des vulnérabilités des systèmes industriels n’ont pas été corrigées. Un constat malvenu à l’heure où ces environnements sont confrontés aux menaces grandissantes de nouveaux groupes de cybercriminels.
La correction des failles dans les environnements industriels a toujours été un défi en raison de problèmes d’interopérabilité, d’exigences strictes en matière de disponibilité et parfois de l’âge des terminaux. Selon une analyse récente, un tiers des vulnérabilités n’ont même pas de correctifs disponibles. Selon une analyse de SynSaber, une société de sécurité spécialisée dans la surveillance des actifs industriels et des réseaux, compter simplement les vulnérabilités sans examiner leur impact et leur probabilité d’exploitation est loin d’être une manière appropriée d’évaluer les risques, mais la tendance peut être inquiétante à un moment où le nombre d’attaques contre les opérateurs d’équipements industriels dans divers secteurs est en augmentation.
En comparaison, le nombre de failles ICS non corrigées au cours du premier semestre de l’année était de 13 % sur un nombre bien inférieur de 681. « Même s’il existe un correctif logiciel ou micrologiciel disponible, les propriétaires d’actifs sont toujours confrontés à un certain nombre de contraintes », ont averti les chercheurs de SynSaber dans leur rapport. « On ne peut pas simplement patcher un ICS. Les fabricants d’équipement d’origine (OEM) ont souvent des processus de test, d’approbation et d’installation de patchs stricts qui retardent les mises à jour. Les opérateurs doivent tenir compte des restrictions d’interopérabilité et de garantie pour les changements à l’échelle de l’environnement en plus d’attendre la prochaine maintenance de cycle ».
Tous les défauts ICS ne sont pas égaux
Les vulnérabilités peuvent différer à bien des égards en plus d’avoir simplement des scores de criticité différents et un impact différent sur différents environnements. Par exemple, les vulnérabilités de corruption de mémoire telles que les écritures out of bounds peuvent entraîner l’exécution de code arbitraire ou des plantages d’application (déni de service). Le premier est évidemment plus grave en général, mais dans un contexte ICS où les appareils sont utilisés pour superviser et exécuter des processus physiques critiques, le déni de service peut avoir des implications plus graves que dans les environnements informatiques typiques. Selon un dernier article de la société de sécurité ICS et IoT Nozomi Networks, les écritures et les lectures hors limites étaient les faiblesses les plus courantes (CWE) associées aux CVE dans les avis CISA entre juillet et décembre 2022. En voici les principales :
– Validation d’entrée incorrecte (CWE-20) ;- Contrôle d’accès inapproprié (CWE-284) ;- Limitation incorrecte d’un nom de chemin à un répertoire restreint également connu sous le nom de traversée de chemin (CWE-22) ;- Authentification manquante pour la fonction critique (CWE-306) ;- Neutralisation incorrecte des entrées lors de la génération de pages Web, également appelée script intersite (CWE-79) ;- Utilisation d’informations d’identification codées en dur (CWE-798) ;- Débordement de tampon basé sur la pile (CWE-121) ;- Neutralisation incorrecte d’éléments spéciaux utilisés dans une commande SQL – a.k.a. Injection SQL (CWE-89).
Les avis CISA ont concerné 184 produits uniques de 70 fournisseurs différents, les secteurs les plus touchés étant la fabrication critique, l’énergie, les systèmes d’eau, les soins de santé et les transports. De plus, environ les deux tiers (69 %) des vulnérabilités ICS divulguées au cours du second semestre 2022 étaient élevées (58 %) ou critiques (13 %), selon leurs scores CVSS. La bonne nouvelle est que la probabilité qu’une vulnérabilité soit exploitée dans les environnements ICS diffère de celle de l’informatique d’entreprise en raison de facteurs tels que l’accessibilité du réseau et l’interaction de l’utilisateur. Les environnements et les terminaux OT (technologie opérationnelle) devraient avoir une meilleure segmentation et être séparés des réseaux informatiques avec des contrôles d’accès stricts, donc au moins en théorie, il devrait être plus difficile pour les attaquants d’atteindre ces appareils si les meilleures pratiques sont suivies.
Des failles de protocoles mettant à risque toute l’architecture
Selon l’analyse de SynSaber, 104 CVE (11 %) nécessitaient à la fois un réseau local ou un accès physique au terminal à exploiter, ainsi qu’une interaction de l’utilisateur. 25 % supplémentaires avaient besoin d’une interaction de l’utilisateur, quelle que soit la disponibilité du réseau. Des exemples de telles vulnérabilités sont celles qui impliquent le stockage en clair d’un mot de passe (CWE-798) ou le script intersite (CWE-79). « Dans cet exemple, l’attaquant doit avoir un accès physique à l’appareil et être capable d’interagir avec la mémoire flash du système afin d’accéder aux mots de passe en clair », ont déclaré les chercheurs de SynSaber. « Il est possible qu’un attaquant puisse acquérir ou voler un appareil, extraire des mots de passe de la mémoire flash, puis réutiliser ces informations d’identification pour une attaque. Ces chaînes d’événements nécessitent un accès physique et logique ainsi que d’autres mises en garde ». De plus, l’emplacement de la vulnérabilité à l’intérieur de la pile est important car il influencera le niveau de correctif requis. Par exemple, les failles des applications qui s’exécutent sur un appareil sont plus faciles à corriger car elles ne peuvent nécessiter qu’une mise à jour logicielle. D’autres qui sont plus profonds dans les composants du système d’exploitation peuvent nécessiter une mise à jour du micrologiciel qui nécessite la mise hors ligne de tous les appareils concernés. Cela pourrait s’avérer problématique pour de nombreuses raisons : les appareils sont déployés sur le terrain dans des endroits éloignés et difficiles d’accès, les terminaux ne peuvent pas être mis hors ligne, sauf pendant les périodes de maintenance planifiées, etc. Ensuite, il existe des vulnérabilités de protocole, qui pourraient avoir un impact sur une architecture entière et pourraient nécessiter la mise à niveau de plusieurs appareils et des systèmes associés pour maintenir l’interopérabilité.
« Un nombre important d’appareils industriels ne peuvent être mis à jour que via un flash d’image de micrologiciel qui peut contenir des modifications de fonctionnalité en plus de remédier à la sécurité, sans parler du risque de bloquer un appareil pendant le processus », ont déclaré les chercheurs de SynSaber. Selon l’éditeur, 63 % des failles du S2 2022 nécessitaient un correctif logiciel, 33 % des mises à jour du firmware et 4 % des actualisation du protocole. L’incidence des défauts de micrologiciel et de protocole était plus faible qu’au premier semestre, mais dans l’ensemble, environ 35 % des CVE n’avaient aucun correctif disponible auprès du fournisseur et beaucoup d’entre eux pourraient rester indéfiniment parce que les produits ne sont plus pris en charge ou que le fournisseur ne le fait pas.
SecurityScorecard, une société spécialisée dans l’évaluation des postures de cybersécurité, a analysé toutes les organisations de fabrication critiques incluses dans la liste Global 2000 Forbes et a constaté que 48 % d’entre elles avaient une note de F, D ou C selon ses critères de notation. En particulier, la Patching Cadence, l’un des facteurs suivis par l’entreprise, a vu une chute de 88 (note B) à 76 (note C) pour le secteur manufacturier critique de 2021 à 2022. « Le facteur Patching Cadence analyse le nombre d’actifs obsolètes d’une entreprise et la vitesse à laquelle les organisations corrigent et appliquent les correctifs par rapport à leurs pairs », a déclaré l’équipe SecurityScorecard dans son rapport. « Cette baisse est probablement due à un volume accru de vulnérabilités. Les infrastructures critiques des manufacturiers ont connu une augmentation de 38% d’une année sur l’autre des vulnérabilités élevées ».
Un pic de menaces hybrides contre les ICS
Les environnements ICS étaient principalement la cible de groupes de cyber-espionnage ou de cyber-sabotage, souvent associés aux Etats et à leurs agences de renseignement. Cependant, les groupes traditionnels de cybercriminalité tels que les gangs de rançongiciels et les hacktivistes ciblent également de plus en plus les infrastructures industrielles critiques et de soins de santé, ce qui pourrait entraîner des perturbations dans les équipements. En juin, un groupe hacktiviste surnommé Gonjeshke Darande a provoqué des perturbations de la chaîne de production de trois entreprises sidérurgiques iraniennes. Au début de l’année dernière, le même groupe a utilisé des logiciels malveillants d’effacement contre le système ferroviaire iranien. Le groupe de rançongiciels BlackCat était à l’origine d’une attaque contre la société publique italienne de services énergétiques GSE ainsi que le fournisseur d’énergie colombien EPM.
Une cyberattaque à motivation économique contre Supeo, un fournisseur de solutions de gestion d’équipements pour les compagnies ferroviaires, a provoqué des perturbations dans les horaires des trains au Danemark. Le rançongiciel Hive a frappé Tata Power, la plus grande compagnie d’électricité indienne, et le gang LockBit a frappé Continental, un géant de la technologie automobile et ferroviaire. « Au cours des six derniers mois, nous avons vu des cyberattaques sur des infrastructures critiques affectant des secteurs allant des transports aux soins de santé », ont déclaré des chercheurs de Nozomi Networks. « Les attaques continues contre les chemins de fer ont donné lieu à des directives pour aider les opérateurs ferroviaires à sécuriser leurs actifs. Les hacktivistes ont choisi d’utiliser des logiciels malveillants d’effacement pour lancer des attaques perturbatrices sur des infrastructures critiques, afin de renforcer leur position politique dans la guerre Russie/Ukraine ».
De plus, les frontières entre APT et les attaques de cybercriminalité se sont estompées, les acteurs des États-nations adoptant des techniques destructrices de type ransomware et les cybercriminels adoptant des tactiques de persistance et de furtivité des États-nations. La semaine dernière, les membres du groupe hacktiviste GhostSec se sont vantés d’avoir réussi à chiffrer un RTU (Remote Terminal Unit), même s’il s’agissait d’un routeur 3G avec des capacités de communication série qui relèveraient davantage de la catégorie « passerelle de communication ». Dans l’espace ICS, les RTU sont des systèmes programmables spécialisés qui relient les dispositifs ICS de terrain aux systèmes SCADA (contrôle de supervision et acquisition de données). Sur la base de la télémétrie anonymisée collectée par Nozomi Networks à partir des environnements ICS des clients, les types d’alertes d’intrusion les plus courants observés étaient les mots de passe en texte clair et les mots de passe faibles, suivis des correspondances de règles de paquets suspectes, du cryptage faible, de l’inondation TCP SYN et des paquets réseau malformés. Tous ces vecteurs pourraient être utilisés pour exploiter différents types de vulnérabilités. En termes de logiciels malveillants observés dans les environnements OT, les types les plus courants étaient les RAT (chevaux de Troie d’accès à distance) avec 3 392 alertes de détection. Selon SecurityScorecard, 37 % des entreprises manufacturières critiques ont été infectées par des logiciels malveillants en 2022, une augmentation par rapport à 2021. « Le secteur manufacturier critique se distingue comme un secteur qui a encore un long chemin à parcourir en termes de cyber-résilience », a déclaré la société. « Telle que définie par la CISA, ce secteur comprend la fabrication de métaux primaires, la fabrication de machines, la réalisation d’équipements électriques, de terminaux et de composants et la création de matériel de transport ».
Les groupes APT nord-coréens, russes et chinois changent de tactique. Sous couvert de mener des attaques par rançongiciels, ils mènent des campagnes de l’espionnage ou du sabotage. Un modification de posture que les entreprises occidentales doivent prendre en compte.
Les groupes malveillants soutenus par des Etats utilisent de plus en plus des attaques de type rançongiciel comme couverture pour dissimuler des activités plus insidieuses. Le groupe russe Sandworm a ainsi utilisé des ransomwares pour détruire des données à plusieurs reprises au cours des six derniers mois, tandis que le groupe nord-coréen Lazarus a employé une infrastructure précédemment associée à un groupe de rançongiciels pour des campagnes de collecte de renseignements. Dans le même temps, certaines APT chinoises qui ciblaient traditionnellement des entités en Asie se sont tournées vers des entreprises européennes, tandis que des groupes basés en Iran qui ciblaient historiquement des sociétés israéliennes ont commencé à s’en prendre à leurs filiales étrangères. Au moins un groupe nord-coréen qui se concentrait sur la Corée du Sud et la Russie a commencé à utiliser l’anglais dans ses opérations. Tous ces changements opérationnels suggèrent que les organisations et les entreprises des pays occidentaux sont exposées à un risque accru de l’activité APT.
Au cours des derniers mois de 2022, Sandworm a poursuivi ses attaques d’effacement de données contre des organisations ukrainiennes, mais a étendu ses efforts à des entreprises de pays qui sont de fervents partisans de l’Ukraine, comme la Pologne, selon un dernier rapport de l’éditeur ESET. On pense que Sandworm opère comme une unité au sein de l’agence de renseignement militaire russe, le GRU. Sandworm a lancé des attaques destructrices contre des organisations ukrainiennes pendant des années. On lui attribue les attaques contre l’infrastructure énergétique ukrainienne qui ont provoqué des pannes d’électricité dans le pays en 2015 ainsi que l’attaque destructrice de type ransomware NotPetya en 2017 qui a commencé comme une attaque de la supply chain logiciel contre un éditeur ukrainien mais a fini par avoir un impact sur les firmes internationales aussi. Depuis le début de la guerre, les chercheurs d’ESET ont attribué à Sandworm deux programmes de sabotage appelés CaddyWiper et HermeticWiper utilisés en Ukraine. Le cybergang est également soupçonné d’avoir tenté de perturber le réseau électrique ukrainien en avril en utilisant un nouveau malware appelé Industroyer2.
Des rançongiciels utlisés dans des opérations comme leurres
En octobre, ESET a vu d’autres variantes de CaddyWiper et HermeticWiper, mais aussi un wiper de données attribué à Sandworm appelé NikoWiper. Ce dernier est basé sur SDelete, un utilitaire de Microsoft pour supprimer des fichiers en toute sécurité et a été utilisé contre une entreprise ukrainienne du secteur de l’énergie. « Cette attaque s’est produite à peu près à la même période où les forces armées russes ont ciblé l’infrastructure énergétique ukrainienne avec des frappes de missiles », ont déclaré les chercheurs de l’éditeur. « Même si nous n’avons pu démontrer aucune coordination entre ces événements, cela suggère que Sandworm et les forces armées russes ont les mêmes objectifs ». Outre les wipers, Sandworm semble poursuivre sa tactique de réutilisation des ransomwares. La différence entre les effaceurs de données et les programmes rançongiciels est que ces derniers cryptent les fichiers au lieu de les supprimer, mais les deux ont pour effet de rendre les données inaccessibles.
Les chercheurs d’ESET attribuent les attaques d’octobre avec un ransomware appelé Prestige contre les entreprises de logistique ukrainiennes et polonaises à Sandworm. Un mois plus tard, le groupe a utilisé une autre charge appelée RansomBoggs contre des structures ukrainiennes. Elle a été écrite en .NET et faisait référence au film d’animation Monsters Inc. « Dans ces attaques, des rançongiciels ont été utilisés mais l’objectif final était le même que pour les wipers : la destruction des données », ont déclaré les experts. Contrairement aux attaques traditionnelles de ransomwares, ici les pirates ne visent pas à fournir la clé pour décrypter les données. Il est probable que ces attaques destructrices se poursuivront et, comme dans le cas du rançongiciel Prestige, elles pourraient s’étendre aux sociétés des pays qui fournissent un soutien militaire et logistique à l’Ukraine. Pas plus tard que la semaine dernière, l’équipe ESET a découvert un autre programme d’effacement qu’elle a attribué à Sandworm et baptisé SwiftSlicer. Il est écrit en Go et est déployé sur les réseaux via la stratégie de groupe Active Directory.
La Corée du Nord aux première loges
D’autres groupes APT peuvent ne pas utiliser directement les ransomware, mais peuvent se servir des tactiques, techniques et procédures (TTP) associées à des groupes de rançongiciels connus pour masquer leurs activités. Celles-ci sont connues dans l’industrie de la sécurité sous le nom d’opérations « sous fausse bannière ». La plupart des groupes de rançongiciels exfiltrent désormais les données pour les rançonner avant de les chiffrer localement. Ce vol de données peut être une bonne couverture pour le cyber-espionnage. La société de sécurité WithSecure a récemment enquêté sur une campagne d’attaque qui était initialement soupçonnée d’être causée par le groupe BianLian. Une enquête plus approfondie a révélé qu’il s’agissait en fait d’une opération de collecte de renseignements par le groupe Lazarus parrainé par l’État nord-coréen. Elle ciblait des organismes de recherche publics et privés dans le domaine médicale et énergétique, ainsi que leur partenaires.
La Corée du Nord compte plusieurs groupes APT qui partagent parfois des outils, mais qui seraient contrôlés par différentes agences ou départements gouvernementaux. Lazarus, APT38 et Andariel (également connu sous le nom de Silent Chollima) sont des groupes attribués au 3e Bureau du Foreign Intelligence and Reconnaissance General Bureau, l’agence de renseignement étrangère de la Corée du Nord. Un autre groupe appelé Kimsuky est attribué au 5e Bureau – Affaires intercoréennes et s’occupe des opérations ciblant principalement la Corée du Sud. Encore un autre identifié en tant qu’APT37 ciblant également principalement le pays voisin est attribué au ministère nord-coréen de la Sécurité d’État. « Bon nombre des TTP observés et des outils collectés ont déjà été attribués par d’autres chercheurs aux groupes Kimsuky ou Lazarus », ont déclaré les chercheurs de WithSecure. Ils ajoutent, « le fait que des références aux deux groupes soient observées pourrait mettre en évidence le partage d’outils et de capacités entre Acteurs nord-coréens de la menace ».
Des ransomwares intriqués
Les chercheurs ont trouvé un malware similaire à celui appelé GREASE qui était auparavant attribué à Kimsuky, ainsi qu’une version personnalisée de cet incident, WithSecure a observé l’utilisation d’un malware similaire à GREASE, également précédemment attribué à Kimsuky. Un autre malware récupéré était une version personnalisée de Dtrack, un cheval de Troie d’accès à distance (RAT), avec une configuration très similaire à celle utilisée par Lazarus lors d’une attaque contre la centrale nucléaire indienne de Kudankulam en 2019. Les chercheurs ont également découvert l’utilisation de Putty Plink et 3Proxy, deux outils précédemment observés dans d’autres campagnes Lazarus. Le chevauchement avec le rançongiciel BianLian était l’utilisation d’un serveur de commande et de contrôle hébergé à une adresse IP précédemment utilisée par BianLian. Lazarus et les APT nord-coréens ont l’habitude d’utiliser des ransomwares dans leurs attaques, à la fois comme couverture et pour en tirer profit. Cela inclut le principal ver/rançongiciel WannaCry de 2017 qui a touché des sociétés du monde entier.
En juillet, le CISA a émis une alerte indiquant que des acteurs soutenus par l’État nord-coréen utilisaient le rançongiciel Maui pour cibler les secteurs de la santé et de la santé publique. En raison des sanctions économiques strictes auxquelles le gouvernement nord-coréen est confronté, ses armes de piratage se livrent fréquemment à des activités qui s’apparentent davantage à la cybercriminalité qu’au cyber-espionnage. « Dans diverses parties du monde, des groupes alignés sur la Corée du Nord ont utilisé d’anciens exploits pour compromettre les entreprises et les échanges de crypto-monnaie. Fait intéressant, Konni a élargi le répertoire des langues qu’il utilise dans ses documents leurres pour inclure l’anglais, ce qui signifie qu’il pourrait ne pas être visant ses cibles russes et coréennes habituelles », ont déclaré les chercheurs d’ESET dans leur rapport sur l’activité APT.
Les groupes APT nord-coréens, russes et chinois changent de tactique. Sous couvert de mener des attaques par rançongiciels, ils mènent des campagnes de l’espionnage ou du sabotage. Un modification de posture que les entreprises occidentales doivent prendre en compte.
Les groupes malveillants soutenus par des Etats utilisent de plus en plus des attaques de type rançongiciel comme couverture pour dissimuler des activités plus insidieuses. Le groupe russe Sandworm a ainsi utilisé des ransomwares pour détruire des données à plusieurs reprises au cours des six derniers mois, tandis que le groupe nord-coréen Lazarus a employé une infrastructure précédemment associée à un groupe de rançongiciels pour des campagnes de collecte de renseignements. Dans le même temps, certaines APT chinoises qui ciblaient traditionnellement des entités en Asie se sont tournées vers des entreprises européennes, tandis que des groupes basés en Iran qui ciblaient historiquement des sociétés israéliennes ont commencé à s’en prendre à leurs filiales étrangères. Au moins un groupe nord-coréen qui se concentrait sur la Corée du Sud et la Russie a commencé à utiliser l’anglais dans ses opérations. Tous ces changements opérationnels suggèrent que les organisations et les entreprises des pays occidentaux sont exposées à un risque accru de l’activité APT.
Au cours des derniers mois de 2022, Sandworm a poursuivi ses attaques d’effacement de données contre des organisations ukrainiennes, mais a étendu ses efforts à des entreprises de pays qui sont de fervents partisans de l’Ukraine, comme la Pologne, selon un dernier rapport de l’éditeur ESET. On pense que Sandworm opère comme une unité au sein de l’agence de renseignement militaire russe, le GRU. Sandworm a lancé des attaques destructrices contre des organisations ukrainiennes pendant des années. On lui attribue les attaques contre l’infrastructure énergétique ukrainienne qui ont provoqué des pannes d’électricité dans le pays en 2015 ainsi que l’attaque destructrice de type ransomware NotPetya en 2017 qui a commencé comme une attaque de la supply chain logiciel contre un éditeur ukrainien mais a fini par avoir un impact sur les firmes internationales aussi. Depuis le début de la guerre, les chercheurs d’ESET ont attribué à Sandworm deux programmes de sabotage appelés CaddyWiper et HermeticWiper utilisés en Ukraine. Le cybergang est également soupçonné d’avoir tenté de perturber le réseau électrique ukrainien en avril en utilisant un nouveau malware appelé Industroyer2.
Des rançongiciels utlisés dans des opérations comme leurres
En octobre, ESET a vu d’autres variantes de CaddyWiper et HermeticWiper, mais aussi un wiper de données attribué à Sandworm appelé NikoWiper. Ce dernier est basé sur SDelete, un utilitaire de Microsoft pour supprimer des fichiers en toute sécurité et a été utilisé contre une entreprise ukrainienne du secteur de l’énergie. « Cette attaque s’est produite à peu près à la même période où les forces armées russes ont ciblé l’infrastructure énergétique ukrainienne avec des frappes de missiles », ont déclaré les chercheurs de l’éditeur. « Même si nous n’avons pu démontrer aucune coordination entre ces événements, cela suggère que Sandworm et les forces armées russes ont les mêmes objectifs ». Outre les wipers, Sandworm semble poursuivre sa tactique de réutilisation des ransomwares. La différence entre les effaceurs de données et les programmes rançongiciels est que ces derniers cryptent les fichiers au lieu de les supprimer, mais les deux ont pour effet de rendre les données inaccessibles.
Les chercheurs d’ESET attribuent les attaques d’octobre avec un ransomware appelé Prestige contre les entreprises de logistique ukrainiennes et polonaises à Sandworm. Un mois plus tard, le groupe a utilisé une autre charge appelée RansomBoggs contre des structures ukrainiennes. Elle a été écrite en .NET et faisait référence au film d’animation Monsters Inc. « Dans ces attaques, des rançongiciels ont été utilisés mais l’objectif final était le même que pour les wipers : la destruction des données », ont déclaré les experts. Contrairement aux attaques traditionnelles de ransomwares, ici les pirates ne visent pas à fournir la clé pour décrypter les données. Il est probable que ces attaques destructrices se poursuivront et, comme dans le cas du rançongiciel Prestige, elles pourraient s’étendre aux sociétés des pays qui fournissent un soutien militaire et logistique à l’Ukraine. Pas plus tard que la semaine dernière, l’équipe ESET a découvert un autre programme d’effacement qu’elle a attribué à Sandworm et baptisé SwiftSlicer. Il est écrit en Go et est déployé sur les réseaux via la stratégie de groupe Active Directory.
La Corée du Nord aux première loges
D’autres groupes APT peuvent ne pas utiliser directement les ransomware, mais peuvent se servir des tactiques, techniques et procédures (TTP) associées à des groupes de rançongiciels connus pour masquer leurs activités. Celles-ci sont connues dans l’industrie de la sécurité sous le nom d’opérations « sous fausse bannière ». La plupart des groupes de rançongiciels exfiltrent désormais les données pour les rançonner avant de les chiffrer localement. Ce vol de données peut être une bonne couverture pour le cyber-espionnage. La société de sécurité WithSecure a récemment enquêté sur une campagne d’attaque qui était initialement soupçonnée d’être causée par le groupe BianLian. Une enquête plus approfondie a révélé qu’il s’agissait en fait d’une opération de collecte de renseignements par le groupe Lazarus parrainé par l’État nord-coréen. Elle ciblait des organismes de recherche publics et privés dans le domaine médicale et énergétique, ainsi que leur partenaires.
La Corée du Nord compte plusieurs groupes APT qui partagent parfois des outils, mais qui seraient contrôlés par différentes agences ou départements gouvernementaux. Lazarus, APT38 et Andariel (également connu sous le nom de Silent Chollima) sont des groupes attribués au 3e Bureau du Foreign Intelligence and Reconnaissance General Bureau, l’agence de renseignement étrangère de la Corée du Nord. Un autre groupe appelé Kimsuky est attribué au 5e Bureau – Affaires intercoréennes et s’occupe des opérations ciblant principalement la Corée du Sud. Encore un autre identifié en tant qu’APT37 ciblant également principalement le pays voisin est attribué au ministère nord-coréen de la Sécurité d’État. « Bon nombre des TTP observés et des outils collectés ont déjà été attribués par d’autres chercheurs aux groupes Kimsuky ou Lazarus », ont déclaré les chercheurs de WithSecure. Ils ajoutent, « le fait que des références aux deux groupes soient observées pourrait mettre en évidence le partage d’outils et de capacités entre Acteurs nord-coréens de la menace ».
Des ransomwares intriqués
Les chercheurs ont trouvé un malware similaire à celui appelé GREASE qui était auparavant attribué à Kimsuky, ainsi qu’une version personnalisée de cet incident, WithSecure a observé l’utilisation d’un malware similaire à GREASE, également précédemment attribué à Kimsuky. Un autre malware récupéré était une version personnalisée de Dtrack, un cheval de Troie d’accès à distance (RAT), avec une configuration très similaire à celle utilisée par Lazarus lors d’une attaque contre la centrale nucléaire indienne de Kudankulam en 2019. Les chercheurs ont également découvert l’utilisation de Putty Plink et 3Proxy, deux outils précédemment observés dans d’autres campagnes Lazarus. Le chevauchement avec le rançongiciel BianLian était l’utilisation d’un serveur de commande et de contrôle hébergé à une adresse IP précédemment utilisée par BianLian. Lazarus et les APT nord-coréens ont l’habitude d’utiliser des ransomwares dans leurs attaques, à la fois comme couverture et pour en tirer profit. Cela inclut le principal ver/rançongiciel WannaCry de 2017 qui a touché des sociétés du monde entier.
En juillet, le CISA a émis une alerte indiquant que des acteurs soutenus par l’État nord-coréen utilisaient le rançongiciel Maui pour cibler les secteurs de la santé et de la santé publique. En raison des sanctions économiques strictes auxquelles le gouvernement nord-coréen est confronté, ses armes de piratage se livrent fréquemment à des activités qui s’apparentent davantage à la cybercriminalité qu’au cyber-espionnage. « Dans diverses parties du monde, des groupes alignés sur la Corée du Nord ont utilisé d’anciens exploits pour compromettre les entreprises et les échanges de crypto-monnaie. Fait intéressant, Konni a élargi le répertoire des langues qu’il utilise dans ses documents leurres pour inclure l’anglais, ce qui signifie qu’il pourrait ne pas être visant ses cibles russes et coréennes habituelles », ont déclaré les chercheurs d’ESET dans leur rapport sur l’activité APT.