WinRM

Windows necesitaba una interfaz de administración remota que pudiera atravesar redes mediante mensajes estructurados y políticas comunes. Windows Remote Management (WinRM) implementa WS-Management para exponer esa capa. PowerShell Remoting la utiliza habitualmente como transporte, pero WS-Man y una shell de PowerShell no son la misma capacidad.

Entre una respuesta HTTP y un prompt remoto intervienen listener, TLS o protección de mensaje, autenticación, autorización del endpoint, configuración de sesión y límites de PowerShell. Un 401 puede confirmar WS-Man y una credencial válida puede seguir terminando en un endpoint JEA restringido. La enumeración conserva esas fases para explicar acceso completo, parcial o bloqueado.

Los ejemplos usan TARGET_IP, FQDN, DOMAIN y USERNAME como placeholders.

Nmap confirma HTTP o HTTPS y sus respuestas iniciales. Test-WSMan comprueba WS-Management desde PowerShell. Enter-PSSession y New-PSSession validan un endpoint de PowerShell Remoting. Evil-WinRM ofrece una consola práctica desde Linux, pero el acceso que obtiene depende de WinRM, la autenticación y la configuración del endpoint.

Un 401 puede confirmar el listener y exigir autenticación. Un 404 o 405 puede proceder de un proxy inverso, una ruta incorrecta o un servicio HTTP que no es WinRM. Analiza cabeceras y cuerpo antes de clasificarlo.

Los listeners predeterminados suelen usar:

HTTP no implica que las credenciales y mensajes viajen siempre como texto claro. Kerberos y NTLM pueden proporcionar autenticación y message encryption. HTTPS añade protección TLS y autenticación del servidor mediante certificado. El resultado efectivo depende del mecanismo, del cliente y de la configuración.

Nmap -sV identifica ambos endpoints y puede reconocer WS-Man a través de sus respuestas HTTP:

nmap -sV -p 5985,5986 TARGET_IP

Un listener puede estar ligado a una dirección concreta o aceptar solo determinados orígenes mediante firewall. Registra la interfaz y el endpoint desde los que se obtuvo cada respuesta. Para Kerberos, el cliente necesita un hostname que pueda asociar al SPN HTTP/FQDN. Usar una IP suele hacer que el cliente cambie a NTLM o falle, según su política.

Test-WSMan envía una petición de identificación. -ComputerName selecciona el destino y -UseSSL cambia al listener HTTPS:

Test-WSMan -ComputerName FQDN
Test-WSMan -ComputerName FQDN -UseSSL

La respuesta puede revelar versión del protocolo y stack. Todavía faltan autenticación y autorización. WinRM decide el acceso mediante endpoints de sesión, grupos, SDDL, JEA y políticas del host.

Test-WSMan -Authentication permite fijar un mecanismo compatible con el cliente. Cambiar autenticación, transporte y hostname a la vez dificulta atribuir el fallo. Empieza por el endpoint observado y cambia una variable cada vez.

Evil-WinRM abre una sesión PowerShell. -i fija el destino y -u el usuario. Al omitir -p, solicita la contraseña sin incluirla en los argumentos:

evil-winrm -i TARGET_IP -u 'DOMAIN\USERNAME'

Dentro de la sesión, registra whoami /all, hostname, PowerShell language mode, endpoint y configuración de remoting antes de interpretar permisos. Una shell con PowerShell restringido puede seguir permitiendo cmdlets definidos por JEA sin entregar una sesión completa del sistema.

Desde un cliente Windows, New-PSSession conserva la sesión para varias operaciones:

$session = New-PSSession -ComputerName FQDN -Credential DOMAIN\USERNAME
Enter-PSSession -Session $session
Remove-PSSession -Session $session

-Credential abre un prompt seguro. El hostname influye en Kerberos y en la validación del certificado, por lo que sustituirlo por una IP puede cambiar el mecanismo negociado.

winrm enumerate winrm/config/listener
winrm get winrm/config/service
winrm get winrm/config/service/auth
winrm get winrm/config/client
Get-PSSessionConfiguration

Relaciona dirección, transporte, certificado, mecanismos de autenticación, TrustedHosts, límites de memoria y procesos, SDDL y configuración JEA. TrustedHosts afecta a la confianza del cliente cuando no puede usar Kerberos. No es una ACL del servidor.

La combinación importa. Basic transmite el usuario y la contraseña codificados en Base64 y no aporta cifrado. Necesita TLS o AllowUnencrypted para funcionar según la política. AllowUnencrypted = false impide mensajes sin protección, pero HTTP todavía puede transportar sesiones protegidas por Kerberos o NTLM. Habilitar HTTPS no obliga al cliente a validar correctamente el certificado. Kerberos aporta identidad mutua cuando SPN, DNS y reloj son correctos. NTLM no depende del SPN, pero cambia las propiedades de autenticación y delegación.

Cada entrada de Get-PSSessionConfiguration representa un endpoint. Su SDDL decide quién puede abrirlo. ConfigFilePath, RunAsUser y las definiciones JEA pueden limitar comandos o cambiar el contexto. Una cuenta aceptada por WinRM puede quedar rechazada por un endpoint concreto, y otra puede obtener una sesión restringida sin ser administradora local.

WinRM suele usar HTTP/5985 o HTTPS/5986, pero puede publicarse en otros puertos. Nmap puede identificar HTTP, TLS, métodos y NTLM mediante scripts genéricos. No existe en Nmap 7.99 un script winrm-* que sustituya WS-Man:

nmap -sV -n -Pn -p 5985,5986 \
  --script http-ntlm-info,http-auth-finder,sdoc-cert TARGET_IP

sdoc-cert solo se activa donde haya TLS. Valida el endpoint con una petición WS-Man o Test-WSMan. Una respuesta HTTP 404, 401 o 405 puede demostrar que el listener existe aunque la herramienta no abra una shell.

Kerberos, NTLM, certificate y CredSSP tienen requisitos de nombre, SPN, canal y delegación diferentes. Basic transmite la credencial dentro de la protección del canal y no debe asumirse habilitado. HTTPS protege transporte. En HTTP, WinRM puede seguir cifrando mensajes después de Negotiate, pero eso no equivale a TLS para todos los metadatos.

Tras autenticar, el endpoint de PowerShell aplica session configuration, SDDL, JEA, language mode, quotas y permisos de la cuenta. Test-WSMan correcto no demuestra Enter-PSSession. Evil-WinRM, PowerShell y una librería WS-Man pueden divergir por autenticación, TLS o envelope size. Conserva error y mecanismo.

Crear una sesión remota inicia procesos host y puede cargar perfiles. File transfer, service operations y scripts cambian estado. WinRM Operational, PowerShell Operational, Security y EDR pueden registrar autenticación, shell, pipeline y proceso. Cierra PSSession, elimina archivos creados, detén listeners o tunnels locales y no alteres TrustedHosts como solución permanente. Si se modificó temporalmente en una estación desechable, restaura su valor exacto y registra la comparación.

Compara PowerShell, Evil-WinRM, NetExec y Nmap en herramientas y automatización. La checklist controla listener, identidad, autenticación y endpoint. La cheatsheet recupera comandos ya contextualizados.

• Microsoft: Installation and Configuration for WinRM
• Microsoft: WinRM Portal
• Microsoft: Security Considerations for PowerShell Remoting Using WinRM
• Microsoft: about_Remote_Requirements
• Evil-WinRM