Comment auditer la securite de vos outils d'acces distant (RMM) en 7 etapes

En juin 2026, la publication de la vulnerabilite CVE-2026-48558 dans SimpleHelp (score CVSS 10/10) a rappele brutalement une realite que trop d'organisations ignorent : les outils de Remote Monitoring & Management (RMM) sont devenus le vecteur d'attaque privilegie des cybercriminels. Cette faille critique permettait un contournement complet de l'authentification OIDC, offrant a n'importe quel attaquant un acces administrateur total a l'ensemble des machines gerees par l'outil. Des centaines d'entreprises a Paris, Lyon, Bordeaux et partout en France ont du reagir en urgence.

Le probleme est structurel : la majorite des PME et ETI francaises deploient des outils RMM sans jamais auditer leur securite. TeamViewer est installe sur les postes des techniciens sans MFA. AnyDesk tourne sur un serveur expose directement sur Internet. ConnectWise ScreenConnect fonctionne avec les identifiants par defaut. Ces outils, concus pour simplifier la maintenance a distance, deviennent des portes d'entree royales pour les attaquants lorsqu'ils ne sont pas correctement configures et surveilles.

Ce guide vous propose 7 etapes concretes et actionnables pour auditer la securite de vos outils d'acces distant. Chaque etape est illustree par des exemples reels issus de missions d'audit realisees aupres de PME et ETI francaises, et accompagnee d'une checklist que vous pouvez appliquer des aujourd'hui. Que vous soyez RSSI, DSI ou responsable IT, vous trouverez ici un cadre methodologique complet pour reprendre le controle de vos acces distants.

— Etape 1 : Inventorier tous vos outils RMM

La premiere etape d'un audit de securite RMM est aussi la plus souvent negligee : realiser un inventaire exhaustif de tous les outils d'acces distant presents dans votre systeme d'information. Le shadow IT en matiere de RMM est un phenomene massif. Les techniciens installent TeamViewer pour depanner un utilisateur, un prestataire deploie AnyDesk pour ses interventions, un developpeur utilise Splashtop pour acceder a son poste de travail depuis chez lui. Chacune de ces installations non repertoriees represente une surface d'attaque invisible pour votre equipe securite.

Les outils a rechercher en priorite incluent SimpleHelp, TeamViewer, AnyDesk, ConnectWise ScreenConnect, Splashtop, LogMeIn, BeyondTrust (Bomgar), Datto RMM et NinjaRMM. Pour les decouvrir, combinez plusieurs approches : analysez les logs DNS a la recherche de domaines associes a ces outils, interrogez votre solution EDR pour identifier les processus caracteristiques (tvnserver.exe, AnyDesk.exe, ScreenConnect.ClientService.exe), et lancez des scans reseau sur les ports habituels (5938 pour TeamViewer, 7070 pour AnyDesk, 8040 pour ConnectWise).

Lors d'une mission d'audit a Lyon, nous avons decouvert chez une PME industrielle de 120 salaries pas moins de 3 instances TeamViewer non repertoriees, installees par d'anciens prestataires. L'une d'entre elles utilisait encore un mot de passe statique datant de 2023. Ce type de decouverte est loin d'etre exceptionnel : dans 70% de nos audits, nous identifions au moins un outil RMM non inventorie par la DSI.

— Etape 2 : Verifier les versions et appliquer les correctifs critiques

Une fois votre inventaire etabli, l'etape suivante consiste a dresser une matrice de versions pour chaque outil RMM installe et a la comparer avec les derniers correctifs de securite disponibles. Les outils RMM sont des cibles de choix pour les attaquants precisement parce qu'ils offrent un acces privilegie a l'ensemble du parc informatique. Une seule instance non patchee peut compromettre des dizaines, voire des centaines de machines.

L'exemple le plus parlant en 2026 est CVE-2026-48558, la vulnerabilite critique affectant SimpleHelp. Avec un score CVSS de 10/10 — le maximum possible — cette faille permettait un contournement complet de l'authentification OIDC. Toute instance SimpleHelp anterieure a la version 5.5.16 etait vulnerable. En pratique, un attaquant pouvait prendre le controle total du serveur SimpleHelp et, par extension, de l'ensemble des machines clientes connectees, sans aucun identifiant valide. ConnectWise ScreenConnect a egalement fait l'objet de correctifs critiques recents, tout comme AnyDesk qui a subi une compromission de son infrastructure de signature de code.

Notre recommandation : definissez un SLA de deploiement de correctifs specifique aux outils RMM. Les vulnerabilites critiques activement exploitees (CVSS ≥ 9.0) doivent etre corrigees dans les 24 heures. Les vulnerabilites hautes (CVSS 7.0-8.9) dans les 72 heures. Integrez la surveillance des bulletins de securite de chaque editeur RMM dans votre processus de veille. Abonnez-vous aux flux RSS des advisories de SimpleHelp, TeamViewer, AnyDesk et ConnectWise, et configurez des alertes automatiques dans votre outil de ticketing.

— Etape 3 : Auditer la configuration OIDC et l'authentification

OpenID Connect (OIDC) est le protocole d'authentification adopte par la plupart des outils RMM modernes pour federer les identites. Il permet de deleguer l'authentification a un fournisseur d'identite central (Azure AD, Okta, Google Workspace) plutot que de gerer des identifiants locaux sur chaque outil. En theorie, c'est une excellente pratique de securite. En pratique, une mauvaise configuration OIDC peut s'averer plus dangereuse que des identifiants locaux bien geres.

La vulnerabilite CVE-2026-48558 de SimpleHelp illustre parfaitement ce risque. La faille residait dans la validation insuffisante des tokens OIDC : l'outil n'effectuait pas de verification stricte de la signature du token, de l'emetteur (issuer) et de l'audience. Un attaquant pouvait forger un token JWT valide sans posseder les cles de signature du fournisseur d'identite. Votre checklist d'audit OIDC doit couvrir les points suivants : verification de la signature du token (algorithme RS256 ou ES256, jamais none), validation stricte de l'issuer contre une liste blanche, restriction de l'audience au seul identifiant client de votre outil RMM, duree d'expiration des tokens (maximum 1 heure pour les access tokens), et revocation immediate des refresh tokens lors du depart d'un collaborateur.

Verifiez egalement que vos outils RMM ne supportent pas de methodes d'authentification legacy en parallele de l'OIDC. Il est frequent de trouver des identifiants locaux encore actifs apres la migration vers un fournisseur d'identite federe. Ces comptes locaux residuels constituent des portes derobees parfaites. Desactivez-les systematiquement et documentez chaque exception avec une justification metier et une date de revision.

— Etape 4 : Scanner vos instances exposees sur Internet

L'exposition non maitrisee d'instances RMM sur Internet est l'une des failles les plus courantes et les plus critiques que nous observons lors de nos audits. Selon les donnees collectees via Shodan en juin 2026, environ 14 000 instances SimpleHelp sont directement accessibles depuis Internet dans le monde, dont pres de 1 800 en France. TeamViewer, de par son architecture peer-to-peer, pose des problemes differents mais tout aussi preoccupants lorsque les politiques de connexion ne sont pas restreintes. AnyDesk et ConnectWise ScreenConnect presentent des situations similaires avec des panneaux d'administration frequemment exposes.

Pour scanner votre exposition, utilisez une combinaison d'outils externes et internes. Cote externe, Shodan et Censys permettent d'identifier vos instances RMM visibles depuis Internet en recherchant les empreintes specifiques de chaque outil (certificats TLS, bannieres de service, pages de connexion). Cote interne, lancez des scans Nmap cibles sur les plages de ports associees aux outils RMM : nmap -sV -p 5938,7070,8040,8041,443,80 votre-plage-ip. Croisez les resultats avec votre inventaire de l'etape 1 pour identifier les ecarts.

Lors d'un audit pour une ETI bordelaise du secteur viticole, nous avons identifie 2 instances ConnectWise ScreenConnect exposees sur Internet avec les identifiants par defaut encore actifs. Ces instances avaient ete deployees par un prestataire d'infogrance externe 18 mois auparavant et n'avaient jamais ete integrees dans le perimetre de surveillance de la DSI. L'une d'entre elles permettait un acces direct a 47 postes de travail, incluant des machines du service comptabilite. La remediation a ete realisee en moins de 2 heures une fois le probleme identifie, mais l'exposition existait depuis un an et demi.

— Etape 5 : Deployer le MFA sur tous les acces administrateur

L'authentification multi-facteurs (MFA) n'est plus une option pour les outils RMM : c'est une obligation reglementaire et une necessite operationnelle. La directive NIS2, entree en application en octobre 2024 et dont les controles se renforcent en 2026, exige explicitement le MFA pour tous les acces privilegies aux systemes critiques. Les outils RMM, par leur nature meme d'acces distant privilegie, entrent pleinement dans ce perimetre.

Tous les types de MFA ne se valent pas. Le MFA par SMS est considere comme insuffisant depuis plusieurs annees en raison des attaques de type SIM swapping et SS7 interception. Privilegiez les solutions TOTP (Time-based One-Time Password) via des applications comme Microsoft Authenticator ou Google Authenticator, ou mieux encore, les cles materielles de type YubiKey ou Titan Security Key qui offrent une resistance native au phishing. Les notifications push constituent un bon compromis entre securite et experience utilisateur, a condition d'implementer des mecanismes anti-fatigue (number matching, contexte geographique).

La strategie de deploiement recommandee est progressive mais rapide. Commencez par les comptes administrateurs de chaque outil RMM : ce sont les cibles les plus critiques et les premiers vises par les attaquants. Dans un second temps, etendez le MFA aux comptes techniciens. Enfin, si votre outil le supporte, activez le MFA pour les connexions des utilisateurs finaux. Fixez-vous un objectif de couverture de 100% des comptes administrateurs sous 30 jours et 100% des comptes techniciens sous 60 jours. Documentez chaque exception et planifiez une revision trimestrielle.

— Etape 6 : Mettre en place la journalisation et le monitoring

Sans journalisation et monitoring adequats, vos outils RMM sont des boites noires. Vous ne pouvez pas detecter une utilisation malveillante, vous ne pouvez pas mener une investigation post-incident, et vous ne pouvez pas prouver votre conformite aux regulateurs. La journalisation des acces RMM doit capturer au minimum les evenements suivants : toutes les connexions distantes (qui, quand, vers quelle machine, depuis quelle adresse IP), toutes les actions administratives (creation/modification de comptes, changement de configuration, installation d'agents), les transferts de fichiers (direction, taille, nom du fichier), et les tentatives d'authentification echouees.

Ces logs doivent etre centralises dans votre SIEM (Splunk, ELK Stack, Microsoft Sentinel, Wazuh) et correles avec vos autres sources de telemetrie. Configurez des regles d'alerte specifiques aux outils RMM : connexions en dehors des heures ouvrees (22h-6h en semaine, week-ends et jours feries), connexions depuis des adresses IP geolocalisees en dehors de vos zones d'activite, tentatives de brute-force (plus de 5 echecs d'authentification en 10 minutes), et creation de comptes administrateurs non sollicitee.

La retention des logs est un point souvent neglige. Pour des raisons de conformite (NIS2, RGPD, LPM) et de capacite d'investigation, nous recommandons une retention minimale de 12 mois pour les logs d'acces RMM. Certains secteurs reglementes (banque, sante) peuvent exiger des durees plus longues. Assurez-vous que vos logs sont stockes dans un environnement distinct de vos outils RMM eux-memes : si un attaquant compromet votre outil RMM, il ne doit pas pouvoir effacer les traces de son intrusion.

— Etape 7 : Etablir un plan de reponse aux incidents RMM

La derniere etape de votre audit RMM consiste a documenter un playbook de reponse aux incidents specifique aux scenarios impliquant vos outils d'acces distant. Un plan de reponse generique ne suffit pas : les incidents RMM presentent des particularites qui necessitent des procedures dediees. Lorsqu'un outil RMM est compromis, l'attaquant dispose potentiellement d'un acces a l'ensemble du parc informatique, ce qui change radicalement l'echelle de la reponse.

Votre playbook doit couvrir quatre phases pour chaque scenario. La detection : quels sont les indicateurs de compromission specifiques a chaque outil RMM (processus suspects, connexions anormales, modifications de configuration non autorisees) ? Le confinement : comment isoler rapidement l'outil RMM compromis sans paralyser l'ensemble des operations de maintenance (couper l'acces Internet du serveur RMM, revoquer les sessions actives, desactiver les comptes suspects) ? L'eradication : comment s'assurer que l'attaquant n'a pas installe de persistance sur les machines clientes accessibles via l'outil RMM ? La reprise : comment restaurer un service d'acces distant securise dans les delais acceptables pour l'activite ?

N'oubliez pas le volet communication et reglementaire. En France, une compromission via un outil RMM doit etre signalee a l'ANSSI si votre organisation est un operateur de services essentiels (OSE) ou une entite importante au sens de NIS2. Si des donnees personnelles ont ete exfiltrees, la CNIL doit etre notifiee dans les 72 heures. Documentez clairement les roles et responsabilites : qui prend la decision de couper l'outil RMM, qui communique aux equipes metier, qui contacte l'ANSSI et la CNIL. Enfin, organisez des exercices de simulation (tabletop exercises) trimestriels pour tester votre playbook avec des scenarios realistes inspires des incidents recents comme CVE-2026-48558.

Avis d'expert

« L'audit des outils RMM n'est pas un projet ponctuel, c'est un processus continu. CVE-2026-48558 a demontre qu'une vulnerabilite CVSS 10 peut apparaitre a tout moment sur des outils que vous utilisez quotidiennement. Les organisations qui survivent a ces crises sont celles qui ont deja un inventaire a jour, un processus de patch accelere et un playbook d'incident pret a etre active. Les autres decouvrent le probleme dans les journaux de leur SIEM — quand elles en ont un. »

Marie Lefevre, Consultante cybersecurite PME — WebGuard Agency

— Conclusion

Les outils RMM sont des composants critiques de votre infrastructure IT. Ils offrent un acces distant privilegie a l'ensemble de votre parc informatique, ce qui en fait des cibles de premier choix pour les attaquants. La vulnerabilite CVE-2026-48558 dans SimpleHelp, avec son score CVSS maximal de 10, a rappele qu'un seul outil RMM mal securise peut compromettre l'integralite d'un systeme d'information en quelques minutes.

Les 7 etapes decrites dans ce guide — inventaire, patch management, audit OIDC, scan d'exposition, deploiement MFA, journalisation et plan de reponse — constituent un cadre methodologique complet et actionnable. Elles ne necessitent pas d'investissement technologique majeur, mais exigent de la rigueur, de la systematisation et un engagement de la direction. Commencez par l'etape 1 des aujourd'hui : ouvrez un tableur et listez tous les outils d'acces distant presents dans votre SI. Vous serez probablement surpris par le resultat.