Un scan du web qui tourne mal pour des milliers d’administrateurs
Les chercheurs de Cyble ont conduit une opération de scan assez basique : interroger le port 5900, port par défaut de VNC, sur l’ensemble des adresses IP accessibles depuis internet. Le résultat est sans ambiguïté — plus de 9 000 instances VNC répondent sans exiger aucun mot de passe. Aucune tentative de force brute, aucun exploit. Juste une connexion directe.
Ce chiffre s’inscrit dans un contexte plus large. En 2026, on dénombre près de 60 000 serveurs VNC exposés sans authentification active sur internet. Parmi eux, 670 donnent accès à des interfaces de contrôle industriel, les systèmes ICS/OT, sans la moindre vérification d’identité. Ce n’est pas une vulnérabilité logicielle à patcher : c’est une absence délibérée, ou négligente, de configuration.
VNC sans mot de passe : ce que ça veut dire concrètement
VNC (Virtual Network Computing) est un protocole de prise en main à distance. Il transmet l’affichage d’un bureau distant et retransmet les actions clavier et souris de l’utilisateur connecté. Quand l’authentification est désactivée, n’importe qui connaissant l’adresse IP et le port peut prendre le contrôle du bureau en quelques secondes.
Ce que voit un attaquant en se connectant : l’écran actif de la machine distante, les applications ouvertes, les fichiers accessibles, les navigateurs avec leurs sessions en cours, les outils métier lancés. Si la machine est sur un réseau d’entreprise, il voit également l’arborescence réseau disponible depuis ce poste. Aucun identifiant, aucun code à deux facteurs, aucun journal d’accès côté client dans les configurations minimales.
Chine, Suède, États-Unis : la répartition géographique n’est pas anodine
Le top 5 des pays avec le plus d’instances VNC non protégées rassemble la Chine, la Suède, les États-Unis, l’Espagne et le Brésil. Cette distribution reflète davantage la densité d’hébergement et les pratiques de déploiement que des lacunes propres à chaque pays.
La Chine et les États-Unis concentrent une part massive de l’infrastructure serveur mondiale, ce qui mécaniquement augmente leur exposition statistique. La présence de la Suède s’explique en partie par son rôle d’hébergeur neutre historique, avec de nombreux serveurs déployés par des tiers étrangers. Dans tous ces pays, la cause commune reste la même : des configurations par défaut jamais modifiées, souvent sur des machines déployées à la hâte pour un besoin ponctuel.
Ce que la géographie ne dit pas, en revanche, c’est la nature des organisations concernées. Un serveur VNC ouvert hébergé en Suède peut très bien appartenir à une PME française ou à une ONG d’Amérique centrale ayant loué un VPS sans s’occuper de sa sécurisation.
Quand l’écran partagé donne accès à une station de traitement d’eau
Les 670 instances donnant accès direct à des panneaux ICS/OT sont le point le plus préoccupant de ce rapport. Parmi les environnements identifiés figurent des stations de traitement d’eau, des installations de production industrielle et des sites de recherche. Ces systèmes partagent plusieurs caractéristiques qui aggravent le risque.
D’abord, les environnements OT fonctionnent souvent sur des systèmes d’exploitation non maintenus — Windows XP, Windows 7 — parce que les équipements industriels qu’ils pilotent n’ont jamais été recertifiés pour des versions plus récentes. Ensuite, les équipes qui les opèrent sont des ingénieurs de process, des techniciens de maintenance, rarement des spécialistes en cybersécurité. Enfin, une intrusion dans ces systèmes ne se limite pas à une fuite de données : elle peut se traduire par une action physique réelle sur un équipement, une vanne, une pompe, un automate.
Ce type d’exposition a déjà alimenté des incidents documentés. En 2021, un attaquant avait accédé au système de traitement d’eau d’Oldsmar, en Floride, via un logiciel de prise en main à distance pour tenter de modifier le taux de soude caustique. Le vecteur d’entrée était comparable à ce que ces 670 instances offrent aujourd’hui, librement.
De l’accès VNC au réseau interne : le chemin est court
Un serveur VNC exposé est rarement la cible finale. Pour un attaquant, c’est une tête de pont. Une fois connecté au bureau distant, il dispose d’un poste actif sur le réseau local de l’organisation. À partir de là, les options sont nombreuses : scan du réseau interne, accès aux partages de fichiers, tentatives d’authentification sur d’autres services avec les identifiants récupérés sur la machine compromise.
Le mouvement latéral depuis un poste VNC non protégé suit exactement les mêmes mécaniques qu’une intrusion classique — à la différence que l’accès initial n’a requis ni phishing, ni exploit, ni credential stuffing. Des outils comme Mimikatz peuvent extraire des hachages de mots de passe directement depuis la mémoire du système, ouvrant la voie à une élévation de privilèges. C’est le même enchaînement que celui observé dans des attaques par ransomware utilisant le bureau à distance comme point d’entrée, un schéma bien documenté par plusieurs rapports CISA ces dernières années.
Les équipes qui n’ont pas de visibilité sur leur propre surface d’exposition — ce qui est le cas d’une majorité des structures touchées — ne détectent souvent rien pendant des semaines ou des mois. La faille PrintNightmare avait déjà montré qu’un service exposé par défaut, considéré comme bénin par les équipes IT, pouvait devenir un vecteur d’élévation de privilèges à l’échelle d’un domaine entier.
Pourquoi ces serveurs sont encore là, ouverts, en 2026
La réponse tient rarement à de la malveillance ou de l’incompétence flagrante. Elle tient à des logiques organisationnelles très ordinaires. VNC a été installé pour dépanner un poste à distance un soir de panne, personne ne l’a désinstallé ensuite. Ou bien l’accès a été ouvert pour un prestataire externe, le contrat s’est terminé, le port est resté ouvert.
Dans les petites structures, la gestion du parc repose souvent sur une seule personne, débordée, qui n’a pas les outils pour auditer ce qui écoute sur quels ports. Dans les environnements industriels, le principe implicite est « si ça tourne, on ne touche à rien ». Un serveur VNC configuré il y a huit ans sur une machine de supervision n’est jamais repassé sous le radar d’un audit.
La configuration par défaut de certains logiciels VNC n’aide pas non plus. Plusieurs implémentations historiques démarrent sans authentification activée, laissant à l’administrateur la responsabilité de l’activer manuellement. Quand le déploiement est fait vite, cette étape saute. C’est la même mécanique qui produit des bases de données MongoDB ou Elasticsearch exposées sans mot de passe — un défaut par facilité qui persiste parce que personne ne revient vérifier.
Ce qu’un administrateur doit faire dans les prochaines heures
La priorité est d’établir ce qui écoute sur votre réseau avant qu’un scan externe ne le fasse à votre place. Voici les actions concrètes à conduire :
- Vérifier l’exposition externe via Shodan (shodan.io) en cherchant votre plage d’adresses IP publiques avec le filtre
port:5900. Ce que Shodan voit, un attaquant le voit aussi. - Activer l’authentification sur chaque instance VNC identifiée. Sur RealVNC, TigerVNC ou UltraVNC, l’option est explicite dans les paramètres de sécurité. Un mot de passe fort, minimum 12 caractères.
- Restreindre l’accès au port 5900 par pare-feu. Si VNC est nécessaire, l’accès doit être limité à des adresses IP précises ou conditionné à une connexion VPN active. Aucun service de bureau à distance n’a de raison légitime d’être exposé directement à internet sans filtrage préalable.
- Auditer les installations présentes sur le réseau interne. Un scan Nmap sur le port 5900 en interne révèle souvent des instances oubliées sur des postes utilisateurs ou des serveurs legacy. L’outil d’Assistance Rapide Windows bloqué via Intune illustre bien la logique à appliquer : si un canal d’accès à distance n’est pas activement géré, il se bloque ou se contrôle, pas laissé à la discrétion de chaque poste.
- Désinstaller VNC quand il n’est plus utilisé. Un service fermé ne peut pas être compromis. Sur les machines de production industrielle, envisager le remplacement par une solution d’accès à distance avec authentification multifacteur et journalisation des sessions.
Un dernier point : si vous gérez des systèmes OT ou ICS, ces machines ne doivent jamais être directement accessibles depuis internet, quel que soit le protocole. Une architecture en DMZ avec rebond sécurisé est le minimum. Neuf mille portes ouvertes sur internet, dont certaines donnent sur des automates industriels, c’est le résultat de l’absence de cette règle de base.