L'énumération WinRM confirme le service et sa posture avant l'attaque. Les listeners sont 5985 (HTTP) et 5986 (HTTPS), et ils répondent à une requête WS-Management (un POST HTTP vers /wsman) de façon distinctive, de sorte qu'une sonde identifie WinRM même s'il repose sur HTTP. L'énumération établit aussi quel transport est en usage et quelles méthodes d'authentification le listener autorise (Negotiate/NTLM, Kerberos, Basic, CredSSP). Enfin, une vérification d'identifiant contre WinRM montre si un compte donné est réellement autorisé à se connecter (appartenance à Remote Management Users ou admin) et si cette connexion est privilégiée.
nmap -p5985,5986 -sV <target>
# WS-Management probe
curl -s -X POST http://<target>:5985/wsman -H 'Content-Type: application/soap+xml' | head
# validate an account and its WinRM access/privilege
nxc winrm <target> -u user -p 'pass' # (Pwn3d! indicates admin via WinRM)
Notes d'exploitation#
- Les ports 5985/5986 ouverts plus une réponse WS-Management confirment WinRM ; un
401à la sonde confirme quand même le service et révèle les méthodes d'authentification offertes dans les en-têtesWWW-Authenticate. - La vérification d'identifiant est l'énumération décisive :
nxc winrmindique si le compte peut utiliser WinRM du tout (tout compte valide ne le peut pas) et s'il atterrit en tant qu'admin. - HTTPS (5986) enveloppe le même protocole dans TLS ; il ne change pas l'attaque, seulement le transport, bien qu'il bloque la capture passive d'un identifiant en authentification Basic.
- Un endpoint WinRM confirmé plus un identifiant ou un hash utilisable mène directement à l'authentification et à l'exécution de commandes.