KERBEROASTING – El ataque a dominios Microsoft Numero 1 entre los hackers

KERBEROASTING – En el ambiente de administración de dominios, más conocido como Active Directory o Directorio Activo hay un tipo de cuentas que son específicas para la ejecución de un servicio. Generalmente, este tipo de cuentas disfrutan de privilegios excesivos y muchas veces también pertenecen al grupo de “Administradores de Dominio” en los controladores de dominio. Para incrementar la vulnerabilidad, están cuentas raramente son auditadas.

El nombre de este ataque (Kerberoasting) fue dado por Tim Medin y el proceso de ataque fue presentado en DerbyCon 2014.

Antes de proceder a la demostración de este ataque debemos entender un proceso de autenticación usado por sistemas Microsoft llamado Kerberos.

KERBEROASTING

KERBEROASTING – Anatomia de un ataque interno

Cuando un atacante obtiene un acceso inicial a través de phishing email, ataque USB, o alguna contraseña débil, puede fácilmente enumerar este tipo de cuentas utilizadas para acceder a los servicios usando el comando “setspn -T NombreDelDominio -Q */*”

SETSPN es una herramienta de línea de comandos integrada desde la versión Windows Server 2008. Pero se da el caso que puede ser descargada desde Microsoft y ejecutada como un .exe file desde cualquier usuario en un ambiente de dominio. Aquí ejecutamos la herramienta SETSPN desde un usuario llamado “usuario.vulnerable”.

Como podemos ver, procedemos a enumerar al usuario “usuario.vulnerable” y descubrimos que este posee permisos básicos en el dominio. “usuario.vulnerable” representa a cualquier usuario descuidado que permitió el acceso a un agente externo a la red interna.

Pero al momento de ejecutar la herramienta SETSPN podemos encontrar un montón de información reveladora:

Lo que estamos viendo aquí son los nombres de servicios principales (SPNs) en el bosque al cual el dominio “notanseguro.com” pertenece.

El último boleto necesita una mirada un poco más exhaustiva:

Este boleto fue creado para que el usuario “SVC-SERVICIOSQL” tuviera acceso al servidor llamado

“SERVIDORSQL.notanseguro.com” a través del puerto 1433, que es el puerto por defecto del servicio MSSQL.

Generalmente, los atacantes están más interesados en cuentas que tengan un “AdminCount” de 1 porque estas cuentas son cuentas privilegiadas que están o estuvieron en algún grupo de dominio con privilegios. Te invito a que puedas encontrar más información sobre ataques usando AdminCount de 1 en:

https://seguridad-ofensiva.com/blog/directorioactivoseguridad/admincount1/(abre en una nueva pestaña)

El boleto ya mencionado nos hace asumir que en un momento el usuario completó el proceso de autenticación de Kerberos que examinamos al principio y que además un administrador de sistema configuro a este usuario con los permisos necesarios para poder tener un acceso privilegiado a este tipo de recursos a través del puerto 1433 en el servidor “SERVIDORSQL”. El proceso de ataque requiere que solicitemos un boleto Kerberos, en este caso un TGS boleto en nombre del usuario “SVC-SERVICIOSQL” con destino al servidor “SERVIDORSQL”. Ahora, me imagino que hay dos preguntas dando vueltas:

¿Como es posible que este proceso de autenticación llamado Kerberos sea vulnerable?

¿Como podemos completar este proceso de ataque?

Bueno, la respuesta para la primera pregunta no es tan complicada, lo que sucede es que el controlador de dominio, en el proceso de generación del boleto de servicio utiliza un tipo de cifrado llamado RC4_HMAC_MD5, el cual utiliza el hash NTLM de la contraseña del usuario que solicitó el acceso al servicio, en este caso el usuario que solicita el servicio fue “SVC-SERVICIOSQL”. Esto implica que, si somos capaces de adquirir el boleto, lo podemos manipular para descifrar la contraseña si tenemos acceso al hash escondido en el boleto.

Respondiendo a la segunda pregunta, el proceso de ataque implica varios pasos. Lo primero es solicitar el boleto en nombre del usuario “SVC-SERVICIOSQL”; al obtener el boleto, este queda guardado en la memoria del computador, en ese momento el boleto se puede extraer, guardar y procesar, lo que implica dar un formato que un programa de fuerza bruta pueda procesar para encontrar la contraseña del usuario “SVC-SERVICIOSQL”.

La buena noticia es que todo este proceso es automatizado usando PowerShell. Will Schroeder creo un PowerShell script que permite ejecutar todo este proceso obteniendo al final de este un cifrado listo para ser ejecutado en Hashcat permitiendo obtener la contraseña del usuario. Veamos…

Como podemos ver, al momento de ejecutar el script PowerShell, obtenemos el hash de “SVC-SERVICIOSQL”. Ahora es muy importante indicar que los ataques usando PowerShell son tremendamente difíciles de detectar por los antivirus debido a su versatilidad. Debemos recordar que PowerShell es una herramienta nativa incluida en la mayoría de las versiones de los sistemas operativos Windows. Hay incontables formas de ejecutar estos PowerShell scripts en la memoria del computador sin tocar el disco duro, lo que permite no ser detectado por los antivirus; incluso, es posible correr PowerShell script en forma encriptada.

Veamos el mismo ataque corriendo en forma encriptada…

Obteniendo el mismo resultado y sin ser detectado por los antivirus:

Otra forma que mencione, fue que es posible ejecutar el mismo tipo de ataque en la memoria del computador sin tocar el disco:

Obteniendo de nuevo el mismo resultado y sin ser detectado por los antivirus.

Es muy importante recalcar estos procesos porque una y otra vez vemos que las empresas no están prestando suficiente atención a las nuevas modalidades de los ataques permitiendo el uso indiscriminado de ataques usando PowerShell.

Al fin, el hash del boleto que incluye el hash NTLM fue obtenido. Ahora es tiempo de procesarlo usando Hashcat para obtener la credencial del usuario:

Este proceso de fuerza bruta es ejecutado en el computador del atacante. Me gustaría que pudieran prestar atención un poco al código que se utilizó para obtener la contraseña “Pass1234!!” que pueden ver al final del código.

En este caso utilizamos “-m 13100”, lo que para Hashcat significa que estamos procesando un hash llamado “Kerberos 5 TGS-REP etype 23”.

De esta forma y al finalizar el proceso la cuenta perteneciente al usuario “SQL SERVICIO” ha sido vulnerada. Quizás en este momento estés pensando que esto no es un problema. La verdad es un muy grave problema para la empresa que tiene este tipo de configuración sin los mecanismos de seguridad correspondiente, porque en este caso “SVC-SERVICIOSQL” es parte del grupo de los “Administradores de Dominio”:

Si, estás viendo bien, desde un usuario con permiso regular se pueden enumerar los usuarios, los grupos, los permisos, y un sinfín de datos haciendo llamadas al controlador de dominio sin ninguna dificultad para el atacante. En este caso, el atacante procedió a enumerar los usuarios del grupo de administradores de dominio descubriendo que el usuario recién vulnerado era de gran valor, lo que al final le permitió un acceso al controlador de dominio como administrador del sistema usando PowerShell Remote:

Ahora si hay un grave problema.

¿Cómo Seguridad-Ofensiva puede ayudarme a mantener mi dominio libre de vulnerabilidades internas?

En Seguridad-Ofensiva hemos prestado atención a la situación real de los dominios. Entendemos que muchas veces los administradores de dominio no tienen tiempo para dedicarse al estudio y la búsqueda de vulnerabilidades tan peligrosas como esta porque están ocupados dando soporte a los empleados, creando nuevos usuarios o reemplazando computadores. Si ese es el caso de su departamento de tecnología, lo invitamos a que nos contacte para que de esa forma podamos contarle de nuestros procedimientos NO INVASIVOS. Nuestra intención es darle una solución real a las vulnerabilidades internas a las cuales los antivirus no pueden identificar. Sírvase contactarnos a info@seguridad-ofensiva.com

Si desea conocer más de nuestros servicios especializados en la prevención de vulnerabilidades en redes internas lo invitamos a visitar: https://seguridad-ofensiva.com/pruebas-de-penetracion-internas

Estamos aquí para evaluar e incrementar la seguridad de su entorno tecnológico.

 

YouTube Channel

REMEDIACIÓN ATAQUES INTERNOS

Leave a Reply

Your email address will not be published. Required fields are marked *