ConnectWise corrige une faille ScreenConnect notée 9,9 exploitée dans des attaques de type ver

ConnectWise a publié une mise à jour d'urgence pour ScreenConnect, son logiciel d'assistance et d'accès à distance, afin de colmater une faille critique côté client qui permettait à un attaquant de déplacer et d'exécuter des fichiers dans une session active sans l'accord de l'hôte. Le correctif, ScreenConnect 26.6.5, est sorti le 8 septembre, selon le bulletin de sécurité du fournisseur. La vulnérabilité, suivie sous la référence CVE-2026-84869, porte un score CVSS de 9,9 sur 10, et les chercheurs l'avaient déjà vue exploitée en conditions réelles pendant environ deux semaines avant qu'un correctif n'existe.

À lire aussi: Des attaquants ont utilisé l'identité applicative de ConnectWise Cloud Backup pour entrer dans des tenants Microsoft 365 · Le FBI arrête un employé d'OpenAI soupçonné d'avoir placé un enregistreur caché.

Le bug se trouve dans le client ScreenConnect, pas dans le serveur. ConnectWise décrit une situation dans laquelle les actions de transfert de fichiers peuvent se poursuivre « à travers une session distante active sans autorisation ni confirmation de l'Hôte dans certaines circonstances », et précise que les serveurs ScreenConnect ne sont pas touchés. En pratique, un attaquant déjà présent dans une session peut pousser un fichier vers le poste connecté et l'exécuter, y compris par des actions d'exécution élevée.

Ce que Huntress a observé

La société de sécurité Huntress a documenté l'activité, l'ayant signalée pour la première fois fin août, et a publié ses conclusions le 9 septembre dans une analyse détaillée. À travers trois incidents sans lien entre eux, ses analystes ont trouvé des installations pirates de ScreenConnect sur des machines victimes, qui lançaient ensuite à répétition wscript.exe pour exécuter quatre scripts nommés 1.vbs à 4.vbs.

Les installations pirates sont arrivées par ingénierie sociale. L'une a commencé par une arnaque au support technique bâtie sur Windows Quick Assist. Une autre a suivi la recherche d'un formulaire de remboursement Geek Squad, qui a conduit la victime à exécuter un fichier d'installation du client téléchargé. Une troisième est partie d'un résultat de recherche empoisonné qui poussait un ScreenConnect.Client.exe pirate. Ces tactiques sont familières : les outils de surveillance et de gestion à distance (RMM) attirent les criminels précisément parce qu'il s'agit de logiciels de confiance qui pénètrent profondément dans un réseau.

Ce qui distinguait cette campagne, c'est ce que les clients modifiés faisaient ensuite. Selon Huntress, le client pirate surveillait la liste de connexions de ScreenConnect et, dès qu'une nouvelle session hôte apparaissait, il enregistrait les quatre fichiers VBScript auprès du système de transfert de fichiers du logiciel lui-même et les poussait vers la machine fraîchement connectée. La chaîne se répétait alors sur ce poste. Huntress a qualifié le comportement de type ver, car la charge utile se propage de session en session toute seule, sans attendre qu'un opérateur refasse le travail à la main.

Sur chaque hôte, les intrusions laissaient aussi une clé Run utilisateur de Windows nommée WindowsServiceHost pointant vers WindowsServiceHost.vbs dans le dossier AppData de l'utilisateur, et dans au moins un incident installaient un second outil d'accès à distance, UltraViewer. Huntress a listé les adresses de commande et contrôle observées pendant les incidents, dont 45.13.237[.]190, 131.123.40[.]98 et 15.204.185[.]204.

Le chargeur en quatre étapes

Les scripts étaient agencés pour profiler chaque machine avant de choisir une charge utile. Le premier, 1.vbs, écrivait dans un fichier temporaire une valeur de trois bits décrivant si ScreenConnect était déjà installé, quels produits de sécurité étaient actifs et de combien de mémoire disposait l'hôte. Le contrôle de mémoire, observe Huntress, est un moyen courant d'empêcher une charge utile de s'exécuter dans une petite machine virtuelle d'analyse.

Un deuxième script attendait cette valeur, récupérait un fichier depuis Dropbox, le décodait avec une clé XOR d'un seul octet et produisait un catalogue d'autres charges utiles indexées sur la valeur de trois bits. Un troisième script lisait le catalogue et téléchargeait l'entrée correspondante, stockée chiffrée sous le nom out.enc. Le quatrième la déchiffrait avec une clé AES tirée du catalogue, lançait un exécuteur PowerShell, déchiffrait une seconde archive dans un répertoire de modèles Windows, supprimait les fichiers d'attente et tuait les hôtes de script restants.

Parmi les résultats observés par Huntress figuraient un contournement de l'UAC bâti sur le gestionnaire de protocole ms-settings, une tentative de désactivation de l'interface d'analyse antimalware, une exclusion de Microsoft Defender pour toute l'arborescence C:\Users, et un client ScreenConnect dissimulé dont l'entrée de désinstallation et le descripteur de service avaient été retirés pour qu'il n'apparaisse pas aux endroits habituels. Une variante de charge utile livrait aussi un mineur de cryptomonnaie, signe d'un savoir-faire motivé par l'argent.

Un détail saute aux yeux des défenseurs. Un commentaire dans 3.vbs exposait le format attendu du catalogue de charges utiles, le genre de note explicative qu'un développeur humain laisse derrière lui. Huntress a écrit que le script était « probablement » généré par un grand modèle de langage. Les logiciels malveillants de grande diffusion assemblés avec les mêmes assistants qui écrivent du code ordinaire font désormais partie du quotidien de la réponse à incident, et cela rend les scripts plus lisibles que leur intention ne le mérite.

Des charges utiles ramifiées

Tous les hôtes n'ont pas reçu le même paquet. Huntress a constaté que le catalogue associait le profil de trois bits à l'une de trois charges utiles chiffrées : une porte dérobée ScreenConnect au niveau utilisateur, un paquet d'accès portant des outils de persistance et d'élévation de privilèges, ou un paquet combiné qui, selon elle, incluait des utilitaires de création de tunnels et un mineur de cryptomonnaie. Établir un profil de cible puis choisir une charge utile est un savoir-faire ordinaire pour un chargeur de ce type, mais cela montre que les opérateurs triaient les machines plutôt que de vaporiser une seule étape sur tout ce qu'ils touchaient.

Comment la réponse s'est déroulée

La divulgation s'est faite selon un calendrier serré. ConnectWise a publié un avis le 3 septembre signalant un problème dans le comportement du transfert de fichiers des sessions d'assistance et d'accès de ScreenConnect, dans les déploiements cloud comme sur site, et a indiqué qu'une CVE et un correctif officiel suivraient dans la semaine, tout en recommandant aux partenaires d'examiner et de désactiver la permission TransferFiles entre-temps. Huntress, qui suivait les anomalies depuis fin août, a mis à jour son analyse le 8 septembre à l'arrivée du correctif 26.6.5, puis de nouveau à mesure que le tableau de l'exploitation se précisait. L'inscription au catalogue de la CISA le 11 septembre a transformé une remédiation de fournisseur en échéance fédérale du 14 septembre pour les agences civiles. Cette séquence, avis d'abord, correctif quelques jours plus tard, puis inscription comme vulnérabilité exploitée, est devenue le rythme standard d'un grave bug d'entreprise, mais elle a tout de même laissé environ deux semaines entre les premières intrusions observées et un correctif.

Pourquoi l'accès à distance reste la cible

ScreenConnect est largement utilisé par les fournisseurs de services gérés et les centres d'assistance informatique. C'est exactement ce qui le rend précieux aux yeux d'un attaquant : c'est un logiciel légitime qui atteint largement les réseaux des clients et qui s'exécute avec les privilèges qu'un technicien de support est censé détenir. L'abus d'outils RMM est un vecteur d'attaque de premier plan depuis des années, et ScreenConnect est déjà passé par là. Un contournement d'authentification du produit en 2024 a été largement exploité, et le schéma consistant à utiliser une session d'assistance à distance pour déposer de l'outillage est devenu si courant que les défenseurs traitent désormais les installations RMM comme une surface de détection à part entière.

Pour un fournisseur de services gérés, les enjeux sont plus élevés que pour une entreprise isolée. Un MSP administre souvent de nombreux clients depuis un seul déploiement ScreenConnect, de sorte qu'un client contaminé qui pousse des charges utiles vers de nouvelles sessions peut menacer les clients en aval comme les machines du fournisseur lui-même. C'est un problème de chaîne d'approvisionnement en miniature, et c'est pourquoi le conseil du fournisseur d'auditer les permissions de transfert de fichiers des sessions concerne en priorité les prestataires de services.

Le modèle de propagation est l'élément nouveau. L'abus de RMM dépend normalement d'un opérateur qui pousse un outil vers une machine à la fois, ce qui limite la vitesse de propagation d'une intrusion et donne aux défenseurs plus d'occasions de la repérer. Un client qui pousse l'étape suivante vers toute machine à laquelle il se connecte ensuite supprime ce goulot d'étranglement. Cela complique aussi l'attribution, car chaque machine d'un même déploiement ScreenConnect devient un point de livraison potentiel.

L'échéance du correctif

La CISA a ajouté CVE-2026-84869 à son catalogue des vulnérabilités exploitées connues le 11 septembre et a donné aux agences civiles fédérales jusqu'au 14 septembre pour remédier, en vertu de la directive opérationnelle contraignante 26-04. C'était l'une des trois entrées de ce jour-là et le membre d'un groupe plus large que l'agence a catalogué durant la semaine, aux côtés de deux failles de MikroTik RouterOS et de deux failles de JFrog Artifactory qui, rapporte The Hacker News, étaient enchaînées dans des attaques contre des serveurs auto-hébergés. SecurityWeek figure parmi les médias qui ont confirmé l'exploitation de ScreenConnect.

Deux mises en garde méritent d'être gardées en tête. La description de type ver vient de l'enquête de Huntress, pas de ConnectWise, et elle décrit une propagation de session à session entre des machines qui partagent un déploiement ScreenConnect, non la diffusion autonome à l'échelle d'internet que le mot ver suggère habituellement. Par ailleurs, aucune des deux entreprises n'a attribué la campagne à un groupe nommé. Le composant de minage commun et les leurres de support grand public pointent vers un opérateur motivé par l'argent, mais il s'agit d'une déduction tirée du savoir-faire, pas d'une identification confirmée.

Ce qu'il faut surveiller

La question immédiate, pour toute organisation qui utilise ScreenConnect, est de savoir si les clients modifiés ont atteint des machines situées hors du parc que ses propres administrateurs connaissent, puisque toute la logique de la propagation est d'atterrir sur des postes que l'opérateur n'a pas touchés directement. Les journaux d'audit montrant un processus Guest exécutant des fichiers sur un hôte sont le point de départ.

La question de fond est de savoir si la même technique apparaîtra dans d'autres produits d'assistance à distance. La condition sous-jacente, un client qui agit sur les instructions d'une session sans contrôle d'autorisation clair, a peu de chances d'être propre à un seul fournisseur. ConnectWise a livré le correctif ; le reste du marché du RMM a désormais une raison d'examiner comment ses propres clients décident quels transferts de fichiers méritent confiance.

Image : logo ScreenConnect par ScreenConnect, via Wikimedia Commons, sous licence CC BY-SA 4.0. L'image a été recadrée et placée sur un fond.