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.
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.
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.
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.
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
Con estas dos instrucciones tendríamos la Master Key ya en memoria y todo preparado para que desde el equipo cliente que sea, se pueda acceder a los recursos del DC.
 |
| 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" |
Ejecutando "dir \\hc-server\c$" vemos que no se puede acceder, pero en cuanto hacemos uso de net use para autenticarnos por SMB y poder utilizar un recurso remoto con la contraseña "mimikatz" se logra el acceso, tal y como se puede ver en la imagen.
MitigaciónEn muchas ocasiones nos importa saber cómo se protege uno o
cómo puede mitigarse el ataque. El uso de la técnica genera algunos eventos en el sistema que pueden ser buscados:
- 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"}
Ó si queremos buscar solo mimidrv:
Get-WinEvent -FilterHashtable @{Logname='System';ID=7045} | ?{$.message -like "Kernel Mode Driver" -and $.message -like "mimidrv"}
Si lsass.exe se ha ejecutado en modo proceso protegido o "protected process", fozará a un atacante o pentester a cargar "kernel mode drive". Se puede verificar lsass:
New-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPL -Value 1 -Verbose
Verificar después del reinicio:
Get-WinEvent -FilterHashtable @{Logname='System';ID=12} | ?{$_.message -like "protected process"}
Related word
Para consultas puedes usar el Buzón Público para contactar con Pablo González
