Seguro que ya conocéis Pass-The-Hash (PTH), una técnica que permite a un atacante iniciar el movimiento lateral en la red a través del protocolo NTLM, sin la necesidad de la contraseña del usuario.
Windows almacena diferentes tipos de valores hash, derivados de la contraseña del usuario, para permitir el acceso a diferentes servicios sin la necesidad de volver a ingresar la contraseña. Uno de esos tipos de hash es un hash MD4 de la contraseña también conocido como NTLM hash.
El protocolo NTLM utiliza el hash NT para la autenticación y no hace un 'salt' de la contraseña, lo que a su vez significa que si uno toma el valor del hash, la autenticación se puede realizar sin conocer la contraseña real.
Cuando se lleva a cabo una conexión NTLM se registrará en la máquina destino un Evento con ID 4624 ("Una cuenta inició sesión correctamente") con Logon Type 3 ("Un usuario o computadora inició sesión en esta computadora desde la red") y Authentication Package NTLM (o por nombre de proceso de logon NtLmSsp):
Un atacante por lo tanto puede autenticarse sin una contraseña pasando el hash. Para ello tendrá dos opciones:
- Inyectar el hash en LSASS.exe y abrir sesión con el hash inyectado.
- Implementar parte del protocolo NTLM para la autenticación con el hash y enviar comandos a través de la red con protocolos como SMB, WMI, etc.
La principal diferencia entre pasar el hash a una conexión NTLM legítima es el uso de una contraseña. La búsqueda de inicios de sesión de usuarios legítimos, donde se usó la contraseña antes de la conexión NTLM, puede ayudar a filtrar todos los inicios de sesión legítimos y dejar solo el inicio de sesión sospechoso.
Conexiones legítimas desde el visor de eventos
El visor de eventos contiene una cantidad de registros que indican inicios de sesión interactivos:
4768 - Se solicitó un ticket de autenticación de Kerberos (TGT)
4769 - Se solicitó un ticket de servicio Kerberos (TGS)
4648 - Se intentó un inicio de sesión utilizando credenciales explícitas
4624 - Se inició sesión correctamente en una cuenta
Tipos de inicio de sesión: 2 (Interactivo), 7 (Desbloqueo), 10 (RemoteInteractive) o 11 (CachedInteractive).
Comprobar que cada conexión NTLM tenía un inicio de sesión interactivo con la misma cuenta antes de la conexión, basándose en los registros anteriores, puede ayudar a distinguir entre un atacante que usa el hash y un usuario normal que usa la contraseña.
Algunas conexiones NTLM son más arriesgadas que otras
Un inicio de sesión creado a través de una conexión NTLM con una cuenta sin privilegios es menos arriesgada que una con una cuenta con privilegios. Por ejemplo, Event ID 4672 ("Privilegios especiales asignados al nuevo inicio de sesión") nos permite saber cuándo se inicia sesión con una cuenta con privilegios. Al crear la correlación entre la conexión NTLM y el evento ID 4672, se filtrarán todas las conexiones NTLM privilegiadas que pueden realizar cambios en la computadora de destino, como se ve en la siguiente imagen:
Detectando Pass-The-Hash
Al unir todas las piezas, podemos buscar conexiones NTLM privilegiadas y verificar si tenían un inicio de sesión legítimo antes de la conexión NTLM al correlacionar con identificadores de eventos buenos conocidos. Para facilitar la tarea, la empresa israelí CyberArk ha creado la herramienta Ketshash que automatiza la detección de conexiones NTLM con privilegios sospechosos, en particular ataques Pass-The-Hash, en función de los registros del visor de eventos.
En el siguiente vídeo se muestra cómo este enfoque (con la ayuda de Ketshash) es eficaz para detectar los ataques de PTH utilizados por PTH-winexe, Mimikatz, WCE e Invoke-SMBClient:
Requisitos:
Cuenta con los siguientes privilegios:
- Acceso a registros de eventos de seguridad de máquinas remotas
- Permisos de lectura de ActiveDirectory (cuenta de dominio estándar)
- Computadoras sincronizadas con el mismo tiempo, de lo contrario puede afectar los resultados
- PowerShell 2.0 como mínimo
Uso
Hay dos opciones:
- Uso Básico
Abre PowerShell y ejecuta:
Import-Module. \ Ketshash.ps1 o copiar y pegar el contenido de Ketshash.ps1 a la sesión de PowerShell
Invoke-DetectPTH<argumentos>
- Ketshash Runner
Hay que asegurse de que Ketshash.ps1 esté en el mismo directorio de KetshashRunner.exe
Haz doble clic en KetshashRunner.exe, cambia la configuración si es necesario y presiona Ejecutar
Invoke-DetectPTH
Ejemplo (recomendado):
Invoke-DetectPTH -TargetComputers "MARS-7" -LogFile "C:\tmp\log.txt"
Ejemplo:
Invoke-DetectPTH -TargetComputers "ComputerName" -StartTime ([datetime]"2017-12-14 12:50:00 PM") -LogFile "C:\tmp\log.txt" -UseKerberosCheck -UseNewCredentialsCheck
Debugging
Debido a que utiliza threads, no es posible depurar el bloque de script de la función principal. Una solución alternativa puede ser utilizando Invoke-Command antes de Detect-PTHMultithreaded:
Invoke-Command -ScriptBlock $detectPTHScriptBlock -ArgumentList $TargetComputers, $startTime, $LogFile, $UseKerberosCheck, $UseNewCredentialsCheck, $MaxHoursOfLegitLogonPriorToNTLMEvent`
Detectar sólo un equipo destino:
Invoke-DetectPTH -TargetComputers "" ...
Cambia $TargetComputer a una [string] en lugar de un [array]. De esta forma es posible utilizar breakpoints dentro del bloque de scripts de la función principal.
Proyecto: https://github.com/cyberark/ketshash
La herramienta se publicó como parte de la investigación "Detección de Pass-The-Hash", tienes más detalle en:
https://www.cyberark.com/threat-research-blog/detecting-pass-the-hash-with-windows-event-viewer
La investigación completa se puede encontrar en el whitepaper:
https://www.cyberark.com/resource/pass-hash-detection-using-windows-events/
Windows almacena diferentes tipos de valores hash, derivados de la contraseña del usuario, para permitir el acceso a diferentes servicios sin la necesidad de volver a ingresar la contraseña. Uno de esos tipos de hash es un hash MD4 de la contraseña también conocido como NTLM hash.
El protocolo NTLM utiliza el hash NT para la autenticación y no hace un 'salt' de la contraseña, lo que a su vez significa que si uno toma el valor del hash, la autenticación se puede realizar sin conocer la contraseña real.
Cuando se lleva a cabo una conexión NTLM se registrará en la máquina destino un Evento con ID 4624 ("Una cuenta inició sesión correctamente") con Logon Type 3 ("Un usuario o computadora inició sesión en esta computadora desde la red") y Authentication Package NTLM (o por nombre de proceso de logon NtLmSsp):
Un atacante por lo tanto puede autenticarse sin una contraseña pasando el hash. Para ello tendrá dos opciones:
- Inyectar el hash en LSASS.exe y abrir sesión con el hash inyectado.
- Implementar parte del protocolo NTLM para la autenticación con el hash y enviar comandos a través de la red con protocolos como SMB, WMI, etc.
La principal diferencia entre pasar el hash a una conexión NTLM legítima es el uso de una contraseña. La búsqueda de inicios de sesión de usuarios legítimos, donde se usó la contraseña antes de la conexión NTLM, puede ayudar a filtrar todos los inicios de sesión legítimos y dejar solo el inicio de sesión sospechoso.
Conexiones legítimas desde el visor de eventos
El visor de eventos contiene una cantidad de registros que indican inicios de sesión interactivos:
4768 - Se solicitó un ticket de autenticación de Kerberos (TGT)
4769 - Se solicitó un ticket de servicio Kerberos (TGS)
4648 - Se intentó un inicio de sesión utilizando credenciales explícitas
4624 - Se inició sesión correctamente en una cuenta
Tipos de inicio de sesión: 2 (Interactivo), 7 (Desbloqueo), 10 (RemoteInteractive) o 11 (CachedInteractive).
Comprobar que cada conexión NTLM tenía un inicio de sesión interactivo con la misma cuenta antes de la conexión, basándose en los registros anteriores, puede ayudar a distinguir entre un atacante que usa el hash y un usuario normal que usa la contraseña.
Algunas conexiones NTLM son más arriesgadas que otras
Un inicio de sesión creado a través de una conexión NTLM con una cuenta sin privilegios es menos arriesgada que una con una cuenta con privilegios. Por ejemplo, Event ID 4672 ("Privilegios especiales asignados al nuevo inicio de sesión") nos permite saber cuándo se inicia sesión con una cuenta con privilegios. Al crear la correlación entre la conexión NTLM y el evento ID 4672, se filtrarán todas las conexiones NTLM privilegiadas que pueden realizar cambios en la computadora de destino, como se ve en la siguiente imagen:
Detectando Pass-The-Hash
Al unir todas las piezas, podemos buscar conexiones NTLM privilegiadas y verificar si tenían un inicio de sesión legítimo antes de la conexión NTLM al correlacionar con identificadores de eventos buenos conocidos. Para facilitar la tarea, la empresa israelí CyberArk ha creado la herramienta Ketshash que automatiza la detección de conexiones NTLM con privilegios sospechosos, en particular ataques Pass-The-Hash, en función de los registros del visor de eventos.
En el siguiente vídeo se muestra cómo este enfoque (con la ayuda de Ketshash) es eficaz para detectar los ataques de PTH utilizados por PTH-winexe, Mimikatz, WCE e Invoke-SMBClient:
Requisitos:
Cuenta con los siguientes privilegios:
- Acceso a registros de eventos de seguridad de máquinas remotas
- Permisos de lectura de ActiveDirectory (cuenta de dominio estándar)
- Computadoras sincronizadas con el mismo tiempo, de lo contrario puede afectar los resultados
- PowerShell 2.0 como mínimo
Uso
Hay dos opciones:
- Uso Básico
Abre PowerShell y ejecuta:
Import-Module. \ Ketshash.ps1 o copiar y pegar el contenido de Ketshash.ps1 a la sesión de PowerShell
Invoke-DetectPTH
- Ketshash Runner
Hay que asegurse de que Ketshash.ps1 esté en el mismo directorio de KetshashRunner.exe
Haz doble clic en KetshashRunner.exe, cambia la configuración si es necesario y presiona Ejecutar
Invoke-DetectPTH
TargetComputers: array de equipos destino para detectar conexiones NTLM. TargetComputersFile: ruta al archivo con una lista de equipos de destino para detectar conexiones NTLM. StartTime - Hora en que comienza la detección. El valor predeterminado es la hora actual. UseKerberosCheck - Comprueba el inicio de sesión de TGT\TGS en los DC de la organización. El valor predeterminado es buscar el inicio de sesión legítimo en la máquina fuente. De todos modos, con o sin este parámetro todavía hay una consulta para el evento ID 4648 en la máquina de origen. UseNewCredentialsCheck - Comprueba los eventos de inicio de sesión con el tipo de inicio de sesión 9 (como Mimikatz). Esto es opcional, el algoritmo por defecto ya lo cubre. Existe solo para mostrar otra opción para detectar conexiones NTLM sospechosas. En las versiones de Windows 10 y Server 2016, se debe habilitar "Microsoft-Windows-LSA / Operational" en el visor de eventos. En Windows 10 y Server 2016, habilitar la "auditoría de objetos del kernel" proporcionará información más precisa, como escribir en LSASS. LogFile - Ruta del archivo de registro para guardar los resultados. MaxHoursOfLegitLogonPriorToNTLMEvent: cuántas horas hay que mirar hacia atrás y buscar un inicio de sesión legítimo desde el momento del evento NTLM. El valor predeterminado es de 2 horas hacia atrás.
Invoke-DetectPTH -TargetComputers "MARS-7" -LogFile "C:\tmp\log.txt"
Ejemplo:
Invoke-DetectPTH -TargetComputers "ComputerName" -StartTime ([datetime]"2017-12-14 12:50:00 PM") -LogFile "C:\tmp\log.txt" -UseKerberosCheck -UseNewCredentialsCheck
Debido a que utiliza threads, no es posible depurar el bloque de script de la función principal. Una solución alternativa puede ser utilizando Invoke-Command antes de Detect-PTHMultithreaded:
Invoke-Command -ScriptBlock $detectPTHScriptBlock -ArgumentList $TargetComputers, $startTime, $LogFile, $UseKerberosCheck, $UseNewCredentialsCheck, $MaxHoursOfLegitLogonPriorToNTLMEvent`
Detectar sólo un equipo destino:
Invoke-DetectPTH -TargetComputers "
Cambia $TargetComputer a una [string] en lugar de un [array]. De esta forma es posible utilizar breakpoints dentro del bloque de scripts de la función principal.
Proyecto: https://github.com/cyberark/ketshash
La herramienta se publicó como parte de la investigación "Detección de Pass-The-Hash", tienes más detalle en:
https://www.cyberark.com/threat-research-blog/detecting-pass-the-hash-with-windows-event-viewer
La investigación completa se puede encontrar en el whitepaper:
https://www.cyberark.com/resource/pass-hash-detection-using-windows-events/
¿Soy el único incapaz de descargar el paper?
ResponderEliminarHi, inside this link you have another link to the white paper:
ResponderEliminarhttps://www.cyberark.com/resource/pass-hash-detection-using-windows-events/