On ne se fait pas compromettre par un magicien. On se fait compromettre par un port RDP exposé à Internet, un mot de passe administrateur local périmé, et des logs que personne ne regarde avant que l’assureur ne les réclame.
RDP reste l’outil d’accès à distance le plus utilisé dans de nombreuses infrastructures Windows. C’est aussi l’un des aimants à attaques les plus bruyants sur Internet public. La bonne nouvelle : vous pouvez empêcher la plupart des attaques RDP avec un référentiel qui soit ennuyeux, strict et mesurable. Et si vous le faites correctement, vous dormirez mieux — et votre téléphone d’astreinte cessera de sonner « nouvelle vague de credential stuffing ».
Le modèle de menace (ce qui vous attaque réellement)
Soyons honnêtes sur l’apparence des « attaques RDP » en production :
- Scan massif + brute force : Des scans automatisés repèrent TCP/3389 (ou votre « port alternatif malin ») et essaient des noms d’utilisateur courants et des mots de passe divulgués. C’est l’essentiel du bruit de commodité.
- Spray de mots de passe : Tentatives lentes et réparties sur de nombreux comptes pour éviter les verrouillages. C’est ce qui touche les organisations avec des politiques faibles et sans MFA.
- Rejeu d’identifiants : Identifiants valides issus de phishing, malware ou fuites précédentes. Avec RDP, un seul identifiant fonctionnel suffit souvent pour obtenir une base.
- Collecte de mauvaises configurations : NLA désactivé, paramètres TLS anciens, mauvaises pratiques d’admin local, règles de pare-feu entrantes larges, accès « temporaire » fournisseur devenu permanent.
- Escalade post-authentification : Une fois à l’intérieur, ils dumpent des identifiants, pivotent latéralement, désactivent l’EDR et commencent à chiffrer. RDP n’est que la porte d’entrée ; la maison a encore besoin de serrures internes.
Le référentiel de cet article cible la partie qui cause la majorité des incidents RDP : exposition à Internet + authentification faible + politiques faibles + absence de surveillance. Ça représente 80 %. Les 20 % restants, c’est ce qui occupe les équipes sécurité.
Faits intéressants et contexte historique (parce que les schémas se répètent)
- RDP existe depuis la fin des années 1990 (ère Windows NT 4.0 Terminal Server Edition), assez longtemps pour que chaque attaquant et chaque défenseur en ait la mémoire musculaire.
- TCP/3389 est devenu « le nouveau 22 » pour les environnements Windows : un port d’administration à distance par défaut scanné en continu par des bots, quel que soit votre secteur.
- NLA (Network Level Authentication) a été introduit pour réduire la surface d’attaque pré-authentification en exigeant l’authentification avant la création complète d’une session.
- Le credential stuffing est devenu courant une fois que les dumps de mots de passe sont devenus routiniers et que les utilisateurs réutilisent des mots de passe. RDP profite directement de cette mauvaise habitude.
- BlueKeep (CVE-2019-0708) a été un électrochoc : des vulnérabilités RDP pré-authentification peuvent être wormables. Même si vous avez patché, vous avez compris que « RDP exposé » est un choix de vie.
- RD Gateway existe parce que les entreprises ont appris que le RDP direct depuis Internet génère des incidents, ce n’est pas une stratégie d’accès.
- Les ID d’événements Windows pour la télémétrie de connexion sont stables depuis des années (par ex. 4624/4625), ce qui est positif : votre détection et réponse ne devraient pas dépendre de la nouveauté.
- Les politiques de verrouillage de compte existaient bien avant le MFA moderne, mais les attaquants se sont adaptés avec le password spraying. C’est pourquoi les verrouillages sont nécessaires mais pas suffisants.
- Les référentiels de sécurité se sont professionnalisés (Microsoft security baselines, CIS Benchmarks) parce que le « savoir tribal des administrateurs » ne scale pas — et échoue lors des audits.
Le référentiel : les quelques décisions qui écrasent la plupart des attaques RDP
Voici la partie opinionnée. Vous voulez réduire votre surface d’attaque, rendre l’authentification coûteuse pour les attaquants et rendre les abus évidents dans les logs. Faites ces étapes, dans l’ordre.
1) Cesser d’exposer RDP sur Internet public
Si vous ne faites qu’une chose, faites celle-ci. Le RDP entrant direct depuis Internet, c’est comme laisser la porte du hall ouverte parce que la réceptionniste « est habituellement là ».
Choisissez l’un de ces modèles :
- VPN + RDP restreint : Autoriser RDP uniquement depuis l’espace d’adresses VPN. Propre, commun, efficace.
- RD Gateway : Terminer du HTTPS à l’extérieur ; RDP est proxifié. Mieux pour l’accès géré, la politique et l’audit.
- Postes d’accès privilégiés (PAW) + bastion : Les administrateurs RDP uniquement depuis un poste contrôlé vers un jump box, puis vers l’intérieur. C’est agaçant. Correct.
- Accès distant basé sur SSO : Si vous l’avez, tant mieux. Restreignez néanmoins le RDP entrant au pare-feu.
Ce qu’il ne faut pas faire : « Nous avons changé le port de 3389 à 53389. » Ce n’est pas de la sécurité ; cela ne fait que pousser les bots à faire un scan SYN de plus.
2) Exiger NLA et TLS moderne
NLA réduit la surface RDP pré-authentification et coupe certaines classes d’abus. Combinez-le avec une configuration TLS moderne pour ne pas négocier de la cryptographie d’époque par nostalgie.
Et aussi : désactiver « Allow connections only from computers running Remote Desktop with Network Level Authentication » seulement si vous aimez vous expliquer pendant l’analyse d’incident. Vous n’en avez pas envie.
3) Imposer MFA pour les cheminements d’administration à distance
RDP en soi n’active pas magiquement le MFA. Vous imposez le MFA via le chemin d’accès :
- VPN avec MFA
- RD Gateway avec intégration MFA
- Accès conditionnel / conformité des appareils quand applicable
Le MFA ne résoudra pas une segmentation catastrophique, mais il arrête un nombre décourageant d’incidents « l’identifiant a fonctionné, c’est fini ».
4) Utiliser une politique de comptes robuste : verrouillage, longueur de mot de passe et pas d’admin partagé
L’administrateur local partagé entre serveurs reste douloureusement courant. C’est aussi la façon dont une machine compromise devient quarante. Utilisez LAPS/Windows LAPS pour que chaque machine ait un mot de passe administrateur local unique.
Fixez des seuils de verrouillage sensés. Mais comprenez le compromis : les verrouillages peuvent devenir un vecteur de déni de service si vous avez beaucoup d’exposition publique (autre raison d’éliminer l’exposition publique).
5) Restreindre qui peut RDP (et supprimer les autres)
Ne laissez pas « Domain Users » ou des groupes larges RDP. Utilisez un groupe dédié, principe du moindre privilège, et gardez-le petit. Si vous avez besoin d’accès fournisseur, créez un groupe fournisseur spécifique, avec accès limité dans le temps, et auditez-le sérieusement.
6) Durcir l’endpoint : Defender/EDR, patching et réduction des mouvements latéraux
Les attaques RDP sont souvent juste le début. Une fois un hôte accédé, les attaquants cherchent à escalader et pivoter. Rendez cela difficile :
- Patcher régulièrement (surtout les composants RDP et la pile d’auth Windows)
- Désactiver les protocoles anciens (là où c’est faisable)
- Bloquer SMB entrant depuis des segments non fiables
- Utiliser des règles Windows Firewall explicites et limitées
7) Logger comme si vous en aurez besoin à 3h du matin
Un RDP sans journalisation est une maison hantée : vous entendez des pas, mais vous ne pouvez rien prouver. Collectez :
- Événements de connexion de sécurité (succès/échec, type de logon, IP source)
- Journaux TerminalServices RemoteConnectionManager et LocalSessionManager
- Journaux pare-feu (au minimum en périphérie ; de préférence aussi au niveau des hôtes)
Une citation à afficher sur chaque mur d’équipe ops :
« L’espoir n’est pas une stratégie. » — Gene Kranz
Blague n°1 : Changer le port RDP, c’est comme coller une fausse moustache sur votre serveur et l’appeler « StealthHost01 ». Internet n’est pas dupe.
Tâches pratiques (commandes, sorties et ce que vous décidez)
Ces commandes sont conçues pour être exécutables sur Windows (localement ou via gestion à distance). Le label du prompt de commande est juste une convention de shell — ne vous en faites pas trop.
Tâche 1 : RDP est-il activé sur cet hôte ?
cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
fDenyTSConnections REG_DWORD 0x0
Ce que signifie la sortie : 0x0 signifie que les connexions RDP sont autorisées. 0x1 signifie refusées.
Décision : Si cette machine n’a pas de raison métier d’avoir RDP, mettez-la en refus et supprimez toutes règles de pare-feu entrantes. Si elle en a, poursuivez le durcissement.
Tâche 2 : NLA est-il requis ?
cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
UserAuthentication REG_DWORD 0x1
Ce que signifie la sortie : 0x1 indique généralement que NLA est requis. 0x0 signifie non requis.
Décision : Si 0x0, activez NLA sauf si vous avez un client legacy spécifique — et si c’est le cas, corrigez ce besoin. Ne l’entérinez pas.
Tâche 3 : Sur quel port RDP écoute-t-il (et est-il ouvert) ?
cr0x@server:~$ netstat -ano | findstr ":3389"
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1148
TCP [::]:3389 [::]:0 LISTENING 1148
Ce que signifie la sortie : L’hôte écoute sur 3389 sur toutes les interfaces ; le PID 1148 possède le socket.
Décision : Si l’hôte écoute sur une interface publique, vous devez restreindre les chemins réseau entrants (VPN/RD Gateway/pare-feu de périmètre) et les règles du pare-feu hôte. « On va le surveiller » n’est pas un contrôle.
Tâche 4 : Confirmer la posture des règles entrantes du Windows Firewall pour RDP
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter | Select-Object Name,RemoteAddress"
Name RemoteAddress
---- -------------
RemoteDesktop-UserMode-In-TCP Any
RemoteDesktop-UserMode-In-UDP Any
Ce que signifie la sortie : Les règles RDP intégrées autorisent depuis Any. C’est le réglage de commodité par défaut, pas un réglage de sécurité.
Décision : Changez RemoteAddress pour vos sous-réseaux VPN ou IP de jump host. Si vous ne pouvez pas articuler les plages sources autorisées, vous n’êtes pas prêt à autoriser RDP.
Tâche 5 : Restreindre RDP aux sous-réseaux source connus (pare-feu hôte)
cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'Remote Desktop - User Mode (TCP-In)' -RemoteAddress 10.8.0.0/24,10.9.0.0/24; Get-NetFirewallRule -DisplayName 'Remote Desktop - User Mode (TCP-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
RemoteAddress
-------------
{10.8.0.0/24, 10.9.0.0/24}
Ce que signifie la sortie : Seuls les clients dans ces sous-réseaux peuvent atteindre RDP TCP.
Décision : Si vous ne pouvez pas restreindre aux sources connues, vous ne devriez pas exposer RDP. Mettez en place VPN ou RD Gateway d’abord.
Tâche 6 : Vérifier qui est autorisé à se connecter via RDP
cr0x@server:~$ powershell -NoProfile -Command "Get-LocalGroupMember -Group 'Remote Desktop Users' | Select-Object Name,ObjectClass"
Name ObjectClass
---- ----------
CONTOSO\IT-RemoteAdmins Group
Ce que signifie la sortie : Seul le groupe spécifié figure dans le groupe local « Remote Desktop Users ».
Décision : Si vous voyez des groupes larges ou des utilisateurs ajoutés à la volée, resserrez. Utilisez des groupes dédiés. Supprimez les exceptions créées parce que quelqu’un ne voulait pas faire une demande d’accès.
Tâche 7 : Vérifier la politique de verrouillage des comptes (domaine ou local)
cr0x@server:~$ net accounts
Force user logoff how long after time expires?: Never
Minimum password age (days): 1
Maximum password age (days): 90
Minimum password length: 14
Length of password history maintained: 24
Lockout threshold: 10
Lockout duration (minutes): 15
Lockout observation window (minutes): 15
Ce que signifie la sortie : La longueur de mot de passe, l’historique et les paramètres de verrouillage sont visibles. Ils peuvent être remplacés par une stratégie de domaine.
Décision : Si le seuil de verrouillage est 0 (jamais verrouiller) ou si la longueur de mot de passe est courte, corrigez la politique. Si vous êtes exposé à Internet, corrigez aussi l’exposition — les verrouillages seuls sont un pansement.
Tâche 8 : Vérifier la politique d’audit pour les événements de connexion
cr0x@server:~$ auditpol /get /subcategory:"Logon"
System audit policy
Category/Subcategory Setting
Logon Success and Failure
Ce que signifie la sortie : Les événements de connexion sont enregistrés pour les succès et les échecs.
Décision : Si ce n’est pas « Success and Failure », activez-le. Vous ne pouvez pas enquêter sur ce que vous n’avez pas logué.
Tâche 9 : Identifier les échecs de connexion RDP dans le journal de sécurité (50 derniers)
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Select-Object TimeCreated,@{n='User';e={$_.Properties[5].Value}},@{n='Ip';e={$_.Properties[19].Value}} | Format-Table -Auto"
TimeCreated User Ip
----------- ---- --
1/28/2026 2:11:05 AM Administrator 203.0.113.44
1/28/2026 2:10:58 AM admin 203.0.113.44
1/28/2026 2:10:52 AM test 203.0.113.44
1/28/2026 2:10:45 AM svc_backup 203.0.113.44
1/28/2026 2:10:39 AM user 203.0.113.44
Ce que signifie la sortie : L’ID d’événement 4625 montre les échecs de connexion ; l’IP indique la source. Voir des IP publiques ici est un signe si vous aviez prévu que RDP soit privé.
Décision : Si les sources ne sont pas vos plages VPN/jump, votre histoire de pare-feu est fausse. Bloquez en périphérie et sur l’hôte. Puis chassez toute connexion réussie depuis la même source.
Tâche 10 : Trouver les connexions RDP réussies (Logon Type 10) dans le journal de sécurité
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20 | Where-Object { $_.Properties[8].Value -eq 10 } | Select-Object TimeCreated,@{n='Account';e={$_.Properties[5].Value}},@{n='Ip';e={$_.Properties[18].Value}} | Format-Table -Auto"
TimeCreated Account Ip
----------- ------- --
1/27/2026 9:14:22 PM CONTOSO\j.smith 10.8.0.24
Ce que signifie la sortie : Le Logon Type 10 indique typiquement RemoteInteractive (RDP). L’IP source doit être votre chemin de gestion attendu.
Décision : Toute connexion RDP réussie depuis une IP inattendue est un incident jusqu’à preuve du contraire. Contenez d’abord, débattez après.
Tâche 11 : Vérifier les journaux opérationnels TerminalServices pour les tentatives de connexion
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-List"
TimeCreated : 1/28/2026 2:12:01 AM
Id : 1149
Message : Remote Desktop Services: User authentication succeeded: CONTOSO\j.smith
TimeCreated : 1/28/2026 2:11:55 AM
Id : 1149
Message : Remote Desktop Services: User authentication succeeded: CONTOSO\it-admin
Ce que signifie la sortie : Ces journaux aident à corréler les événements d’authentification RDP avec le comportement de session ; ils sont utiles lorsque les journaux de sécurité sont bruyants.
Décision : Si ce journal est désactivé ou non collecté centralement, corrigez cela. C’est un signal peu coûteux.
Tâche 12 : Valider l’état du service RDP
cr0x@server:~$ sc query TermService
SERVICE_NAME: TermService
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
Ce que signifie la sortie : Remote Desktop Services est en cours d’exécution. S’il tourne sur des machines qui ne devraient pas accepter le RDP, c’est de la dérive.
Décision : Pour les endpoints/serveurs non-administratifs, envisagez de désactiver le service RDP et retirer les permissions plutôt que de le laisser « disponible au cas où ».
Tâche 13 : Confirmer que vous n’acceptez pas des couches de sécurité RDP anciennes et faibles
cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
SecurityLayer REG_DWORD 0x2
Ce que signifie la sortie : Les valeurs diffèrent selon la configuration ; en général, vous voulez TLS et non un repli sur « RDP Security Layer ». (La correspondance exacte peut varier selon la build et la politique.)
Décision : Si vous voyez des paramètres autorisant le repli vers des couches de sécurité plus faibles, imposez TLS-only via la politique et supprimez les exceptions. Les exceptions font que la « compatibilité temporaire » devient une « exposition permanente ».
Tâche 14 : Vérifier la journalisation du Windows Defender Firewall (visibilité hôte)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name,LogAllowed,LogBlocked,LogFileName | Format-Table -Auto"
Name LogAllowed LogBlocked LogFileName
---- ---------- ---------- -----------
Domain False True %systemroot%\system32\logfiles\firewall\pfirewall.log
Private False True %systemroot%\system32\logfiles\firewall\pfirewall.log
Public False True %systemroot%\system32\logfiles\firewall\pfirewall\pfirewall.log
Ce que signifie la sortie : Les connexions bloquées sont journalisées. Les connexions autorisées ne le sont pas (souvent acceptable ; tout logger peut être bruyant).
Décision : Si vous dépannez une exposition ou des attaques, la journalisation des blocs aide à valider que les règles fonctionnent. Si les logs ne sont activés nulle part, vous dépannez à l’aveugle.
Tâche 15 : Vérifier l’exposition entrante sur 3389 en périphérie depuis un jump Linux (vue externe)
cr0x@server:~$ nmap -Pn -p 3389 198.51.100.10
Starting Nmap 7.80 ( https://nmap.org ) at 2026-01-28 02:14 UTC
Nmap scan report for 198.51.100.10
Host is up (0.020s latency).
PORT STATE SERVICE
3389/tcp open ms-wbt-server
Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds
Ce que signifie la sortie : L’hôte est joignable sur 3389 depuis l’endroit où vous avez lancé ce scan. Si cet endroit est Internet public ou un réseau non fiable, vous avez un problème.
Décision : Fermez-le au pare-feu de périmètre. Ne comptez pas uniquement sur le pare-feu de l’hôte. La défense en profondeur n’est pas un slogan ; c’est votre futur timeline d’incident.
Tâche 16 : Énumérer les sessions RDP actives (qui est connecté ?)
cr0x@server:~$ quser
USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME
j.smith rdp-tcp#12 2 Active . 1/27/2026 9:14 PM
it-admin rdp-tcp#13 3 Disc 8 1/28/2026 1:58 AM
Ce que signifie la sortie : Vous voyez les sessions actives et déconnectées. Les sessions déconnectées peuvent persister et être exploitées si vous ne les gérez pas.
Décision : Si vous voyez des administrateurs inattendus ou des sessions déconnectées de longue durée, enquêtez et envisagez des durées d’inactivité et des politiques « déconnecter les sessions déconnectées ».
Tâche 17 : Confirmer que la machine n’est pas en profil réseau « Public » (courant dans les images cloud)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias,NetworkCategory"
InterfaceAlias NetworkCategory
-------------- ---------------
Ethernet0 DomainAuthenticated
Ce que signifie la sortie : DomainAuthenticated signifie généralement que les stratégies de domaine s’appliquent et que les profils de pare-feu sont appropriés.
Décision : Si c’est Public de manière inattendue, corrigez l’identification réseau et l’application du profil pare-feu ; vous pourriez manquer des GPO de domaine ou appliquer les mauvaises règles.
Blague n°2 : Mettre RDP sur Internet ouvert, c’est l’équivalent sécurité de « on va garder les mots de passe dans un spreadsheet, mais c’est un onglet caché. » Les attaquants adorent les onglets cachés.
Trois mini-récits d’entreprise depuis le terrain
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
L’entreprise avait migré un ensemble de serveurs Windows dans un VPC cloud. L’équipe réseau jurait que « rien n’est public sauf si on le rend explicitement public ». Hypothèse raisonnable. Mais fausse en pratique.
Une équipe projet avait besoin qu’un fournisseur fasse une installation ponctuelle sur un serveur d’application legacy. Quelqu’un a ajouté une règle entrante temporaire dans un security group pour autoriser TCP/3389 « depuis la plage IP du fournisseur ». Cette plage était plus large que tout le monde ne le réalisait — parce que le fournisseur utilisait une pool rotative et que le ticket s’est transformé en « autoriser depuis n’importe où pour l’instant ». La règle n’a jamais été supprimée. Personne ne l’a remarqué parce que rien ne cassait. Et le fait que rien ne casse est la façon dont le risque s’accroît.
Deux mois plus tard, le journal de sécurité s’est rempli d’échecs 4625 contre des comptes locaux. Le SOC l’a vu mais a catégorisé ça comme du bruit Internet de fond. Après tout, « RDP n’est pas public. » La compromission est passée par un mot de passe réutilisé pour un compte admin local qui existait aussi sur d’autres serveurs. L’attaquant s’est connecté une fois, a ensuite énuméré le réseau, a récolté des identifiants et a utilisé RDP latéralement là où c’était autorisé en interne.
Le rapport post-incident a été brutal dans le bon sens. La défaillance principale n’était pas le « mauvais mot de passe ». C’était l’hypothèse que l’environnement rendait l’exposition impossible. La correction a été tout aussi tranchante : contrôles automatisés qui vérifient en continu quels hôtes sont joignables sur 3389 depuis l’extérieur du réseau de gestion, plus une exigence stricte que tout RDP doit provenir d’un VPN ou d’un RD Gateway, appliquée en périphérie et sur l’hôte.
Les mauvaises hypothèses ne se signalent pas. Elles se manifestent plus tard sous forme de « connexions inattendues » et d’un calendrier rempli de réunions inconfortables.
Mini-récit 2 : L’optimisation qui a mal tourné
Une équipe ops a décidé de réduire les appels helpdesk en assouplissant les verrouillages de compte. Leur raisonnement : les travailleurs à distance se trompent souvent de mot de passe, et les verrouillages créaient une file de support. Ils ont donc augmenté fortement le seuil de verrouillage et raccourci la durée de verrouillage. C’était présenté comme « améliorer la productivité ». Cela a amélioré la productivité — pour les attaquants.
En parallèle, ils ont onboardé des contractuels et ne voulaient pas gérer la distribution de postes gérés. Les contractuels ont reçu des identifiants VPN (sans MFA à l’époque) et devaient RDP vers un jump host. Le jump host avait le RDP ouvert au sous-réseau VPN, ce qui semblait correct. Mais le sous-réseau VPN était énorme, partagé entre partenaires, et mal monitoré.
Puis est venu le password spraying. Pas un brute force rapide qui déclenche des alarmes. Un spray patient, distribué sur de nombreux comptes depuis de nombreuses IP VPN. Avec les verrouillages assouplis, l’attaquant avait de l’air. Finalement, un compte contractuel avec un mot de passe faible a été compromis. Ensuite : RDP vers le jump host, puis vers des serveurs internes, puis dump d’identifiants.
L’équipe a annulé les changements de verrouillage, mis en place le MFA sur le VPN et segmenté les pools VPN pour que « contractuels » ne soient pas dans le même océan que les admins. La leçon n’était pas « les verrouillages résolvent tout ». La leçon était : optimiser pour moins de tickets sans comprendre le comportement des menaces, c’est payer le silence avec la sécurité.
Une bonne exploitation réduit le travail sans augmenter le rayon d’impact. Si votre optimisation réduit le travail et augmente le rayon d’impact, vous n’avez pas optimisé. Vous avez emprunté des problèmes.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une autre entreprise avait une pratique tenace, presque old-school : chaque trimestre, ils faisaient une revue d’accès et une revue d’exposition pare-feu. Pas un diaporama. Une vraie revue avec changements exécutés et validés.
Ils avaient une règle : RDP n’est pas une méthode d’accès ; c’est un protocole interne. La méthode d’accès est le VPN avec MFA, et uniquement depuis des appareils gérés. Les pare-feu hôtes étaient configurés pour accepter RDP uniquement depuis des jump hosts et un petit VLAN admins. En plus, le pare-feu de périmètre avait un deny global pour le 3389 entrant. Si vous vouliez une exception, vous deviez l’expliquer par écrit à deux équipes qui aiment dire « non ».
Un weekend, leur SIEM a alerté sur une rafale d’échecs 4625 contre quelques comptes admins sur un serveur qui ne devrait être joignable que depuis le VLAN admin. Le SRE d’astreinte a vérifié les logs du pare-feu hôte et a vu des tentatives bloquées depuis une plage réseau partenaire. Ça aurait dû être impossible.
Il s’est avéré qu’un changement réseau avait accidentellement routé la plage partenaire vers un segment interne pouvant atteindre le serveur. Le pare-feu hôte a quand même bloqué les tentatives, et les logs l’ont prouvé. Ils ont corrigé l’erreur de routage avant toute connexion réussie. Le rapport d’incident a été court, ennuyeux et satisfaisant — le meilleur genre. Le contrôle préventif a marché, le contrôle détectif a dit la vérité, et la récupération a été « changer une route, fermer le ticket. »
Les pratiques ennuyeuses ne font pas de conférences. Elles vous évitent d’être nommé dans les notifications de violation.
Playbook de diagnostic rapide (trouvez le goulot d’étranglement vite)
Voici la séquence « vous êtes d’astreinte, le RDP se comporte bizarrement et quelqu’un crie ». L’objectif est de déterminer rapidement si le problème est d’exposition, d’authentification, de politique ou de ressources.
Premier : vérifier l’exposition et le chemin
- Depuis l’extérieur du réseau de gestion, testez la joignabilité sur 3389 (ou votre port configuré). S’il est joignable publiquement, ce n’est pas un « problème de connectivité » — c’est une défaillance de politique.
- Sur le serveur, vérifiez les sockets à l’écoute (
netstat -ano) et la portée du pare-feu (RemoteAddress pas Any). - Confirmez le chemin client : les utilisateurs se connectent-ils via VPN ou RD Gateway ? S’ils ne peuvent pas répondre, vous non plus.
Deuxième : vérifier l’authentification et les contrôles politiques
- La NLA est-elle requise ? Vérifiez
UserAuthenticationet les GPO. - Y a-t-il des verrouillages de comptes ? Vérifiez les échecs (4625), les événements de verrouillage (4740 en environnement domaine) et identifiez si c’est une faute de frappe ou un trafic d’attaque.
- Le MFA est-il appliqué sur le chemin d’accès (VPN/RD Gateway) ? Sinon, supposez que les identifiants finiront par être rejoués.
Troisième : confirmer la santé du service et des sessions
- Vérifiez l’état de
TermService. S’il est arrêté, demandez pourquoi (crash ? patch ? politique ?). - Vérifiez les sessions actives/déconnectées (
quser). Trop de sessions peuvent dégrader l’expérience et masquer un abus. - Vérifiez la charge CPU et mémoire (Task Manager/PerfMon). La « lenteur RDP » est souvent une VM saturée CPU.
Quatrième : rechercher rapidement une intention malveillante
- Pointe d’échecs 4625 depuis des IP inattendues → traiter comme trafic d’attaque ; bloquer en périphérie et sur l’hôte.
- Tout 4624 Logon Type 10 depuis une IP source inattendue → incident jusqu’à preuve du contraire.
- Corrélez avec les journaux opérationnels TerminalServices pour identifier la timeline utilisateur/session.
Erreurs courantes : symptôme → cause racine → correction
1) « Nous avons désactivé RDP, mais il est toujours joignable »
Symptôme : Le port 3389 apparaît toujours ouvert dans les scans ; les utilisateurs peuvent encore se connecter.
Cause racine : Vous avez désactivé les connexions utilisateur à un endroit (registre/UI) mais laissé des règles pare-feu ou un chemin RD Gateway, ou vous scannez un hôte/NAT différent.
Correction : Validez sur l’hôte fDenyTSConnections, l’état du service et les règles pare-feu ; validez en périphérie (security group/pare-feu) et confirmez les mappings NAT. Assurez-vous qu’il n’y a pas d’écouteur alternatif ni de load balancer qui forwarde.
2) « Nous avons activé NLA, mais les clients legacy ne peuvent pas se connecter »
Symptôme : Anciens clients fins ou systèmes embarqués échouent après le changement.
Cause racine : Le client ne supporte pas NLA/CredSSP.
Correction : Mettez à jour ou remplacez les clients. Si vous devez absolument les supporter temporairement, isolez les hôtes cibles, restreignez fortement les IP sources et fixez une date butoir. Ne généralisez pas l’exception.
3) « RDP continue de verrouiller des comptes »
Symptôme : Les utilisateurs sont verrouillés à répétition ; les tickets helpdesk explosent.
Cause racine : Password spraying ou un identifiant enregistré (tâche planifiée, service, lecteur mappé) échoue à répétition. Parfois c’est un attaquant ; parfois c’est votre propre automatisation.
Correction : Inspectez les journaux de sécurité : motifs 4625 et IP sources. Si c’est depuis des plages externes/inattendues, bloquez. Si c’est depuis des hôtes internes, trouvez la source d’identifiants stockés (tâche, service, RDP credential mis en cache). Réinitialisez et mettez à jour.
4) « Nous avons restreint le pare-feu au sous-réseau VPN, mais des gens se connectent de chez eux sans VPN »
Symptôme : Des connexions réussissent depuis des IP publiques.
Cause racine : Une autre règle pare-feu l’autorise (priorité plus élevée), ou il y a un allow en amont au périmètre avec NAT hairpinning, ou vous avez restreint la mauvaise règle (UDP vs TCP, ou nom d’affichage différent).
Correction : Énumérez toutes les règles entrantes référençant 3389 et les groupes Remote Desktop ; vérifiez la politique effective ; désactivez les règles larges ; activez le logging des blocs et retestez depuis un réseau externe.
5) « Nous avons déplacé RDP sur un autre port et les attaques ont cessé » (pour l’instant)
Symptôme : Moins d’entrées de log ; moins d’alertes.
Cause racine : Vous avez réduit le bruit, pas le risque. Les attaquants scannent tous les ports ; vous êtes juste sorti de la liste des fruits les plus accessibles temporairement.
Correction : Remettez-le si vous aimez la standardisation. Plus important : retirez l’exposition Internet, imposez NLA, imposez le MFA via le chemin d’accès, restreignez les sources et surveillez. La réduction du bruit n’est pas un contrôle.
6) « RDP est lent et instable »
Symptôme : Déconnexions fréquentes, latence, écrans noirs.
Cause racine : Souvent manque de ressources (CPU/mémoire), ou problèmes de chemin réseau (perte de paquets, MTU sur VPN), ou hôte de session surchargé.
Correction : Vérifiez le nombre de sessions, CPU/mémoire et les logs d’événements pour les raisons de déconnexions. Traitez la performance séparément de la sécurité, mais ne laissez pas des « optimisations de performance » affaiblir les contrôles de sécurité.
7) « Nous avons RD Gateway, donc nous sommes en sécurité »
Symptôme : Le RDP direct reste ouvert « pour les urgences », et il est utilisé.
Cause racine : Contournement culturel. Le chemin d’urgence devient le chemin principal parce qu’il est plus facile.
Correction : Supprimez le RDP entrant direct. Si vous devez garder une méthode break-glass, elle doit être limitée dans le temps, journalisée et exiger une approbation explicite avec MFA.
Listes de vérification / plan étape par étape
Phase 0 : Décider ce que RDP est autorisé à être
- Politique : « RDP est interne uniquement. » Consignez-le.
- Méthode d’accès : Choisissez VPN+MFA ou RD Gateway+MFA (ou les deux).
- Modèle admin : Comptes admin dédiés ; pas d’admin local partagé ; utilisez LAPS/Windows LAPS.
- Journalisation : Security + journaux TerminalServices collectés centralement, avec alerting pour anomalies.
Phase 1 : Supprimer l’exposition
- Au périmètre, bloquer TCP/3389 entrant (et UDP/3389 si applicable) depuis Internet.
- Si vous ne pouvez pas bloquer globalement, bloquez par hôte et documentez les exceptions avec propriétaires et date d’expiration.
- Sur chaque hôte, restreignez les règles pare-feu RDP aux sous-réseaux VPN/jump hosts seulement.
- Validez depuis un réseau externe que 3389 est fermé.
Phase 2 : Durcir l’authentification
- Activer NLA partout.
- Implémenter MFA sur VPN/RD Gateway.
- Appliquer une longueur minimale de mot de passe et l’historique ; éviter les exceptions faibles pour les comptes de service.
- Définir seuil/durée/fenêtre de verrouillage appropriés à votre environnement (et réduire l’exposition d’abord pour éviter le DoS par verrouillage).
Phase 3 : Réduire le rayon d’impact
- Utiliser des comptes admin séparés (pas d’email, pas de navigation) et restreindre où ils peuvent se connecter.
- Limiter l’appartenance au groupe « Remote Desktop Users » aux groupes dédiés.
- Segmenter les réseaux pour que les sous-réseaux utilisateurs ne puissent pas RDP vers les serveurs par défaut.
- S’assurer que l’EDR/Defender est activé et que la protection contre la manipulation est configurée selon le standard de l’organisation.
Phase 4 : Rendre observable
- Activer la politique d’audit pour les succès/échecs de connexion.
- Collecter 4624/4625 et les journaux opérationnels TerminalServices centralement.
- Alertes sur :
- Pointe de 4625 depuis une seule IP ou de nombreuses IPs
- 4624 Logon Type 10 depuis des plages IP non-management
- Connexions RDP hors des fenêtres de changement attendues pour des serveurs sensibles
- Effectuer des vérifications d’exposition mensuelles (scan externe + vérification interne).
FAQ
1) Changer le port RDP aide-t-il ?
Ça réduit le bruit, pas le risque. C’est une petite gêne pour certains scanners, mais ils le trouvent. Ne le faites que si cela sert la standardisation de votre environnement, pas comme contrôle primaire.
2) NLA suffit-il à sécuriser RDP ?
Non. NLA est nécessaire. Ce n’est pas suffisant. Vous avez encore besoin d’un accès réseau restreint (VPN/RD Gateway), du MFA et de contrôles de comptes appropriés.
3) Dois-je autoriser RDP uniquement depuis une allowlist d’IP ?
Oui, si l’allowlist est stable (sous-réseaux VPN, IP de jump hosts, VLAN admins). Évitez d’autoriser des IP domestiques aléatoires ; c’est ingérable et pousse aux exceptions.
4) Quels ID d’événements sont les plus importants pour les enquêtes RDP ?
Commencez par le journal Security 4624 (connexion réussie) et 4625 (échec de connexion). En environnement domaine, surveillez aussi les verrouillages de compte (4740). Ajoutez les journaux opérationnels TerminalServices RemoteConnectionManager pour corrélation spécifique RDP.
5) Nous devons laisser des fournisseurs RDP. Quelle est l’approche la moins pire ?
Utilisez RD Gateway ou VPN avec MFA, restreignez par appartenance à un groupe, limitez l’accès dans le temps et limitez aux hôtes cibles spécifiques. Journalisez et révisez. « Fournisseur admin local permanent » conduit à des réponses d’incident permanentes.
6) Ai-je besoin d’ouvrir UDP/3389 ?
Beaucoup d’environnements fonctionnent avec TCP uniquement, mais certaines fonctionnalités de performance peuvent utiliser UDP. Côté sécurité, traitez l’exposition UDP de la même manière : restreindre les sources et éviter l’exposition Internet. Testez avec vos clients avant de désactiver.
7) Quel est le gain le plus rapide si j’hérite d’un environnement en désordre ?
Bloquez le RDP entrant au périmètre, puis restreignez les règles du pare-feu hôte aux réseaux de gestion. Cela coupe instantanément le scan massif et le brute force depuis Internet.
8) Si nous utilisons RD Gateway, pouvons-nous laisser le RDP direct ouvert en secours ?
Non. Les chemins de secours deviennent primaires sous pression. Si vous avez besoin d’un chemin break-glass, il doit être limité dans le temps, protégé par MFA et audité avec approbation explicite.
9) Comment savoir si nos « attaques RDP » sont réelles ou juste du bruit Internet ?
Si vous voyez des échecs de connexion (4625) depuis des IP publiques, c’est du bruit mais c’est un problème car cela indique l’exposition. Si vous voyez une connexion réussie (4624 type 10) depuis des sources inattendues, c’est réel.
10) Devons-nous désactiver entièrement RDP sur les serveurs ?
Si vous pouvez gérer les serveurs via des canaux plus sûrs (outils de gestion à distance, administration just-in-time, accès console), oui — réduisez le nombre de machines où RDP est possible. Pour les autres, gardez-le privé et contrôlé.
Prochaines étapes pratiques
Faites cela dans les deux semaines qui viennent, pas « ce trimestre ». Les attaquants n’attendent pas que votre calendrier de changement soit émotionnellement prêt.
- Inventaire : Trouvez chaque hôte Windows avec RDP activé et chaque chemin pouvant l’atteindre (interne et externe).
- Fermer l’exposition : Bloquez le RDP entrant au périmètre. Puis restreignez les règles pare-feu hôte aux sources VPN/jump.
- Imposer NLA : Activez-le partout, supprimez les exceptions, mettez à jour les clients.
- Mettre MFA sur le chemin d’accès : VPN ou RD Gateway, avec politique d’utilisation d’appareils gérés pour les admins.
- Corriger l’hygiène admin : Comptes admin séparés, retirer permissions RDP larges, déployer LAPS/Windows LAPS.
- Opérationnaliser la télémétrie : Activer l’audit des connexions, centraliser les logs et alerter sur les signaux qui comptent.
- Prouver-le : Relancez les commandes ci-dessus après les changements. Si vous ne pouvez pas prouver le référentiel, vous n’avez pas de référentiel — vous avez des vibes.