ADCS Cheatsheet

La plantilla permite al solicitante definir el Subject Alternative Name (SAN) libremente (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT), tiene EKU Client Authentication (lo más común) y un usuario de bajos privilegios tiene derechos de enrollment. Permite solicitar un certificado como cualquier usuario del dominio, incluyendo el Administrador.
Campo abusado: msPKI-Certificate-Name-Flag + ENROLLEE_SUPPLIES_SUBJECT activado

La plantilla tiene EKU Any Purpose (OID 2.5.29.37.0) o no tiene ningún EKU definido. Esto implícitamente concede la capacidad de Enrollment Agent (OID 1.3.6.1.4.1.311.20.2.1), permitiendo usar el certificado obtenido para solicitar certificados en nombre de otros usuarios (como en ESC3).

Requiere dos plantillas: una con el EKU Certificate Request Agent (1.3.6.1.4.1.311.20.2.1) y otra plantilla target que acepte enrollment via agente. El atacante obtiene primero un certificado de agente y luego lo usa para solicitar certificados en nombre del Administrator sin tener sus credenciales.

El atacante tiene permisos peligrosos sobre una plantilla (Owner, FullControl, WriteOwner, WriteDacl, WriteProperty). Esto permite modificar la plantilla para añadir ENROLLEE_SUPPLIES_SUBJECT, convirtiéndola en vulnerable a ESC1. Siempre usar -save-old para preservar la configuración original.

⚠ IMPORTANTE: La modificación ocurre en vivo en el dominio target. Guardar siempre el JSON original con -save-old.

El atacante tiene permisos de escritura/control sobre objetos PKI más allá de las plantillas: el propio objeto CA en AD, el servidor ADCS, o el contenedor NTAuthCertificates. Permite solicitar, aprobar y recuperar certificados de plantillas privilegiadas como SubCA, o registrar nuevas CA.

ESC5 aplica si tienes control sobre cualquiera de estos objetos PKI: Objeto CA en AD (CertificationAuthority / PKIEnrollmentService) o Contenedor NTAuthCertificates o Servidor ADCS (cuenta de equipo) o contenedor CDP (CRL Distribution Point) o AIA (Authority Information Access)

La CA tiene el flag EDITF_ATTRIBUTESUBJECTALTNAME2 activado, lo que permite especificar un SAN arbitrario en cualquier solicitud de certificado, independientemente de la configuración de la plantilla.
Fue parcheado (CVE Certifried), pero es explotable si no se ha aplicado el parche o si CT_FLAG_NO_SECURITY_EXTENSION está activo.
También es importante mirar permisos ManageCA ya que nos permiten editar la configuración de la CA e introducir EDITF_ATTRIBUTESUBJECTALTNAME2 habilitando ESC6

El usuario tiene el derecho Manage CA sobre la CA. Esto permite tres ataques distintos:

Ataque 1 — Flip EDITF (ESC6-like) · ManageCA + ManageCertificates: Con Manage CA se puede modificar el flag EDITF_ATTRIBUTESUBJECTALTNAME2 via PSPKI, convirtiendo la CA en vulnerable a ESC6 — cualquier plantilla enrollable permite SAN arbitrario. Con ManageCertificates se aprueban requests pendientes saltándose el Manager Approval. ⚠ Requiere reinicio de CertSvc para que el flag tenga efecto, y aunque ManageCA permite reiniciarlo, no puede hacerse remotamente.

Ataque 2 — SubCA + Officer · solo ManageCA: Con Manage CA se puede auto-promoverse a Officer (ganando Manage Certificates) y habilitar la plantilla SubCA. La plantilla SubCA es especial porque su EKU incluye All (OID 2.5.29.37.0) — un certificado emitido con ella sirve para cualquier propósito incluyendo autenticación de cliente. Los usuarios normales no pueden enrollarse en SubCA (solo Domain/Enterprise Admins), por lo que la solicitud será denegada automáticamente — pero la CA genera un Request ID y una clave privada. Como Officer, se aprueba esa solicitud fallida y se recupera el certificado. Alternativa preferida cuando el Ataque 1 no funciona por el parche de Mayo 2022 o por imposibilidad de reiniciar CertSvc.

Ataque 3 — SetExtension · solo ManageCertificates: Primitiva nueva de Certify 2.0. El método RPC ICertAdmin::SetExtension permite inyectar extensiones arbitrarias (OIDs de Issuance Policy, EKUs personalizados) en una request pendiente. Como la plantilla no define valor por defecto para esa extensión, la CA no sobreescribe el valor inyectado al emitir el cert. El certificado resultante puede encadenarse con otros ataques (ESC13, etc.). No requiere ManageCA — convierte ManageCertificates en vector de escalada completo por sí solo.

⚠ Importante: Añadirse como Officer no garantiza siempre poder aprobar requests — la CA puede tener CertificateManagerRestrictions que limiten qué plantillas o usuarios puede aprobar el Officer recién añadido, resultando en Access Denied al intentar -issue-request.

La interfaz Web Enrollment de ADCS (http://CA/certsrv/certfnsh.asp) acepta autenticación NTLM y por defecto no tiene Extended Protection for Authentication (EPA) ni channel binding. Un atacante puede forzar la autenticación de un equipo privilegiado (DC, servidor) mediante técnicas de coerción (PetitPotam, PrinterBug, Coercer) y reenviar esas credenciales NTLM a la CA para obtener un certificado válido — sin necesidad de credenciales previas.

Condiciones necesarias: Web Enrollment HTTP habilitado + NTLM no bloqueado + sin EPA/channel binding + plantilla enrollable para la cuenta coercionada (Machine, DomainController, User).

Post-explotación: Con el PFX del DC → certipy auth → hash NTLM del DC → DCSync (si es DA) o Silver Ticket (con el hash de la cuenta de máquina).

Escenario especial — DNS Record + SPN Serializado: Cuando no es posible hacer coerción SMB directa (por signing, EPA, etc.), se puede registrar un registro DNS malicioso con un SPN serializado (CredMarshalTargetInfo) que fuerza al DC a generar un AP_REQ Kerberos para sí mismo pero enviarlo a la IP del atacante — combinado con certipy relay hacia HTTPS.

La plantilla tiene el flag CT_FLAG_NO_SECURITY_EXTENSION (0x80000) en msPKI-Enrollment-Flag, lo que impide que la CA incruste la extensión szOID_NTDS_CA_SECURITY_EXT (SID del usuario) en el certificado emitido. Sin esa extensión, el DC mapea la cuenta autenticada por UPN en lugar de por SID.

Combinado con GenericWrite/GenericAll sobre una cuenta víctima (cuenta A), el atacante modifica temporalmente su userPrincipalName para que coincida con el Administrator (cuenta B), solicita el certificado como cuenta A — que ahora lleva el UPN del Administrator — y autentica como cuenta B sin conocer su contraseña.

Campo abusado: msPKI-Enrollment-Flag → CT_FLAG_NO_SECURITY_EXTENSION + mapeo por UPN del DC

ESC10 abusa de una configuración débil de mapeo de certificados en el DC. Existen dos variantes según qué clave de registro esté mal configurada:

Case 1: StrongCertificateBindingEnforcement = 0 bajo HKLM\SYSTEM\CurrentControlSet\Services\Kdc. El DC no exige mapeo fuerte por SID, por lo que autentica por UPN. Flujo idéntico a ESC9 — cualquier plantilla con Client Authentication sirve.

Case 2: CertificateMappingMethods incluye el bit UPN (0x4) bajo HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel. El servidor usa mapeo UPN en Schannel (LDAPS). Permite comprometer cuentas sin UPN (máquinas, Administrator built-in) y escalar vía RBCD.

En ambos casos se requiere GenericWrite/GenericAll sobre una cuenta víctima para modificar su userPrincipalName temporalmente.

🛈 Nota: Certipy no detecta ESC10 automáticamente — hay que enumerar las claves de registro manualmente.
↗ ESC9 Vs ESC10 : A pesar de que ambos permiten suplantación de UPN (UPN Spoofing), la vulnerabilidad raíz es diferente
- ESC9 Vulnerabilidad raíz reside en la configuración de la CA (plantilla no tiene OID SID en la extensión de seguridad) corregido en parche KB5014754 (Mayo 2022)
- ESC10 Vulnerabilidad raíz en la configuración del DC (registro no exige mapeo fuerte por SID) corregido con el mismo parche KB5014754 + StrongCertificateBindingEnforcement = 2

Vulnerabilidad en AD CS donde la CA no requiere cifrado en solicitudes ICPR (RPC)(IF_ENFORCEENCRYPTICERTREQUEST = Disabled). Esto permite realizar NTLM Relay hacia RPC (MS-ICPR) y solicitar certificados en nombre de la víctima (ej: Domain Controller) sin necesidad de Web Enrollment (HTTP). . Similar a ESC8 pero hace relay a través de RPC/ICPR en lugar de la interfaz Web Enrollment HTTP. La CA acepta solicitudes de certificado vía RPC (MS-ICPR) sin signing requerido.

Vulnerabilidad en AD CS cuando la CA está configurada para almacenar su clave privada en un dispositivo USB externo (ej: YubiHSM2). La contraseña de autenticación del Key Storage Provider se guarda en texto plano en el registro bajo HKLM\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword. Un atacante con acceso shell (incluso bajos privilegios) al servidor CA puede leer esta contraseña y forjar certificados arbitrarios firmados por la CA, permitiendo suplantar cualquier usuario o máquina del dominio.

Vulnerabilidad en AD CS cuando una plantilla de certificado tiene una política de emisión (msPKI-Certificate-Policy) vinculada a un grupo mediante msDS-OIDToGroupLink. Cuando un usuario solicita un certificado de esa plantilla y el certificado permite Client Authentication, el sistema autoriza al usuario como si fuera miembro del grupo vinculado. El grupo debe ser vacío y tener ámbito Universal (Forest Wide). Los grupos por defecto que cumplen son: Enterprise Admins, Schema Admins, Enterprise Key Admins y Enterprise Read-only Domain Controllers.

Vulnerabilidad en AD CS cuando el mapeo explícito de certificados está mal configurado. Existen cuatro escenarios que permiten a un atacante con una cuenta víctima (con capacidad de solicitar certificados) suplantar a una cuenta objetivo aprovechando atributos modificables (altSecurityIdentities, mail, cn, dNSHostName). Los escenarios son:

• A: El atacante tiene escritura en altSecurityIdentities del objetivo — añade mapeo X509IssuerSerialNumber apuntando a certificado de la víctima.
• B: El objetivo tiene un mapeo X509RFC822 débil — el atacante modifica el mail de la víctima para que coincida y solicita certificado con email en SAN.
• C: El objetivo tiene un mapeo X509IssuerSubject débil — el atacante modifica el cn (usuario) o dNSHostName (máquina) de la víctima para que coincida con el subject.
• D: El objetivo tiene un mapeo X509SubjectOnly débil — el atacante modifica cn o dNSHostName de la víctima para que coincida con el subject.

Las plantillas de schema versión 1 (V1) no validan las Application Policies que el solicitante incluye en el CSR. Un atacante con permisos de Enroll puede inyectar OIDs arbitrarios (p.ej. Client Authentication o Certificate Request Agent) en la extensión Application Policy del certificado emitido. Como Windows da prioridad a esa extensión sobre el EKU real de la plantilla, el certificado resultante puede usarse para autenticación de cliente o como Enrollment Agent, aunque la plantilla sea solo WebServer.

A diferencia de ESC1, ESC15 ocurre cuando la plantilla no incluye el EKU de Client Authentication (Client Authentication: False), lo que habilita el abuso mediante Certificate Request Agent para solicitar certificados en nombre de otros usuarios. Puede verse como un ESC2 con más pasos.

Escenario A: Inyectar Client Authentication → cert usable vía SChannel (LDAP shell). PKINIT normalmente falla.
Escenario B: Inyectar Certificate Request Agent → actuar como Enrollment Agent y derivar el ataque a ESC3 (on-behalf-of Administrator). Este es el camino que funciona en la práctica para obtener TGT.

[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=Administrator"
KeyLength = 2048
Exportable = TRUE
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
HashAlgorithm = sha256
RequestType = PKCS10
SMIME = FALSE
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "upn=Administrator@domain.htb"
1.3.6.1.4.1.311.21.10 = "{text}"
_continue_ = "1.3.6.1.5.5.7.3.2"

Import-Module PSCertificateEnrollment
PS > $Csr = New-CertificateRequest -Upn "Administrator@domain.htb" -ApplicationPolicy ClientAuthentication
PS > $Csr | Get-IssuedCertificate -ConfigString "CA-Host\CA-Name" -CertificateTemplate "WebServer"

La CA tiene la extensión de seguridad deshabilitada (OID 1.3.6.1.4.1.311.25.2 — szOID_NTDS_CA_SECURITY_EXT), lo que impide incrustar el SID del sujeto en el certificado. Esto ocurre cuando el OID está en el policy\DisableExtensionList de la CA, o cuando el parche KB5014754 (Mayo 2022) no está aplicado. La CA se comporta entonces como si todas sus plantillas fueran vulnerables a ESC9.

Escenario A (Compatibility mode): StrongCertificateBindingEnforcement = 0 o 1 → el KDC solo verifica el UPN del SAN. Con GenericWrite sobre una cuenta víctima se manipula su UPN para obtener un cert que autentica como Administrator.
Escenario B (Full enforcement): StrongCertificateBindingEnforcement = 2 → el KDC verifica el SID de la security extension. Requiere que la CA sea también vulnerable a ESC6 para inyectar el SID directamente en el SAN del CSR.

Variante de ESC1 donde la plantilla vulnerable tiene EKU de Server Authentication en lugar de Client Authentication. Esto impide impersonar usuarios directamente (no sirve para PKINIT), pero sí permite impersonar servidores — en concreto, un servidor WSUS. Si en el dominio existe un endpoint WSUS cuyo DNS puede ser creado o redirigido por el atacante, se puede obtener un certificado legítimo para ese hostname (wsus.domain.htb) y levantar un servidor WSUS falso con TLS usando la herramienta wsuks. Los clientes Windows que consultan WSUS ejecutarán el payload entregado por el servidor falso como SYSTEM.

Campo abusado: ENROLLEE_SUPPLIES_SUBJECT = True + EKU Server Authentication → cert para hostname arbitrario (wsus.domain.htb) → MitM TLS del tráfico WSUS