Active Directory Certificate Services (ADCS)
Introduction to ADCS
ADCS es el rol que maneja la emisión de certificados para usuarios, equipos y servicios en la red de Active Directory. Este servicio, si está mal configurado, puede presentar vulnerabilidades que los atacantes podrían explotar para elevar privilegios o acceder a información sensible.
Algunas de las posibles vulnerabilidades que puede tener ADCS son:
Delegación de privilegios en la emisión de certificados: Si ciertos usuarios tienen permisos para emitir certificados para otros, un atacante podría abusar de estos privilegios para obtener permisos elevados.
Mala configuración en las plantillas de certificados: Configuraciones incorrectas en las plantillas de certificados podrían permitir que un atacante solicite un certificado en nombre de otro usuario, incluso uno con privilegios elevados.
NTLM Relaying en HTTP: Si el ADCS acepta autenticación NTLM en lugar de Kerberos, un atacante podría redirigir las solicitudes para ganar acceso.
Componentes principales:
CA (Certification Authority): Emite y gestiona certificados. Puede haber múltiples CAs en una jerarquía.
Certificate Templates: Definen la configuración, permisos y requisitos para emitir certificados.
CES (Certificate Enrollment Server): Permite renovar certificados mediante solicitudes HTTPS.
Certificate Enrollment Policy Web Server: Proporciona información sobre la política de inscripción de certificados.
CA Web Enrollment: Permite que hosts fuera del dominio o con otros sistemas operativos renueven certificados.
NDES (Network Device Enrollment Service): Permite a dispositivos de red obtener certificados sin conexión.
Formatos de certificados X.509:
PEM: Certificado DER codificado en base64; puede almacenar múltiples claves sin protección por contraseña.
DER: Certificado en formato binario crudo.
PFX/P12 (PKCS#12): Almacena claves privadas con protección por contraseña.
P7B (PKCS#7): Almacena certificados de cadena, pero no claves privadas.
Principales atributos de certificados:
Subject: Entidad a la que se emite el certificado.
Issuer: Normalmente la CA.
SAN: Nombre alternativo del sujeto.
Validity Period: Periodo de validez del certificado.
EKU (Extended Key Use): Define usos específicos del certificado.
OID (Object Identifier): Indica el propósito o escenario de uso del certificado.
OID
Uso del certificado
1.3.6.1.5.5.7.3.1
Autenticación de servidor
1.3.6.1.5.5.7.3.2
Autenticación de cliente
1.3.6.1.5.5.7.3.3
Firma de código
1.3.6.1.5.5.7.3.4
Correo electrónico seguro
Proceso de CSR (Certificate Signing Request):
El cliente envía una solicitud de certificado (CSR).
La CA verifica los permisos del cliente para emitir el certificado solicitado.
Si los permisos coinciden, la CA genera y firma el certificado con su clave privada.
El certificado firmado es devuelto al cliente.
Checking Misconfigured Templates
Herramienta que utilizaremos para la escalada de privilegios con los ADCS.
Para verificar si existen plantillas mal configuradas, las cuales podemos abusar, podemos hacer uso del siguiente comando para que nos lo muestre en la terminal.
Ejemplo de cómo debería salirnos si existe una plantilla mal configurada en el ADCS que podemos intentar explotar. En este ejemplo, nos aparece que podemos realizar la explotación ESC7.

KDC_ERR_PADATA_TYPE_NOSUPP
Es posible que en algún momento obtengamos este mensaje de error al intentar autenticarnos con el certificado PFX del usuario que estamos impersonando, lo que indica que el KDC no admite el tipo de autenticación proporcionado.
Nos encontramos con varios blogs que mencionan el error KDC_ERR_PADATA_TYPE_NOSUPP, el cual ocurre cuando el controlador de dominio no soporta PKINIT. Esto impide que autenticarnos directamente con el certificado PFX.
Como alternativa, podemos utilizar PassTheCert para autenticarnos a LDAP a través de SChannel con nuestro certificado. Aunque esto solo nos daría acceso a LDAP, podría ser suficiente si el certificado nos identifica como Administrador de Dominio.
Lo primero que haremos será extraer la clave privada y el certificado desde el archivo PFX que obtuvimos del usuario Administrator. Para ello, utilizamos Certipy de la siguiente manera. A continuación, haremos uso de la herramienta PassTheCert.py para autentifcarnos con el certificado obtenido.
Con PassTheCert, utilizamos la clave privada y el certificado generado anteriormente para autenticarnos. En este ejemplo. se nos mostraría el resultado del comando whoami.
Para poder escalar privilegios y buscar otras maneras. podemos obtener una consola LDAP Shell con el parámetro -action ldap-shell.
Para ver varios ejemplos del uso de PassTheCert y de cómo logramos obtener acceso al sistema como el usuario Administrator podemos comprobar el siguiente blog.
ESC1
Domain Users Enrollment
Solicitud del certificado con SAN alternativo.
Autenticación con certificado.
Domain Computers (Machine Account)
En algunas ocasiones, es posible que exista la ESC1 pero solamente se pueda realizar a través de algún Domain Computer. En este resultado de adPEAS se comprueba que solamente los Domain Computers tienen permisos de enrollment sobre la plantilla vulnerable para realizar el ESC1.
Por lo tanto, hay que disponer de las credenciales de un equipo, que se pueden obtener de diversas maneras. En caso de que podemos añadir nuevas máquinas al dominio, podemos realizar lo siguiente a través de la herramienta de PowerView.py.
Una vez dispongamos de acceso a autenticarnos como un Domain Computer, realizaremos el ataque. Sustituir Gzzcoo$ por el nombre del PC y la contraseña Gzzcoo123 por la correspondiente.
Autenticación con certificado.
ESC2
Solicitud del certificado con SAN alternativo.
Autenticación con certificado.
Verificación.
ESC3
Solicitar un certificado.
Solicitar un certificando suplantando al Administrator.
ESC4
Atacando a la plantilla vulnerable a ESC4.
Verificar plantilla ESC4 después de la modificación.
Abusando de la plantilla modificada.
Recuperando el hash NTLM del usuario Administrator.
Volviendo la plantilla ESC4 al estado original.
ESC5
Solicitar el certificado del Domain Admin.
Emitir el certificado solicitado.
En este caso, aprobamos la solicitud anterior especificando el ID de la solicitud con la opción -issue-request 10.
Recuperar el certificado emitido.
Autenticarse con el certificado del Administrator.
ESC6
Solicitud de certificado con UPN alternativo, en este caso, el usuario Administrator.
ESC7
Requisitos previos
Para que esta técnica funcione, el usuario también debe tener el derecho de acceso Administrar certificados y la plantilla de certificado SubCA debe estar habilitada. Con el derecho de acceso Administrar CA, podemos cumplir con estos requisitos previos.
La técnica se basa en el hecho de que los usuarios con el derecho de acceso Administrar CA y Administrar certificados pueden emitir solicitudes de certificado fallidas. La plantilla de certificado SubCA es vulnerable a ESC1, pero solo los administradores pueden inscribirse en la plantilla. Por lo tanto, un usuario puede solicitar inscribirse en la SubCA (que será denegada) pero luego el administrador la emitirá.
Si solo tiene el derecho de acceso Administrar CA, puede otorgarse el derecho de acceso Administrar certificados agregando a su usuario como un nuevo funcionario.
La plantilla SubCA se puede habilitar en la CA con el parámetro -enable-template. De manera predeterminada, la plantilla SubCA está habilitada.
Ataque
Si hemos cumplido con los requisitos previos para este ataque, podemos comenzar solicitando un certificado basado en la plantilla SubCA.
Esta solicitud será rechazada, pero guardaremos la clave privada y anotaremos el ID de la solicitud.
Con Administrar CA y Administrar certificados, podemos emitir la solicitud de certificado fallida con el comando ca y el parámetro -issue-request.
Y finalmente, podemos recuperar el certificado emitido con el comando req y el parámetro -retrieve . Obtenemos el certificado del Administrator.
ESC8
Certipy relay
Realizar la Autenticación Coercion (desde otra terminal)
Esto nos dará el certificado y la clave privada del usuario.
Solicitar un TGT como máquina de equipo (o Domain Controller)
Esto nos dará el hash NTLM del usuario, que podemos usar para autenticarnos.
Dependiendo de la situación, ahora tenemos 2 ataques posibles...
DCSync (si disponemos de permisos de Administradores del dominio)
Realizando DCSync Attack utilizando el hash NTLM como Domain Controller.
Silver Ticket (utilizando el hash NTLM de una cuenta de equipo)
Creación del Silver Ticket
Realizando PassTheTicket con PsExec
ESC9
Requisitos:
GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B.
En este caso 'hacker' dispone de los privilegios sobre 'victim'. El usuario 'victim' tiene permisos para realizar el ESC9.
Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.
Utilizamos Certipy para actualizar el UPN de la cuenta 'victim', asignándole el valor de Administrator. Esto nos permite asociar cualquier certificado emitido a 'victim' con la identidad de Administrator:
Solicitamos un certificado utilizando la plantilla vulnerable. Este certificado se emitió con el UPN de Administrator, habilitando su uso para autenticación con privilegios elevados.
Posteriormente, restauramos el UPN de 'victim' a su valor original para minimizar evidencias de la modificación realizada.
Seguidamente utilizamos el certificado emitido para autenticarnos y verificamos que obtenemos el hash NTLM del usuario "Administrator".
ESC10
Caso 1
Requisitos:
GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B.
En este caso 'hacker' dispone de los privilegios sobre 'victim'. El usuario 'victim' tiene permisos para realizar el ESC10.
Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.
Modificar el UPN del usuario 'victim' al usuario Administrator.
Solicitud del certificado.
Revertiremos los cambios del usuario 'victim' (para asegurarse de que solo el administrador coincida con el certificado)
Autenticarse como usuario Administrator.
Caso 2
Requisitos:
GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B sin que disponga un userPrincipalName (cuentas de máquina y administrador de dominio integrado Administrador.
En este caso 'hacker' dispone de los privilegios sobre 'victim' y deseamos comprometer el Domain Controller DC$@domain.htb.
Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.
Modificamos el UPN del usuario 'victim' a 'DC$@dominio.htb'.
Solicitamos un certificado como 'victim' para obtener el certificado del Domain Controller (DC).
Revertir los cambios de 'victim' (para asegurarse de que solo el administrador coincida con el certificado).
Autenticación con el certificado del DC.
Creación de una nueva cuenta de equipo.
Abusar de RBCD (Resource Based Constrained Delegation) para impersonar al Administrator.
Autenticarse utilizando el TGT del usuario Administrator.
ESC11
Configuramos el relay
Autenticación Coerce con PetitPotam
Certipy recibe autenticación del DC de AD
A continuación, se deberá realizarlos pasos del ESC8
ESC12
ESC13
Desde sistemas tipo UNIX, esta solicitud de extracción en Certipy (Python) permite identificar una plantilla de certificado con una política de emisión, es decir, con la propiedad msPKI-Certificate-Policy no vacía. Además, verifica si esta política de emisión tiene un enlace de grupo OID a un grupo en la propiedad msDS-OIDToGroupLink.
Si se encuentra una plantilla vulnerable, no hay ningún requisito de emisión particular, el principal puede inscribirse y la plantilla indica el EKU de autenticación del cliente; solicite un certificado para esta plantilla con Certipy (Python) como de costumbre:
Luego, el certificado se puede usar con Pass-the-Certificate para obtener un TGT y autenticarse como el principal controlado, pero con sus privilegios agregados a los del grupo vinculado.
ESC14
Scenario A: Write altSecurityIdentities on Target
Comprobar que con el usuario (userA) tengamos permisos de escritura en el atributo altSecurityIdentities en el usuario TARGET (userB).
Crearemos un nuevo Domain Computer.
Autenticamos con el Domain Computer recién creado para obtener su PFX.
Obtener el .crt del certificado PFX del Domain Computer recién creado.
Script para obtener el X509 a travésdel issuer y el serial.
Resultado obtenido al ejecutar el script.
Modificamos el atributo altSecurityIdentities del userB a través del userA ya que disponemos de permisos y le asignamos el valor X509 anteriormente obtenido.
Una vez modificado, nos autenticamos con el PFX del Domain Computer creado impersonando al userB, obtenemos su hash NTLM y su TGT (.ccache).
ESC15
ESC16
Nota muy importante: disponer de la última versión de certipy para que aparezca. Actualmente (5.0.2)
Output:
Scenario A: UPN Manipulation (Requires StrongCertificateBindingEnforcement = 1 (Compatibility) or 0 (Disabled) on DCs, and attacker has write access to a "victim" account's UPN)
# Step 1: Read initial UPN of the victim account (Optional - for restoration).
Step 2: Update the victim account's UPN to the target administrator's sAMAccountName.
Step 3: (If needed) Obtain credentials for the "victim" account (e.g., via Shadow Credentials).
En caso de disponer de las credenciales de victim, pasar directamente al paso 4.
Step 4: Request a certificate as the "victim" user from any suitable client authentication template (e.g., "User") on the ESC16-vulnerable CA.
En caso de haber realizado el Shadow Credentials (Step 3) realizar los siguientes pasos.
En caso de disponer de las credenciales de victim y no haber realizado el Step 3, realizar lo siguiente:
Step 5: Revert the "victim" account's UPN.
Step 6: Authenticate as the target administrator.
References
Abusing Active Dierctory Certificate Services Explication --> https://www.blackhillsinfosec.com/abusing-active-directory-certificate-services-part-one/
Abusing ADCS Attacks (ADMinions) --> https://adminions.ca/books/abusing-active-directory-certificate-services
Abusing ACS Attacks (The Hacker Recipes) --> https://www.thehacker.recipes/ad/movement/adcs/
Abusing ESC8 & ESC10 on ADCS --> https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7
Última actualización
¿Te fue útil?
