Active Directory - Abusando de AD CS para realizar un RBCD y obtener un Service Ticket

Introducción

El servicio de Active Directory Certificate Services es un rol de Windows Server para emitir y administrar certificados de infraestructura de clave pública (PKI) que se usan en protocolos de autenticación y comunicación seguros.

Las plantillas de certificados pueden simplificar enormemente la tarea de administrar una entidad emisora de certificados (CA) de Servicios de Certificación de Active Directory (AD CS) al permitir a un administrador emitir certificados preconfigurados para tareas seleccionadas.

El problema viene cuando estas plantillas de certificados son vulnerables, y ese es el caso en el que nos vamos a encontrar el día de hoy. Estaremos viendo como, a partir de una simple plantilla que no se ha prestado atención, podemos aprovechar para conseguir delegar los permisos del propio DC sobre un equipo que previamente hemos creado. Al tener permisos de delegación sobre el DC, algo sencillo que podemos hacer, es solicitar un service ticket a nombre del administrador y en consecuencia, conseguir conectarnos como este.

Contexto

Nos encontramos auditando el dominio authority.htb y, en nuestra evaluación hemos logrado acceder a la máquina víctima 10.10.11.222 como el usuario svc_ldap. Entre nuestras acciones de enumeración, algo que hemos hecho es visualizar los grupos a los que pertenecemos como este usuario, lo que nos ha provocado una llamada de atención el pertenecer al grupo Certificate Service DCOM Access.

whoami /groups

Este grupo se configura cuando el servicio de Active Directory Certificate Service está activo en el dominio. Uno de los ataques más comunes cuando observamos que estamos dentro de este grupo consiste en, abusar de una plantilla de certificado vulnerable para, de alguna manera, conseguir impersonar al usuario administrador. Vamos a intentarlo, así que como siempre nos ponemos manos a la obra.

Manos a la obra

Buscando certificados vulnerables

Como hemos comentado anteriormente, tenemos que ver si existe algún certificado vulnerable en el dominio, y con la herramienta certipy seremos capaz de enumerarlos.

certipy find -u 'USUARIO@DOMINIO' -p 'CONTRASEÑA' -dc-ip DC-IP -vulnerable

El resultado de la ejecución se guardará en ficheros .txt y .json. Vamos a ver cual es la plantilla que ha detectado vulnerable.

En este caso, la plantilla vulnerable es CorpVPN y además, entre toda la información que nos muestra, una de ellas es que la entidad certificadora (ca) es AUTHORITY-CA. Esta información, es necesario que nuestra máquina de atacante conozca a que se refiere, por lo que lo agregaremos a nuestro /etc/hosts.

La plantilla de certificado CorpVPN permite que todos los equipos del dominio se inscriban siendo vulnerable a ESC1, lo que permite al solicitante proporcionar un Subject Alternate Name (SAN) arbitrario.

Esto significa que podemos solicitar un certificado en nombre de otro usuario (como por ejemplo, como un Domain Admin).

Creando un nuevo equipo

Como esta plantilla CorpVPN permite que todos los equipos del dominio se inscriban, crearemos un nuevo equipo con addcomputer.py desde el cual tendremos control.

addcomputer.py -method LDAPS -computer-name 'MACHINE-NAME$' -computer-pass 'MACHINE-PASSWORD' -dc-host 'FQDN-DC' -domain-netbios 'DOMINIO' 'DOMINIO/USUARIO:CONTRASEÑA'

Comprobar si podemos agregar equipos al dominio
Es probable que la cuota establecida en el dominio para la creación de equipos esté al límite. Para comprobar si se nos permitirá agregar uno nuevo, podemos comprobar el atributo MachineAccountQuota.

netexec ldap IP -u 'USUARIO' -p 'CONTRASEÑA' -M maq

Este atributo, nos indica el número de máquinas que podemos agregar al dominio usando addcomputer.py. En la imagen anterior, podemos observar que en el dominio se pueden crear un máximo de 10.

Con esto, habremos logrado agregar un nuevo Computer Object al dominio.

• -method LDAPS ➜ El protocolo LDAPS (Lightweight Directory Access Protocol Secure) es un protocolo usado para la autenticación contra varios servicios de directorio. También tendríamos la opción de usar SAMR.
• -computer-name HEGOCIV$ ➜ Agregamos el nuevo “fake computer” con nombre HEGOCIV$.
• --computer-pass 'hegociv123$' ➜ Especificamos una contraseña a la nueva cuenta de máquina HEGOCIV$ para poderla usar más adelante.
• -dc-host 'AUTHORITY.AUTHORITY.HTB' ➜ Indicamos el controlador de dominio al que nos conectaremos para realizar la operación de creación de la máquina.
• -domain-netbios 'authority.htb' ➜ Definimos el nombre NetBIOS del dominio.
• Por último, introducimos las credenciales del usuario que tiene los permisos para realizar esta acción.

Solicitando el hash NTLM del Administrator

Una vez agregado el equipo, al estar en el grupo Certificate Service DCOM Access, tenemos la posibilidad de solicitar un certificado pfx a nombre de Administrator con el cual posteriormente, podremos obtener el hash NTLM del administrador.

certipy req -username MACHINE-NAME$ -password 'MACHINE-PASSWORD' -ca AUTHORITY-CA -dc-ip DC-IP -template VULNERABLE-TEMPLATE-NAME -upn Administrator@DOMINIO -dns DOMINIO -debug

Esto nos habrá generado un fichero administrator_authority.pfx en nuestro directorio actual. Haciendo uso de este certificado, podemos impersonar al usuario administrador y solicitar su hash NTLM en su nombre.

certipy auth -pfx administrator_authority.pfx -debug

Como queremos obtener el hash de Administrator@authority.htb ejecutamos la opción 0. En posesión de este hash, podemos intentar efectuar un Pass The Hash sin embargo, debemos tener en cuenta algo importante.

Solucionando KDC_ERR_PADATA_TYPE_NOSUPP

Habrá ocasiones en el que a la hora de solicitar este hash nos aparezca el error de KDC_ERR_PADATA_TYPE_NOSUPP, lo que significa que el DC no soporta PKINIT, es decir, la autenticación a través de un certificado. Entonces, debemos tener en nuestro arsernal una manera alternativa para poder llegar a ganar acceso como administradores.

KDC_ERR_PADATA_TYPE_NOSUPP
Si buscamos en Internet el significado del mensaje de error KDC_ERR_PADATA_TYPE_NOSUPP nos aparece lo siguiente.

Traducción a Español: “Se está intentando un inicio de sesión con tarjeta inteligente, pero no se puede localizar el certificado adecuado. Esto puede ocurrir porque se está consultando a la autoridad de certificación (CA) incorrecta o porque no se puede contactar con la CA adecuada. También puede suceder si un controlador de dominio no tiene instalado un certificado para tarjetas inteligentes (plantillas de Controlador de Dominio o Autenticación de Controlador de Dominio). Este código de error no puede aparecer en el evento “4768. Se solicitó un ticket de autenticación Kerberos (TGT)”. Aparece en el evento “4771. Falló la preautenticación de Kerberos””

En el caso que nos ocurra lo mencionado, contamos con la herramienta passthecert.py, pero para que pueda realizar su función necesitamos obtener los ficheros .key y .crt sobre este administrator_authority.pfx que solicitamos con certipy.

Para obtener los dos ficheros que necesitamos podemos ejecutar dos sencillos comandos. El primero, generará el .key (como PEM pass podemos poner cualquier cosa, como 1234). El segundo comando, sacará el fichero .crt.

openssl pkcs12 -in administrator_authority.pfx -nocerts -out administrator.key
openssl pkcs12 -in administrator_authority.pfx -clcerts -nokeys -out administrator.crt

De esta manera, tendremos administrator.key y administrator.crt, los cuales usaremos para efectuar un Resource-Based Constrained Delegation (RBCD) con el fin de modificar el atributo msDS-AllowedToActOnBehalfOfOtherIdentity del DC y lograr obtener el ticket de servicio de Administrator.

Resource Based Constrained Delegation (RBCD)

El Resource Based Constrained Delegation (RBCD) funciona de manera distinta a una delegación restringida (Constrained Delegation). En el RBCD es al contrario, quien decide quien puede delegar contra él es el propio recurso, es decir, el SERVICIO B en el siguiente ejemplo.

USUARIO ➜ SERVICIO A ➜ SERVICIO B (RECURSO)

En resumidas cuentas, la idea es la siguiente:

1. Me autentico en el SERVICIO A.
2. El SERVICIO A le dice al DC que me quiere impersonar en el RECURSO B (SERVICIO B).
3. El DC, comprueba la lista (msDS-AllowedToActOnBehalfOfOtherIdentity) del RECURSO B (SERVICIO B).
4. Si en la lista se encuentra presente la cuenta de servicio de SERVICIO A, SERVICIO B permitirá la impersonación.

En conclusión, Resource-Based Constrained Delegation (RBCD) es una mejora y un enfoque más flexible de la delegación de autenticación en comparación con la delegación restringida tradicional Constrained Delegation. RBCD fue introducido en Windows Server 2012 como una alternativa a la delegación tradicional para mejorar la seguridad y flexibilidad en cómo se gestionan los permisos de delegación en un entorno de Active Directory.

Sabiendo como funciona un RBCD, procederemos a efectuarlo. Para ello, nos clonaremos la herramienta passthecert.py e introduciremos los ficheros que hemos extraído del .pfx en la misma carpeta del repositorio.

git clone https://github.com/AlmondOffSec/PassTheCert.git
cd PassTheCert
cp ../administrator_authority.pfx .../administrator.key ../administrator.crt .

Ahora si, para realizar un Resource-Based Constrained Delegation (RBCD), ejecutaremos la herramienta de la siguiente manera.

python3 ./Python/passthecert.py -dc-ip DC-IP -crt administrator.crt -key administrator.key -domain DOMINIO -port 636 -action write_rbcd -delegate-to 'DC-NAME$' -delegate-from 'MACHINE-NAME$'

Este comando usa la técnica Pass-The-Certificate para autenticarse en el controlador de dominio (10.10.11.222) usando un certificado (administrator.crt) y su clave (administrator.key). Luego, ejecuta una acción (write_rbcd) para configurar la delegación de privilegios, permitiendo que HEGOCIV$ (nuestro “fake computer”) pueda actuar en nombre del DC (AUTHORITY-CY$), lo que podríamos usar para realizar acciones en nombre del administrador (impersonar)

Con esta pequeña configuración, lograremos que el equipo que hemos creado (en mi caso HEGOCIV$) tenga los permisos de delegación necesarios para poder solicitar un ticket de servicio a nombre del administrador. Con getST.py conseguiremos lo que acabamos de mencionar.

impacket-getST -spn 'cifs/DC-NAME.DOMINIO' -impersonate Administrator 'DOMINIO/MACHINE-NAME$:CONTRASEÑA'

DCSync Attack

La herramienta habrá generado un fichero .ccache y, algo que podemos realizar con esto es un DCSync Attack. Para ello, necesitaremos exportar la variable KRB5CCNAME para que valga el propio nombre de este fichero generado por getST.py. En mi caso, lo he renombrado a Administrator.ccache.

export KRB5CCNAME=Administrator.ccache

Con la variable configurada, podemos efectuar un DCSync Attack gracias al parámetro -k, que usará nuestro fichero .ccache definido en la variable KRB5CCNAME, para autenticarse como el usuario Administrator e impersonarle.

secretsdump.py -k -no-pass DOMINIO/Administrator@DC-NAME.DOMINIO -just-dc-ntlm

Pass The Hash

Con el hash NTLM del Administrator en nuestro poder, podemos hacer un Pass the Hash (PtH) y conseguir acceso como este sin tener que conoecer sus credenciales.

En este caso se ha usado psexec pero se podrían usar herramientas como wmiexec, evil-winrm para realizar este Pass The Hash.

Conclusión

En el día de hoy, hemos aprendido nuevos conceptos como Resource-Based Constrained Delegation o Constrained Delegation, y como abusar de ellos en un entorno real de AD. Hemos visto una nueva técnica, Pass The Certificate que nos permite autenticarnos haciendo uso de un certificiado, en vez de las credenciales tradicionales. Nos ha sido posible ver, la ejecución de un DCSync Attack utilizando un fichero .ccache definido en nuestra variable KRB5CCNAME y seguidamente, como efectuar un Pass The Hash con el hash NTLM obtenido del DCSync.

Enlaces de referencia

Los siguientes son recursos de utilidad que me ayudaron a realizar este artículo y sobre todo, a aprender sobre ello.

• Explicación de KDC_ERR_PADATA_TYPE_NOSUPP
• Resource-Based Constrained Delegation (RBCD)
• Constrained Delegation
• DCSync Attack
• Máquina Authority - Hack The Box
• Explicación de Unconstrained Delegation
• Unconstrained Delegation

Cabe mencionar que el blog Deep Hacking es un excelente recurso para quienes buscan aprender sobre ciberseguridad, hacking ético y pentesting. Allí encontrarás contenido detallado sobre pruebas de penetración, Active Directory y técnicas avanzadas utilizadas en el mundo de la ciberseguridad. Personalmente, siempre lo uso para desarrollar y conocer técnicas nuevas de ataque y lo recomiendo totalmente.

Despedida

Espero que te hayas sentido cómodo con los superpoderes que has adquirido en este artículo. ¡Nunca pares de aprender! Hasta la próxima.