Español - Ht
HackTricks Training Twitter Linkedin Sponsor

Kerberos Double Hop Problem

Aprende hacking en AWS de cero a héroe con htARTE (Experto en Red de HackTricks AWS)!

Introducción

El problema de "Doble Salto" de Kerberos ocurre cuando un atacante intenta utilizar la autenticación de Kerberos a través de dos saltos, por ejemplo, utilizando PowerShell/WinRM.

Cuando ocurre una autenticación a través de Kerberos, las credenciales no se almacenan en la memoria. Por lo tanto, si ejecutas mimikatz, no encontrarás las credenciales del usuario en la máquina aunque esté ejecutando procesos.

Esto se debe a que al conectarse con Kerberos, estos son los pasos:

  1. El Usuario1 proporciona credenciales y el controlador de dominio devuelve un TGT de Kerberos al Usuario1.

  2. El Usuario1 utiliza el TGT para solicitar un ticket de servicio para conectarse al Servidor1.

  3. El Usuario1 se conecta al Servidor1 y proporciona el ticket de servicio.

  4. El Servidor1 no tiene las credenciales de Usuario1 en caché ni el TGT de Usuario1. Por lo tanto, cuando Usuario1 desde Servidor1 intenta iniciar sesión en un segundo servidor, no puede autenticarse.

Delegación no restringida

Si la delegación no restringida está habilitada en la PC, esto no sucederá ya que el Servidor obtendrá un TGT de cada usuario que acceda a él. Además, si se utiliza la delegación no restringida, probablemente se pueda comprometer el Controlador de Dominio desde allí. Más información en la página de delegación no restringida.

CredSSP

Otra forma de evitar este problema, que es notablemente insegura, es el Proveedor de Soporte de Seguridad de Credenciales. Según Microsoft:

La autenticación de CredSSP delega las credenciales de usuario de la computadora local a una computadora remota. Esta práctica aumenta el riesgo de seguridad de la operación remota. Si la computadora remota se ve comprometida, cuando se pasan las credenciales a ella, las credenciales se pueden utilizar para controlar la sesión de red.

Se recomienda encarecidamente que CredSSP esté deshabilitado en sistemas de producción, redes sensibles y entornos similares debido a preocupaciones de seguridad. Para determinar si CredSSP está habilitado, se puede ejecutar el comando Get-WSManCredSSP. Este comando permite verificar el estado de CredSSP e incluso puede ejecutarse de forma remota, siempre que WinRM esté habilitado.

Invoke-Command -ComputerName bizintel -Credential ta\redsuit -ScriptBlock {
Get-WSManCredSSP
}

Soluciones alternativas

Invocar Comando

Para abordar el problema del doble salto, se presenta un método que implica un Invoke-Command anidado. Esto no resuelve el problema directamente, pero ofrece una solución alternativa sin necesidad de configuraciones especiales. El enfoque permite ejecutar un comando (hostname) en un servidor secundario a través de un comando PowerShell ejecutado desde una máquina atacante inicial o a través de una sesión de PS previamente establecida con el primer servidor. Así es como se hace:

$cred = Get-Credential ta\redsuit
Invoke-Command -ComputerName bizintel -Credential $cred -ScriptBlock {
Invoke-Command -ComputerName secdev -Credential $cred -ScriptBlock {hostname}
}

Alternativamente, se sugiere establecer una sesión de PS con el primer servidor y ejecutar el Invoke-Command usando $cred para centralizar tareas.

Registrar la Configuración de la Sesión de PS

Una solución para evitar el problema de doble salto implica usar Register-PSSessionConfiguration con Enter-PSSession. Este método requiere un enfoque diferente al de evil-winrm y permite una sesión que no sufre la limitación del doble salto.

Register-PSSessionConfiguration -Name doublehopsess -RunAsCredential domain_name\username
Restart-Service WinRM
Enter-PSSession -ConfigurationName doublehopsess -ComputerName <pc_name> -Credential domain_name\username
klist

Reenvío de Puertos

Para los administradores locales en un objetivo intermedio, el reenvío de puertos permite enviar solicitudes a un servidor final. Utilizando netsh, se puede agregar una regla para el reenvío de puertos, junto con una regla del firewall de Windows para permitir el puerto reenviado.

netsh interface portproxy add v4tov4 listenport=5446 listenaddress=10.35.8.17 connectport=5985 connectaddress=10.35.8.23
netsh advfirewall firewall add rule name=fwd dir=in action=allow protocol=TCP localport=5446

winrs.exe

winrs.exe se puede utilizar para reenviar solicitudes de WinRM, potencialmente como una opción menos detectable si la supervisión de PowerShell es una preocupación. El siguiente comando demuestra su uso:

winrs -r:http://bizintel:5446 -u:ta\redsuit -p:2600leet hostname

OpenSSH

La instalación de OpenSSH en el primer servidor habilita una solución alternativa para el problema del doble salto, particularmente útil para escenarios de caja de salto. Este método requiere la instalación de CLI y la configuración de OpenSSH para Windows. Cuando se configura para la Autenticación de Contraseña, esto permite que el servidor intermedio obtenga un TGT en nombre del usuario.

Pasos de Instalación de OpenSSH

  1. Descargar y mover el archivo zip de la última versión de OpenSSH al servidor de destino.

  2. Descomprimir y ejecutar el script Install-sshd.ps1.

  3. Agregar una regla de firewall para abrir el puerto 22 y verificar que los servicios de SSH estén en ejecución.

Para resolver errores de Conexión restablecida, es posible que sea necesario actualizar los permisos para permitir que todos tengan acceso de lectura y ejecución en el directorio de OpenSSH.

icacls.exe "C:\Users\redsuit\Documents\ssh\OpenSSH-Win64" /grant Everyone:RX /T

Referencias

Aprende hacking de AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!
AnteriorKerberos AuthenticationSiguienteLAPS

Última actualización