RDP Exposé : La Mauvaise Configuration Qui Continue de Payer pour les Attaquants
Detection stack
- AIDR
- Alert
- ETL
- Query
Résumé
L’article explique que les services Remote Desktop Protocol exposés continuent d’être un vecteur d’accès initiale courant pour les attaquants. De nombreuses organisations laissent encore les ports RDP accessibles depuis Internet, ce qui en fait des cibles faciles pour les scans automatisés et les tentatives d’intrusion opportunistes. Le post met en avant des incidents réels dans lesquels des attaquants ont abusé de l’accès RDP ouvert ou des portails RDWeb exposés pour pénétrer dans des environnements et étendre ensuite leur accès par mouvement latéral.
Investigation
Les cas décrits incluent une organisation de santé avec un port RDP exposé sur Internet, un incident impliquant une compromission via un portail RDWeb, et une intrusion où les attaquants ont modifié les paramètres de pare-feu et de registre pour activer RDP après avoir exploité un appareil SonicWall VPN vulnérable. Dans ces scénarios, les attaquants se sont appuyés sur des commandes Windows simples, des utilitaires de tunneling inverse, et des scripts de collecte d’identifiants pour maintenir l’accès et progresser plus loin dans le réseau.
Atténuation
Les défenses recommandées se concentrent sur l’élimination de l’exposition inutile de RDP, la mise en place de l’accès RDP requis derrière des pare-feu correctement configurés, la rotation des identifiants après toute exposition suspectée, et le transfert des journaux de pare-feu et de VPN dans un SIEM pour une détection plus rapide. L’article conseille également de déployer une couverture EDR et de surveiller les modifications de registre qui activent ou réactivent les services RDP.
Réponse
Si une activité suspecte liée à RDP est détectée, les intervenants doivent bloquer l’adresse IP fautive, désactiver le service RDP, inverser les modifications malveillantes du registre, s’assurer que les règles du pare-feu n’ont pas été modifiées, et réinitialiser les identifiants affectés. Un suivi continu des tentatives d’accès répétées et la validation de tous les changements de configuration sont également essentiels.
Flux d’attaque
Détections
Possibilité de confidentialité des services de bureau à distance (via registry_event)
Voir
Possibilité de confidentialité des services de bureau à distance (via process_creation)
Voir
Modifications suspectes du pare-feu via CLI (via cmdline)
Voir
Détecter la modification du registre pour activer les connexions RDP [Événement du Registre Windows]
Voir
Détection de l’exposition RDP et de la modification des règles de pare-feu [Pare-feu]
Voir
Exécution de Simulation
Préalable : Le contrôle préalable de télémétrie et de baselining doit avoir réussi.
Rationnel: Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit doivent refléter directement les TTP identifiés et viser à générer exactement la télémétrie attendue par la logique de détection.
-
Narration et Commandes d’attaque :
-
Reconnaissance (T1016.001) : L’adversaire exécute une analyse rapide du sous-réseau cible pour identifier les hôtes avec le port 3389 ouvert, en utilisant
Test-NetConnectiondans une boucle. -
Escalade des privilèges / Manipulation du pare-feu (T1021.001) : Ayant obtenu les droits administratifs locaux, l’attaquant utilise
netsh.exepour ajouter une règle de pare-feu permissive pour RDP, exposant ainsi le service à Internet. - Vérification après création : L’attaquant liste les règles de pare-feu pour confirmer l’existence de la nouvelle entrée, puis initie une session RDP (hors du périmètre de ce test).
-
Reconnaissance (T1016.001) : L’adversaire exécute une analyse rapide du sous-réseau cible pour identifier les hôtes avec le port 3389 ouvert, en utilisant
-
Script de Test de Régression :
#--------------------------------------------------------- # Activité Simulée de l'Adversaire – Exposition RDP via netsh #--------------------------------------------------------- # 1. Analyser le sous-réseau local /24 pour des ports RDP ouverts (recon bénigne) $subnet = "10.0.0." 1..254 | ForEach-Object { $ip = "$subnet$_" $result = Test-NetConnection -ComputerName $ip -Port 3389 -WarningAction SilentlyContinue if ($result.TcpTestSucceeded) { Write-Host "[+] RDP ouvert sur $ip" } } # 2. Ajouter une règle de pare-feu permettant l'entrée RDP depuis n'importe quelle adresse $ruleName = "TempAllowRDP_$(Get-Random -Maximum 10000)" $netshCmd = "advfirewall firewall add rule name=`"$ruleName`" dir=in action=allow protocol=TCP localport=3389" Write-Host "`n[+] Création de la règle de pare-feu via netsh..." Start-Process -FilePath "$env:SystemRootSystem32netsh.exe" -ArgumentList $netshCmd -Wait -NoNewWindow # 3. Vérifier que la règle existe (optionnel, aide à confirmer la télémétrie) netsh advfirewall firewall show rule name=$ruleName # Fin de l'attaque simulée -
Commandes de Nettoyage :
#--------------------------------------------------------- # Supprimer la règle de pare-feu temporairement créée pendant le test #--------------------------------------------------------- $rulePrefix = "TempAllowRDP_" $rules = netsh advfirewall firewall show rule name=all | Select-String -Pattern $rulePrefix | ForEach-Object { ($_ -split 's+')[0] } foreach ($r in $rules) { Write-Host "[*] Suppression de la règle $r" netsh advfirewall firewall delete rule name=$r }