RMM exposé : bloquer le contournement d’authentification

Sécuriser un outil RMM n’est plus une option : les attaquants exploitent activement un contournement d’authentification dans les serveurs N-able N-central pour atteindre, en une seule intrusion, l’ensemble du parc géré. Pour une PME-ETI qui confie son infogérance à un prestataire, la console RMM est devenue le maillon le plus rentable de la chaîne : un accès, des centaines de postes. Ce tutoriel détaille comment sécuriser un outil RMM et bloquer ce type de contournement, étape par étape.

Pourquoi le RMM est la cible idéale

Un outil de Remote Monitoring and Management concentre trois privilèges que les attaquants recherchent : l’exécution de commandes à distance en SYSTEM, le déploiement de logiciels sur tout le parc, et un canal sortant légitime que les EDR laissent passer. Dans les incidents récents visant N-central, les intrus ont enchaîné trois étapes :

• Contournement d’authentification sur le serveur exposé — le correctif initial était contournable, ce qui a rouvert la faille chez les clients ayant patché trop tôt ;
• Pivot vers les agents déployés sur les postes et serveurs clients, via les fonctions natives de l’outil ;
• Installation de tunnels Cloudflare persistants pour maintenir l’accès hors de tout flux VPN surveillé.

Le point crucial : aucune de ces étapes n’utilise de malware classique. L’attaquant se sert de l’outil d’administration lui-même. C’est la même logique que celle observée avec la faille SimpleHelp exploitée pour diffuser l’infostealer Djinn.

Étape 1 — Sortir la console RMM d’Internet

La très grande majorité des compromissions RMM commencent par un serveur d’administration directement joignable depuis Internet. Première action, avant même le correctif :

• Placez l’interface web de la console derrière un VPN ou un proxy d’accès Zero Trust ; aucune console d’administration ne doit répondre sur le port 443 public ;
• Si la remontée des agents impose une exposition, restreignez-la par liste d’adresses IP autorisées et séparez le port agent du port administrateur ;
• Vérifiez l’exposition réelle depuis l’extérieur, pas depuis le réseau interne : un simple scan Shodan ou nmap sur votre plage publique suffit à trancher.

Étape 2 — Appliquer le correctif, puis vérifier qu’il tient

Le cas N-central illustre un piège classique : un premier correctif publié, puis un contournement du correctif découvert quelques jours plus tard. Pour sécuriser un outil RMM durablement :

• Identifiez la version exacte en production et comparez-la à la dernière version corrigée de l’éditeur, pas à celle du bulletin initial ;
• Abonnez-vous au flux d’avis de l’éditeur et à celui du CERT-FR pour être notifié des révisions ;
• Réappliquez systématiquement le correctif après toute mise à jour mineure : les rollbacks silencieux existent.

Rythme de patch attendu

Pour un composant d’administration exposé, la fenêtre cible est de 24 heures, pas de 30 jours. Nous détaillons cette approche dans notre article sur la réduction de la fenêtre de patch.

Étape 3 — Chasser la persistance par tunnel

Un attaquant qui a franchi le contournement d’authentification laisse rarement une trace bruyante. Les tunnels sortants (Cloudflare Tunnel, ngrok, FRP) sont le signal le plus fiable. Cherchez sur vos serveurs RMM et vos postes gérés :

• Des processus cloudflared, ngrok ou frpc non inventoriés, y compris installés en service Windows ;
• Des résolutions DNS vers *.trycloudflare.com ou *.ngrok.io depuis des serveurs qui n’ont aucune raison métier de le faire ;
• Des connexions sortantes persistantes en 443 vers des ASN de CDN depuis un serveur d’infrastructure.

Ces trois requêtes se traduisent directement en règles de détection dans un SIEM ou dans notre Agentic SOC, qui corrèle l’apparition d’un tunnel avec l’activité de la console d’administration pour lever une alerte contextualisée plutôt qu’un simple événement isolé.

Étape 4 — Cloisonner les comptes et les agents

Même compromise, une console RMM ne doit pas offrir un accès uniforme à tout le parc :

• Activez le MFA résistant au phishing (clés FIDO2) sur tous les comptes administrateurs de la console, sans exception de compte de service ;
• Segmentez les groupes d’agents par client et par criticité, avec des rôles distincts : un opérateur de niveau 1 n’a pas besoin d’exécuter des scripts sur les contrôleurs de domaine ;
• Journalisez et exportez vers votre SIEM chaque exécution de script et chaque déploiement de paquet — c’est la seule trace exploitable en cas d’incident.

Étape 5 — Poser la question à votre infogérant

Si votre RMM est opéré par un prestataire, vous héritez de son exposition. Trois questions à lui poser par écrit, dès aujourd’hui :

• Quelle version de la console est en production, et quand le dernier correctif a-t-il été appliqué ?
• La console est-elle joignable depuis Internet, et le MFA est-il actif sur tous les comptes ?
• Quels journaux d’exécution de scripts pouvez-vous nous fournir sur les 90 derniers jours ?

L’absence de réponse claire est en soi un résultat d’audit. Sécuriser un outil RMM est un travail partagé : la console appartient au prestataire, mais le risque, lui, reste chez vous. Traitez votre serveur d’administration à distance comme un contrôleur de domaine — parce que, du point de vue de l’attaquant, c’est exactement ce qu’il est.

Sources

• BleepingComputer — N-able warns of N-central auth bypass flaw exploited in attacks
• Dark Reading — Attackers exploit N-able patch bypass flaw on RMM servers
• HackRead — Hackers exploit N-able N-central flaw, install Cloudflare tunnels
• SecurityWeek — N-able patches vulnerability exploited to hack N-central servers