Quand un prestataire informatique met à jour son logiciel de support, ses clients s'attendent à recevoir une amélioration. Ce que les organisations israéliennes ciblées par Cavern Manticore ont reçu à la place, c'est un accès persistant aux mains d'un groupe lié au Ministère iranien du Renseignement et de la Sécurité, le MOIS. Le vecteur d'entrée : la fonctionnalité de mise à jour de SysAid, un logiciel de gestion des services informatiques largement déployé. La charge utile : un agent .NET sophistiqué accompagné de cinq modules spécialisés capables de cartographier un Active Directory, d'exfiltrer des bases de données SQL, et d'établir un tunnel SOCKS5 persistent vers une infrastructure de commande et contrôle.
Le groupe a été documenté par Check Point Research sous le nom Cavern Manticore. Il chevauche deux clusters déjà connus : MuddyWater, un acteur MOIS opérant depuis 2017, et Lyceum, un sous-groupe d'OilRig identifié pour la première fois en 2019 dans des campagnes ciblant l'énergie et les télécoms. Cavern Manticore représente cependant une évolution technique notable : la conception de son framework C2, baptisé Cavern ou Cav3rn, intègre des techniques anti-analyse qui n'avaient pas été observées dans les outils précédents de ces groupes.
Le point d'entrée documenté est la fonctionnalité de mise à jour logicielle de SysAid. Dans un premier temps, l'attaquant compromet un prestataire de services informatiques qui utilise SysAid pour gérer ses clients. Depuis ce prestataire compromis, une mise à jour SysAid truquée est poussée vers les systèmes cibles. Cette mise à jour déclenche un chargement latéral de DLL : un fichier uxtheme.dll malveillant remplace la bibliothèque légitime de Windows qui gère les thèmes visuels, un composant chargé très tôt dans le processus de démarrage des applications.
Ce uxtheme.dll truqué est l'agent Cavern. Son premier acte est de charger n-HTCommp.dll, la bibliothèque de communication qui établit le canal vers l'infrastructure C2. La communication s'effectue vers le domaine hospitalinstallation[.]com via HTTPS ou WebSocket. Le choix du WebSocket n'est pas anodin : il permet au trafic C2 de se fondre dans les flux de communication applicatifs légitimes que la plupart des outils de filtrage réseau ne bloquent pas par défaut.
La structure de l'attaque est délibérément en cascade. Cavern Manticore ne compromet pas directement les cibles finales. Il compromet d'abord le prestataire de services informatiques, utilise ce prestataire comme tremplin vers un second prestataire, puis atteint les organisations gouvernementales et les fournisseurs de technologies israéliens qui constituent la cible réelle. Cette approche à deux sauts complique l'attribution et retarde la détection : les connexions entrantes proviennent d'une infrastructure de gestion légitime, celle du prestataire compromis, et non d'une adresse IP directement associée à un acteur malveillant connu.
Une fois l'agent installé, l'opérateur dispose d'un menu de capacités modulaires, chaque module étant une DLL distincte chargée à la demande depuis le serveur C2.
mhm.dll gère les opérations sur le système de fichiers. Il permet l'énumération récursive des répertoires, la recherche de fichiers correspondant à des critères définis, la compression d'archives, et le transfert bidirectionnel de fichiers entre la machine compromise et l'infrastructure C2. C'est le module d'exfiltration de base : identifier les documents sensibles, les regrouper dans une archive, et les transmettre.
db.dll est dédié aux bases de données SQL. Il énumère les instances SQL Server accessibles sur le réseau local, exécute des requêtes arbitraires, et exporte les résultats vers le C2. Pour des organisations dont les données clients, les contrats, ou les configurations opérationnelles résident dans des bases de données SQL, ce module représente un accès direct aux actifs les plus sensibles.
ode.dll cible l'Active Directory. Il effectue une reconnaissance complète des utilisateurs, groupes, et unités organisationnelles. Il intègre également une capacité de force brute LDAP, permettant de tester des combinaisons d'identifiants contre les comptes de domaine. La combinaison de la reconnaissance AD et de la force brute LDAP est une technique classique de mouvement latéral : cartographier les comptes à privilèges, identifier ceux dont les mots de passe sont faibles, les compromettre pour accéder à des ressources plus sensibles.
n-ten.dll prend en charge la reconnaissance réseau. Il analyse les ports ouverts sur les hôtes du réseau local, énumère les partages réseau accessibles via SMB, et dispose de capacités de force brute SMB. La reconnaissance des partages SMB est particulièrement utile dans les environnements d'entreprise où les partages de fichiers contiennent des données opérationnelles qui ne sont pas stockées dans des bases de données formelles.
n-sws.dll établit un proxy SOCKS5 couplé à un tunnel WebSocket. Ce module transforme la machine compromise en relais réseau : l'opérateur peut faire transiter n'importe quel trafic IP à travers la machine compromise, atteignant des ressources internes qui ne sont normalement pas accessibles depuis l'extérieur du réseau. C'est le module de persistence ultime : même si les autres modules sont détectés et supprimés, tant que n-sws.dll fonctionne, l'opérateur conserve une voie d'accès au réseau interne.
Ce qui distingue Cavern des outils .NET standard est l'usage délibéré de formats de compilation inhabituels pour entraver l'analyse. Le framework combine trois modes de compilation dans une même chaîne d'infection.
Le premier est le .NET Framework classique, la base sur laquelle les analystes de sécurité ont développé leurs outils de décompilation et d'analyse statique. Le second est le Mixed-Mode C++/CLI : des assemblées qui contiennent à la fois du code managé .NET et du code natif non managé dans le même binaire. Les décompilateurs classiques comme dnSpy ou ILSpy ne peuvent pas traiter correctement ces assemblées : ils voient le code managé mais pas le code natif, produisant une analyse partielle qui peut être trompeuse. L'analyste doit basculer vers des outils d'analyse de binaires natifs comme IDA Pro ou Ghidra pour couvrir la partie native, et reconstruire mentalement l'interaction entre les deux parties.
Le troisième mode est le Native AOT (.NET Ahead-of-Time compilation) : le code .NET est compilé directement en code machine natif avant le déploiement. Il n'existe pas de bytecode intermédiaire. Les décompilateurs .NET ne peuvent rien en faire. Pour l'analyser, il faut utiliser exclusivement des outils d'analyse de binaires natifs, et même alors, la piste reliant le code source original au binaire compilé est effacée.
En plus de ces techniques de compilation, chaque module est exécuté dans son propre AppDomain isolé. En .NET, un AppDomain est un espace d'exécution isolé au sein d'un processus. L'isolation par AppDomain signifie qu'une exception dans un module ne propage pas d'informations vers les autres modules. Elle complique également l'analyse dynamique : un analyste qui inspecte le processus en cours d'exécution voit des AppDomains distincts, pas une vue unifiée de tous les modules actifs.
Check Point Research a documenté les chevauchements entre Cavern Manticore, MuddyWater, et Lyceum. Ces recoupements portent sur les infrastructures partagées et les techniques communes, non sur une identité d'opérateurs. La structure du MOIS iranien est connue pour opérer via plusieurs groupes contractants et équipes internes qui partagent certaines ressources et techniques tout en conduisant des campagnes distinctes.
MuddyWater est actif depuis 2017 et a été attribué au MOIS par le Cyber Command américain en 2022. Il est connu pour ses campagnes de spear-phishing et son usage d'outils légitimes d'administration à distance pour maintenir l'accès. Lyceum est un sous-groupe d'OilRig documenté depuis 2019, ciblant principalement les secteurs de l'énergie, des télécommunications, et des gouvernements au Moyen-Orient. La découverte de Cavern Manticore comme entité distincte s'appuyant sur des éléments de ces deux groupes illustre la capacité du MOIS à faire évoluer ses tactiques et à développer de nouveaux outils quand les anciens sont documentés par les chercheurs.
Le ciblage des prestataires informatiques israéliens comme vecteur d'accès aux organisations gouvernementales s'inscrit dans un schéma plus large d'attaques contre la chaîne d'approvisionnement documenté depuis SolarWinds. Pour les prestataires de services informatiques qui opèrent dans des environnements à risque élevé, en particulier ceux qui gèrent des accès privilégiés aux réseaux de leurs clients, la compromission de leur propre infrastructure de gestion est un scénario de menace qui mérite une attention spécifique dans leur modèle de sécurité.
Les indicateurs publiés dans l'analyse de Check Point Research incluent le domaine C2 hospitalinstallation[.]com, le fichier uxtheme.dll malveillant identifiable par ses hachages cryptographiques, et les cinq modules DLL avec leurs noms et hachages respectifs. Ces indicateurs constituent les points de départ pour une recherche dans les logs réseau et les journaux d'événements Windows.
Sur le plan défensif, plusieurs mesures s'appliquent directement à ce mode d'attaque. La vérification d'intégrité des mises à jour logicielles des outils d'administration, en particulier des outils comme SysAid qui ont accès à un grand nombre de systèmes clients, est la première ligne de défense contre les compromissions de chaîne d'approvisionnement. La surveillance des chargements inhabituels de DLL dans des processus systèmes Windows, notamment uxtheme.dll chargé depuis un chemin non standard, peut détecter la phase initiale de l'infection. La surveillance du trafic WebSocket sortant vers des domaines nouvellement enregistrés ou à faible réputation peut détecter le canal C2 une fois l'agent installé.
Le ciblage délibéré des prestataires de services informatiques plutôt que des cibles finales est une stratégie qui a prouvé son efficacité depuis la compromission de SolarWinds en 2020. Pour un acteur étatique dont l'objectif est l'espionnage à long terme, compromettre un prestataire qui gère les systèmes de dix ou vingt organisations gouvernementales est plus rentable que de conduire dix ou vingt intrusions séparées, chacune avec ses propres exigences de reconnaissance et d'établissement de l'accès initial.
Dans le contexte israélien, les prestataires de services IT occupent une position particulièrement sensible. Beaucoup d'entre eux gèrent des contrats avec plusieurs entités gouvernementales, des entreprises de défense, et des fournisseurs de technologies de sécurité. Un accès maintenu chez un tel prestataire représente une fenêtre sur un large spectre d'organisations sensibles, avec les connexions de gestion distante comme chemin d'accès direct. L'usage de SysAid comme vecteur est particulièrement adapté à ce modèle d'attaque : SysAid est conçu pour la gestion des services informatiques centralisée, ce qui signifie que les prestataires qui l'utilisent ont souvent des connexions configurées vers l'ensemble de leurs clients.
Pour les organisations opérant dans les secteurs ciblés par Cavern Manticore, la détection repose sur plusieurs couches distinctes. Au niveau réseau, la surveillance des connexions WebSocket sortantes vers des domaines inconnus ou récemment enregistrés est un indicateur pertinent. Les connexions WebSocket légitimes dans un environnement d'entreprise ont généralement des destinations connues et stables. Une connexion WebSocket établie par un processus svchost.exe ou par un processus chargé depuis un chemin inhabituel vers un domaine jamais vu dans les logs précédents mérite une investigation immédiate.
Au niveau endpoint, la détection du chargement latéral de DLL dans des processus systèmes Windows est une capacité que les EDR modernes exposent. Le chargement d'un uxtheme.dll dont le chemin ne correspond pas à %SystemRoot%\System32\uxtheme.dll est une anomalie détectable. La surveillance de l'intégrité des fichiers sur les DLL système Windows, en particulier celles susceptibles d'être ciblées par le side-loading, est une mesure de détection applicable sans attendre la publication d'indicateurs spécifiques à une campagne donnée.
Pour les prestataires de services informatiques qui gèrent des clients dans des secteurs sensibles, la révision régulière des mises à jour logicielles déployées depuis leurs plateformes de gestion vers leurs clients est une mesure de sécurité rarement implementée mais directement pertinente au mode d'attaque de Cavern Manticore. La signature cryptographique des mises à jour et la vérification de cette signature avant déploiement sont les contrôles techniques qui auraient bloqué ce vecteur d'infection spécifique.
La combinaison de formats de compilation inhabituels dans Cavern crée un problème pratique spécifique pour les équipes de sécurité opérationnelle. Dans un environnement de détection et réponse aux incidents standard, quand un analyste identifie un processus suspect, l'étape suivante est la décompilation du binaire associé pour comprendre ce qu'il fait. Avec un binaire .NET standard, un outil comme dnSpy ou dotPeek peut produire un code source lisible en quelques secondes. Avec un binaire en Mode Mixte C++/CLI ou en Native AOT, ce flux de travail standard est rompu.
L'analyste face à un composant Cavern doit basculer vers des outils d'analyse de binaires natifs comme IDA Pro ou Ghidra, reconstruire manuellement la logique du programme depuis le code désassemblé, et gérer simultanément deux couches d'analyse: le code managé .NET et le code natif non managé qui s'exécutent dans le même binaire. Ce processus prend des heures plutôt que des minutes, allongeant significativement le temps de réponse à un incident impliquant Cavern. C'est précisément l'effet recherché : les développeurs de Cavern ne cherchent pas à rendre l'analyse impossible, mais à la rendre suffisamment coûteuse pour que les défenseurs ne puissent pas characteriser la menace complète pendant la fenêtre d'accès.
L'isolation par AppDomain ajoute une difficulté supplémentaire pour l'analyse dynamique. Un analyste qui attache un débogueur au processus de l'agent Cavern ne voit qu'un AppDomain à la fois. Pour obtenir une vue complète de tous les modules actifs, il foit énumérer et attacher à chaque AppDomain séparément, une opération qui n'est pas triviale avec les outils de débogage standards et qui prend du temps pendant lequel l'attaquant peut détecter l'analyse et désactiver ses modules.
Le mode d'attaque de Cavern Manticore positionne les prestataires de services IT comme cible principale plutôt que les organisations finales. Cette stratégie a des implications directes pour la façon dont les prestataires doivent architecturer leurs propres défenses. Un prestataire qui gère les systèmes de clients dans des secteurs sensibles est, du point de vue d'un acteur étatique, une cible qui offre un retour sur investissement démultiplié : compromettre ce prestataire unique donne accès à l'ensemble de son portfolio de clients.
La surveillance de l'intégrité des déploiements logiciels que le prestataire pousse vers ses clients est un contrôle technique directement pertinent. Des outils de gestion des modifications qui journalisent chaque déploiement, comparent les hachages des composants déployés avec les hachages originaux signés par l'éditeur, et alertent en cas de divergence, auraient pu détecter la modification du uxtheme.dll avant qu'elle n'atteigne les clients finaux.
La segmentation des accès entre clients est également essentielle. Un prestataire dont l'infrastructure de gestion permet à un opérateur de passer d'un client à un autre sans barrières d'authentification supplémentaires amplifie considérablement l'impact d'une compromission. Si l'infrastructure de gestion de SysAid d'un prestataire est compromise, et que cette infrastructure a un accès direct à tous les tenants clients, l'attaquant hérite de cet accès. La mise en place de cloisonnements entre les tenants clients dans l'infrastructure de gestion, même si elle complexifie les opérations quotidiennes du prestataire, réduit le rayon de blast d'une compromission de l'infrastructure centrale.
Enfin, les prestataires opérant dans des environnements à risque élevé devraient envisager des audits de sécurité réguliers de leur propre chaîne de déploiement logiciel. Ces audits, conduits par des tiers indépendants, examinent l'ensemble du cycle de vie des déploiements : création des packages, stockage, transmission, et installation chez les clients. Une compromission de chaîne d'approvisionnement comme celle documentée dans la campagne Cavern Manticore ne laisse des traces que dans cette chaîne, et non dans les systèmes clients qui reçoivent les mises à jour, ce qui en fait un vecteur particulièrement difficile à détecter sans surveillance spécifique de la chaîne d'approvisionnement elle-même.
Pour les organisations qui découvrent une potentielle compromission liée à Cavern Manticore, la coordination avec les équipes de réponse aux incidents doit tenir compte d'une particularité de ce groupe : la chaîne de compromission à deux sauts signifie que les preuves de l'intrusion peuvent se trouver chez le prestataire compromis plutôt que chez l'organisation finale. Les logs de connexion sur les systèmes de la cible finale montreront des connexions provenant de l'infrastructure légitime du prestataire, pas d'adresses IP directement associées à un acteur malveillant. Reconstruire la chaîne d'attaque complète exige donc une coordination entre l'organisation cible et son prestataire, avec une visibilité sur les systèmes des deux parties.
Les indicateurs de compromission publiés par Check Point Research constituent le point de départ pour une investigation initiale. Une recherche sur le domaine hospitalinstallation[.]com dans les logs DNS et proxy des deux dernières années peut révéler des communications antérieures à la publication de l'analyse, ce qui fournirait un indicateur de la durée de l'accès non détecté. La présence de communications vers ce domaine avant la date de publication de l'analyse de Check Point est un indicateur fort que l'organisation a été ciblée et potentiellement compromise pendant une période significative.
Les acteurs étatiques, les outils d'accès distant distribués sur mesure et les techniques d'exfiltration physique représentent des menaces que les seuls outils de protection de poste ne suffisent pas à contenir. Defendis surveille en continu la surface d'attaque exposée de votre organisation : services accessibles sur Internet, identifiants compromis circulant dans les marchés clandestins, et indicateurs de compromission associés aux groupes documentés dans cet article. Quand un acteur hostile cible votre secteur ou que des données propres à votre organisation apparaissent dans un nouveau canal d'exfiltration, votre équipe reçoit le signal avant que l'attaquant ait pu agir. Découvrez comment la détection précoce change les résultats d'un incident, ou demandez un briefing personnalisé pour votre organisation.
