Comment les attaquants détournent des outils RMM légitimes
Points clés
- Les attaquants peuvent utiliser des emails de phishing et des scénarios trompeurs d’accès à des documents pour convaincre les utilisateurs d’installer des logiciels RMM légitimes.
- La chaîne d’installation peut comprendre un exécutable déguisé, un package MSI, un service Windows, des modifications du pare-feu et un mécanisme de persistance en mode sans échec.
- Les équipes de sécurité doivent distinguer les déploiements RMM autorisés des logiciels installés à la suite d’activités inhabituelles impliquant des emails, un navigateur, des scripts ou des dossiers temporaires.
- Une détection efficace associe des listes d’applications autorisées aux données de télémétrie des emails, de la création de processus, des services, des modifications du registre, des règles de pare-feu et des connexions réseau.
- La récurrence de certains leurres et schémas d’installation peut aider à regrouper des campagnes liées.
Table des matières
Du phishing à la prise de contrôle à distance
Les analystes du Threat Intelligence Lab ont observé une nouvelle vague de campagnes qui utilisent des outils légitimes de supervision et de gestion à distance comme mécanisme d’accès final.
Les plateformes de supervision et de gestion à distance (RMM) permettent aux équipes d’administration d’assurer le support d’un grand nombre d’ordinateurs. Elles proposent la prise de contrôle à distance, le déploiement de logiciels, l’inventaire des systèmes, le transfert de fichiers, l’exécution de commandes et la maintenance automatisée.
Ces fonctionnalités offrent aussi aux attaquants un canal d’accès prêt à l’emploi. Au lieu de développer une porte dérobée sur mesure, un attaquant peut convaincre un utilisateur d’installer un agent qui intègre déjà des fonctions d’administration à distance. Le résultat peut ressembler à un déploiement IT non autorisé plutôt qu’à une infection classique par un malware.
En 2026, nous avons observé une nouvelle vague de campagnes détournant ainsi des produits RMM légitimes. Les leurres et les programmes d’installation variaient, mais la chaîne d’attaque suivait le même schéma : inspirer confiance par email, amener l’utilisateur à exécuter un fichier, installer l’agent RMM, modifier le poste et se connecter à une infrastructure d’accès à distance.
Un leurre aux couleurs de Chase a mené à FleetDeck
En septembre 2026, une campagne usurpant l’identité de Chase a diffusé plus de 80 000 messages en quelques heures. L’email présentait un relevé de compte sécurisé et dirigeait les destinataires vers un fichier HTML hébergé sur l’infrastructure user-attachments de GitHub. L’ouverture du fichier déclenchait le téléchargement de Chase_Statement.Viewer.exe, qui installait ensuite FleetDeck sur le poste.
Le nom du fichier évoquait une visionneuse de documents. Son comportement révélait une tout autre réalité. Une fois exécutée, la visionneuse créait un package MSI dans le dossier temporaire de l’utilisateur et lançait msiexec.exe. Les composants FleetDeck étaient installés dans C:\Program Files (x86)\FleetDeck Agent\ et enregistrés sous le nom FleetDeck Agent Service. Des commandes PowerShell créaient des règles du pare-feu Windows autorisant le trafic entrant pour le service et l’exécutable de l’agent. L’installation ajoutait également le service dans la branche SafeBoot Network du registre, lui permettant de fonctionner en mode sans échec avec prise en charge réseau.
LE CONSTAT CLÉ : le produit était légitime, mais son déploiement n’était pas autorisé. L’usurpation d’une marque de confiance avait conduit à un scénario trompeur d’accès à un document, à l’exécution d’une visionneuse, à la création d’un service et à l’activation d’un canal d’accès à distance.
Le déroulement de l’installation de FleetDeck
Une fois actif, FleetDeck interrogeait le poste via PowerShell et WMI. Les informations collectées comprenaient le domaine, l’état du système, le fabricant et le modèle, la mémoire physique, le système d’exploitation et sa version, le numéro de série du BIOS, la date et l’heure du dernier démarrage, le processeur, le contrôleur vidéo, l’architecture, le type de carte réseau, l’adresse MAC, la langue du système et l’adresse IP externe. L’agent communiquait ensuite avec l’infrastructure légitime de FleetDeck.
Une même chaîne d’attaque pour plusieurs produits RMM
Le cas Chase n’est pas un exemple isolé de recours à un produit d’accès à distance par des attaquants. D’autres campagnes utilisaient des leurres et des modes de diffusion différents, mais suivaient la même logique opérationnelle : convaincre l’utilisateur d’exécuter un document, un script ou un programme d’installation, puis faire d’un outil d’administration légitime le canal d’accès final.
ScreenConnect se cachait derrière des leurres prenant la forme de relevés administratifs, de mises à jour de plateformes collaboratives et de demandes de signature de documents. SimpleHelp était installé après qu’un dropper avait dressé le profil du poste. Une campagne utilisant un leurre de facture s’appuyait sur une archive ZIP et un petit script batch de téléchargement pour récupérer un MeshAgent probablement préconfiguré, puis lancer une installation complète avec des privilèges d’administration. Remcos, commercialisé à l’origine comme un outil légitime d’administration à distance, était diffusé au moyen de plusieurs chaînes combinant archives, scripts et techniques d’obfuscation.
Notre précédente analyse décrit en détail l’une des chaînes d’attaque de Remcos. Lire l’analyse de la chaîne d’attaque du RAT Remcos.
Les outils variaient, mais l’avantage opérationnel restait le même. Les produits RMM offrent des fonctionnalités éprouvées de persistance, de découverte des systèmes, d’exécution à distance, de transfert de fichiers et de surveillance. Ils peuvent aussi communiquer avec l’infrastructure de leur éditeur, qui semble légitime. Le contexte comportemental devient donc plus important qu’une simple liste de blocage de domaines.
| Produit | Contexte de diffusion |
|---|---|
| ScreenConnect | Relevés administratifs, mises à jour de plateformes collaboratives et leurres de signature |
| SimpleHelp | Dropper utilisant un leurre lié à la Social Security, diffusé sous forme de fichier .scr |
| MeshAgent | Archive ZIP sur le thème d’une facture et script batch de téléchargement |
| Remcos | Chaînes combinant archives, scripts et techniques d’obfuscation |
Détecter les détournements en retraçant l’installation
Les entreprises doivent tenir un inventaire des logiciels de gestion à distance qui répondent à un besoin métier légitime. Pour chaque produit autorisé, documentez le tenant ou le compte attendu, la méthode de déploiement, le responsable du support et les postes concernés. L’utilisation des produits qui ne sont pas nécessaires à l’activité doit être restreinte par des politiques de contrôle des applications et de sécurité des postes.
La détection doit ensuite porter sur la façon dont le logiciel est arrivé, sur ce qui l’a lancé et sur les changements survenus immédiatement après. Les combinaisons d’indices utiles comprennent :
- un nouvel agent RMM lancé par un client email, un navigateur ou un interpréteur de scripts, ou depuis un dossier temporaire dans lequel l’utilisateur dispose de droits d’écriture ;
- un programme d’installation téléchargé dans Downloads ou Temp, puis copié dans Program Files ;
- un nouveau service associé à un produit RMM, créé en dehors du processus de déploiement autorisé ;
- des chaînes de processus telles que wscript.exe suivi de PowerShell et de msiexec.exe, ou cmd.exe suivi de PowerShell et de curl.exe ;
- des règles de trafic entrant du pare-feu créées par PowerShell peu après l’installation d’un nouvel agent ;
- des modifications de SafeBoot, de la clé Run, du dossier Démarrage ou de COM après une interaction avec un message externe.
Lors de la réponse à un incident, corrélez les données de télémétrie des emails et du Web avec la création de processus, l’installation de services, les modifications du registre et du pare-feu, ainsi qu’avec les premières connexions réseau de l’agent.
Les questions clés sont les suivantes : qui a installé le logiciel ? Quand a-t-il été installé ? Quelle chaîne de processus l’a lancé ? À quel compte ou tenant se connecte-t-il ? Le poste est-il censé être administré par l’infrastructure de support de l’entreprise ?
Regrouper les campagnes sans extrapoler sur leur attribution
Nous regroupons les campagnes récurrentes en ensembles d’activités définis en interne, à partir des thèmes de phishing répétés, des méthodes de diffusion, du comportement des chargeurs, des schémas de déploiement RMM et de la réutilisation des infrastructures. Ces regroupements décrivent les modes opératoires observés. Ils ne désignent pas un acteur de la menace.
Des opérateurs sans lien entre eux peuvent réutiliser les mêmes logiciels RMM et infrastructures d’hébergement. Les éléments recueillis dans ces cas ne permettent donc pas d’attribuer les campagnes à un groupe identifié. Le regroupement reste utile : il relie des incidents apparemment distincts, met en évidence des méthodes de diffusion récurrentes et aide les analystes à reconnaître qu’une chaîne connue sert à déployer un autre produit d’accès à distance.
Conclusion
La campagne Chase montre à quelle vitesse un simple leurre de phishing peut conduire au déploiement non autorisé d’un outil de gestion à distance. En quelques étapes, l’usurpation d’une marque de confiance a mené l’utilisateur à un fichier HTML, à un exécutable, à une installation MSI, à un service Windows, à des modifications assurant la persistance et à un canal d’accès à distance actif.
Plus largement, il faut retenir que la marque du logiciel n’est qu’un élément de l’enquête. Une défense efficace combine des listes de logiciels autorisés, des déploiements RMM contrôlés et une détection comportementale centrée sur le déroulement de l’installation. Pour les équipes de sécurité, l’objectif est de repérer les outils légitimes utilisés en dehors des procédures autorisées, de relier les campagnes grâce à des modes opératoires récurrents et de tirer parti de ces constats pour une détection plus précoce et plus fiable.
Indicateurs de compromission
Les indicateurs suivants concernent la campagne Chase/FleetDeck décrite dans cet article.
| Type | Valeur | Description |
|---|---|---|
| URL | https://github.com/user-attachments/files/31489398/Chase_SecureDocument.html?Voka.com | URL malveillante hébergeant la charge utile et intégrée à l’email – usurpation de l’identité de Chase |
| URL | https://github.com/user-attachments/files/31489398/Chase_SecureDocument.html?Vouka.com | URL malveillante hébergeant la charge utile et intégrée à l’email – usurpation de l’identité de Chase |
| [email protected] | Adresse email utilisée pour diffuser la campagne malveillante | |
| [email protected] | Adresse email utilisée pour diffuser la campagne malveillante | |
| IP | 129.159.94.43 | Adresse IP utilisée pour diffuser la campagne malveillante |
| IP | 79.127.222.213 | Adresse IP utilisée pour diffuser la campagne malveillante |
| IP | 23.234.104.111 | Adresse IP utilisée pour diffuser la campagne malveillante |
| SHA256 | 09ccaa4487af73b7f490656e1289acc6f532964498bcaff4cb4b0125384b7093 | Chase_SecureDocument.html / Fichier téléchargé lorsque la victime clique sur l’URL intégrée à l’email |
| SHA256 | b3d73d532a9b4786dd17b1d1814e9c4fcbc3841f1b4fed1e92a8793ee4980dd6 | Chase_Statement.Viewer.exe / Fichier téléchargé lorsque la victime ouvre le fichier HTML |
Cybersecurity Report 2026
L’accélération des menaces mondiales sous l’impulsion de l’IA