Hola!
Tenia que publicar esta entrada hace bastante tiempo, pero por temas de vacaciones la retrase bastante, estuve ocupado, pero bueno, acá esta, como siempre intentando divulgar un poco el conocimiento que obtuve.
Continuando con el tema de ACLs, acá veremos otros tipos de ataques que abusan permisos excesivos otorgados sobre ciertos objetos de dominio.
Utilizaremos como siempre la instancia de AD desplegada en posts anteriores, agregando ciertas configuraciones inseguras para demostrar la explotación.
Agregue a un nuevo usuario al dominio interno, llamado max.power.
Adicionalmente, agregué un nuevo equipo al dominio interno, asegurándome de utilizar la cuenta max.power para esta acción.
Ya que el usuario que agrego a este nuevo equipo al dominio es max.power, el mismo tiene ciertos privilegios de modificación sobre el equipo (para modificar las propiedades de este, no necesariamente como administrador local).
Utilizaremos a este equipo SOPORTE01 para las acciones respectivas.
Sin embargo, ya que nosotros agregamos a este equipo al dominio a traves de la interfaz de Windows, no conocemos su contraseña, por lo que posteriormente, asumiendo el compromiso del usuario max.power, agregaremos un nuevo equipo a través de la linea de comandos, realizaremos un ataque RBCD (Resource Based Constrained Delegation) desde el nuevo equipo hacia SOPORTE01 y luego desde el equipo SOPORTE01 hacia TECNOLOGIA01.
Adicionalmente, por temas de simplicidad, se agregaran permisos de control total de max.power sobre el equipo SOPORTE01.
Configuración para ataque de RBCD.
Otorgando permisos de control total desde el equipo SOPORTE01 hacia TECNOLOGIA01.
Accedemos a la ventana ADSI en nuestro controlador de dominio, buscando al grupo Computers, click derecho en el equipo TECNOLOGIA01 y accedemos a properties.
Obtenemos la lista de objetos del dominio que tienen algún privilegio definido de manera explicita sobre este equipo.
Le damos click a add y nos mostrara la pantalla que se vio en anteriores posts, pero aca necesitamos un paso adicional, darle click a Object Types en la primera opción.
En la nueva ventana, seleccionamos Computers y le damos OK.
Por defecto, no se consideran a las computadoras del dominio para otorgar estos privilegios de control, pero al haber marcado la opción, podemos escribir SOPORTE01 y darle click a Check Names.
Se identifico el objeto de dominio, le damos OK y otorgamos control total sobre TECNOLOGIA01.
Agregando los mismos tipos de permisos para el usuario max.power sobre SOPORTE01.
Configuración para ataque de Targeted Kerberoasting.
En la configuración de ADSI, buscamos al usuario jsec y le modificamos las propiedades, otorgando privilegios de escritura de propiedades del objeto para el usuario max.power.
Confirmando el nivel de permisos.
Ejecución de Sharphound desde un equipo fuera del dominio
Es posible ejecutar herramientas de enumeración de dominio desde equipos que no están asociados al mismo utilizando funcionalidades propias de Windows, esto es bastante útil en Pentests internos donde se le otorga al consultor un solo punto de red para su equipo y las estaciones de trabajo internas cuentan con medidas de seguridad eficientes (Antivirus bien configurado, EDR, restricción de acceso a cmd, powershell y rundll, no se permite la ejecución de binarios no firmados, AMSI, etc.).
Se levanto un nuevo equipo Windows, que no se agregará al dominio.
Se realiza la descarga de Sharphound.
Link: https://github.com/BloodHoundAD/SharpHound/releases/download/v1.1.0/SharpHound-v1.1.0.zip
Descomprimiendo el archivo, se tiene el binario Sharphound.exe que se ejecutara, sin embargo, para poder ejecutarlo sin problemas necesitamos configurar los servidores DNS de nuestro equipo externo, apuntando al DC del dominio objetivo.
Confirmamos que podemos resolver el dominio jsec.local y el equipo ATENCION01.
Descomprimiendo el archivo e intentando ejecutarlo obtenemos un error.
El mensaje de error confirma que si llegamos al DC objetivo, pero que no tenemos credenciales válidas.
Tiene sentido, ya que el equipo no esta en dominio, la sesión activa y utilizada por la herramienta es la de un usuario local que no es válido en jsec.local.
Si bien Sharphound tiene la opción de definir las credenciales a utilizar, yo prefiero levantar una nueva terminal que utilice el perfil de un usuario de dominio para la comunicación por red, para no tener que estar definiendo credenciales de usuario en cada herramienta que se vaya a utilizar, para esto utilizo runas.
Comando: runas /netonly /user:jsec.local\max.power cmd.exe
En este caso, utilizo el binario runas para levantar un proceso como un usuario distinto, /netonly indica que la comunicación por red utilizara el perfil de usuario definido, /user define el usuario a utilizar y al final se especifica que proceso se quiere levantar con estas credenciales.
Cabe destacar que es necesario introducir la contraseña del usuario después de ejecutar el comando, sin embargo, este no valida si la credencial es valida o no, por lo que se recomienda tener mucho cuidado al momento de introducir la contraseña.
Se levanta la nueva consola cmd y la descripción (running as jsec.local\max.power), indicando que estamos utilizando el perfil de este usuario y que las herramientas de enumeración de dominio utilizaran estas credenciales por defecto.
Si volvemos a ejecutar Sharphound desde esta nueva consola, observamos que se logra conectar al DC y obtener la información respectiva.
Copiamos el fichero generado a nuestro equipo Kali o donde se tenga instalado Bloodhound para analizarlo.
Ya en la interfaz de Bloodhound, seleccionamos la query Find shortest paths to Domain Admins, obteniendo el siguiente resultado.
Algunos paths ya fueron explorados en posts anteriores, por lo que nos concentraremos en los dos remarcados.
El primero indica que el usuario max.power tiene privilegios de escritura de propiedades sobre el usuario jsec, el cual pertenece al grupo de domain admins, confirmando que se puede realizar un ataque tipo Targeted Kerberoast.
El segundo caso indica que el equipo SOPORTE01 tiene control total sobre el equipo TECNOLOGIA01, miembro del grupo Domain Admins, dando lugar a un ataque tipo Resource Based Constrained Delegation.
Ahora nuestros dos caminos son:
- Utilizar al usuario max.power para generar un ticket SPN del usuario jsec y crackearlo de manera offline.
- Obtener control del equipo SOPORTE01 y con su hash NTLM, realizar un ataque tipo RBCD para obtener control de TECNOLOGIA01 y el dominio respectivo.
Para el segundo punto, analizamos al objeto SOPORTE01, especificamente sus Explicit Object Controllers.
El usuario max.power tiene privilegios totales sobre el equipo, dando lugar a otro ataque tipo RBCD.
EXPLOTACION – RBCD
Procedemos con el vector de ataque a través de RBCD, como max.power tiene control del equipo SOPORTE01, podemos modificar la propiedad msDS-AllowedToActOnBehalfOfOtherIdentity.
Según la definición de la documentación de Microsoft.
“Este atributo se usa para las comprobaciones de acceso para determinar si un solicitante tiene permiso para actuar en nombre de otras identidades en servicios que se ejecutan como esta cuenta.”
Ref: https://docs.microsoft.com/es-es/windows/win32/adschema/a-msds-allowedtoactonbehalfofotheridentity
Por temas de simplicidad, definiremos a esta propiedad como la capacidad de un host de dominio, de interactuar con este a nombre de otro host, esta interacción incluye la solicitud de tickets de acceso por Kerberos.
Entonces, yo puedo modificar la propiedad del equipo SOPORTE01, indicando que otro equipo tiene los privilegios de solicitar tickets de Kerberos a nombre de SOPORTE01.
Para este caso, crearemos un nuevo equipo en el dominio interno a través de la linea de comandos, ya que por defecto, en una instalación estándar de un Active Directory, cualquier usuario registrado puede agregar hasta 10 equipos al dominio interno (propiedad MS-DS-Machine-Account-Quota de los usuarios).
Explotación desde Kali
Utilizando impacket, el usuario max.power crea un nuevo equipo llamado jsecrbcd.
Ahora, ya que max.power tiene privilegios de escritura sobre las propiedades de SOPORTE01, modificamos su contenido indicando que el equipo jsecrbcd puede personificar al equipo SOPORTE01.
La acción se ejecuto de manera correcta, indicando que la cuenta jsecrbcd$ puede personificar usuarios en el equipo SOPORTE01.
Utilizamos estos privilegios para solicitar un ticket de acceso por Kerberos hacia SOPORTE01, personificando al usuario de dominio Administrator.
Es necesario utilizar la cuenta del equipo que se creo y que tiene privilegios de actuar a nombre de SOPORTE01 para esta acción, por eso es importante conocer la contraseña.
Exportando el ticket como variable de entorno con el comando export KRB5CCNAME=Administrator.ccache, validamos que el mismo sea reconocido.
De esta manera, tenemos una sesión válida con los privilegios de un Domain Admin únicamente sobre el equipo SOPORTE01.
Comando: impacket-secretsdump.py -k (autenticación por kerberos) -no-pass (no solicitar password de la cuenta, útil y necesario para interacción con Kerberos) DOMINIO/USUARIO(en este caso, usuario al que se personifico con el ticket de kerberos solicitado)@EQUIPO(FQDN).
El primer paso esta realizado, ya controlamos al equipo SOPORTE01 y según lo observado en Bloodhound, podemos utilizarlo para replicar este ataque hacia el equipo TECNOLOGIA01, para esto necesitamos la contraseña o el hash NTLM de este equipo, el cual esta remarcado (por funcionalidad, la contraseña de este equipo cambia cada 30 días).
Cabe destacar que un equipo unido al dominio tiene su propio usuario, identificado como el hostname y el simbolo $ al final del mismo, en este caso, para el equipo de dominio SOPORTE01, su usuario es SOPORTE01$, esto lo podemos validar de manera directa con el DC.
Este usuario de equipo tiene privilegios mínimos, pero en instalaciones por defecto, tiene la posibilidad de agregar hasta 10 equipos al dominio interno, así que replicamos los pasos anteriores.
Agregamos un equipo al dominio llamado jsecrbcd2, esta ves utilizando al usuario SOPORTE01$.
Ejecutamos el ataque de cambio de propiedades sobre el equipo TECNOLOGIA01 con el usuario SOPORTE01$, ya que según Bloodhound, este usuario tiene privilegios de escritura sobre el objetivo.
Los permisos de delegación se agregaron correctamente, por lo que el equipo recien creado puede actuar a nombre de TECNOLOGIA01.
Obteniendo el ticket de Kerberos como un usuario Administrador de dominio utilizando la cuenta de equipo creada y que puede actuar a nombre de TECNOLOGIA01.
Extracción de hashes del equipo TECNOLOGIA01 utilizando el ticket de Kerberos.
De esta manera, obtenemos control administrativo del equipo y, más importante, su hash NTLM, ya que podemos utilizarlo para comprometer el dominio interno.
Realizando un DCSYNC utilizando al usuario TECNOLOGIA01$ y su hash.
Se obtiene control total del dominio, abusando los privilegios excesivos entre objetos del dominio.
Como recomendaciones principales:
- Evitar otorgar privilegios de control total o escritura a usuarios regulares y equipos de dominio, en caso de que se necesite alguno de estos privilegios en un usuario, se recomienda crear un usuario especifico para esta tarea, con una contraseña compleja y que no sea utilizado por usuarios internos para sus labores diarias.
- Revocar los privilegios de creación de equipos para usuarios no privilegiados, ya sea restringiendo totalmente la creación o modificando la propiedad MS-DS-Machine-Account-Quota del dominio, estableciendola en 0.
- No agregar equipos como administradores de dominio.
EXPLOTACIÓN DE TARGETED KERBEROASTING.
Explorando el primer vector.
Ya que asumimos el compromiso del usuario max.power, podemos utilizarlo para generar un ticket SPN del usuario jsec, miembro del grupo de administradores de dominio e intentar crackear su contraseña.
Como se esta ejecutando todo desde Kali, se utilizara un script especifico para esta tarea.
targetedkerberoast.py
https://github.com/ShutdownRepo/targetedKerberoast
Este script automatiza la explotación de este ataque, realizando los siguientes pasos:
- Utilizando los privilegios del usuario especificado, intenta modificar las propiedades del objeto jsec, agregando un ticket SPN en el dominio interno.
- Extrae todos los tickets SPN registrados en el dominio, incluyendo el del usuario jsec que fue definido momentos antes.
- Una vez se muestra el ticket SPN, lo elimina.
Si bien se puede explotar este camino, el éxito depende de la complejidad de la contraseña utilizada para el usuario jsec.
Ejecutando la herramienta.
Observamos que se agrego un ticket SPN para el usuario jsec, mostrando el ticket respectivo y posteriormente eliminandolo.
Guardamos el contenido del ticket en un fichero y procedemos a su crackeo respectivo.
Al tratarse de un ticket SPN, el módulo a utilizar en hashcat es 13100.
Vemos que, debido a que la contraseña utilizada es bastante débil, obtenemos la contraseña de manera inmediata.
Validamos la credencial en el DC, observando que se tiene control administrativo sobre el mismo.
Si bien este tipo de ataques no son tan comunes en entornos reales, existen casos muy específicos donde pueden ser viables, yo recientemente tuve dos proyectos en los que fue posible explotar estos puntos para acceder a ciertos servidores considerados críticos, un punto importante a considerar es que la configuración de seguridad de un dominio llega a ser de igual importancia que los parches de seguridad instalados y los controles implementados.