ADCS ESC2, ESC3, ESC5, ESC7: escalada de certificados entre las técnicas más conocidas

Qué son las rutas de escalada de certificados ADCS ESC2 ESC3 ESC5 ESC7

Las rutas de escalada de certificados ADCS ESC2 ESC3 ESC5 ESC7 se ubican en el hueco entre dos extremos bien cubiertos de la superficie de ataque de Active Directory Certificate Services (AD CS). La investigación Certified Pre-Owned de SpecterOps nombró ocho técnicas, ESC1 a ESC8, y estudios posteriores añadieron ESC9, ESC10 y ESC11. Este corpus ya cubre ambos extremos: Rutas de ataque ADCS: cómo errores de certificados se convierten en rutas de escalada en Active Directory cubre ESC1, ESC4, ESC6 y ESC8, y ADCS ESC9, ESC10, ESC11: escalada de certificados más allá de ESC1-ESC8 cubre las técnicas de la capa de vinculación publicadas después de KB5014754. ESC2, ESC3, ESC5 y ESC7 son las cuatro técnicas de la numeración original de SpecterOps que ninguno de los dos artículos etiqueta.

Ese hueco importa porque estas cuatro técnicas no son un resto aleatorio, y se encadenan con las mismas rutas de ataque de Active Directory que el análisis tipo BloodHound mapea para cualquier otra técnica Tier 0. ESC2 y ESC3 son técnicas a nivel de plantilla, como ESC1, pero en lugar de una plantilla que filtra quién puede autenticarse con un certificado, filtran para qué puede usarse un certificado una vez emitido — ya sea para cualquier propósito, o para el propósito específico de solicitar certificados en nombre de otra persona. ESC5 y ESC7 son técnicas de control de acceso, como ESC4, pero en lugar de una ACL sobre una única plantilla de certificado, actúan sobre los objetos y permisos que controlan cada plantilla y cada certificado que la CA emitirá jamás: el control de acceso propio de la CA, y los contenedores PKI en Active Directory que albergan las plantillas, los registros de CA, y la lista de CA en las que los controladores de dominio confían para la autenticación.

Un entorno que ya ha remediado todos los hallazgos ESC1, ESC4, ESC6 y ESC8, y todos los hallazgos ESC9, ESC10 y ESC11, puede seguir teniendo una ruta activa hacia Domain Admin a través de estas cuatro técnicas — porque ninguno de los demás controles revisa el alcance de los EKU, la delegación de agente de inscripción, o el control de acceso a nivel de objeto PKI y de CA.

Cómo funciona

ESC2 — Plantillas Any Purpose o sin EKU

ESC2 es una plantilla de certificado cuyo Extended Key Usage (EKU) es el OID Any Purpose (2.5.29.37.0) o no define ningún EKU en absoluto, lo que Windows trata como una plantilla equivalente a una CA subordinada utilizable para cualquier propósito. Según la documentación de Certify de SpecterOps, explotar esto requiere que se cumplan todas estas condiciones a la vez: el principal del atacante tiene derechos de inscripción a nivel de CA, ese mismo principal tiene derechos de inscripción en la plantilla específica, la plantilla no exige aprobación de un gestor, la plantilla no exige firmas autorizadas (co-firmadas), y el EKU de la plantilla es Any Purpose o está completamente ausente.

Cuando esas condiciones se alinean, el atacante se inscribe con un certificado desde la plantilla y obtiene una credencial que Windows aceptará para cualquier propósito que consuma certificados — incluido, según la documentación de SpecterOps, el mismo rol de "Certificate Request Agent" del que depende ESC3. En otras palabras, una plantilla ESC2 puede usarse para iniciar un ataque de agente de inscripción tipo ESC3 aunque nunca declare explícitamente el EKU Certificate Request Agent. Por eso los hallazgos ESC2 siempre deben verificarse frente a las demás plantillas publicadas de la CA antes de descartarlos como poco severos: un certificado Any Purpose es tan peligroso como lo que la CA permita canjear con él.

ESC3 — Plantillas de agente de inscripción (cadena de dos plantillas)

ESC3 es una cadena de dos plantillas, no un único error de configuración. La primera plantilla debe llevar el EKU Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1) — el mismo OID que Microsoft documenta como la extensión de política de aplicación de agente de inscripción usada para la emisión de tarjetas inteligentes. Según la documentación de SpecterOps, la plantilla de primera etapa necesita los mismos requisitos de inscripción que ESC2 (derechos de inscripción a nivel de CA y de plantilla, sin aprobación de gestor, sin firmas autorizadas) más ese EKU específico.

Una vez que el atacante tiene ese certificado de agente de inscripción, necesita una segunda plantilla: una que no restrinja quién puede actuar como agente de inscripción, en la que el atacante pueda inscribirse, que no exija aprobación de gestor, y cuyo EKU sea compatible con el rol de agente — autenticación de cliente, PKINIT, inicio de sesión con tarjeta inteligente, Any Purpose, o ningún EKU en absoluto. Con ambas piezas en su lugar, el atacante solicita un certificado desde la segunda plantilla en nombre de una identidad objetivo, como un Domain Admin, usando el certificado de agente de inscripción para firmar la solicitud. El certificado resultante autentica como el objetivo, no como el atacante.

La documentación de Microsoft sobre la función Restricted Enrollment Agent, introducida en Windows Server 2008 Enterprise, describe con precisión por qué esto es peligroso por defecto: antes de esa función, "no es posible permitir que un agente de inscripción inscriba solo a un determinado grupo de usuarios", así que cualquier certificado de agente de inscripción válido podía usarse para solicitar un certificado en nombre de cualquier usuario de la organización, incluidos los Domain Admins. Restricted Enrollment Agent permite a un administrador de CA delimitar qué plantillas y qué grupos de seguridad objetivo puede usar cada certificado de agente de inscripción — pero solo en una CA de edición Enterprise, y solo si realmente se ha configurado.

ESC5 — Control de acceso vulnerable sobre objetos PKI

ESC5 no es en absoluto un problema de plantilla. Es un problema de ACL de Active Directory sobre los objetos que hacen que toda la PKI sea digna de confianza. Según la documentación de SpecterOps, los objetos en alcance son:

• el propio objeto de equipo AD del servidor de la CA
• el servidor RPC/DCOM de la CA
• el árbol del contenedor Public Key Services en el contexto de nomenclatura de Configuración (CN=Public Key Services,CN=Services,CN=Configuration,DC=...), incluidos sus subcontenedores Certificate Templates, Certification Authorities y Enrollment Services
• el objeto NTAuthCertificates dentro de ese contenedor

Según la documentación del protocolo [MS-WCCE] de Microsoft, el objeto NTAuthCertificates contiene un atributo multivalor de certificados de firma de CA codificados en DER — en la práctica, la lista de CA en las que los controladores de dominio confían para la autenticación basada en certificados (incluido el inicio de sesión con tarjeta inteligente). Si un atacante puede escribir en ese objeto, puede añadir una CA maliciosa a la lista de confianza; cada certificado que esa CA maliciosa firme a partir de entonces pasa a ser de confianza para la autenticación de dominio. La documentación de SpecterOps da un ejemplo concreto del riesgo general: Domain Users con GenericAll sobre el contenedor Certificate Templates y sus descendientes — control total sobre cada definición de plantilla de certificado del bosque, desde un grupo con alcance por defecto.

La severidad de un hallazgo ESC5 depende por completo de qué objeto está expuesto y a quién. El acceso de escritura al contenedor Certificate Templates permite a un atacante crear o modificar plantillas hasta darles una forma ESC1/ESC2/ESC3 desde cero, sorteando cualquier endurecimiento ya realizado sobre las plantillas existentes. El acceso de escritura al objeto de equipo de la CA o a su servidor RPC/DCOM puede llevar al compromiso del propio host de la CA, y con él, de la clave privada de la CA — la misma clase de impacto documentada en Certighost CVE-2026-54121 ADCS: usuarios con pocos privilegios pueden suplantar a un controlador de dominio, donde una falla distinta de AD CS permitía a un usuario con pocos privilegios suplantar a un controlador de dominio.

ESC7 — Control de acceso vulnerable sobre la autoridad de certificación

ESC7 reside en el propio descriptor de seguridad del objeto CA, no en objetos AD — y a diferencia de ESC6, no es un indicador del registro. Las CA de Windows admiten la separación de roles mediante dos derechos de acceso configurables en la pestaña Seguridad de la consola Entidad emisora de certificados: ManageCA (rol de administrador de CA) y ManageCertificates (rol de gestor/oficial de certificados).

Según la documentación de SpecterOps, tener ManageCA permite a un principal cambiar la configuración de la CA a nivel global — incluido activar el indicador EDITF_ATTRIBUTESUBJECTALTNAME2 del que depende ESC6, reactivar plantillas vulnerables previamente deshabilitadas, y habilitar las condiciones de las que dependen ESC11 y ESC16. Eso significa que un atacante que solo tiene ManageCA — sin ningún error de configuración de plantilla a la vista — puede fabricar condiciones ESC6 o ESC11 a voluntad. La documentación de SpecterOps también describe un abuso más directo de ManageCA: solicitar un certificado desde una plantilla que exige aprobación de gestor, dejar que la solicitud falle y quede pendiente, y luego usar ManageCA junto con ManageCertificates para forzar la emisión de esa solicitud pendiente, sin importar el requisito de aprobación que se suponía debía bloquearla.

ManageCertificates por sí solo permite a un principal gestionar y emitir certificados que están pendientes de aprobación. Según la documentación de SpecterOps, esto habilita una evasión tipo ESC1 mediante políticas de emisión vinculadas a grupos: solicitar un certificado desde una plantilla sujeta a aprobación, usar ManageCertificates para inyectar un OID de política de emisión vinculado a un grupo en la solicitud pendiente, y luego emitirlo — obteniendo un certificado cuya política de emisión mapea a un grupo privilegiado, sin llegar a satisfacer nunca el control de aprobación de gestor que la plantilla estaba configurada para exigir.

La cadena de ataque

El patrón común a las cuatro técnicas: ESC2 y ESC3 abusan de lo que una plantilla puede hacer una vez que sale un certificado de ella; ESC5 y ESC7 abusan de quién puede controlar las plantillas y la CA en primer lugar. Esa segunda categoría explica por qué remediar cada plantilla individual señalada por ESC1, ESC2, ESC3, ESC4 o ESC6 no cierra la puerta — un atacante con acceso ESC5 o ESC7 puede simplemente recrear la condición vulnerable después de que termine la revisión.

🚨 Peligro: ESC3 y las variantes de escritura de ESC5 terminan ambas en el mismo resultado que ESC1 — un certificado que autentica como una identidad objetivo, convertible en un TGT de Kerberos y utilizable para suplantar esa identidad, incluido un Domain Admin. La escalada hacia la ACL de un objeto PKI a menudo comienza como reconocimiento ordinario de abuso ACL y DCSync en lugar de como una técnica específica de AD CS.

Detección

Remediación

1. Eliminar las plantillas de autenticación Any Purpose y sin EKU (ESC2). Restrinja la lista de EKU de cada plantilla publicada a lo que realmente necesita. Si una plantilla genuinamente necesita ser reutilizable para varios propósitos, mantenga los requisitos de aprobación de gestor y de firma autorizada en lugar de depender únicamente de un EKU limitado.
2. Restringir las plantillas de agente de inscripción (ESC3). Configure Restricted Enrollment Agent en cada CA de edición Enterprise que emita certificados Certificate Request Agent, delimitando cada agente de inscripción a plantillas específicas y grupos de seguridad objetivo específicos en lugar de dejarlo sin restricción. Donde Restricted Enrollment Agent no esté disponible, limite quién puede inscribirse en la plantilla de agente de inscripción al grupo más pequeño y mejor gestionado posible.
3. Endurecer las ACL de los objetos PKI (ESC5). Revise las ACL de los contenedores Certificate Templates, Certification Authorities y Enrollment Services, del objeto NTAuthCertificates, y del objeto de equipo AD de cada servidor CA. Elimine GenericAll, WriteDacl, WriteOwner, y derechos equivalentes de cualquier principal fuera del grupo de administración PKI Tier 0 previsto.
4. Ajustar la separación de roles de la CA (ESC7). Revise la pestaña Seguridad de cada CA y confirme que Manage CA e Issue and Manage Certificates solo los tienen las cuentas que los necesitan. Trate ambos como privilegios equivalentes a Tier 0, no como valores por defecto de administración de TI general — vea Endurecimiento Active Directory: qué bloquear primero y cómo validarlo para ver cómo encaja esto en una revisión de privilegios Tier 0 más amplia.
5. Revisar el manejo de solicitudes pendientes. Confirme que forzar la emisión de una solicitud de certificado denegada o pendiente no está disponible rutinariamente para los mismos principales que también pueden solicitar certificados — esa combinación es exactamente lo que hace posible la evasión de aprobación de ESC7.
6. Reprobar después de cada cambio. Las restricciones de agente de inscripción y los cambios de ACL de PKI pueden romper flujos legítimos de emisión de tarjetas inteligentes y de administración delegada. Valide con un grupo piloto representativo antes de aplicar los cambios en toda la CA, y mantenga activa la revisión del registro de auditoría de la CA de la sección de detección durante el despliegue.

Dónde encaja esto: ANSSI R36, R37, y el resto del corpus ADCS

La guía de ANSSI sobre la administración segura de Active Directory (ANSSI-PA-099) trata el riesgo de PKI sobre Tier 0 como su propia recomendación numerada, independiente de la higiene general de certificados. R36 establece que siempre que una PKI pueda generar certificados utilizables para la autenticación hacia Tier 0, esa PKI "no debe ofrecer rutas de ataque hacia Tier 0 desde niveles de confianza inferiores, ya sea mediante la administración de los sistemas que la alojan, mediante la delegación de derechos sobre las capacidades de generación de certificados, o mediante las plantillas de certificados publicadas" — una descripción casi exacta de lo que abusan ESC5 y ESC7 (el control delegado sobre la capacidad de generación de certificados, es decir, la CA y sus objetos PKI) y de lo que abusa ESC2 (plantillas publicadas que otorgan más capacidad de la prevista). La misma guía menciona por separado R37, que aborda la robustez criptográfica de los certificados (prohibiendo firmas DSA, exigiendo hashes SHA-2/SHA-3, y estableciendo tamaños mínimos de clave RSA) — una preocupación real pero distinta de los errores de configuración de EKU y ACL cubiertos aquí, que conviene auditar junto a estas cuatro técnicas en lugar de en su lugar.

Este artículo deliberadamente no repite ESC1, ESC4, ESC6 u ESC8 — vea Rutas de ataque ADCS: cómo errores de certificados se convierten en rutas de escalada en Active Directory para esos — ni ESC9, ESC10, ESC11, que residen en la capa de vinculación de certificados y cifrado RPC cubierta en ADCS ESC9, ESC10, ESC11 y su artículo complementario sobre mapeo débil de certificados. Una revisión completa de AD CS necesita los tres artículos, más la lista de verificación Tier 0 más amplia en Auditar la seguridad de Active Directory: qué revisar primero y cómo demostrar la remediación, porque ninguna de las once técnicas sustituye a otra.

Cómo lo detecta EtcSec

Los controles de auditoría de AD de EtcSec se corresponden directamente con cada técnica cubierta aquí: ESC2_ANY_PURPOSE señala las plantillas capaces de autenticación con un EKU Any Purpose o vacío y sin control de aprobación, ESC3_ENROLLMENT_AGENT señala las plantillas Certificate Request Agent y sus objetivos posteriores sin restricción, ESC5_PKI_OBJECT_ACL revisa las ACL del árbol del contenedor Public Key Services, NTAuthCertificates, y los objetos de equipo de las CA, y ESC7_CA_VULNERABLE_ACL revisa la separación de roles a nivel de CA en busca de otorgamientos demasiado amplios de ManageCA y ManageCertificates. Los hallazgos de las cuatro técnicas se agregan en PATH_CERTIFICATE_ESC cuando forman una ruta activa hacia Domain Admin, de modo que un indicador de plantilla o una entrada de ACL se prioriza según si realmente es alcanzable — no se señala de forma aislada.

Referencias principales

• SpecterOps / Certify — Escalation Techniques Overview
• SpecterOps / Certify — ESC2: Misconfigured Any Purpose
• SpecterOps / Certify — ESC3: Misconfigured Certificate Request Agent
• SpecterOps / Certify — ESC5: Vulnerable PKI Object Access Control
• SpecterOps / Certify — ESC7: Vulnerable Certificate Authority Access Control
• Certified Pre-Owned: Abusing Active Directory Certificate Services
• Microsoft: AD CS Restricted Enrollment Agent
• Microsoft: [MS-WCCE] NTAuthCertificates Object
• ANSSI-PA-099: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory