RDP exposé sur Internet : risques, durcissement et détection

RDP (Remote Desktop Protocol) transporte une session graphique Windows complète à travers le réseau : affichage dans un sens, clavier, souris et périphériques dans l’autre. C’est l’outil d’administration et de télétravail le plus répandu du parc Windows, et pour la même raison l’une des portes d’entrée préférées des opérateurs de rançongiciels. Cette page décrit ce que le protocole fait réellement, ce qu’il ne protège pas, et la seule architecture d’exposition défendable : aucune exposition directe, une passerelle avec MFA (Multi-Factor Authentication) devant, et des postes cibles qui ne gardent pas les identifiants en mémoire.

→ Lire l’explication complète de la marmotte

Fonctionnement de RDP : session graphique, canaux virtuels, TLS et CredSSP

Le service côté serveur s’appelle Remote Desktop Services (anciennement Terminal Services). Il écoute par défaut sur le port TCP (Transmission Control Protocol) 3389 ; depuis la version 8.0 du protocole, un transport UDP (User Datagram Protocol) sur le même port 3389 sert à améliorer la fluidité sur les liens à perte ou à latence élevée, TCP restant le canal de contrôle et de repli. Bloquer UDP 3389 ne coupe donc pas RDP, il le dégrade. Un filtrage qui ne pense qu’à TCP laisse en revanche un second chemin ouvert.

Le protocole multiplexe des canaux virtuels dans la même connexion : affichage, entrées, presse-papiers, redirection de lecteurs (le fameux \\tsclient\C), imprimantes, audio, cartes à puce, ports, périphériques USB (Universal Serial Bus). Chaque canal est un tuyau bidirectionnel entre le client et le serveur, et chaque tuyau est un chemin de données que le pare-feu ne voit pas : tout circule dans le flux chiffré vers 3389.

Le chiffrement repose sur TLS (Transport Layer Security). Par défaut, l’hôte génère un certificat auto-signé. Le client affiche alors un avertissement que les utilisateurs ont appris à ignorer depuis une quinzaine d’années, ce qui transforme le chiffrement en protection contre l’écoute passive uniquement : un intermédiaire actif présente son propre certificat, l’utilisateur clique sur « Oui », et l’interception est faite. Un certificat émis par la PKI (Public Key Infrastructure) interne, avec un nom correspondant à l’hôte, est un prérequis et non une option de confort (voir Construire une autorité de certification privée interne).

L’authentification passe par CredSSP (Credential Security Support Provider), qui négocie Kerberos ou, à défaut, NTLM (NT LAN Manager), à l’intérieur du tunnel TLS. NLA (Network Level Authentication) est le mode qui impose cette authentification avant la création de la session graphique. Sans NLA, le serveur alloue une session et affiche l’écran d’ouverture Windows à n’importe qui ; avec NLA, rien n’est alloué tant que l’utilisateur n’a pas prouvé son identité.

L’ordre des opérations avec NLA activée :

La ligne qui compte est l’avant-dernière : en mode standard, CredSSP délègue les identifiants au serveur, qui ouvre une session interactive et garde de quoi s’authentifier ailleurs au nom de l’utilisateur. Tout le chapitre sur les risques internes découle de ce choix de conception.

Côté prérequis : l’hôte doit être une édition Windows qui accepte les connexions entrantes (Pro, Entreprise, Server ; l’édition Famille ne peut être que client). Windows Server autorise deux sessions administratives simultanées sans licences ; au-delà, il faut le rôle Remote Desktop Session Host et des licences d’accès client RDS (Remote Desktop Services). NLA exige un client récent qui sait parler CredSSP, ce qui exclut de fait les clients antiques qu’on garde « pour une appli ».

RDP exposé sur Internet, porte d’entrée des rançongiciels

Un port 3389 joignable depuis Internet est découvert en quelques heures. Des moteurs d’indexation et des botnets balaient l’intégralité de l’espace IPv4 en permanence ; changer le port pour 33890 retire le serveur des scans les plus paresseux et de rien d’autre, puisque la négociation RDP se reconnaît sur n’importe quel port. Le « port non standard » reste une mesure de réduction du bruit dans les journaux, pas une mesure de sécurité.

Trois vecteurs dominent :

Force brute et pulvérisation de mots de passe : peu de tentatives par compte, beaucoup de comptes, pour passer sous les seuils de verrouillage. NLA ne bloque pas cette attaque, elle la déplace avant l’ouverture de session.
Réutilisation d’identifiants : les combinaisons issues de fuites ou de voleurs d’informations (infostealers) sur les postes personnels sont testées directement. Un mot de passe complexe réutilisé ne vaut rien.
Revente d’accès : un RDP fonctionnel avec un compte valide est une marchandise. Les courtiers d’accès initial les collectent et les revendent à des opérateurs de rançongiciels, qui n’ont plus qu’à se connecter. Le délai entre l’intrusion et le chiffrement peut donc être long, et l’acheteur n’est pas celui qui a forcé la porte.

Vingt ans de métier apprennent que le RDP exposé « temporairement, pour le prestataire » survit en général à la relation commerciale avec le prestataire.

Reste la vulnérabilité pré-authentification, le cas où même un mot de passe parfait ne sert à rien. BlueKeep (CVE-2019-0708, CVE pour Common Vulnerabilities and Exposures) est l’exemple de référence : une exécution de code à distance dans Remote Desktop Services, exploitable sans authentification, donc propageable de machine en machine sans intervention. Elle touchait les anciennes versions de Windows (notamment Windows 7 et Windows Server 2008 et 2008 R2) et Microsoft a publié en 2019 des correctifs jusque pour des systèmes déjà hors support. Microsoft a indiqué que NLA constituait une atténuation partielle : l’attaquant doit s’authentifier avant d’atteindre le code vulnérable, ce qui ramène le problème à un vol d’identifiants. La leçon d’architecture dépasse cette CVE : tout service joignable avant authentification hérite de chaque future faille pré-authentification de son code, et c’est précisément ce qu’une passerelle évite d’exposer.

Risques internes : mouvement latéral, identifiants en mémoire, détournement de session

Une fois dans le réseau, RDP devient le véhicule naturel du mouvement latéral : il est autorisé partout, ses connexions ressemblent à de l’administration légitime, et il donne une session interactive complète avec les outils graphiques de la machine cible.

Identifiants laissés en mémoire. En mode standard, la délégation CredSSP produit une ouverture de session interactive sur la cible. Le processus LSASS (Local Security Authority Subsystem Service) y conserve des éléments d’authentification réutilisables (empreintes NT, tickets Kerberos) pendant la durée de la session et parfois au-delà. Un attaquant administrateur local de cette cible les extrait et rebondit. Le schéma classique : un administrateur de domaine ouvre un RDP sur un serveur applicatif compromis, et le domaine tombe avec lui. La règle qui en découle : un compte à privilèges ne s’authentifie jamais de façon interactive sur une machine d’un niveau de confiance inférieur (voir PAM, JIT et comptes break-glass).

Détournement de session. Un compte disposant des droits SYSTEM sur un hôte peut rattacher à sa console une session RDP déconnectée d’un autre utilisateur, sans connaître son mot de passe. Les sessions « déconnectées mais pas fermées », laissées par confort pendant des jours, sont donc des sessions privilégiées en libre service pour quiconque contrôle l’hôte. Contre-mesure : stratégies de limite de temps pour les sessions déconnectées et inactives, et fermeture systématique.

Canaux virtuels détournés. Le presse-papiers et la redirection de lecteurs servent à exfiltrer (copier un fichier depuis le serveur vers le poste client) et, en sens inverse, à déposer des outils. Le sens inverse existe aussi : un serveur malveillant ou compromis voit les lecteurs redirigés du client et le contenu du presse-papiers. Se connecter à une machine douteuse avec C: redirigé revient à lui tendre son disque.

Restricted Admin et Remote Credential Guard

Deux modes suppriment la délégation des identifiants à la cible. Ils ne règlent pas le même problème.

Critère	Restricted Admin	Remote Credential Guard
Identifiants envoyés à la cible	Non	Non
Accès réseau depuis la session	Au nom du compte machine de la cible	Au nom de l’utilisateur, requêtes Kerberos renvoyées vers le client
Protocole requis	Kerberos ou NTLM	Kerberos uniquement
Droits requis sur la cible	Administrateur local	Utilisateur autorisé RDP
Effet de bord connu	Permet l’authentification RDP avec une empreinte NT seule (pass-the-hash)	Ne protège pas si le poste client est compromis
Option du client `mstsc`	`/restrictedAdmin`	`/remoteGuard`

Restricted Admin protège l’identifiant de l’administrateur mais ouvre la porte à l’authentification RDP par empreinte : son activation sans réflexion échange un risque contre un autre, sans que l’un soit franchement préférable. Remote Credential Guard est le choix par défaut pour l’administration en domaine (client et serveur à partir de Windows 10 1607 et Windows Server 2016, joints au même domaine ou à des domaines approuvés) : les tickets restent côté client, la session garde l’authentification unique vers les ressources réseau. Ce que ni l’un ni l’autre ne garantit : pendant que la session est ouverte, un attaquant présent sur la cible agit dans cette session. Ces modes empêchent le vol durable d’identifiants, pas l’abus de la session en cours. La protection du poste client, enfin, devient critique : avec Remote Credential Guard, c’est lui qui détient les secrets. D’où le poste d’administration dédié, et non le portable bureautique qui lit aussi les pièces jointes.

Durcissement RDP : passerelle RD Gateway, VPN, bastion et MFA

Le compromis central tient en une phrase : RDP donne un accès graphique complet avec un effort de déploiement nul, et ce confort se paie par un service authentifié par mot de passe, riche en canaux, qui délègue des identifiants à la cible. On ne durcit pas RDP en le rendant moins pratique au hasard ; on retire l’exposition, on ajoute un facteur d’authentification avant lui, et on coupe la délégation. Position assumée : RDP n’est jamais joignable directement depuis Internet, sans exception pour « un seul serveur » ni pour « juste le temps du projet ».

La comparaison qui justifie cette position :

À y lire : dans le premier cas, chaque serveur exposé est sa propre surface d’attaque, authentifiée par un seul secret ; dans le second, la surface se réduit à un composant unique qui impose le second facteur et décide quelles cibles sont joignables.

Trois architectures tiennent la route, avec leur question de choix :

RD Gateway, la passerelle RD (Remote Desktop), encapsule RDP dans HTTPS sur le port 443 (et un transport UDP optionnel sur 3391). L’authentification et les stratégies d’autorisation de connexion et de ressource se font sur la passerelle ; le MFA s’y greffe par une extension NPS (Network Policy Server) ou un fournisseur tiers. À retenir quand la population est large (télétravail sur postes fixes du bureau).
VPN (Virtual Private Network) avec MFA, puis RDP en interne : le VPN amène l’utilisateur dans un segment réseau, la passerelle ne le fait pas. Défendable seulement si le segment d’arrivée ne voit que les cibles RDP utiles ; un VPN qui débouche sur tout le réseau à plat ne fait que déplacer le 3389 exposé (détails dans VPN, tunnels et bastions).
Bastion ou PAM (Privileged Access Management) : obligatoire pour l’administration à privilèges, car il ajoute l’enregistrement des sessions, la mise à disposition temporaire des comptes et la séparation des cibles. La question de choix entre passerelle et bastion n’est pas technique, elle porte sur la population : utilisateurs métier d’un côté, administrateurs de l’autre, jamais le même chemin.

Sur chaque hôte, quel que soit le chemin d’accès :

NLA obligatoire (stratégie « Exiger l’authentification utilisateur pour les connexions à distance à l’aide de l’authentification au niveau du réseau ») et couche de sécurité TLS imposée, avec certificat issu de la PKI.
Comptes autorisés restreints : le groupe « Utilisateurs du Bureau à distance » ne contient que ce qui est nécessaire ; le droit « Interdire l’ouverture de session par les services Bureau à distance » est appliqué aux comptes à privilèges de domaine sur les serveurs de niveau inférieur et aux comptes de service.
Redirections désactivées par défaut : lecteurs, presse-papiers, imprimantes, ports, USB, puis réouverture au cas par cas. La minimisation de surface s’applique aux canaux virtuels comme aux ports.
Filtrage réseau du 3389 entrant : seules les adresses de la passerelle ou du bastion sont autorisées, sur le pare-feu de l’hôte et sur la segmentation. Sinon, n’importe quel poste compromis parle RDP à n’importe quel serveur, ce qui est la définition même du mouvement latéral.
Verrouillage de compte calibré pour freiner la pulvérisation sans offrir à l’attaquant un déni de service gratuit sur tous les comptes : le verrouillage n’est pas une défense en soi, il complète le MFA, il ne le remplace pas.
Limites de session : déconnexion des sessions inactives, fermeture des sessions déconnectées.

Ce qui ne figure pas dans la liste parce qu’il n’aide pas : changer le port, masquer la bannière, compter sur le chiffrement TLS pour « sécuriser l’accès ». TLS protège le transport, il ne dit rien de qui est autorisé à se connecter.

Exploitation : la passerelle devient le composant le plus exposé du système d’information, donc le premier dans le cycle de correctifs. Les certificats TLS de la passerelle et des hôtes suivent le cycle de renouvellement de la PKI, avec supervision des échéances. Le fournisseur MFA est une dépendance de disponibilité : sans procédure de compte d’urgence (break-glass), documentée, hors MFA tiers, scellée et surveillée, une panne de MFA coupe l’administration au pire moment. La configuration de la passerelle et ses stratégies s’intègrent aux sauvegardes et au plan de reprise.

Détection des connexions RDP : événements Windows et anomalies

Les sources à collecter dans le SIEM (Security Information and Event Management), sur chaque hôte et sur la passerelle :

Journal	Identifiant	Sens
Security	4624, type d’ouverture 10	Ouverture de session interactive à distance (RemoteInteractive)
Security	4625	Échec d’ouverture de session ; avec NLA, l’échec survient à l’étape réseau et apparaît généralement en type 3 et non 10
Security	4778 / 4779	Reconnexion / déconnexion d’une session existante
TerminalServices-RemoteConnectionManager/Operational	1149	Connexion réseau reçue par le service, avec l’adresse source
TerminalServices-LocalSessionManager/Operational	21 / 24 / 25	Ouverture de session / déconnexion / reconnexion

Le piège classique : chercher la force brute dans les 4625 de type 10 alors que NLA les fait apparaître en type 3. Une règle mal écrite sur ce point ne déclenche jamais, et un tableau de bord vide passe facilement pour une bonne nouvelle.

Les anomalies qui méritent une alerte, par ordre de rendement :

Un 4624 de type 10 sur un serveur dont l’adresse source n’est pas la passerelle ou le bastion : contournement du chemin d’accès, donc soit une règle de filtrage manquante, soit un attaquant interne.
Un compte à privilèges de domaine en type 10 sur un serveur de niveau inférieur : violation du modèle de tiering, à traiter comme un incident.
Un même compte qui enchaîne des connexions RDP vers plusieurs hôtes en peu de temps, ou une chaîne de rebonds (A vers B vers C).
Une rafale d’échecs répartie sur de nombreux comptes depuis une même source (pulvérisation).
Des reconnexions (4778) à des sessions d’un autre utilisateur, signal possible de détournement de session.

Pour la corrélation réseau, les flux vers 3389 hors passerelle sont visibles sans agent sur les équipements de filtrage (voir menaces réseau et détection).

Exemple de vérification et d’extraction des connexions RDP

Deux commandes PowerShell, à exécuter en administrateur sur l’hôte. La première vérifie que RDP et NLA sont dans l’état attendu ; la seconde extrait les ouvertures de session RDP réussies du journal Security.

# État du service : fDenyTSConnections = 1 signifie RDP désactivé, 0 activé
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' |
  Select-Object fDenyTSConnections

# NLA : UserAuthentication = 1 signifie NLA exigée sur l'écouteur RDP-Tcp
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
  Select-Object UserAuthentication

# Ouvertures de session à distance réussies (4624, type 10), les 50 plus récentes
Get-WinEvent -LogName Security -MaxEvents 50 `
  -FilterXPath "*[System[EventID=4624] and EventData[Data[@Name='LogonType']='10']]" |
  Select-Object TimeCreated,
    @{n='Compte';e={$_.Properties[5].Value}},
    @{n='Source';e={$_.Properties[18].Value}}

Dans le 4624, l’index 5 correspond au nom du compte cible et l’index 18 à l’adresse réseau source. En exploitation, la commande sert à un contrôle ponctuel ou à valider une règle de collecte ; la détection continue se fait dans le SIEM, sur l’ensemble du parc, avec comparaison de la colonne « Source » à la liste des adresses de passerelle et de bastion. La stratégie de groupe reste la source de vérité de la configuration : une valeur corrigée à la main dans le registre est écrasée au prochain rafraîchissement si la GPO (Group Policy Object) dit le contraire.

FAQ

NLA suffit-elle à exposer RDP sur Internet ?

Non. NLA évite d’allouer une session avant l’authentification et réduit l’exposition aux failles pré-authentification comme BlueKeep, mais l’authentification reste un mot de passe soumis à la force brute et à la réutilisation. Sans second facteur et sans passerelle, le serveur reste un objectif de choix pour les courtiers d’accès.

Faut-il préférer Restricted Admin ou Remote Credential Guard ?

En domaine avec Kerberos, Remote Credential Guard : pas d’identifiants sur la cible, pas d’ouverture au pass-the-hash RDP. Restricted Admin reste une solution de repli pour les cas sans Kerberos, en acceptant qu’une empreinte NT volée suffise alors à ouvrir une session RDP.

Un accès RDP par un service SaaS de prise en main à distance règle-t-il le problème ?

Il remplace un port ouvert par un agent qui sort vers un tiers, avec son propre modèle d’authentification et sa propre surface d’attaque. Le besoin de MFA, de restriction des comptes et de journalisation reste entier ; le service porte simplement une autre étiquette sur la même porte.

🐝 Ce qui arrive si on s’en passe

Sans passerelle ni filtrage du 3389, aucune adresse source n’est légitime par construction. La règle qui compare la source des 4624 de type 10 à la liste des passerelles et bastions n’a donc plus de référence, et une session ouverte avec un compte valide se confond avec de l’administration ordinaire. La trace des accès ne subsiste alors que dans le journal Security de chaque hôte. Un attaquant devenu administrateur local peut l’effacer (événement 1102), la rotation du journal peut l’écraser, et un hôte chiffré emporte ses propres preuves. Retirer l’accès d’un compte ou d’un prestataire oblige à intervenir sur chaque serveur au lieu de modifier une seule stratégie de passerelle ; un serveur oublié reste joignable avec les droits d’avant.

🦫 Explication de la marmotte 🍫

Le bureau à distance permet de piloter un ordinateur Windows depuis un autre. L’ordinateur piloté envoie l’image de son écran ; celui qui pilote renvoie les touches du clavier et les mouvements de souris. Le même lien peut transporter le contenu du copier-coller, les fichiers d’un disque ou l’impression. Tout est chiffré pour qu’on ne puisse pas lire ce qui passe, mais le chiffrement ne dit pas qui a le droit d’entrer.

Avant d’afficher quoi que ce soit, l’ordinateur piloté demande un nom et un mot de passe. Si cet ordinateur est joignable depuis Internet, des programmes automatiques le trouvent vite et essaient des milliers de mots de passe, souvent volés ailleurs. Un accès réussi est ensuite revendu à des criminels qui bloquent les données et réclament une rançon. Parfois, une erreur dans le logiciel permet même d’entrer sans mot de passe.

À l’intérieur de l’entreprise, un autre danger existe : quand un administrateur se connecte, l’ordinateur piloté garde en mémoire de quoi se faire passer pour lui. Si cet ordinateur est déjà piraté, l’attaquant récupère ces informations et passe d’une machine à l’autre.

La protection consiste à ne jamais laisser l’ordinateur directement joignable, à faire passer toutes les connexions par un point d’entrée unique qui exige un second code (sur un téléphone, par exemple), à empêcher la machine de garder les informations de connexion, à couper le copier-coller et le partage de disques inutiles, et à surveiller les journaux qui notent chaque connexion et chaque échec.

Pages voisines

La citent

RDP exposé sur Internet : risques, durcissement et détection

Elle cite

: les deux pages se citent l’une l’autre.

RDP exposé sur Internet : risques, durcissement et détection

RDP exposé sur Internet : risques, durcissement et détection

Fonctionnement de RDP : session graphique, canaux virtuels, TLS et CredSSP

RDP exposé sur Internet, porte d’entrée des rançongiciels

Risques internes : mouvement latéral, identifiants en mémoire, détournement de session

Restricted Admin et Remote Credential Guard

Durcissement RDP : passerelle RD Gateway, VPN, bastion et MFA

Détection des connexions RDP : événements Windows et anomalies

Exemple de vérification et d’extraction des connexions RDP

FAQ

NLA suffit-elle à exposer RDP sur Internet ?

Faut-il préférer Restricted Admin ou Remote Credential Guard ?

Un accès RDP par un service SaaS de prise en main à distance règle-t-il le problème ?

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines