Référence des ports
Port 5986 (TCP) – WinRM sur HTTPS
Point d'accès Windows Remote Management (WS-Management) chiffré par TLS, contrepartie sécurisée du WinRM en clair sur le 5985.
État par défaut
À l'écoute uniquement si WinRM est configuré pour HTTPS. Une fois activé, il exige des identifiants Windows valides ; le canal est chiffré, contrairement au 5985 sur HTTP.
Attaques courantes
- Mouvement latéral basé sur les identifiants via Evil-WinRM et outils similaires
- Pulvérisation de mots de passe et brute-force des comptes Windows
- Pass-the-hash / relais NTLM pour obtenir une session PowerShell distante
- Abus de comptes de service surprivilégiés pour l'exécution de commandes à distance
Durcissement
- Préférer le 5986 (HTTPS) au 5985 (HTTP) et désactiver le WinRM en clair
- Restreindre WinRM aux réseaux de gestion/hôtes de rebond via pare-feu
- Exiger des identifiants forts et uniques et imposer le MFA si possible
- Limiter les privilèges de gestion à distance ; éviter la réutilisation large d'admin local
- Utiliser des certificats TLS valides et surveiller les connexions WinRM anormales
Commande nmap
nmap -p5986 --script ssl-cert <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Ce qui s'exécute sur le port 5986
Le port 5986 est WinRM sur HTTPS — la forme chiffrée par TLS de Windows Remote Management (WS-Management). Il permet aux administrateurs d'exécuter PowerShell et des commandes de gestion à distance. C'est la contrepartie sécurisée du WinRM en clair sur le 5985 : même service, mais la session est protégée par TLS au lieu de transiter sur du HTTP en clair.
Pourquoi c'est important pour la sécurité
WinRM distribue une session PowerShell distante, exactement ce que veut un attaquant pour le mouvement latéral. Le TLS du 5986 protège le canal, mais il ne fait rien pour arrêter un adversaire qui dispose déjà d'identifiants valides. Des comptes de service surprivilégiés et des mots de passe d'admin local réutilisés transforment un seul identifiant volé en accès à tout le parc.
Comment c'est attaqué
Après avoir collecté des identifiants, les attaquants utilisent Evil-WinRM et des outils similaires pour ouvrir un shell interactif sur le 5986. Ils pulvérisent et brute-forcent les comptes Windows, et exploitent le pass-the-hash ou le relais NTLM pour s'authentifier sans le mot de passe en clair. De là, ils exécutent des commandes et pivotent dans le domaine.
Liste de durcissement
Préférez le 5986 (HTTPS) au 5985 (HTTP) et désactivez le WinRM en clair. Restreignez WinRM aux réseaux de gestion et hôtes de rebond via pare-feu, exigez des identifiants forts et uniques et imposez le MFA si possible. Limitez les privilèges de gestion à distance et évitez la réutilisation large d'admin local. Utilisez des certificats TLS valides et surveillez les connexions WinRM anormales. Utilisez la commande nmap ci-dessus pour vérifier l'exposition sur les hôtes que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- Quelle différence entre le port 5985 et le 5986 ?
- Les deux servent WinRM (WS-Management). Le 5985 le transporte sur HTTP en clair ; le 5986 l'enveloppe dans HTTPS/TLS. Préférez toujours le 5986 pour que les identifiants et les données de session soient chiffrés en transit.
- Pourquoi les attaquants ciblent-ils WinRM sur le 5986 ?
- WinRM accorde une session PowerShell distante, idéale pour le mouvement latéral. Avec des identifiants volés ou pulvérisés, des outils comme Evil-WinRM donnent un shell interactif complet sur l'hôte — même si le canal 5986 lui-même est chiffré.