Seguridad de AD CS y ESC1-ESC16

Aviso legal y ético: el contenido de este módulo tiene fines exclusivamente educativos y defensivos, dirigido a administradores de PKI, arquitectos de identidad y equipos de seguridad que necesitan auditar y proteger sus propias infraestructuras de Active Directory Certificate Services (AD CS). Auditar, atacar o intentar escalar privilegios contra una CA o una plantilla de certificado que no sea de tu propiedad, o para la que no dispongas de autorización explícita y por escrito, es ilegal en prácticamente todas las jurisdicciones (en España, arts. 197 y ss. y 264 y ss. del Código Penal, sobre acceso no autorizado a sistemas y daños informáticos). Todas las técnicas se describen para que sepas identificarlas y corregirlas en tu propio bosque, no para explotarlas contra terceros. Practica exclusivamente en laboratorios aislados de tu propiedad.

Este módulo desarrolla en profundidad el trabajo seminal de SpecterOps «Certified Pre-Owned: Abusing Active Directory Certificate Services» (Will Schroeder y Lee Christensen, 2021), que catalogó por primera vez de forma sistemática las vías de escalada de privilegios ESC1-ESC8 en AD CS, y las extensiones posteriores investigadas por la comunidad (incluyendo ESC9-ESC16) hasta la actualidad. El enfoque es íntegramente defensivo: cada vía se explica para que puedas detectarla en tu propia PKI con Certify, Certipy (en modo de auditoría/lectura) o PSPKI, y corregirla antes de que alguien más la encuentre primero.

Qué aprenderás

Por qué una CA empresarial de AD es, por definición, un activo Tier 0 equivalente a un DC, y qué implica que «una CA comprometida permite falsificar cualquier identidad».
Los fundamentos de PKI en AD: jerarquía de CA, plantillas de certificado, el objeto NTAuth, el proceso de inscripción y cómo Windows traduce un certificado en una identidad de Kerberos/NTLM.
Las ocho vías originales (ESC1-ESC8) de «Certified Pre-Owned»: qué configuración las causa, cómo se detectan y cómo se corrigen.
Las vías descubiertas después (ESC9-ESC16), su relación con KB5014754, y por qué siguen apareciendo variantes nuevas.
Cómo auditar plantillas y CAs con PSPKI y con Certify/Certipy en modo defensivo de auditoría, sin credenciales elevadas.
Cómo leer y corregir EDITF_ATTRIBUTESUBJECTALTNAME2, Extended Protection en la web de inscripción, y el ciclo de hardening recomendado por Microsoft y SpecterOps.
Cómo monitorizar la emisión de certificados (eventos 4886/4887) para detectar abuso en tiempo real.

Por qué AD CS es Tier 0

El modelo de Tiers de Microsoft (Tier 0 / Tier 1 / Tier 2) clasifica los activos de una infraestructura de identidad según el radio de impacto de su compromiso. Tier 0 agrupa todo aquello cuyo control equivale, directa o indirectamente, a controlar el dominio completo: controladores de dominio, cuentas con membresía en Domain Admins/Enterprise Admins, el propio Active Directory, y —desde la publicación de «Certified Pre-Owned» en 2021— toda Autoridad de Certificación empresarial (Enterprise CA) integrada en AD.

La razón es estructural, no una cuestión de grado. Una CA empresarial es un servicio de confianza: cuando emite un certificado con EKU de autenticación de cliente para una cuenta de usuario o equipo, ese certificado se convierte, a todos los efectos de Kerberos PKINIT y Schannel, en una prueba de identidad válida. Si un atacante consigue que la CA le emita —o emite él mismo— un certificado en nombre de un Domain Admin o de un DC, obtiene esa identidad sin contraseñas ni hashes NTLM, y con una vigencia que puede ser de años. A diferencia de un hash NTLM (mitigable rotando la contraseña) o un ticket Kerberos (con expiración natural), un certificado fraudulento sigue siendo válido hasta su caducidad o revocación explícita —y muchas organizaciones no tienen un proceso maduro de revocación (CRL/OCSP) verificado en producción.

El compromiso de la clave privada de la CA misma es catastrófico: permite firmar certificados arbitrarios para cualquier identidad del bosque, indistinguibles de una emisión legítima. Es el equivalente PKI del hash krbtgt: un «golden ticket» en forma de certificado, con la particularidad de que revocar el daño exige revocar y reemitir toda la cadena de confianza. Por esto, el host donde corre el rol AD CS y las cuentas con permisos sobre CN=Public Key Services,CN=Services,CN=Configuration,DC=... deben tratarse con el mismo aislamiento que un DC. La investigación de SpecterOps demostró, además, que no hace falta comprometer la CA en sí: basta una plantilla mal configurada para escalar directamente a Domain Admin sin tocar la clave privada. Es esa superficie —las plantillas y su ACL de inscripción— la que ocupa el grueso de este módulo.

Fundamentos de PKI en Active Directory

Antes de entrar en las vías de escalada hace falta fijar el vocabulario, porque cada ESC se explica exactamente en términos de estos componentes.

Una jerarquía de PKI corporativa típica tiene una CA raíz (Root CA), habitualmente offline salvo para emitir/renovar certificados de sus CAs subordinadas, y una o varias CAs subordinadas (Issuing CA) que emiten certificados en el día a día. Una CA subordinada instalada como Enterprise CA (frente a «Standalone CA») queda integrada en AD: publica su certificado y CRL, usa plantillas de certificado como objetos de AD (clase pKICertificateTemplate), y autentica a los solicitantes vía Kerberos/NTLM sin exigir aprobación manual de cada solicitud. Es esa integración la que habilita —y expone— el modelo de plantillas abusado en las vías ESC. Cada plantilla define qué EKU lleva el certificado, cuánto dura, si requiere aprobación de manager, y —crítico aquí— quién tiene Enroll y de dónde saca el Subject/SAN. Una CA solo emite certificados de plantillas que tenga explícitamente publicadas; auditar una PKI empieza siempre por enumerar qué plantillas están publicadas y qué ACL de inscripción tiene cada una.

El objeto NTAuthCertificates, ubicado en CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=..., contiene la lista de certificados de CA que AD confía explícitamente para autenticación de clientes vía certificado (smart card logon / PKINIT). Que una CA esté en el almacén de «Trusted Root CA» de Windows no basta para que sus certificados sirvan para autenticarse contra AD: la CA emisora tiene que estar publicada en NTAuth. Este objeto es en sí mismo Tier 0: cualquiera que pueda escribir en él puede introducir una CA maliciosa que AD aceptará después como fuente válida de identidades.

Cuando un cliente solicita un certificado (vía certreq, el snap-in MMC, autoenrollment por GPO, o la interfaz web de inscripción), la CA valida contra la ACL de la plantilla si el solicitante tiene el permiso extendido Enroll, construye el Subject/SAN según la configuración de la plantilla, y firma el certificado con la clave de la CA. La EKU resultante determina para qué se puede usar: Client Authentication (OID 1.3.6.1.5.5.7.3.2) permite autenticarse como la identidad del Subject/SAN; Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1, «Enrollment Agent») permite solicitar certificados en nombre de otro usuario; y Any Purpose (OID 2.5.29.37.0) o la ausencia total de EKU permiten literalmente cualquier uso, incluida autenticación de cliente. Estas tres EKU son las protagonistas de la mayoría de las vías ESC.

Las vías de escalada: ESC1 a ESC8 y siguientes

La tabla siguiente resume, para cada vía catalogada por SpecterOps y la comunidad posterior, la causa raíz (la configuración vulnerable concreta), cómo detectarla en auditoría, y la contramedida recomendada. Es la referencia central de este módulo: cada fila se desarrolla después en prosa con más detalle y con los comandos de detección/corrección.

Vía	Causa (configuración vulnerable)	Cómo detectarla	Contramedida
ESC1	Plantilla permite `ENROLLEE_SUPPLIES_SUBJECT` (el solicitante indica su propio SAN) + EKU de autenticación de cliente + ACL de Enroll abierta a usuarios de bajo privilegio, sin requerir aprobación de manager.	Certify/Certipy en modo lectura contra plantillas publicadas; PSPKI `Get-CertificateTemplate` revisando el flag `msPKI-Certificate-Name-Flag` y la ACL de Enroll.	Desmarcar «Supply in the request» del Subject Name en la plantilla; restringir Enroll a grupos concretos; exigir aprobación de manager si el SAN debe seguir siendo flexible.
ESC2	Plantilla con EKU `Any Purpose` o sin ninguna EKU definida, combinada con ACL de Enroll amplia.	Revisar `pKIExtendedKeyUsage` de cada plantilla publicada; cualquier plantilla vacía o con Any Purpose y Enroll abierto es sospechosa.	Definir EKU explícita y mínima necesaria (nunca Any Purpose salvo justificación documentada); restringir ACL de Enroll.
ESC3	Plantilla con EKU `Certificate Request Agent` (Enrollment Agent) asignable a usuarios de bajo privilegio, que luego puede usarse para solicitar certificados «en nombre de» cualquier otro usuario en una segunda plantilla que permita agentes de inscripción.	Buscar plantillas con esa EKU y revisar quién tiene Enroll sobre ellas; revisar qué plantillas de «on behalf of» existen y su ACL.	Restringir estrictamente qué cuentas pueden ser Enrollment Agent (idealmente solo cuentas de servicio dedicadas para emisión de smart cards); auditar uso real vía eventos de la CA.
ESC4	El propio objeto plantilla tiene una ACL débil (no solo de Enroll, sino de `WriteProperty`/`WriteOwner`/`WriteDacl`) que permite a un usuario de bajo privilegio reconfigurar la plantilla y convertirla en vulnerable a ESC1/ESC2/ESC3 por su cuenta.	PSPKI/BloodHound revisando la ACL completa (no solo Enroll) de cada objeto plantilla en AD.	Aplicar el principio de mínimo privilegio sobre la ACL de gestión de plantillas; solo Domain/Enterprise Admins y el equipo de PKI deben poder modificar plantillas.
ESC5	Control (ACL débil) sobre otros objetos PKI relevantes: el propio objeto CA en AD, el contenedor `Public Key Services`, el objeto `NTAuthCertificates`, o la cuenta de equipo del servidor de la CA (dueña, vía delegación o RBCD, de la posibilidad de comprometer el servicio).	Revisar ACL de todo el árbol `CN=Public Key Services,CN=Services,CN=Configuration`, no solo de las plantillas; revisar delegación en la cuenta de equipo de la CA.	Bloquear cualquier ACL no estándar sobre estos contenedores; tratar el servidor de la CA como Tier 0 (sin delegación no restringida, sin admins locales innecesarios).
ESC6	La CA (no la plantilla) tiene activado el flag `EDITF_ATTRIBUTESUBJECTALTNAME2`, que permite indicar el SAN por atributo de la solicitud en cualquier plantilla, saltándose la restricción de «Supply in the request» configurada a nivel de plantilla.	`certutil -config <CA> -getreg policyEditFlags` y comprobar si aparece `EDITF_ATTRIBUTESUBJECTALTNAME2` en la salida.	`certutil -setreg policyEditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2` para desactivarlo, seguido de reinicio del servicio `CertSvc`.
ESC7	Control administrativo sobre la propia CA vía los derechos `ManageCA` o `ManageCertificates` concedidos a cuentas de bajo privilegio, que permiten aprobar solicitudes pendientes o manipular la configuración de la CA (incluida la reactivación de EDITF_ATTRIBUTESUBJECTALTNAME2).	PSPKI `Get-CertificationAuthorityAcl` revisando quién tiene esos dos derechos administrativos sobre la CA.	Restringir `ManageCA`/`ManageCertificates` a un grupo mínimo y auditado de administradores de PKI; nunca a grupos amplios tipo «Server Admins».
ESC8	La interfaz de inscripción web (Certificate Enrollment Web Services / `certsrv`) está expuesta por HTTP (no HTTPS) o sin Extended Protection for Authentication, permitiendo un relay NTLM de una víctima autenticándose contra el atacante hacia la interfaz de inscripción para obtener un certificado en su nombre.	Comprobar si el sitio de inscripción responde en HTTP; revisar configuración de Extended Protection en IIS; herramientas de detección de relay (Certipy en modo `find`, PetitPotam como prueba de exposición en laboratorio propio).	Forzar HTTPS exclusivamente, habilitar Extended Protection for Authentication en IIS, deshabilitar NTLM en el servidor de la CA cuando sea viable, y mitigar coacción de autenticación (PetitPotam y similares) con las protecciones de RPC/EFSRPC correspondientes.
ESC9 (No Security Extension)	Plantilla con el flag `CT_FLAG_NO_SECURITY_EXTENSION` (extensión `szOID_NTDS_CA_SECURITY_EXT` deshabilitada), que elimina el vínculo fuerte SID-certificado, combinado con mapeo débil de certificados en el controlador de dominio.	Revisar `msPKI-Enrollment-Flag` de las plantillas buscando ese bit; comprobar el modo de mapeo fuerte de certificados en los DC (ver sección KB5014754).	No deshabilitar la extensión de seguridad salvo necesidad justificada; migrar los DC al modo `Full Enforcement` de mapeo fuerte.
ESC10	Los DC operan en modo de mapeo de certificados débil/permisivo (`Compatibility` o claves de registro `CertificateMappingMethods`/`StrongCertificateBindingEnforcement` mal configuradas), permitiendo que un certificado con UPN/SAN alterable se mapee a otra cuenta.	Revisar en los DC las claves `HKLMSYSTEMCurrentControlSetServicesKdcStrongCertificateBindingEnforcement` y `HKLMSYSTEMCurrentControlSetControlSecurityProvidersSchannelCertificateMappingMethods`.	Migrar a `Full Enforcement` (valor `2`) tras el periodo de auditoría de KB5014754; documentado en la sección específica más abajo.
ESC11	La CA no exige Request Encryption (RPC sin sellado/firmado) en su interfaz RPC de emisión, lo que puede facilitar variantes de relay similares a ESC8 pero contra el endpoint RPC en lugar del web.	PSPKI/Certify comprobando el flag `IF_ENFORCEENCRYPTICERTREQUEST` de la CA.	Activar `IF_ENFORCEENCRYPTICERTREQUEST` con `certutil -setreg` y reiniciar `CertSvc`.
ESC12	La clave privada de una CA con almacenamiento en un dispositivo YubiHSM/HSM mal configurado, o la clave de la CA accesible con el CA administrator combinada con acceso físico/lógico al material criptográfico protegido de forma insuficiente.	Revisión de la configuración de protección de clave privada de la CA (HSM, proveedor CSP/KSP) y de quién tiene acceso administrativo a ese nivel.	Uso correcto de HSM con políticas de acceso segregadas; nunca compartir el PIN/credencial del HSM con administradores de servidor genéricos.
ESC13	Plantilla cuya EKU está vinculada, a través de un Issuance Policy OID (política de emisión) que a su vez está enlazado a un grupo de AD, otorgando pertenencia efectiva a ese grupo con solo obtener el certificado.	Revisar `msPKI-Certificate-Policy` de las plantillas y su vínculo con objetos `msPKI-Enterprise-Oid` que tengan `msDS-OIDToGroupLink` apuntando a grupos privilegiados.	Auditar qué OIDs de política están enlazados a grupos y restringir el Enroll de las plantillas que los usan igual que si concedieran esa membresía de grupo directamente.
ESC14/ESC15/ESC16 (variantes recientes)	Abusos adicionales sobre atributos de mapeo débil en objetos de usuario/equipo (p. ej. `altSecurityIdentities` mal gestionado — ESC14) y sobre plantillas de esquema V1 que ignoran la EKU de la solicitud emitiendo con la Application Policy del cliente en lugar de la de la plantilla (ESC16, descrita públicamente en 2024).	Revisión del atributo `altSecurityIdentities` en cuentas sensibles; comprobación de si la CA tiene publicadas plantillas de esquema V1 con comportamiento de «Application Policy» heredado sin control adicional.	Aplicar el mismo rigor de ESC1-ESC13 a estos vectores; mantener el software de la CA actualizado, ya que ESC16 se mitiga con los parches de Microsoft que corrigen el comportamiento de asignación de política en plantillas V1.

Matices que la tabla no puede capturar

ESC1 es la vía más citada y la más fácil de introducir por error: sin exploit ni vulnerabilidad de código, solo tres flags coincidentes en una plantilla —SAN libre, EKU de autenticación, Enroll abierto sin aprobación— bastan para que cualquier usuario autenticado obtenga un certificado como Domain Admin. ESC2 llega al mismo resultado por otra vía: una EKU vacía o Any Purpose también sirve para autenticación. ESC3 encadena dos plantillas: una otorga el rol de Enrollment Agent, la segunda acepta solicitudes «en nombre de» otro usuario; con ACL amplias en ambas, un usuario de bajo privilegio las combina para obtener un certificado ajeno.

ESC4 y ESC5 desplazan el foco de «qué permite la plantilla» a «quién puede reconfigurarla«: un descuido de delegación (WriteProperty/WriteOwner/WriteDacl) sobre el objeto de una plantilla permite fabricar un ESC1 a medida (ESC4), y lo mismo aplica al resto del árbol PKI —objeto CA, NTAuthCertificates, delegación de la cuenta de equipo de la CA— en ESC5. Auditar solo «Enroll» es insuficiente.

ESC6 sube al nivel de configuración global: EDITF_ATTRIBUTESUBJECTALTNAME2 convierte cualquier plantilla publicada en un ESC1 universal. ESC7 es su equivalente administrativo: ManageCA permite reactivar ese flag, y ManageCertificates permite saltarse la aprobación de manager; asignarlos a un grupo operativo amplio entrega de facto el control de la CA. ESC8 rompe el patrón por completo: no depende de ninguna plantilla, sino del transporte. Web enrollment sin HTTPS o sin Extended Protection es vulnerable a relay NTLM —coaccionando a un DC (vía PetitPotam u otras técnicas RPC) para reenviar sus credenciales y obtener un certificado de su cuenta de equipo.

La investigación no se detuvo en 2021. ESC9/ESC10 están ligadas al mapeo de certificados de KB5014754: sin extensión de seguridad SID y con el DC en modo permisivo, un certificado se puede mapear a otra identidad. ESC11 traslada el relay de ESC8 al canal RPC de la CA. ESC12 cubre HSM mal configurado. ESC13 es menos conocida: una política de emisión enlazada, vía msDS-OIDToGroupLink, a un grupo de AD, de modo que el certificado hereda esa membresía. Las variantes ESC14-ESC16 (2023-2024) cubren altSecurityIdentities mal gestionado y plantillas V1 heredadas. El patrón es siempre el mismo: la configuración heredada abre una vía que nadie diseñó a propósito, y la única defensa sostenible es la auditoría periódica.

Auditoría de la PKI: PSPKI, Certify y Certipy en modo defensivo

La forma correcta de aproximarse a esta auditoría, incluso sin credenciales administrativas de dominio, es enumerar primero qué CAs y plantillas existen y a quién se les concede Enroll, y después revisar los flags de cada plantilla y de cada CA descritos en la tabla anterior. PSPKI (PowerShell PKI Module) es la herramienta nativa y menos intrusiva, apoyada en las mismas APIs de gestión que usaría un administrador de PKI legítimo.

# Instalar/importar el módulo PSPKI (requiere permisos de lectura sobre AD, no admin de dominio)
Install-Module -Name PSPKI -Scope CurrentUser
Import-Module PSPKI

# Enumerar todas las CAs empresariales del bosque
Get-CertificationAuthority | Format-Table Name, DisplayName, ComputerName, IsAccessible

# Volcar la configuración de seguridad (ACL de ManageCA / ManageCertificates / Enroll) de una CA
Get-CertificationAuthority -Name "CONTOSO-CA01" | Get-CertificationAuthorityAcl |
    Select-Object -ExpandProperty Access | Format-Table IdentityReference, Rights, AccessControlType

# Enumerar todas las plantillas publicadas y sus flags de nombre/emisión
Get-CertificateTemplate | Select-Object Name,
    @{N='SupplyInRequest';E={$_.Extensions['Enrollee Supplies Subject'] -ne $null}},
    @{N='EKU';E={($_.Extensions | Where-Object {$_.Oid.FriendlyName -eq 'Enhanced Key Usage'}).EnhancedKeyUsages}},
    @{N='RequiresApproval';E={$_.SubordinationRequirements}} |
    Format-Table -AutoSize

# Revisar la ACL (permisos de Enroll/Autoenroll y de gestión) de una plantilla concreta
Get-CertificateTemplate -Name "VulnUserTemplate" | Get-CertificateTemplateAcl |
    Select-Object -ExpandProperty Access |
    Where-Object { $_.ObjectDeletionRule -notmatch 'Deny' } |
    Format-Table IdentityReference, Rights, AccessControlType

Certify (.NET) y Certipy (Python) son las herramientas ofensivas de referencia surgidas del propio trabajo de SpecterOps y de la comunidad, pero su función de enumeración (find) es puramente de lectura: no modifican nada ni solicitan certificados por sí solas. Ejecutarlas contra tu propio dominio con una cuenta de bajo privilegio reproduce en segundos el mismo resultado que una revisión manual con PSPKI —y es exactamente lo que haría un atacante en fase de reconocimiento, lo cual es la razón por la que auditarte con ellas primero tiene tanto valor defensivo.

# Certify (Windows, .NET) — enumeración de plantillas vulnerables, sin solicitar ningún certificado
Certify.exe find /vulnerable

# Certify — incluir también CAs con EDITF_ATTRIBUTESUBJECTALTNAME2 activo y derechos ManageCA/ManageCertificates abiertos
Certify.exe find /vulnerable /currentuser

# Certipy (Linux/Python) — equivalente, contra un DC con credenciales de un usuario de dominio de bajo privilegio
certipy find -u 'auditor@contoso.local' -p 'PasswordDeAuditoria' -dc-ip 10.10.10.10 -vulnerable -stdout

# Certipy — exportar el resultado completo (todas las CAs y plantillas) a JSON para revisión posterior sin conexión
certipy find -u 'auditor@contoso.local' -p 'PasswordDeAuditoria' -dc-ip 10.10.10.10 -output auditoria_adcs

El matiz operativo importa: ejecutar estas herramientas contra tu propio entorno con autorización expresa del equipo de PKI es una práctica de auditoría legítima (Microsoft recomienda explícitamente PSPKI en su documentación de hardening de AD CS); ejecutarlas contra un dominio ajeno sin autorización es intrusión informática. La frontera es la titularidad y el consentimiento, no la herramienta.

El flag EDITF_ATTRIBUTESUBJECTALTNAME2: detección y corrección

Es probablemente el hallazgo individual más citado en auditorías de AD CS: es binario, afecta a toda la CA de golpe, y su corrección es una línea de certutil. Se comprueba y corrige en el servidor de la CA (o en remoto indicando -config) con permisos administrativos sobre el servicio.

# Comprobar el estado actual de los EditFlags de la política de la CA
certutil -config "CONTOSO-CA01.contoso.localContoso Issuing CA" -getreg policyEditFlags

# Salida esperada si el flag vulnerable está activo (fragmento relevante):
#   EditFlags REG_DWORD = 15014e (...)
#     EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)
#   ...

# Desactivar EDITF_ATTRIBUTESUBJECTALTNAME2 (mantiene el resto de flags intactos)
certutil -config "CONTOSO-CA01.contoso.localContoso Issuing CA" -setreg policyEditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

# El cambio no surte efecto hasta reiniciar el servicio de la CA
# (ejecutar en el propio servidor de la CA, no en remoto)
net stop certsvc && net start certsvc

# Verificar que el flag ya no aparece tras el reinicio
certutil -config "CONTOSO-CA01.contoso.localContoso Issuing CA" -getreg policyEditFlags

Conviene aprovechar la misma sesión de hardening para revisar y activar, si no lo está ya, el flag equivalente de ESC11 sobre cifrado obligatorio de la solicitud RPC:

# Comprobar si la CA exige cifrado en las solicitudes RPC de emisión (mitiga ESC11)
certutil -config "CONTOSO-CA01.contoso.localContoso Issuing CA" -getreg CAInterfaceFlags

# Activar la exigencia de solicitud cifrada
certutil -config "CONTOSO-CA01.contoso.localContoso Issuing CA" -setreg CAInterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
net stop certsvc && net start certsvc

Corrección de plantillas: quitar el SAN libre y restringir Enroll

La corrección de ESC1 se hace desde el snap-in Certificate Templates (certtmpl.msc) del servidor de la CA, o de forma programática con PSPKI. Pasos para el runbook de hardening: en la pestaña Subject Name, cambiar de «Supply in the request» a «Build from this Active Directory information» (usando el DNS/UPN real de la cuenta, no un valor arbitrario); en Security, reducir el grupo con Enroll a solo quien realmente lo necesita; y si el caso de uso exige flexibilidad de SAN, activar en Issuance Requirements la opción «CA certificate manager approval» para que cada solicitud quede pendiente de aprobación manual.

# Auditoría previa: localizar plantillas con Enrollee Supplies Subject + EKU de autenticación + Enroll amplio
Get-CertificateTemplate | ForEach-Object {
    $tpl = $_
    $suppliesSubject = $tpl.Extensions['Enrollee Supplies Subject'] -ne $null
    $hasAuthEku = ($tpl.Extensions | Where-Object {$_.Oid.FriendlyName -eq 'Enhanced Key Usage'}).EnhancedKeyUsages -match 'Client Authentication|Smart Card Logon|Any Purpose'
    if ($suppliesSubject -and $hasAuthEku) {
        [PSCustomObject]@{ Plantilla = $tpl.Name; RiesgoESC1 = $true }
    }
} | Format-Table -AutoSize

# Corrección programática (equivalente a desmarcar "Supply in the request" desde el snap-in):
# NOTA: se recomienda hacerlo desde certtmpl.msc para revisión visual antes de aplicar en producción;
# el cambio directo por LDAP al atributo msPKI-Certificate-Name-Flag requiere pruebas exhaustivas
# en laboratorio antes de replicarlo, ya que afecta a todas las inscripciones futuras de esa plantilla.

KB5014754 y el mapeo fuerte de certificados

En mayo de 2022, Microsoft publicó KB5014754, que cambia de raíz cómo los DC validan el vínculo entre un certificado de autenticación Kerberos PKINIT/Schannel y la cuenta de AD a la que da acceso. Antes, el mapeo dependía en gran medida del UPN/DNS del SAN —precisamente el campo que ESC1/ESC6/ESC9/ESC10 permiten manipular—. KB5014754 introduce el mapeo fuerte: una extensión de seguridad (szOID_NTDS_CA_SECURITY_EXT) que embebe el SID de la cuenta en el certificado al emitirlo, de forma que el DC verifica criptográficamente el SID en lugar de fiarse del UPN declarado.

El despliegue se hizo en fases, y muchos entornos siguen hoy en la intermedia sin saberlo: Compatibility (por defecto tras el parche) acepta mapeo débil y fuerte, y registra en el DC (Event ID 39 y 41) los certificados aceptados solo por mapeo débil; Full Enforcement rechaza cualquier certificado sin la extensión fuerte o un mapeo explícito vía altSecurityIdentities, y es el estado final recomendado. El valor StrongCertificateBindingEnforcement en HKLMSYSTEMCurrentControlSetServicesKdc controla el KDC (0=deshabilitado, 1=Compatibility, 2=Full Enforcement); CertificateMappingMethods en HKLMSYSTEMCurrentControlSetControlSecurityProvidersSchannel controla el equivalente para Schannel/TLS.

# Comprobar el modo actual de mapeo fuerte en un controlador de dominio
reg query "HKLMSYSTEMCurrentControlSetServicesKdc" /v StrongCertificateBindingEnforcement

# Comprobar el modo equivalente para Schannel (TLS con certificado de cliente)
reg query "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSchannel" /v CertificateMappingMethods

# Revisar en el Visor de Eventos del DC los certificados aceptados solo por mapeo débil
# (Event ID 39 = certificado sin la extensión fuerte pero aceptado en modo Compatibility;
#  Event ID 41 = certificado explícitamente mapeado por altSecurityIdentities)
Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=39 or EventID=41)]]" |
    Select-Object TimeCreated, Id, Message | Format-List

# Una vez confirmado (tras el periodo de auditoría en modo Compatibility) que no quedan
# certificados legítimos dependiendo de mapeo débil, forzar Full Enforcement:
reg add "HKLMSYSTEMCurrentControlSetServicesKdc" /v StrongCertificateBindingEnforcement /t REG_DWORD /d 2 /f
# Reiniciar el servicio KDC (o el DC) para aplicar el cambio
Restart-Service kdc -Force

Migrar directamente a Full Enforcement sin auditoría previa es la causa más habitual de incidentes de disponibilidad: cualquier certificado legítimo emitido antes del parche, o de una plantilla con CT_FLAG_NO_SECURITY_EXTENSION activado por una razón de negocio real, dejará de autenticar de golpe. La recomendación del sector es desplegar el parche, dejar correr Compatibility con monitorización de los eventos 39/41 durante varias semanas (idealmente un ciclo completo de renovación de certificados), corregir lo que dependa de mapeo débil, y solo entonces pasar a Full Enforcement.

Monitorización activa: eventos 4886 y 4887

La auditoría puntual es necesaria pero no suficiente: hay que monitorizar la emisión en curso, porque una plantilla segura hoy puede volverse vulnerable mañana por un cambio no autorizado (el escenario de ESC4). Habilitar la subcategoría de auditoría «Certification Services» (por GPO o en las propiedades de auditoría de la propia CA) genera los eventos 4886 (solicitud recibida) y 4887 (certificado emitido) en el log de Seguridad. Enviarlos a un SIEM y correlacionarlos contra «quién debería solicitar qué plantilla» permite detectar en minutos una solicitud anómala —una cuenta de servicio pidiendo un certificado con SAN de Administrator— en lugar de descubrirlo semanas después en la siguiente auditoría trimestral.

# Habilitar la subcategoría de auditoría "Certification Services" en el servidor de la CA
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

# Habilitar también la auditoría a nivel de la propia CA (objeto CA, pestaña Auditing)
certutil -setreg CAAuditFilter 127
net stop certsvc && net start certsvc

# Consultar en el log de Seguridad las solicitudes y emisiones recientes
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4886 or EventID=4887)]]" -MaxEvents 50 |
    Select-Object TimeCreated, Id, @{N='Detalle';E={$_.Message}} | Format-List

# Filtrar específicamente emisiones (4887) que incluyan una plantilla y un solicitante concretos,
# útil para revisar retroactivamente si una plantilla vulnerable fue explotada antes de corregirla
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4887)]]" |
    Where-Object { $_.Message -match 'VulnUserTemplate' } |
    Select-Object TimeCreated, Message

Comparativa: CAs legacy (2003/2008) frente al objetivo de hardening

Es habitual encontrar CAs cuya instalación original data de Windows Server 2003/2008 y que se han ido migrando de servidor en servidor sin que nadie revisara nunca la configuración heredada. El patrón «legacy» reconocible: plantillas de esquema V1 (comportamiento más permisivo por diseño, ver ESC16), la plantilla «User»/»Basic EFS» con Enroll para Authenticated Users sin revisar, EDITF_ATTRIBUTESUBJECTALTNAME2 activado en su día para una migración puntual y nunca desactivado, certsrv accesible por HTTP simple, y ninguna auditoría «Certification Services» habilitada porque nunca formó parte de la línea base cuando el servidor se desplegó.

El objetivo de hardening moderno: plantillas de esquema V3/V4 con Subject construido desde AD (nunca suministrado por el solicitante salvo excepción documentada), EKU explícita y mínima, ACL de Enroll auditada y restringida, EDITF_ATTRIBUTESUBJECTALTNAME2 desactivado, ManageCA/ManageCertificates limitados a un grupo dedicado de PKI, inscripción web solo por HTTPS con Extended Protection, DC en Full Enforcement tras el periodo de auditoría, y 4886/4887 centralizados en el SIEM. La brecha no se cierra con un único cambio: es un programa de hardening con checklist recurrente, el que se practica en el laboratorio de este módulo.

Laboratorio: auditar y corregir una plantilla vulnerable

Requiere un bosque de laboratorio propio con al menos un DC, un servidor con el rol AD CS como Enterprise CA, y una cuenta estándar sin privilegios administrativos para la parte de auditoría.

Preparar el escenario vulnerable a propósito. Duplica la plantilla «User» (certtmpl.msc > Duplicate Template), nómbrala LabESC1, marca «Supply in the request» en Subject Name, confirma EKU Client Authentication, y concede Enroll a Domain Users. Publícala en la CA.
Auditar desde bajo privilegio. Con la cuenta estándar, ejecuta PSPKI o Certify/Certipy en modo find /vulnerable y confirma que LabESC1 aparece como vulnerable a ESC1.
Documentar el impacto sin comprometer nada fuera del laboratorio: qué identidad podría suplantarse y qué permisos tiene en el dominio.
Revisar el flag de la CA. Ejecuta certutil -getreg policyEditFlags; si no está activado, actívalo con -setreg para practicar el ciclo completo, y revierte después.
Corregir LabESC1. Cambia Subject Name a «Build from this Active Directory information», restringe Enroll, y activa «CA certificate manager approval» si quieres practicar la aprobación manual.
Verificar repitiendo el paso 2: LabESC1 ya no debe aparecer como vulnerable.
Habilitar auditoría («Certification Services» + AuditFilter), solicita un certificado de prueba, y localiza los eventos 4886/4887 en el log de Seguridad.
Documentar en un informe breve: plantilla afectada, vía ESC, evidencia, corrección y verificación — el formato de una auditoría real de PKI.

Errores comunes

No tratar AD CS como Tier 0. El error de fondo más extendido: el servidor de la CA se administra con cuentas de «IT genérico», sin el aislamiento y la monitorización reforzada que ya se aplica, correctamente, a los DC.
Dejar plantillas heredadas con SAN libre «porque siempre ha sido así». Migrar de servidor en servidor sin revisar la configuración original es la vía de entrada más habitual de ESC1 en auditorías reales.
Confundir «parcheada» con «endurecida». Windows Update no corrige una plantilla mal configurada ni un EDITF_ATTRIBUTESUBJECTALTNAME2 activado hace años: son decisiones de configuración, no vulnerabilidades de código.
Quedarse en Compatibility de KB5014754 indefinidamente. Es una herramienta de transición, no un estado final; mantenerlo deja abierta la ventana de mapeo débil.
Auditar una sola vez y no repetir. ESC4 existe porque una plantilla segura hoy puede reconfigurarse mañana; sin auditoría recurrente, ese cambio pasa desapercibido.
Exponer la inscripción web sin Extended Protection ni HTTPS. Se justifica como «uso interno», ignorando que buena parte de los ataques de relay parten precisamente de la red interna.
Auditar solo el permiso «Enroll». ESC4 y ESC5 quedan invisibles si la revisión no cubre también WriteProperty/WriteOwner/WriteDacl sobre plantillas y el resto del contenedor Public Key Services.

Ejercicio

Sobre tu laboratorio de AD CS, realiza una auditoría completa y entrega un informe:

Enumera todas las CAs empresariales con PSPKI y documenta su ACL de ManageCA/ManageCertificates.
Enumera todas las plantillas publicadas y clasifícalas frente a la tabla maestra (ESC1-ESC7 como mínimo), señalando cuáles son vulnerables y a qué vía.
Comprueba el estado de EDITF_ATTRIBUTESUBJECTALTNAME2 en cada CA.
Comprueba si la inscripción web está publicada, si fuerza HTTPS y tiene Extended Protection.
Comprueba el modo StrongCertificateBindingEnforcement en tus DC.
Para cada hallazgo, propón la contramedida de la tabla maestra y, si el laboratorio lo permite, aplícala y vuelve a auditar.
Cierra priorizando: si solo pudieras corregir tres hallazgos esta semana con recursos limitados, ¿cuáles y por qué, en términos de radio de impacto?

Preguntas frecuentes

¿Necesito ser Domain Admin para auditar mi PKI con estas herramientas?

No. La enumeración (find en Certify/Certipy, cmdlets de lectura de PSPKI) se apoya en permisos de lectura que cualquier usuario autenticado tiene por defecto, porque la CA necesita poder consultar esa información para procesar solicitudes de cualquier usuario. Corregir plantillas y flags de la CA sí requiere permisos administrativos (ManageCA como mínimo para los flags de política).

¿Basta con desactivar EDITF_ATTRIBUTESUBJECTALTNAME2 para estar a salvo?

No. Cierra una vía muy citada (ESC6) pero es solo una fila de la tabla maestra. Una plantilla con ENROLLEE_SUPPLIES_SUBJECT propio (ESC1) sigue vulnerable aunque el flag global esté desactivado, porque ESC1 no depende de él. Hay que corregir cada vía de forma independiente; no existe un único interruptor que las resuelva todas.

¿Qué diferencia hay entre usar Certify/Certipy como atacante y como defensor?

Ninguna a nivel de código: es la misma herramienta ejecutando el mismo comando de enumeración. La diferencia es exclusivamente de titularidad, autorización y propósito: usarla contra tu propio dominio (o el de un cliente, con contrato y alcance definidos) para generar un informe de hallazgos es auditoría legítima; usarla contra un dominio ajeno sin autorización, o explotar realmente una vía fuera de un laboratorio propio, es un delito.

Mi CA sigue en modo Compatibility de KB5014754 desde 2022. ¿Es grave?

Es una ventana de exposición real, aunque menos crítica que tener plantillas ESC1 activas: en Compatibility el DC sigue aceptando mapeo débil, que es justo lo que abusan ESC9/ESC10. Conviene completar el ciclo de auditoría de eventos 39/41 y pasar a Full Enforcement; cuanto más tiempo se mantenga sin revisión activa, más probable es que nadie note un abuso puntual entre el volumen normal de eventos.

¿Las plantillas por defecto de Windows Server vienen ya vulnerables?

Las modernas (2016 en adelante, esquema V4) vienen razonablemente restringidas de fábrica. El riesgo aparece casi siempre por modificaciones posteriores —alguien amplía Enroll «para que funcione» un caso puntual, o activa «Supply in the request» para resolver una incidencia y no lo revierte— o por plantillas heredadas sin revisión (esquema V1/V2). Por eso la auditoría periódica importa más que la configuración inicial: la PKI se degrada por deriva de configuración, no por defectos de fábrica.

«Given the ubiquity of these misconfigurations across the environments we’ve assessed, and the fact that AD CS is often overlooked from a security perspective, we believe there is immense value for both offensive and defensive practitioners in understanding the array of attack vectors possible in AD CS environments. […] Compromising a CA, or even a CA’s certificate/private key, would be catastrophic for an organization’s trust model, resulting in complete domain compromise.»

— Will Schroeder & Lee Christensen, «Certified Pre-Owned: Abusing Active Directory Certificate Services», SpecterOps, 2021

Módulo 9: Seguridad de Active Directory Certificate Services (AD CS)