Kerberos Double Hop

El problema del doble salto ("double hop") aparece cuando intentamos usar autenticación Kerberos a través de dos o más saltos: por ejemplo, entramos por WinRM a un host A y desde ahí queremos consultar el directorio o acceder a un recurso en un host B. La acción se deniega aunque el usuario tenga permisos. No es un bug, sino una consecuencia de cómo funciona Kerberos: un ticket no es una contraseña, es un permiso firmado para un recurso concreto.

Mecanismo

Al autenticarnos por WinRM con Kerberos recibimos un TGS para ese servicio del host A, que permite ejecutar comandos ahí, pero el TGT del usuario no viaja a la sesión remota. Cuando desde A intentamos acceder a B, no hay TGT que presentar al KDC para pedir un ticket nuevo, así que no podemos probar nuestra identidad y el acceso se rechaza. Con contraseña o pass-the-hash (por ejemplo vía PsExec) esto no ocurre, porque el hash NTLM queda cacheado en la sesión y la máquina lo reutiliza; con Kerberos por WinRM la sesión no guarda credenciales, y Mimikatz las muestra en blanco.

Requisitos

Se da al encadenar sesiones remotas que usan Kerberos sin delegación, típicamente WinRM/evil-winrm. Para sortearlo hay dos soluciones habituales. La primera, si trabajamos desde una shell, es reenviar las credenciales en cada petición con un objeto PSCredential y un Invoke-Command anidado:

$sess = New-PSSession -ComputerName <target> -Credential $cred
Invoke-Command -Session $sess -ScriptBlock { whoami; Get-DomainUser -spn } -Credential $cred

La segunda, con acceso a un host Windows, es habilitar CredSSP, que sí delega las credenciales al segundo salto:

Enable-WSManCredSSP -Role Client -DelegateComputer <target>

Cómo detectarlo

CredSSP es la parte interesante para el defensor: al delegar la credencial completa, esta queda en memoria del host destino y puede ser robada. Conviene vigilar la habilitación de CredSSP (AllowFreshCredentials en HKLM\...\CredentialsDelegation), las sesiones WinRM con delegación activada y los Register-PSSessionConfiguration personalizados, que son otra vía para sortear el doble salto y a la vez una puerta trasera de persistencia.

Defensa. Evitar CredSSP salvo necesidad justificada, preferir protocolos que no requieran doble salto, limitar quién puede crear configuraciones de sesión y auditar las delegaciones. Relacionado con pass the ticket, overpass the hash y Kerberoasting.