🏛️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. Esto puede complementar de forma eficaz hallazgos como Weak Active Directory Passwords Allowed que anotamos tras un ataque de rociado de contraseñas 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 Active Directory Enumeration & Attacksmódulo, 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 Documentation & Reportingmódulo, 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 Department Sharesrecurso compartido y veamos qué más podemos encontrar.
Post-explotación
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 172.16.9.0/23subred. 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 TI privado, podemos ver dos subdirectorios: Developmenty Networking. El subdirectorio Desarrollo contiene el script de copia de seguridad que obtuvimos anteriormente. Analicemos el subdirectorio Redes.
Post-explotación
Podemos ver las claves privadas SSH de tres usuarios diferentes. Esto es interesante.
Can any of these users be leveraged to access a host in the protected network?
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.
Post-explotación
Escribir arp -apara ver la tabla arp no arroja resultados interesantes. Podemos usar PowerShell para realizar un barrido de ping e intentar identificar hosts activos.
Post-explotación
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 evil-winrmconexión al controlador de dominio.
Post-explotación
El doble pivote - MGMT01
Ahora bien, hay varias maneras de realizar la siguiente parte. Tomaremos la ruta larga para poder acceder por SSH directamente al 172.16.9.25host desde nuestra máquina de ataque, realizando un doble pivote complejo en el proceso. Esto es lo que intentamos lograr: comenzando desde nuestro host de ataque y pivotando a través de los hosts dmz01 y DC01 para poder acceder por SSH directamente al host MGMT01, a dos saltos de distancia.
Attack host--> dmz01--> DC01-->MGMT01
Necesitaremos establecer un shell inverso desde la dmz01caja hasta nuestro host de ataque. Podemos hacerlo de la misma manera que en la Internal Information Gatheringsección anterior: crear una carga ELF, subirla al objetivo y ejecutarla para capturar un shell. Comienza creando la carga ELF y subiéndola de vuelta al host dmz01 mediante SCP si la eliminaste.
A continuación, configure Metasploit exploit/multi/handler.
Post-explotación
Una vez más, ejecute el shell.elfarchivo en el sistema de destino:
Post-explotación
Captura el shell Meterpreter usando multi/handler.
Post-explotación
A continuación, configure una regla de reenvío de puerto local para reenviar todo el tráfico destinado al puerto 1234en dmz01 al puerto 8443en nuestro host de ataque.
Post-explotación
A continuación, crea una carga ejecutable que cargaremos en el host del controlador de dominio.
Post-explotación
Subir la carga útil al DC.
Post-explotación
Antecedentes de la sesión de Meterpreter
Post-explotación
Inicie otro multi/handler en la misma sesión msfconsole para capturar el shell del DC.
Post-explotación
Ejecute la carga útil en el DC y, si todo va según lo planeado, la capturaremos en nuestro controlador.
Post-explotación
Al revisar nuestro controlador, vemos la conexión entrante. Parece provenir de 0.0.0.0 porque nuestra regla de reenvío de puertos, 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.
Post-explotación
Para nuestro próximo truco, configuraremos una ruta a la 172.16.9.0/23subred.
Post-explotación
Podemos confirmarlo comprobando la tabla de enrutamiento de MSF.
Post-explotación
Ahora necesitamos configurar un proxy Socks, que es el paso final antes de que podamos comunicarnos directamente con la 172.16.9.0/23red desde nuestro host de ataque.
Post-explotación
Edite el /etc/proxychains.confarchivo para usar el puerto 9050especificado anteriormente. Si ya tiene una línea anterior, coméntela o reemplace el número de puerto.
Ahora podemos probar esto ejecutando Nmap contra el objetivo y confirmamos que podemos escanearlo.
Post-explotación
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 ssmallsadmfunciona (no olvides chmod 600el archivo o no podremos conectarnos).
Post-explotación
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. Durante nuestra enumeración, realizamos una búsqueda en Google basada en la versión del kernel y observamos que probablemente sea vulnerable a DirtyPipe . CVE-2022-0847Podemos encontrar una excelente explicación de esta vulnerabilidad en el blog Hack The Box .
Post-explotación
Usaremos exploit-2 de este repositorio de GitHub . Como tenemos acceso SSH al sistema, podemos crear un archivo con Vimel código del exploit y pegarlo. Luego debemos compilarlo y, por suerte, gccya está presente en el sistema.
Post-explotación
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.
Post-explotación
Por último, ejecutaremos el exploit contra el /usr/lib/openssh/ssh-keysignbinario SUID y lo colocaremos en un shell raíz.
Post-explotación
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 los fideicomisos de dominio
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 Kerberoast 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ó una muestra de lo que podemos hacer AFTERpara 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 la Autorización de Dominio 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 evaluadores 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.
Pregunta 2
Escala privilegios a root en el host MGMT01. Enviar el contenido del archivo
flag.txten el directorio /root.
Última actualización
¿Te fue útil?
