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
Desarrollo del ataque
Identificar servicio ADCS mal configurado en el dominio
Puesta a punto del software para la reutilización de la autenticación NTLM
Forzar autenticación y obtención del certificado expedido por el ADCS
Obtención del ticket TGT del controlador de dominio
Powered by WPeMatico