Kerberos Double Hop Problem
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
El problema de "Doble Salto" de Kerberos aparece cuando un atacante intenta usar autenticación Kerberos a través de dos saltos, por ejemplo usando PowerShell/WinRM.
Cuando ocurre una autenticación a través de Kerberos, las credenciales no se almacenan en memoria. Por lo tanto, si ejecutas mimikatz no encontrarás credenciales del usuario en la máquina, incluso si está ejecutando procesos.
Esto se debe a que al conectarse con Kerberos estos son los pasos:
User1 proporciona credenciales y el controlador de dominio devuelve un TGT de Kerberos a User1.
User1 usa el TGT para solicitar un ticket de servicio para conectarse a Server1.
User1 se conecta a Server1 y proporciona el ticket de servicio.
Server1 no tiene las credenciales de User1 almacenadas o el TGT de User1. Por lo tanto, cuando User1 desde Server1 intenta iniciar sesión en un segundo servidor, no puede autenticarse.
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 puedas comprometer el Controlador de Dominio desde él. Más información en la página de delegación no restringida.
Otra forma de evitar este problema que es notablemente insegura es el Proveedor de Soporte de Seguridad de Credenciales. De Microsoft:
La autenticación CredSSP delega las credenciales del usuario desde la computadora local a una computadora remota. Esta práctica aumenta el riesgo de seguridad de la operación remota. Si la computadora remota es comprometida, cuando se le pasan las credenciales, estas pueden ser utilizadas 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 la verificación del estado de CredSSP y puede incluso ser ejecutado de forma remota, siempre que WinRM esté habilitado.
Para abordar el problema del doble salto, se presenta un método que involucra 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 de PowerShell ejecutado desde una máquina atacante inicial o a través de una PS-Session previamente establecida con el primer servidor. Así es como se hace:
Alternativamente, se sugiere establecer una PS-Session con el primer servidor y ejecutar el Invoke-Command utilizando $cred para centralizar tareas.
Una solución para eludir el problema del 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 de la limitación del doble salto.
Para los administradores locales en un objetivo intermedio, el reenvío de puertos permite que las solicitudes se envíen a un servidor final. Usando netsh, se puede agregar una regla para el reenvío de puertos, junto con una regla de firewall de Windows para permitir el puerto reenviado.
winrs.exe se puede utilizar para reenviar solicitudes de WinRM, potencialmente como una opción menos detectable si la monitorización de PowerShell es una preocupación. El comando a continuación demuestra su uso:
Instalar OpenSSH en el primer servidor permite una solución para el problema de doble salto, particularmente útil para escenarios de jump box. Este método requiere la instalación y configuración de OpenSSH para Windows a través de la CLI. Cuando se configura para la Autenticación por Contraseña, esto permite que el servidor intermedio obtenga un TGT en nombre del usuario.
Descargue y mueva el último archivo zip de OpenSSH al servidor de destino.
Descomprima y ejecute el script Install-sshd.ps1.
Agregue una regla de firewall para abrir el puerto 22 y verifique que los servicios SSH estén en funcionamiento.
Para resolver errores de Connection reset, es posible que sea necesario actualizar los permisos para permitir que todos tengan acceso de lectura y ejecución en el directorio de OpenSSH.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
