Hardening de AD CS: cerrar las configuraciones ESC1-ESC8

Active Directory Certificate Services es infraestructura de Tier 0, al mismo nivel que los controladores de dominio, porque un certificado emitido por la CA puede autenticar como cualquier cuenta que indique el solicitante, esquivando por completo las defensas del controlador de dominio. Las clases de configuración errónea ESC1 a ESC8 documentadas por la comunidad de investigación en seguridad describen formas distintas en que una CA demasiado permisiva entrega certificados que no debería. Esta guía cubre cada clase desde un punto de vista defensivo (qué aspecto tiene la configuración errónea y cómo cerrarla), además de comandos de verificación y la supervisión para detectar intentos de abuso.

Por qué AD CS es Tier 0

La función de una CA es vincular una identidad a una clave pública. Si un usuario con pocos privilegios puede solicitar un certificado para un Domain Admin, o para cualquier cuenta con un EKU Client Authentication, puede usar ese certificado para autenticarse como esa cuenta mediante PKINIT, sin conocer nunca su contraseña y sin tocar directamente la pila de autenticación de un controlador de dominio. El propio servidor de la CA, y la clave privada del certificado raíz o emisor de la CA, deben tratarse con la misma disciplina de tiering que un controlador de dominio: nada de navegar desde la CA, ningún inicio de sesión que no sea de administradores de PKI y estaciones de trabajo de administración dedicadas y reforzadas para gestionar la CA.

Las clases ESC1-ESC8, desde la defensa

Se describen de forma conceptual (la configuración errónea y su corrección), no como pasos de explotación.

ESC1: el solicitante proporciona el sujeto + EKU de autenticación de cliente

Una plantilla de certificado que permite al solicitante especificar un nombre alternativo del sujeto (SAN) arbitrario, combinada con un EKU que permite la autenticación de cliente (Client Authentication, Smart Card Logon o similar), permite a cualquier usuario con derecho de inscripción solicitar un certificado que suplante a otra cuenta, incluidas las privilegiadas.

Corrección: audite todas las plantillas en busca de la marca «el solicitante proporciona el sujeto». Elimínela salvo que exista una necesidad de negocio concreta y documentada (algunos escenarios de inscripción automática la necesitan legítimamente; en esos casos, combínela con permisos de inscripción muy restringidos).

# Enumerar las plantillas y marcar las que permiten que el solicitante proporcione el sujeto
Get-ADObject -SearchBase (Get-ADRootDSE).ConfigurationNamingContext `
    -LDAPFilter "(objectClass=pKICertificateTemplate)" -Properties msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage |
    Select-Object Name, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage

msPKI-Certificate-Name-Flag es una máscara de bits: las plantillas con el bit 0x1 (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) activado son las de riesgo. Crúcelas con los OID de pKIExtendedKeyUsage de autenticación de cliente (1.3.6.1.5.5.7.3.2) o inicio de sesión con tarjeta inteligente (1.3.6.1.4.1.311.20.2.2).

ESC2: plantillas Any Purpose o sin EKU

Una plantilla sin restricción de EKU, o con el EKU Any Purpose, puede usarse de forma abusiva igual que ESC1 en cuanto se combina con el control del sujeto o con un agente de inscripción vulnerable. Retire las plantillas Any Purpose y sin EKU de la inscripción general; limite su ámbito al mínimo o retírelas.

ESC3: agente de solicitud de certificados vulnerable

Las plantillas Enrollment Agent permiten a su titular solicitar certificados en nombre de otros usuarios. Una plantilla Enrollment Agent demasiado amplia (emitida a un grupo grande, sin restringir para qué plantillas o usuarios puede inscribir el agente) se convierte en una ruta de suplantación. Restrinja la emisión de Enrollment Agent y combínela con las «Certificate Managers Restrictions» de la CA (restricciones por agente, por plantilla y por usuario de destino).

ESC4: control de acceso débil en las plantillas

Si un grupo con pocos privilegios tiene derechos Write/WriteDacl/WriteOwner sobre el objeto de AD de una plantilla sensible, puede reescribirla para introducir él mismo marcas de tipo ESC1. Audite las ACL de las plantillas, no solo su configuración.

$templates = Get-ADObject -SearchBase (Get-ADRootDSE).ConfigurationNamingContext `
    -LDAPFilter "(objectClass=pKICertificateTemplate)"
foreach ($t in $templates) {
    (Get-Acl -Path "AD:\$($t.DistinguishedName)").Access |
        Where-Object { $_.ActiveDirectoryRights -match "WriteProperty|WriteDacl|WriteOwner|GenericAll" } |
        Select-Object @{n='Template';e={$t.Name}}, IdentityReference, ActiveDirectoryRights
}

ESC5: control de acceso débil en los objetos de PKI

El mismo principio que ESC4, pero aplicado al objeto de la CA, al objeto NTAuthCertificates o a los propios contenedores Certificate Templates o de la CA. Cualquiera con acceso de escritura a estos objetos de AD puede añadir una CA fraudulenta a los emisores de confianza del bosque.

ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2

Esta marca de ámbito de toda la CA permite indicar un SAN en la solicitud para cualquier plantilla, independientemente de las marcas de sujeto de la propia plantilla, lo que en la práctica convierte cada plantilla habilitada en un riesgo ESC1. Compruébela y elimínela:

certutil -config "<CAHostName>\<CAName>" -getreg policy\EditFlags

Busque EDITF_ATTRIBUTESUBJECTALTNAME2 en la salida. Elimínela:

certutil -config "<CAHostName>\<CAName>" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc; net start certsvc

ESC7: control de acceso vulnerable en la CA

Los permisos de nivel de CA demasiado amplios (Manage CA, Manage Certificates) concedidos a grupos que no son de administradores de PKI permiten a sus titulares aprobar solicitudes pendientes o modificar la configuración de la CA, incluida la emisión de certificados que de otro modo se denegarían. Revíselos con certutil -getreg CA\Security o en la pestaña Seguridad del complemento MMC de la CA, y restrínjalos únicamente al grupo de administradores de PKI.

ESC8: NTLM relay hacia la inscripción web de la CA

El punto de conexión de inscripción web HTTP/HTTPS de la CA (certsrv, o CES/CEP para la inscripción automática) acepta autenticación NTLM sobre un canal que, sin Extended Protection for Authentication (EPA), puede recibir por relay una autenticación NTLM forzada o interceptada en otro punto de la red, lo que produce un certificado para la identidad reenviada. Es la variante específica de AD CS del problema más amplio de NTLM relay tratado en Frenar el NTLM relay.

Corrección: exija HTTPS en todos los puntos de conexión de inscripción web y habilite Extended Protection for Authentication en IIS en los directorios virtuales CertSrv/CES/CEP. Si la inscripción web no se usa activamente, deshabilite por completo el servicio de rol.

# Exigir SSL y habilitar EPA en el directorio virtual CertSrv (ejecutar en la CA/servidor web de inscripción).
# Estas secciones están bloqueadas a nivel de servidor, así que se escriben en applicationHost.config con -Location.
Import-Module WebAdministration
$loc = 'Default Web Site/CertSrv'
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags -Value 'Ssl'
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' `
    -Name 'extendedProtection.tokenChecking' -Value 'Require'

Lista general de correcciones

Supervisión y detección

Habilite la auditoría de la CA para que cada emisión, denegación y cambio de plantilla quede registrado:

certutil -setreg CA\AuditFilter 127
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

Revise el registro de eventos Security de la CA en busca de los ID de evento 4886 (solicitud enviada), 4887 (certificado emitido), 4888 (denegado) y 4899 (plantilla modificada). Establezca una referencia de los solicitantes esperados por plantilla y genere alertas ante emisiones a cuentas o SAN inesperados:

Get-WinEvent -LogName Security | Where-Object { $_.Id -in 4886,4887,4888,4899 } |
    Select-Object TimeCreated, Id, Message

Exporte también periódicamente la configuración de las plantillas para detectar desviaciones:

certutil -v -Template "<TemplateName>" > template-audit.txt

Qué se rompe

• Eliminar las marcas SAN / restringir la inscripción: cualquier flujo de trabajo que dependa de solicitudes de certificado de autoservicio con sujetos personalizados (algunos aprovisionamientos de clientes VPN, scripts de inscripción de IoT/dispositivos) tendrá que redirigirse a una plantilla dedicada y de ámbito muy restringido.
• Aprobación del administrador: convierte la inscripción automática en un flujo de solicitudes pendientes para las plantillas afectadas, lo que añade latencia para los usuarios finales hasta que actúa un aprobador; limítela a las plantillas sensibles, no a toda la CA.
• EPA en la inscripción web: rompe los clientes o balanceadores de carga que terminan TLS antes de IIS de forma que eliminan el token de enlace de canal; valide su ruta de terminación TLS antes de habilitarlo.
• Deshabilitar la inscripción web: rompe cualquier proceso que aún dependa de las páginas heredadas certsrv o de CES/CEP para la inscripción automática sobre HTTP; migre esos procesos antes a la inscripción automática por directiva de grupo.

Consulte también Hardening de controladores de dominio y Hardening de Kerberos para controles de Tier 0 adyacentes, y ESC1 para un análisis más detallado de esa clase concreta de configuración errónea.