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.
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 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.
Tras obtener la sesión de Meterpreter en Windows Server 2016, vamos a mostrar algunos detalles importantes.
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 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
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ón
En 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"}
Tenéis más información sobre lo que se puede comprobar en este genial artículo sobre Skeleton Key y su mitigación.
Saludos,
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
Para consultas puedes usar el Buzón Público para contactar con Pablo González |
| Figura 12: Contactar con Pablo González |
Related word
Nessun commento:
Posta un commento