La técnica que hoy se muestra en el artículo no es nueva, pero podemos decir que para muchos será desconocida. Este técnica tiene grandes frases cómo: “Todas las puertas de tu Active Directory quedan abiertas con la técnica Skeleton Key”. Al principio el tema puede parecer complejo, pero viendo en qué se basa, la idea es sencilla. Podemos hablar de que Skeleton Key te da persistencia, pero realmente es parcial, ya que en el momento que se reinicie el DC o Domain Controller se acabó la persistencia. El tema es que un DC no se reinicia todos los días, por lo que podemos hablar de cierto grado de persistencia.

Figura 1: Skeleton Key: Cómo poner una clave maestra en el Domain Controller en Windows Server 2016 y controlarlo una vez hackeado

Antes de hablar en qué consiste esta técnica y ponerla a prueba vamos a hablar de que hay varios métodos para comprometes cuentas de Active Directory con el objetivo de escalar privilegios y crear persistencia. ¿De dónde viene esta técnica? Fue vista en malware orientado a dominios de Active Directory, el cual permitía el secuestro de cualquier cuenta. ¿Cómo? Esta pieza de código se inyectaba en el proceso lsass.exe y creaba lo que llamaremos una contraseña maestra, la cual funcionaría para cualquier cuenta del dominio. La idea mola. 

 

Figura 2: Libro Windows Server 2016: Administración, Seguridad y Operaciones

Lo curioso de la técnica es que las contraseñas existentes también siguen funcionando, por lo que es complejo saber si el ataque se ha llevado a cabo. Más adelante hablaremos de la mitigación o el cómo darse cuenta o tener indicios de que Skeleton Key ha sido ejecutada en nuestro DC. Para entender bien esta técnica, cuantos más conocimientos tengas de Windows Server 2016:Administración, Seguridad y Operaciones, mejor que mejor, así que te recomiendo la lectura de este libro de 0xWord que explica muchos de los conceptos que vamos a utilizar hoy. Y si tienes tiempo, puedes hacerte el VBook de Windows Server 2016.

Requisitos antes de comenzar  

Los requisitos del ataque Skeleton Key son los siguientes:

- Solo es aplicable a los Domain Controller. 

- El pentester tiene que ser admin del dominio. 

- Cuando la máquina reinicia, el DC eliminará el Skeleton Key y deberá ser desplegado de nuevo si se quiere optar a tener los privilegios que se consiguen con Skeleton Key.

¿En qué consiste? Este ataque se aplica sobre dos métodos de autenticación: NTLM y Kerberos. Cuando se realiza la autenticación NTLM se inyectará el hash NTLM de la contraseña maestra, si lo hacemos con Mimikatz, ésta será “mimikatz”. El hash se inyecta en el proceso lsass.exe y no se comprobará contra la SAM. De esta forma, cuando hagamos login con el usuario X y la contraseña correspondiente al hash que hemos inyectado, se logrará autenticar en el controlador de dominio.

Figura 3: Máxima Seguridad en Windows Gold Edition

El cifrado de Kerberos sufrirá un “downgrade” a un algoritmo que no soporte “salt”: RCA_HMAC_MD5 y el hash que se recupera del AD es reemplazado por el hash generado con la técnica Skeleton Key. El hash que corresponde con la contraseña maestra es validado en el lado del servidor, por lo que se consigue una autenticación exitosa, tanto en NTLM como en Kerberos.

Skeleton Key ‘on fire’

Antes de empezar a jugar vamos a proponer un escenario sencillo, pero real. A continuación se muestra:

- Metasploit (en cualquier máquina o contenedor de Docker que tengáis a mano). Intentaremos que sean últimas versiones. Yo he realizado un msfupdate antes de ejecutarlo. 

- Máquina Windows Server 2016 con dominio de pruebas HC (de mi querido hackersClub). 

- Máquina con un Windows cliente para conectarse con la clave maestra, una vez hecho el proceso.

Para entrar en el Domain Controller vamos a simular el acceso con el módulo web_delivery de Metasploit. Tras comprometer el Domain Controller habría que lograr escalar privilegios en el sistema, ya que sin ello no se podría hacer uso de Skeleton Key. En la siguiente imagen se puede visualizar la configuración del módulo web_delivery de Metasploit con el uso de un Meterpreter inverso. Ese código Powershell es el que utilizaremos para simular la intrusión.

Figura 4: Ataque con módulo web_delivery

Una de las cosas que me ha sorprendido de las últimas versiones y las modificaciones que ha ido sufriendo el código Powershell que se genera con Metasploit es que primero envía un código de bypass de AMSI y, posteriormente, se ejecuta el resto del payload.

Figura 5: Pentesting con Powershell 2ª Edición

Es decir, primero se deshabilita AMSI en el proceso de Powershell y luego se ejecuta el resto del script que proporcionará un Meterpreter en memoria. Ya hemos comentado en el blog que esto, hoy en día es fundamental, ya que AMSI puede detectaros un gran número de herramientas, entre las que se encuentra nuestra querida iBombshell: La estrategia es, primero quito AMSI, luego ejecuto herramienta.

Figura 6: Bypass de AMSI y ejecución de payload

Tras obtener la sesión de Meterpreter en Windows Server 2016, vamos a mostrar algunos detalles importantes.

Figura 7: Información del sistema contrtolado

Como se puede la máquina se llama HC-SERVER, la arquitectura es de 64 bits, tanto en máquina como el Meterpreter, y vemos que tenemos privilegios para impersonar a SYSTEM, por lo que entonces lo hacemos. Aquí ya hemos simulado esa escalada de privilegios, tendríamos el control del Domain Controller. Y desde aquí podríamos planear todos los ataques del Hacking Windows que quisiéramos.

Figura 8: Libro de Hacking Windows

Ahora, se puede hacer de varias formas. Podemos generar un Mimikatz y subirlo, pero debemos tener en cuenta que no nos lo “caze” el AV. Podemos cargar el módulo Kiwi que tiene Meterpreter y ejecutar la sentencia de Mimikatz sobre Skeleton Key.  Para ello, haremos uso de “load kiwi” y cargamos la extensión. Es importante que el payload sea de 64 bits, ya que aquí podemos encontrarnos un punto de fallo. Por otro lado, la sentencia a ejecutar para cargar Skeleton Key es: “kiwi_cmd misc::skeleton”.

Figura 9: Cargando kiwi

Como se puede ver, todo ha ido bien y tenemos el “patch” listo. Ahora, vamos a ir a la máquina cliente, la cual puede ser nuestra u otra máquina que se haya comprometido en el pentesting.  Antes de nada, hay que indicar que con la herramienta Mimikatz, desde su propia consola, hay que ejecutar lo siguiente:

- Privilege::debug 

- Misc::skeleton

 

Figura 10: mimikatz

Hay que fijarse en la contraseña utilizada “mimikatz”. El usuario va con el dominio explícito y, como se puede ver, funciona. Para ver un poco más en detalle, deshacemos la instrucción anterior y comenzamos de nuevo. 

Figura 11: Autenticación remota con password "mmikatz"

- ID 7045 

- ID 4673 (En este “Audit Privilege Use” debe estar habilitado) 

- ID 4611 (“Audit Privilege Use” debe estar habilitado)

Get-WinEvent -FilterHashtable @{Logname='System';ID=7045} | ?{$_.message -like "Kernel Mode Driver"}

Get-WinEvent -FilterHashtable @{Logname='System';ID=7045} | ?{$.message -like "Kernel Mode Driver" -and $.message -like "mimidrv"}

New-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPL -Value 1 -Verbose

Get-WinEvent -FilterHashtable @{Logname='System';ID=12} | ?{$_.message -like "protected process"}

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 12: Contactar con Pablo González