🏛️Post Explotación en Active Directory
Una vez que hayamos comprometido el dominio, dependiendo del tipo de evaluación, nuestro trabajo no termina. Hay muchas cosas que podemos hacer para agregar valor adicional a nuestros clientes. Si el objetivo de la evaluación era alcanzar el nivel Domain Admin y nada más, entonces hemos terminado y debemos asegurarnos de tener todos los resultados de comandos/registros, datos de escaneo y capturas de pantalla, y continuar elaborando el informe.
Si la evaluación se centró en un objetivo (es decir, obtener acceso a una base de datos específica), debemos seguir trabajando para lograrlo. Los derechos de administrador del dominio pueden ser solo el comienzo, ya que podría haber otras redes, dominios o bosques en juego a los que tendremos que acceder. Si la evaluación es más abierta y el cliente nos pidió que demostráramos el mayor impacto posible, hay varias cosas que podemos hacer para agregar valor y ayudarlos a mejorar su seguridad.
Análisis de contraseñas de dominio: descifrado de NTDS
Tras descargar la base de datos NTDS, podemos descifrar contraseñas sin conexión con Hashcat. Una vez agotadas todas las reglas y listas de palabras posibles en nuestro equipo de descifrado, deberíamos usar una herramienta como DPAT para realizar un análisis de contraseñas de dominio.
Generar hashcat.potfile
Ejecutar DPAT
Esto puede complementar de forma eficaz hallazgos como Weak Active Directory Passwords Allowed que anotamos tras un ataque de Password Spraring exitoso. Este análisis puede ayudar a aclarar el punto y puede ser una herramienta visual muy útil. Nuestro análisis puede incluirse en los apéndices del informe con métricas como:
Número de hashes de contraseña obtenidos
Número de hashes de contraseñas descifrados
Porcentaje de hashes de contraseñas descifrados
Las 10 mejores contraseñas
Desglose de la longitud de la contraseña
Número de contraseñas de administrador de dominio descifradas
Número de contraseñas de administrador empresarial descifradas
Auditoría de seguridad de Active Directory
Como se explicó en el módulo Técnicas adicionales de auditoría en AD, podemos ofrecer un valor añadido a nuestros clientes profundizando en Active Directory, encontrando recomendaciones de buenas prácticas y presentándolas en los apéndices de nuestro informe.
La herramienta PingCastle es excelente para auditar la seguridad general del dominio y, a partir del informe que genera, podemos extraer diversos elementos para ofrecer a nuestros clientes recomendaciones sobre cómo reforzar su entorno de AD. Este tipo de trabajo, que va más allá de lo esperado, puede generar confianza con nuestros clientes y generar clientes recurrentes y recomendaciones. Es una excelente manera de diferenciarnos, demostrar los riesgos que afectan a los entornos de AD y demostrar nuestro profundo conocimiento de la red del cliente.
Búsqueda de datos/hosts confidenciales
Una vez que accedamos al controlador de dominio, probablemente podamos acceder a la mayoría de los recursos del dominio. Si queremos demostrar el impacto para nuestros clientes, un buen punto de partida es revisar los recursos compartidos de archivos para ver qué otros tipos de datos podemos ver.
Como se explicó en el módulo Documentación e informes, debemos asegurarnos de tomar capturas de pantalla que muestren la lista de archivos si encontramos un recurso compartido particularmente sensible, y no abrir archivos individuales, tomar capturas de pantalla ni eliminar archivos de la red.
Regresemos al recurso compartido Department Shares y veamos qué más podemos encontrar.
Dependiendo del sector y el negocio del cliente, existen diversos aspectos que podemos analizar para demostrar el impacto. Los datos de RR. HH., como salarios y bonificaciones, deben estar bien protegidos. La información de I+D podría perjudicar a una empresa si se filtra, por lo que deben implementar controles adicionales.
Es recomendable no permitir que los administradores de dominio tengan acceso general a todos los datos, ya que si una cuenta se ve comprometida, se comprometerá todo. Algunas empresas cuentan con un sitio web independiente, un recurso compartido de archivos o un servidor de respaldo no perteneciente al dominio para almacenar datos confidenciales. En nuestro caso, Inlanefreight nos solicitó que probáramos si podemos acceder a algún host de la subred 172.16.9.0/23. Esta es su red de administración y alberga servidores confidenciales a los que no se debería acceder directamente desde los hosts del dominio principal, y obtener derechos de administrador de dominio no debería implicar un acceso inmediato.
Dentro del recurso compartido de IT privado, podemos ver dos subdirectorios: Development y Networking. El subdirectorio Development contiene el script de copia de seguridad que obtuvimos anteriormente. Analicemos el subdirectorio Networking.
Podemos ver las claves privadas SSH de tres usuarios diferentes, destacando el del usuario ssmallsadm (que parece un administrador) . Esto es interesante.
¿Es posible aprovechar alguno de estos usuarios para acceder a un host en la red protegida?
Adaptadores de red interna
Al observar los adaptadores de red en los controladores de dominio, podemos ver que tiene una segunda NIC en la red 172.16.9.0.
Ping Sweep de red interna
Escribir arp -a para ver la tabla arp no arroja resultados interesantes. Podemos usar PowerShell para realizar un ping sweep e intentar identificar hosts activos.
Dependiendo de la conexión puede que tengamos que ejecutarlo varias veces para encontrar los hosts activos
Vemos un host activo, 172.16.9.25, con el que quizás funcione una de las claves privadas SSH. ¡Manos a la obra! Primero, descarguemos las claves SSH mediante nuestra conexión evil-winrm al controlador de dominio.
El doble pivoting - MGMT01
Ahora bien, hay varias maneras de realizar la siguiente parte. Tomaremos la ruta larga para poder acceder por SSH directamente al host 172.16.9.25 desde nuestra máquina de ataque, realizando un doble pivoting complejo en el proceso.
Esto es lo que intentamos lograr: comenzamos desde nuestro host de ataque y pivotamos a través de los hosts dmz01 y DC01 para poder acceder por SSH directamente al host MGMT01, a dos saltos de distancia.
Máquina atacante -> dmz01 -> DC01 -> MGMT01
Necesitaremos establecer un reverse shell desde el host dmz01 hasta nuestro host de ataque. Podemos hacerlo de la misma manera que en la sección Recopilación de información interna: crear un payload ELF, subirlo al objetivo y ejecutarlo para capturar un shell. Comenzamos creando el payload ELF y subiéndolo al host dmz01 mediante SCP.
A continuación, configuramos un Multi Handler con Metasploit:
Ejecutamos el archivo shell.elf en el host dmz01:
Capturamos el shell Meterpreter usando multi/handler:
A continuación, configuramos una regla de Port Forwarding local para reenviar todo el tráfico destinado al puerto 1234 de dmz01 al puerto 8443 en nuestro host de ataque.
A continuación, creamos un payload ejecutable que cargaremos en el controlador de dominio.
Subimos el payload al Domain Controller mediante la sesión de Evil-WinRM:
Llevamos la sesión de Meterpreter al background:
Iniciamos otro multi/handler en la misma sesión msfconsole para capturar el shell del DC.
Ejecutamos el payload en el DC y, si todo va según lo planeado, la capturaremos en nuestro listener.
Al revisar nuestro multi handler, vemos la conexión entrante. Parece provenir de 0.0.0.0 porque nuestra regla de Port Forwarding, establecida anteriormente, especificó que todo el tráfico destinado a nuestro host en el puerto 1234 debe dirigirse a nuestro receptor en el puerto 8443.
Para nuestro próximo truco, configuraremos una ruta a la subred 172.16.9.0/23.
Podemos confirmarlo comprobando la tabla de enrutamiento de MSF:
Ahora necesitamos configurar un proxy Socks, que es el paso final antes de que podamos comunicarnos directamente con la red 172.16.9.0/23 desde nuestro host de ataque.
Editamos el archivo /etc/proxychains4.conf para usar el puerto 9050 especificado anteriormente. Si ya tienes una línea anterior, coméntala o reemplaza el número de puerto.
Ahora podemos probar esto ejecutando Nmap contra el objetivo y confirmamos que podemos escanearlo.
Finalmente, podemos probar cada clave SSH con proxychains para intentar conectarnos al host. Podemos recopilar cada nombre de usuario por el nombre de archivo de la clave SSH. En nuestro caso, la clave ssmallsadm funciona.
No olvides dar permisos chmod 600 al archivo id_rsa o no podremos conectarnos.
Como paso final, enumeraremos el sistema objetivo y comprobaremos si existen oportunidades de escalada de privilegios locales. Si logramos obtener acceso root, habremos cumplido el objetivo principal del cliente, ya que afirmó que este servidor alberga sus datos más importantes.
Elevación de privilegios
Durante nuestra enumeración, realizamos una búsqueda en Google basada en la versión del kernel y observamos que probablemente sea vulnerable a CVE-2022-0847 DirtyPipe. Podemos encontrar una excelente explicación de esta vulnerabilidad en el blog Hack The Box .
Usaremos exploit-2 de este repositorio de GitHub . Como tenemos acceso SSH al sistema, podemos crear un archivo dirtypipe.c con Vim, copiar el código del exploit y pegarlo. Luego debemos compilarlo y, por suerte, gcc ya está presente en el sistema.
Aquí pegamos el exploit y lo guardamos con :wq
Debemos ejecutar el exploit contra un binario SUID para inyectar y sobrescribir memoria en un proceso raíz. Primero, debemos buscar los binarios SUID en el sistema.
Por último, ejecutaremos el exploit contra el binario /usr/lib/openssh/ssh-keysign y conseguimos un shell root.
Desde aquí podríamos realizar una post-explotación del sistema de archivos para demostrar el nivel de acceso que logramos.
Simulación de exfiltración de datos
Algunos clientes podrían querer probar sus capacidades Data Loss Prevention(DLP), por lo que podríamos experimentar con diversas maneras de extraer datos ficticios de su red para ver si nos detectan. Debemos colaborar con el cliente para comprender qué tipos de datos intenta proteger y proceder en consecuencia. Es mejor usar datos ficticios para no tener que gestionar datos altamente sensibles del cliente en nuestro sistema de pruebas.
Ataque a Domain Trusts
Si existen confianzas de dominio, podríamos usar nuestras habilidades para enumerar estas relaciones y explotar una relación de confianza entre dominios secundarios y primarios, una confianza dentro del bosque o una confianza externa. Antes de hacerlo, debemos verificar con el cliente que el dominio objetivo esté dentro del alcance de las pruebas. En ocasiones, comprometemos un dominio menos importante y podemos usar este acceso para controlar completamente el dominio principal.
Esto puede ser muy valioso para el cliente, ya que podría haber establecido relaciones de confianza precipitadamente como resultado de una fusión y adquisición o de la conexión con otra organización. Su dominio puede estar bien protegido, pero ¿qué sucede si logramos aplicar Kerberoasting a una confianza de bosque, comprometemos un bosque asociado y luego encontramos una cuenta en el bosque asociado con derechos de administrador completos en nuestro dominio actual? En esta situación, podríamos demostrarle a nuestro cliente que la principal debilidad no reside en el dominio en el que estamos realizando las pruebas, sino en otro, para que pueda proceder en consecuencia.
Reflexiones finales
Esta sección mostró lo que podemos hacer en post-explotación para obtener la Administración de Dominio en un entorno de cliente. Presenciar, dominar al cliente y presumir de la rapidez con la que se obtuvo el Domain Admin no beneficia al cliente ni ayuda a usted ni a su empresa a retener clientes ni a crear una sólida reputación. Lo que hacemos después de obtener la Administración de Dominio es extremadamente importante y es aquí donde podemos diferenciarnos de otros pentesters que simplemente ejecutan Responder, algunas otras herramientas y scripts, un análisis de Nessus, emiten un informe de inventario y listo.
El informe debe demostrar el valor de la prueba de penetración por la que su cliente está pagando, y podemos asegurarnos de que esté satisfecho y vuelva en los próximos años si superamos las expectativas. Esto no siempre es posible debido a las restricciones contractuales y las evaluaciones con plazos limitados, pero incluso si podemos ofrecer un pequeño extra, estamos a la vanguardia. Tenga en cuenta que los aspectos que identificamos en nuestro informe pueden afectar la financiación de un cliente para el año siguiente, y es probable que dicha financiación incluya pruebas de penetración. No queremos inflar el informe con hallazgos sin sentido, por supuesto, pero a menudo podemos identificar muchas cosas que nuestro cliente ni siquiera había considerado y tanto él como usted saldrán beneficiados por ello.
Caso práctico
Pregunta 1
Obtén acceso al host MGMT01 y envíe el contenido del archivo
flag.txten el directorio de inicio de un usuario.
Obtener id_rsa de los usuarios
En los Department Shares encontramos el id_rsa del usuario administrador ssmallsadm:
Lo leemos con type y lo copiamos a un archivo en nuestro Kali:
Adaptadores de red interna
Encontramos la red interna 172.16.9.1, por lo que buscaremos equipos dentro de esta red para probar el id_rsa de admin que hemos encontrado:
Ping Sweep de red interna
Encontramos la IP del equipo conectado a la red interna: 172.16.9.25
Ejecutarlo 2 o 3 veces para asegurarnos
Crear shell.elf con msfvenom
Subir shell con SCP a DMZ01
Y ejecutamos el archivo shell.elf en el sistema de destino:
Port Forwarding Local
A continuación, creamos un payload ejecutable que cargaremos en el controlador de dominio.
Subimos el payload al DC
Llevamos la sesión de Meterpreter al background:
Iniciamos otro multi/handler en la misma sesión de msfconsole para capturar el shell del DC.
Ejecutamos el payload en el DC y, si todo va según lo planeado, la capturaremos en nuestro listener.
Configurar ruta a la subred 172.16.9.0/23
Comprobación
Configurar SOCKS Proxy
Editar archivo de configuración de proxychains
Editamos el archivo /etc/proxychains4.conf para usar el puerto 9050 especificado anteriormente. Podemos comentar la línea anterior que ya teníamos:
Comprobación
Conexión por SSH
Acceso a la flag
Pregunta 2
Escala privilegios a root en el host MGMT01. Enviar el contenido del archivo
flag.txten el directorio /root.
Versión del Kernel
Al buscar la versión del Kernel nos encontramos un exploit para elevat privilegios a través de DirtyPipe con el CVE asociado CVE-2022-0847:
Crear archivo dirtypipe.c con vim
Aquí pegamos el exploit y lo guardamos con :wq
Compilación con gcc
Buscar binarios SUID
Usaremos el binario ssh-keysign
Ejecución de DirtyPipe
Acceso a la flag
Última actualización