N-able a mis en garde contre une campagne d’intrusion visant sa plateforme N-central de supervision et de gestion à distance. Selon l’éditeur, une attaque par contournement de l’authentification a permis à des acteurs malveillants d’obtenir un accès administratif distant sur des serveurs, puis d’atteindre des systèmes clients gérés via ces infrastructures.
Le point marquant : la première correction fournie par N-able s’est révélée incomplète. L’organisation demande désormais aux clients de mettre à jour tous les environnements concernés vers une version précise et d’effectuer des contrôles supplémentaires sur les endpoints, afin d’éliminer d’éventuelles traces de persistance.
Ce que les attaquants ont fait avec N-central
D’après les informations publiées, les attaquants ont d’abord exploité un problème lié à l’authentification pour obtenir des droits d’administration à distance sur des serveurs N-central. Une fois l’accès obtenu, ils ont pu se déplacer vers les équipements que ces serveurs administraient.
La suite de l’activité s’appuie sur une méthode de prise de contrôle et sur l’utilisation de tunnels. N-able indique que les intrus ont eu recours à une fonctionnalité de Take Control pour atteindre les endpoints, puis ont enregistré des tunnels Cloudflare comme services sur les machines compromis.
Ces tunnels se connectent sortant vers l’infrastructure de Cloudflare. En pratique, cela peut réduire la dépendance à des règles entrantes côté pare-feu, car les flux se font vers l’extérieur. N-able précise aussi qu’exécuter ces tunnels en tant que services aide à conserver l’accès même après un redémarrage.
Pourquoi la première mise à jour n’a pas suffi
N-able explique que son premier correctif était incomplet, ce qui a conduit à l’identification d’un périmètre de versions plus large à corriger. Deux références CVE sont au cœur du sujet.
- CVE-2026-18556 : concerne des versions jusqu’à 2026.1. N-able indique avoir corrigé le chemin d’exploitation associé dans la version 2026.2.
- CVE-2026-18577 : étend l’impact aux builds antérieurs à 2026.3.1.7. L’éditeur dit avoir ensuite découvert une autre manière d’exploiter une faiblesse similaire, non bloquée par le premier correctif.
Sur le plan chronologique, N-able a expédié une version jugée non vulnérable, 2026.3.1.7, le 2 août. L’organisation souligne également qu’une simple montée en version vers 2026.3 n’est plus considérée comme suffisante.
Quelle version installer pour être protégé
La consigne est claire : tous les clients N-central doivent être sur 2026.3.1.7.
Pour les environnements hébergés, N-able indique que des instances NCOD seront mises à jour automatiquement selon un calendrier communiqué directement aux partenaires. Pour les serveurs auto-hébergés, la responsabilité incombe au client : la mise à jour doit être réalisée par leurs soins.
Cette distinction est importante, car elle conditionne le délai réel de remédiation et la capacité à vérifier que l’infrastructure critique a bien été corrigée.
Après la mise à jour : chasse aux tunnels malveillants
Un point souvent sous-estimé dans les incidents de compromission : corriger la faille n’efface pas forcément la persistance déjà installée ailleurs dans l’écosystème.
N-able précise que même après l’upgrade de N-central, des éléments déposés sur d’autres machines peuvent subsister. Concrètement, les clients doivent rechercher et supprimer des services de tunnels malveillants enregistrés sur les endpoints.
En parallèle, si des indicateurs de compromission sont identifiés, N-able recommande d’impliquer les équipes de sécurité et de contacter l’assistance pour guider la remédiation.
Comment repérer une activité non autorisée
N-able et des acteurs de réponse à incident ont partagé plusieurs pistes de recherche. Les éléments ci-dessous ne prouvent pas à eux seuls une intrusion, mais ils peuvent servir de base à une vérification.
Signaux côté serveurs et journaux
Huntress recommande notamment de vérifier le fichier ui_access_control.log et de le recouper avec des journaux Windows situés dans :
C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvc_*.log.gz
À noter : selon Huntress, ces logs peuvent aussi apparaître lors d’un usage légitime de Take Control. Leur présence seule ne suffit donc pas à conclure qu’il y a eu compromission.
Huntress signale également qu’il faut examiner des sessions associées à des identités ressemblant à celles du support N-able, par exemple des adresses telles que mspsupport@n-able.com.
Signaux côté endpoints
Dans ses recommandations, N-able a demandé de surveiller des indicateurs concrets, notamment :
- la présence de svchost.exe dans le dossier Documents d’un utilisateur,
- un service nommé Cloudflared,
- du trafic en provenance des adresses IP publiées.
Si ces éléments sont détectés, N-able conseille de contacter le support et d’engager les équipes de sécurité afin de confirmer l’impact et de nettoyer les composants installés.
Détection via adresses IP et analyse d’acteurs
N-able a publié une liste de six adresses IP observées pendant les attaques. L’objectif est d’aider les équipes à corréler les événements réseau et les journaux applicatifs.
- 173[.]249[.]252[.]200
- 87[.]249[.]138[.]34
- 37[.]19[.]210[.]32
- 37[.]153[.]90[.]88
- 92[.]118[.]112[.]181
- 68[.]235[.]46[.]214
Par la suite, Huntress indique avoir identifié quatre de ces adresses comme des nœuds de sortie appartenant à Mullvad ou NordVPN. L’organisation recommande alors d’effectuer une corrélation avec les traces internes : interface N-central, logs réseau et journaux sur les endpoints.
Comment l’incident a été découvert
N-able affirme avoir commencé à enquêter le 31 juillet, après la réception de volumes inhabituels d’erreurs liées à la licence provenant de clients déployant N-central en local.
L’entreprise indique avoir identifié un acteur ayant obtenu un accès administratif distant sur des serveurs en versions 2026.1 et antérieures. N-able a déclaré avoir contacté un nombre limité de clients impactés, sans divulguer de chiffre précis.
À ce stade, N-able ne fournit pas d’informations complètes sur l’ampleur : nombre exact de clients touchés, identité des victimes, quantité d’équipements atteints, moment exact du début de l’exploitation, ni l’identité des auteurs.
Étendue observée par Huntress
Huntress a d’abord publié, dans une réponse rapide du 3 août, que l’exploitation avait été observée dans une organisation de sa base de clients. Elle avait également mis en avant plusieurs domaines associés aux attaquants.
Par la suite, Huntress a précisé dans un échange avec The Hacker News que l’activité concernait une instance auto-hébergée de N-central au sein d’un compte partenaire. Dans ce contexte, les attaquants auraient accédé à neuf organisations rattachées à ce même compte et auraient atteint un endpoint dans chacune d’elles.
Selon l’analyse disponible, la phase post-compromission aurait été limitée à l’énumération des processus en cours sur les endpoints, avant que les intrus ne se déconnectent. Huntress indique toutefois poursuivre l’examen à la recherche d’autres indicateurs d’activité.
Autre élément : Huntress dit ne pas avoir observé l’installation liée à Cloudflare mentionnée dans la notification initiale de N-able. Elle suggère plutôt que l’abus des fonctionnalités de tunneling de Cloudflare a suffi pour maintenir l’accès, sans que Cloudflare ne soit elle-même compromise.
Contexte des CVE : ce qui est connu (et ce qui ne l’est pas)
Les CVE associées ont été publiées par N-able et chacune affiche une note de 8,2 sur CVSS 4.0. Les descriptions officielles évoquent un contournement d’authentification via un autre chemin ou canal, ce qui correspond à une classe CWE-288 pour la première référence mentionnée.
Cependant, dans les informations disponibles, N-able ne précise ni l’endpoint exact ciblé, ni la séquence exacte des requêtes utilisée pour l’exploitation. L’éditeur n’a pas non plus publié de détail technique au niveau du “root cause” exploitable par des tiers.
Plan d’action recommandé pour les équipes IT
Face à ce scénario, l’approche la plus sûre consiste à combiner correctif et vérification opérationnelle.
- Mettez à jour toutes les installations N-central vers 2026.3.1.7.
- Vérifiez les comportements d’accès et recoupez les journaux, en particulier lorsque Take Control a été utilisé.
- Recherchez la persistance sur les endpoints : services de tunnels et indicateurs fournis (ex. Cloudflared, svchost.exe dans Documents, trafic depuis IP observées).
- Contactez le support et mobilisez l’équipe sécurité si des indices de compromission sont confirmés.
Conclusion
Cette annonce met en lumière un risque concret pour les organisations qui s’appuient sur N-central : une attaque par contournement de l’authentification peut ouvrir la voie à l’accès administratif distant, puis à l’atteinte d’équipements gérés via des tunnels capables de persister.
La priorité reste de passer à 2026.3.1.7, tout en gardant en tête que la mise à jour seule ne suffit pas toujours si des composants malveillants ont été installés sur des endpoints. En combinant migration et chasse aux traces, les équipes IT peuvent réduire fortement le risque de maintien d’accès.
Source: https://thehackernews.com/2026/08/n-able-says-attackers-take-over-n.html
