ESC9 vs. ESC16: misma falla, diferente radio de impacto

ESC9 y ESC16 son dos de las técnicas numeradas de escalada (ESC) catalogadas para Active Directory Certificate Services (AD CS), y son la misma vulnerabilidad en diferentes ámbitos. Ambas eliminan la extensión de seguridad del identificador de seguridad (SID) de los certificados emitidos, lo que permite a un atacante suplantar otra cuenta mediante un mapeo débil de certificados. ESC9 lo hace en una sola plantilla de certificado. ESC16 lo hace en todos los certificados que emite una autoridad certificadora (CA).

Si solucionaste ESC9 hace un par de años, eso no te dice nada sobre ESC16.

¿Qué es ESC9?

ESC9 es una configuración de plantilla. Cuando CT_FLAG_NO_SECURITY_EXTENSION está establecido en el atributo msPKI-Enrollment-Flag de una plantilla, los certificados emitidos desde esa plantilla no llevan la extensión SID (szOID_NTDS_CA_SECURITY_EXT). Esa extensión es la que permite que un controlador de dominio (DC) vincule un certificado a una cuenta específica. Sin ella, el DC recurre a mapear por el nombre principal de usuario (UPN).

El ataque requiere tres cosas: un atacante con acceso de escritura al UPN de una cuenta víctima (GenericWrite es suficiente), derechos de inscripción en una plantilla de client-authentication con la bandera activada, y un DC que no aplique un mapeo fuerte de certificados. El atacante cambia el UPN de la víctima para que coincida con una cuenta privilegiada, se inscribe, vuelve a poner el UPN original y se autentica con el certificado como el usuario privilegiado.

Oliver Lyak documentó ESC9 en agosto de 2022, y muchos escáneres pueden detectarlo, incluyendo Netwrix PingCastle. La lista de verificación a continuación muestra cómo revisar tus propias plantillas.

¿Qué es ESC16?

ESC16 llega al mismo resultado sin modificar una plantilla. Si el OID 1.3.6.1.4.1.311.25.2, que es la extensión de seguridad szOID_NTDS_CA_SECURITY_EXT SID, está listado en el valor del registro DisableExtensionList del módulo de políticas de la CA, la CA deja de añadir la extensión SID a todo lo que emite. Cada plantilla detrás de esa CA ahora se comporta como si la bandera ESC9 estuviera activada, incluyendo plantillas que nadie ha revisado en años.

Un entorno puede terminar con esta configuración por varias razones: una corrección de compatibilidad para una herramienta de terceros, una migración o una aplicación heredada que no maneja la extensión. Es una única entrada en el registro que se pasa fácilmente por alto y cancela silenciosamente la protección que construiste plantilla por plantilla.

La configuración no es un atributo de plantilla. Es una configuración de CA, y muchas revisiones de higiene de certificados nunca abren los ajustes del módulo de políticas de la propia CA. Una organización puede estar limpia en cada plantilla, tener el informe que lo demuestre y aun así estar expuesta a través de la CA. Si escaneaste para ESC9 hace años y no has revisado tus CAs desde entonces, un atacante aún podría realizar el mismo ataque de suplantación mediante ESC16.

¿Te protege el mapeo fuerte de certificados?

En parte. Ambas técnicas dependen de que el DC acepte asignaciones débiles, y los DC que aplican una vinculación fuerte de certificados las neutralizan. Desde las actualizaciones de Windows de septiembre de 2025, los DC parcheados aplican la política de forma completa y la configuración de modo de compatibilidad ya no es compatible, por lo que un dominio completamente parcheado detiene ESC9 y ESC16 sin protección. Aún quedan dos brechas: cualquier DC que no haya recibido esas actualizaciones y las cadenas donde el atacante puede suministrar su propio SID en la solicitud de certificado, como ESC16 combinado con ESC6 o ESC15. Verifique la aplicación en cada DC y también revise la CA.

¿Cómo verificas y corriges ambos?

Necesita dos verificaciones, porque ESC9 está en las plantillas y ESC16 está en el CA.

Verificar ESC9 (plantillas de certificados)

1. Ejecute un escaneo de PingCastle.
2. Abra el informe y busque CT_FLAG_NO_SECURITY_EXTENSION (el riesgo es A-CertTempNoSecurity). Busque el texto "Al menos una plantilla de certificado tiene establecida la bandera CT_FLAG_NO_SECURITY_EXTENSION."
3. Si ese texto no está, ninguna de las plantillas escaneadas tiene la marca. Si está, elimine la marca de las plantillas afectadas.

Verifique ESC16 (la CA)

En cada CA, ejecute:

      certutil -getreg policy\DisableExtensionList
      

Si el OID 1.3.6.1.4.1.311.25.2 aparece en la salida, esa CA está eliminando la extensión SID de todo lo que emite. Elimínelo de la lista a menos que tenga una razón documentada para ello.

Para solucionarlo, elimine el OID y reinicie Certificate Services para que el cambio surta efecto:

      certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
      

Ejecute certutil -getreg policy\DisableExtensionList nuevamente después para confirmar que el OID ha desaparecido. Los certificados ya emitidos sin la extensión permanecen así, por lo que debe revisarlos si sospecha que se abusó de esta configuración. Si una aplicación necesitaba esta configuración, pruébela antes de implementarla ampliamente.

Luego confirme la aplicación: verifique que sus DCs estén aplicando un mapeo fuerte de certificados, ya que eso neutraliza ambas técnicas. En un DC con actualizaciones actuales, eso es el valor predeterminado. Para el resto de la exposición de su CA, incluyendo ESC8 en la inscripción web, revise la configuración riesgosa de AD CS que a menudo aparece junto a estos dos.

¿Cómo detectas el próximo cambio?

Para ESC9 en adelante: la bandera de plantilla reside en Active Directory, lo que significa que un cambio en ella es un cambio en un objeto de AD. Netwrix Threat Prevention supervisa los cambios en AD en tiempo real y puede bloquearlos, por lo que alguien que establezca CT_FLAG_NO_SECURITY_EXTENSION en una plantilla puede ser detenido antes de que surta efecto, no detectado en la siguiente evaluación.

Para ESC16 en adelante: la configuración está en el registro del servidor CA, no en AD, por lo que necesita su propia cobertura: auditoría del registro en los hosts CA que alimentan su SIEM, además de la verificación periódica mencionada arriba. Netwrix también correlaciona los inicios de sesión basados en certificados con la emisión y señala escenarios con extensiones SID faltantes, por lo que el abuso de la configuración se detecta incluso si el cambio en el registro pasa desapercibido.