Référence des ports
Port 5985 (TCP) – WinRM (HTTP)
Windows Remote Management sur HTTP — PowerShell Remoting et administration à distance des hôtes Windows.
État par défaut
Ouvert sur les serveurs où WinRM/PowerShell Remoting est activé (par défaut sous Windows Server). Transporte du SOAP sur HTTP ; le corps du message est chiffré une fois authentifié.
Attaques courantes
- Mouvement latéral Evil-WinRM avec identifiants ou hashs
- Authentification pass-the-hash via WinRM
- Brute force / password spraying d'identifiants
- Exécution de commandes à distance après compromission
Durcissement
- Préférer WinRM sur HTTPS (5986) avec des certificats valides
- Restreindre WinRM aux hôtes d'administration/rebond de confiance via pare-feu
- Désactiver l'authentification Basic ; exiger Kerberos/Negotiate
- Limiter les Remote Management Users et utiliser JEA si possible
- Imposer des comptes privilégiés adossés à la MFA et des mots de passe robustes
Commande nmap
nmap -p5985 --script http-title,http-auth <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Ce qui tourne sur le port 5985
Le port 5985 héberge WinRM (Windows Remote Management) sur HTTP, l'implémentation
Microsoft du protocole WS-Management. C'est le transport derrière PowerShell
Remoting (Enter-PSSession, Invoke-Command) et les outils d'administration à
distance, véhiculant des messages SOAP qui permettent aux administrateurs d'exécuter
des commandes et de gérer la configuration d'hôtes Windows distants. Il est activé par
défaut sous Windows Server et est répandu dans les environnements Active Directory.
Pourquoi c'est important pour la sécurité
WinRM accorde l'exécution de commandes à distance sur un hôte, ce qui en fait une cible de grande valeur et un canal de mouvement latéral privilégié. Comme il accepte l'authentification NTLM et Kerberos, un attaquant détenant des identifiants valides — ou simplement un hash NTLM — peut s'authentifier et exécuter des commandes sans jamais connaître le mot de passe en clair. Cela fait du 5985 un saut naturel après un vol d'identifiants, et l'outil open source Evil-WinRM rend le processus trivial.
Comment c'est attaqué
Après avoir récolté des identifiants ou des hashs, les attaquants utilisent Evil-WinRM ou PowerShell Remoting natif pour se connecter au 5985 et exécuter des commandes, passant d'hôte en hôte dans le domaine. Le pass-the-hash fonctionne directement via WinRM, et les points d'accès exposés subissent du brute force / password spraying. Une fois connectés, les opérateurs effectuent de la reconnaissance, extraient des identifiants et déploient des charges utiles à distance.
Liste de durcissement
Préférez WinRM sur HTTPS (5986) avec des certificats valides pour que le transport soit chiffré de bout en bout. Filtrez le 5985 aux seuls hôtes d'administration et de rebond de confiance. Désactivez l'authentification Basic et exigez Kerberos/Negotiate. Limitez l'appartenance au groupe Remote Management Users, déployez Just Enough Administration (JEA) pour restreindre ce que les sessions distantes peuvent faire, et adossez les comptes privilégiés à la MFA et à des mots de passe robustes. Les scripts nmap ci-dessus sondent le point d'accès HTTP et les méthodes d'authentification sur les systèmes que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- À quoi sert le port 5985 ?
- Le port 5985 héberge WinRM sur HTTP — le transport de PowerShell Remoting et de l'administration Windows à distance via WS-Management/SOAP.
- WinRM sur le port 5985 est-il chiffré ?
- Le transport est HTTP, mais avec Kerberos/Negotiate la charge utile du message est chiffrée. L'authentification Basic sur le 5985 simple ne l'est pas — utilisez HTTPS sur le 5986 pour un chiffrement complet du transport.