📌 Resumen

El problema del doble salto (double-hop) ocurre cuando intentamos ejecutar comandos remotos desde un host intermedio usando Kerberos, y el TGT (Ticket Granting Ticket) del usuario no se reenvía al segundo host.
Resultado: el segundo host no puede autenticarnos, aunque tengamos acceso legítimo.

Ejemplo clásico:

Attack Host → Host A (WinRM) → Host B (DC)

🟥 ¿Por qué ocurre?

✔ Qué se envía en WinRM (Kerberos)

• WinRM solo envía un TGS (Service Ticket) para el host destino.

• No envía el TGT, necesario para autenticarnos en otros recursos.

• Por eso, desde el host remoto no podemos acceder al DC, consultar AD, ejecutar PowerView, etc.

✔ Qué pasa con NTLM / PSExec

• Cuando autenticamos usando contraseña / NTLM, el hash NTLM se almacena en memoria.

• Esto permite autenticación transparente a otros recursos.

• Por eso, con PSExec el doble salto no ocurre.

🟥 Evidencia (Mimikatz)

Al conectarse vía WinRM:

• No aparece la contraseña del usuario.

• No se almacenan credenciales que permitan autenticación a otros hosts.

• Solo se observa la máquina local (ej: DEV01$).

🟥 Qué significa realmente

WinRM con Kerberos:

• ✔ Acceso al host destino.

• ✘ Acceso a cualquier otro host desde allí.

El usuario no puede demostrar identidad ante el segundo host → acceso denegado.

🟩 Cuando NO ocurre el doble salto

🔓 Delegación sin restricciones (Unconstrained Delegation)

Si está habilitada:

• El host recibe junto al TGS el TGT completo.

• El host puede solicitar nuevos TGS en nombre del usuario.

• 🟢 No hay problema de doble salto

• 🟢 Desde ese host prácticamente ya tienes el dominio.

🟦 Soluciones prácticas

✅ 1. Pasar credenciales manualmente con PSCredential

Cuando usamos WinRM (evil-winrm, Enter-PSSession, etc.):

Crear SecureString:

$SecPassword = ConvertTo-SecureString 'PASSWORD' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('DOMAIN\user', $SecPassword)

Usar PowerView con credenciales:

Get-DomainUser -SPN -Credential $Cred

Sin -Credential → falla por doble salto.

❗ Comprobación con klist

Con WinRM:

Solo 1 ticket → HTTP/HOST No hay TGT

Con RDP o PSExec:

TGT + múltiples TGS Delegación permitida → No hay problema de doble salto

✅ 2. Crear nueva configuración de PSSession (registrar sesión)

Cuando tenemos GUI o trabajamos desde un host Windows comprometido.

Permite:

• Reenviar credenciales de manera controlada.

• Evita tener que usar PSCredential constantemente.

• Posible incluso ejecutar módulos que no aceptan -credential.

🟦 Indicadores del doble salto

Sintomas:

• PowerView falla con:

DirectoryServicesCOMException: An operations error occurred

• Klist muestra solo:

HTTP/host → 1 ticket

• Las consultan a SPNs, AD, LDAP fallan.

🟩 Proceso de ataque típico que falla por doble salto

Attack host (evil-winrm) → DEV01 DEV01 intenta → DC01

WinRM autentica con Kerberos, pero:

• No hay TGT.

• No hay NTLM hash.

• No puede autenticarse en un tercer host → fallo.

🟪 Procesos involucrados

Ejemplo:

wsmprovhost.exe conhost.exe tasklist.exe

→ ejecutándose bajo el usuario conectado vía WinRM, pero sin credenciales completas.

🟦 Conclusión clara y útil para pentesting

🟦 Soluciones rápidas (cheat sheet)

✔ Pasar credenciales manualmente:

$pwd = ConvertTo-SecureString 'Pass123' -AsPlainText -Force
$cred = New-Object PSCredential ('DOMAIN\user', $pwd)
Invoke-Command -ComputerName DC01 -Credential $cred -ScriptBlock { ... }

✔ Usar un host Windows comprometido (RDP)

→ Ya tiene los tickets necesarios (klist para confirmar).

✔ Obtener ejecución por PSExec o SMB

✔ Buscar delegación sin restricciones:

Get-DomainComputer -Unconstrained