Problema de configuración de SafeNet Agent para Windows Logon AD CS (ESC1)

Cómo obtuve Domain Admin a través de SafeNet Agent para el inicio de sesión de Windows a través de ESC1

Feb 2, 2026

Netwrix descubrió que las versiones 4.0.0–4.1.2 de SafeNet Agent para Windows Logon crean, por defecto, una plantilla de certificado AD CS insegura, habilitando una ruta ESC1 que permite a cualquier usuario autenticado escalar a Administrador de Dominio. Thales solucionó el problema en la versión 4.1.3 restringiendo la inscripción de certificados a la cuenta de servicio NDES.

Descripción

Netwrix Security Research recientemente informó sobre un riesgo de seguridad relacionado con el SafeNet Agent for Windows Logon versiones 4.0.0, 4.1.1, y 4.1.2. Por diseño, el agente se basa en una plantilla de certificado en los Servicios de Certificación de Active Directory (AD CS), y la configuración de esa plantilla crea una ruta ESC1. Esto permite que los Usuarios Autenticados escalen a Administrador de Dominio, aunque la plantilla está destinada a soportar la función de inicio de sesión en Windows sin contraseña.

SafeNet Agent para Windows Logon es un componente ligero instalado en máquinas Windows para fortalecer la seguridad de inicio de sesión con autenticación multifactor (MFA). Ayuda a garantizar que los recursos sensibles sean accesibles solo por usuarios autorizados y asegura aplicaciones de escritorio y procesos que dependen de CredUI. Al hacerlo, se pretende proporcionar una experiencia de inicio de sesión segura y consistente para los usuarios finales. El inicio de sesión sin contraseña en Windows, que se basa en SafeNet Agent para Windows Logon, elimina la necesidad de contraseñas al acceder a la máquina y otros recursos. El inicio de sesión sin contraseña en Windows utiliza MFA basado en certificados X.509 (PKI) y está diseñado como un punto de entrada para organizaciones que comienzan su transición hacia la autenticación sin contraseña. Ayuda a reducir las llamadas al servicio de asistencia para restablecimientos de contraseña, proporciona a los empleados una experiencia de inicio de sesión más fluida que apoya la productividad y prepara el entorno para una adopción más amplia de la autenticación sin contraseña y moderna.

Aquí hay un diagrama de arquitectura de alto nivel de la solución de inicio de sesión en Windows sin contraseña y cómo interactúan sus componentes.

Figure 1. High-level diagram of Passwordless Windows Logon between the user device, STA, the SCEP server, and ADCS.

Como se mencionó anteriormente, la instalación requiere un AD CS y la creación de una plantilla de certificado para habilitar el inicio de sesión sin contraseña. Thales también proporciona un archivo ZIP en la documentación oficial que contiene dos scripts de PowerShell para automatizar estas tareas.

Figure 2. Official setup steps for Passwordless Windows Logon.

Cuando extraemos el archivo ZIP que viene con la instalación, encontramos un interesante archivo JSON llamado CertTemplate.json, que se utiliza para automatizar y completar la plantilla del certificado. Lo primero que destacó fue el conjunto de Usos de Clave Extendidos que permiten la autenticación, combinado con msPKI-Certificate-Name-Flag establecido en 1, lo que habilita el ENROLLEE_SUPPLIES_SUBJECT bandera. Si estás familiarizado con el abuso de AD CS, esta configuración sugiere fuertemente un problema de estilo ESC1.

Figure 3. CertTemplate.json showing the WLAPwdlessLogon certificate template, including its display name, authentication EKU OIDs, and msPKI-Certificate-Name-Flag set to 1 (ENROLLEE_SUPPLIES_SUBJECT).

Este script instala las herramientas de PowerShell requeridas para Active Directory y AD CS, luego crea una nueva plantilla de certificado AD CS llamada WLAPwdlessLogon utilizando la configuración de CertTemplate.json y la publica. Después de eso, otorga permiso de Inscripción al grupo Authenticated Users sobre la plantilla y reinicia el servicio de Servicios de Certificados.

Figure 4. The CreateCertTemplate.ps1 script uses grant_enroll_permission to assign Enroll rights on the WLAPwdlessLogon certificate template to Authenticated Users. Figure 4. The CreateCertTemplate.ps1 script uses grant_enroll_permission to assign Enroll rights on the WLAPwdlessLogon certificate template to Authenticated Users.

Ejecutar el script de PowerShell en nuestro laboratorio confirma que se crea la plantilla y que a los Usuarios Autenticados se les concede permiso de Inscripción.

Figure 5. Output from CreateCertTemplate.ps1 showing the WLAPwdlessLogon template created and Enroll permission granted to Authenticated Users. Figure 5. Output from CreateCertTemplate.ps1 showing the WLAPwdlessLogon template created and Enroll permission granted to Authenticated Users.

Después de publicar la plantilla del certificado, verificamos si realmente era vulnerable ejecutando Certify.exe para listar las plantillas inseguras. La salida muestra que se cumplen todas las condiciones ESC1, lo que significa que esta plantilla permite a cualquier usuario autenticado escalar a Administrador de Dominio.

Figure 6. Certify output showing the WLAPwdlessLogon template with ENROLLEE_SUPPLIES_SUBJECT set, client/smart card logon EKUs, and Enroll rights granted to Authenticated Users. Figure 6. Certify output showing the WLAPwdlessLogon template with ENROLLEE_SUPPLIES_SUBJECT set, client/smart card logon EKUs, and Enroll rights granted to Authenticated Users.

Ahora podemos solicitar un certificado para cualquier cuenta de usuario o computadora y usar ESC1 para suplantar esa identidad, incluyendo un Administrador de Dominio. En este ejemplo, lo haremos con el MSOL_1191fa1e45e4 cuenta, porque tiene permisos de DCSync.

Figure 7. Using Certipy to request a certificate for the MSOL_1191fa1e45e4 account via the vulnerable WLAPwdlessLogon template.

En este punto, podemos solicitar un TGT de Kerberos para esta identidad y usarlo para movernos lateralmente como esa cuenta.

Figure 8. Rubeus using the MSOL certificate to request a Kerberos TGT via PKINIT, successfully returning a ticket for the MSOL_1191fa1e45e4 account.

Cronograma de divulgación

Informamos sobre este problema de seguridad a Thales PSIRT el 24 de noviembre de 2025, incluyendo una prueba de concepto que muestra que el producto es vulnerable por diseño y permite a los usuarios autenticados usar ESC1 para alcanzar el Administrador de Dominio. Thales reconoció el informe el mismo día y lo escaló al equipo responsable de la solución.
El 28 de noviembre de 2025, contactamos a Thales para solicitar una actualización sobre este caso, ya que creemos que representa un defecto de diseño significativo.
El 4 de diciembre de 2025, Thales respondió que aún estaban esperando comentarios de su equipo de ingeniería.
El 10 de diciembre de 2025, Netwrix Security Research hizo un seguimiento para solicitar una actualización.
El 12 de diciembre de 2025, Thales confirmó que su equipo de ingeniería había identificado el problema y estaba trabajando tanto en una remediación como en un boletín de seguridad para informar a los clientes.
El 5 de enero de 2026, Netwrix Security Research volvió a preguntar para solicitar una actualización sobre el boletín de seguridad de Thales que cubre las mitigaciones para este problema.
El 12 de enero de 2026, Thales respondió y confirmó que habían emitido un boletín de seguridad y lanzado una versión actualizada del producto que mitiga el problema.

Mitigación

En el momento de redactar, Thales había reservado CVE-2026-0872 y publicó un boletín de seguridad recomendando que los clientes actualizaran SafeNet Agent para Windows Logon a la versión 4.1.3 para mitigar el problema.

En la versión actualizada, también se revisaron las directrices de la plantilla de AD CS.Usuarios autenticados ya no tienen Inscribirse derechos, y solo la cuenta de servicio NDES está autorizada para inscribirse en esta plantilla.

Figure 10. Official documentation updated the certificate template configuration to modify security permissions required for Passwordless Windows Logon enrollment. https://thalesdocs.com/sta/agents/wla-windows_logon/wla-preinstallation_passwordless/index.html

Figure 11. Shows CreateCertTemplate.ps1 updated the certificate template to remove Enroll permissions from Authenticated Users and grant Enroll only to the NDES service account.

Si volvemos a ejecutar Certify.exe, podemos confirmar que Read/Enroll los permisos ahora están limitados a la cuenta de servicio NDES, y Usuarios Autenticados ya no tienen esos derechos.

Figure 12. Certify.exe shows Enroll is now limited to the NDES service account.

Conclusión

Este caso muestra un ejemplo del mundo real de un producto MFA que aún puede introducir un riesgo significativo si se basa en un diseño deficiente de AD CS. La función sin contraseña se construyó sobre una plantilla de certificado que permite a cualquier usuario autenticado solicitar un certificado con EKUs de autenticación de cliente y ENROLLEE_SUPPLIES_SUBJECT, y el script del proveedor incluso otorga la inscripción a los usuarios autenticados por defecto. Juntos, esto convierte una característica de seguridad en un camino ESC1 listo para el administrador de dominio.

Referencias

Preguntas frecuentes

¿Qué es ESC1 en los Servicios de Certificados de Active Directory (AD CS)?

¿Cómo puede una plantilla de certificado mal configurada llevar a una escalada de privilegios?

¿Cuál es el papel de AD CS en un entorno de Windows?

¿Cómo se relaciona SafeNet Agent for Windows Logon con la seguridad de AD CS?

¿Qué deben hacer las organizaciones para mitigar las vulnerabilidades de las plantillas de AD CS?

Compartir en

Aprende más

Acerca del autor

Cómo obtuve Domain Admin a través de SafeNet Agent para el inicio de sesión de Windows a través de ESC1

Descripción

Cronograma de divulgación

Mitigación

Conclusión

Referencias

Preguntas frecuentes

Acerca del autor

Huy Kha

Director de Investigación de Seguridad

Últimos blogs

Nuestros artículos más destacados