AD CS (Active Directory Certificate Services) es la implementación de PKI de Microsoft integrada en Windows Server. En la práctica, actúa como la autoridad certificadora interna de una organización: el componente encargado de emitir y validar certificados digitales en los que todo el dominio confía por diseño.
Y suele estar mucho más presente de lo que parece:
Muchas organizaciones lo instalaron hace años, lo configuraron una vez, y nunca más lo tocaron. Ese es el problema.
Conceptos clave
Antes de entrar a las vulnerabilidades, vale la pena tener claros algunos conceptos que van a aparecer en el blog. No es necesario memorizarlos, pero sí entenderlos para que cada ataque tenga sentido.
Plantillas de certificados (Certificate Templates)
Una plantilla es la configuración que define cómo se emite un certificado. Establece quién puede solicitarlo, para qué sirve, cuánto tiempo es válido, y si requiere aprobación manual.
Cuando un usuario solicita un certificado, la CA no improvisa: sigue exactamente lo que dice la plantilla, y ahí está el problema cuando esa plantilla está mal configurada.
EKUs (Extended Key Usages)
Los EKUs, también llamados Application Policies en la documentación de Microsoft, son los atributos que definen para qué puede usarse el certificado que emite una plantilla. Cada propósito está representado por un Object Identifier (OID).
| Propósito | OID |
|---|---|
| Client Authentication | 1.3.6.1.5.5.7.3.2 |
| Smart Card Logon | 1.3.6.1.4.1.311.20.2.2 |
| Document Signing | 1.3.6.1.4.1.311.10.3.12 |
| File Recovery (EFS) | 1.3.6.1.4.1.311.10.3.4.1 |
| Any Purpose | 2.5.29.37.0 |
El EKU más crítico en el contexto de estos ataques es Client Authentication: permite que el certificado se use para autenticarse en el dominio vía Kerberos. Si una plantilla mal configurada lo tiene habilitado, un atacante puede obtener un certificado y autenticarse como cualquier usuario del dominio.
SAN (Subject Alternative Name)
El SAN es el campo del certificado que indica a quién representa. En condiciones normales, la CA construye ese campo desde los atributos reales del usuario en el AD.
El problema ocurre cuando la plantilla permite que el solicitante especifique el SAN libremente. En ese caso, el atacante puede indicar el UPN de cualquier usuario, incluyendo el Administrador del dominio, y la CA lo acepta sin validar.
Enrollment
Enrollment es el proceso mediante el cual un usuario o equipo solicita un certificado a la CA. Los permisos de enrollment en una plantilla definen quién puede hacer esa solicitud.
Cuando esos permisos son demasiado amplios, por ejemplo asignados a Domain Users o Authenticated Users, cualquier cuenta del dominio puede solicitar certificados desde esa plantilla, sea o no su intención legítima.
Manager Approval
Control en la plantilla que indica la solicitud de certificado en estado pendiente hasta que un CA Manager la aprueba manualmente. Cuando está deshabilitado, la CA emite el certificado de inmediato sin intervención humana.
En el contexto de los ataques, la ausencia de Manager Approval es lo que permite que el ataque sea completamente automático.
TGT (Ticket Granting Ticket)
Es el ticket que Kerberos entrega después de una autenticación exitosa. Con un TGT válido de una cuenta privilegiada, el atacante puede solicitar acceso a cualquier servicio del dominio como si fuera esa cuenta.
PKINIT
PKINIT es la extensión de Kerberos que permite autenticarse usando un certificado en lugar de una contraseña. Cuando un atacante obtiene un certificado válido de una cuenta privilegiada, usa PKINIT para solicitar un TGT de Kerberos como esa cuenta, sin necesitar su contraseña.
Caso de uso real: Auto-enrollment + EFS
Para entender por qué ADCS es infraestructura crítica y no solo un servicio técnico, quisimos mostrarlo con un ejemplo práctico y cercano a lo que se podría hacer como empresa.
La empresa COFIACORE genera reportes de ethical hacking con información altamente sensible: vulnerabilidades encontradas, credenciales comprometidas, accesos obtenidos, entre otros. Esos documentos no pueden estar disponibles para cualquier usuario del dominio.
La solución: cifrar esos archivos con EFS usando certificados emitidos por nuestra propia CA. Solo el usuario que tiene el certificado correspondiente puede abrir el archivo. Sin este, sería un acceso denegado.
Paso 1 — Crear la plantilla EFS
Antes de que los usuarios puedan obtener certificados EFS, necesitamos una plantilla configurada en la CA.
En DC1-COFIACORE, duplicamos la plantilla base "EFS básico" y la configuramos de la siguiente manera:
Plantilla EFSUsuario configurada en certsrv.msc con permisos para Domain Users
Paso 2 — Obtener el certificado
ADCS permite configurar auto-enrollment para que el certificado llegue automáticamente cuando el usuario inicia sesión. Para que esto funcione correctamente se debe configurar la GPO de inscripción automática en el dominio.
Para este laboratorio lo generaremos de forma manual para que el proceso sea más visible y fácil de seguir.
En WKS01, como david.soto, abrimos certmgr.msc:
Acción → Todas las tareas → Solicitar automáticamente certificados → Siguiente → Inscribir → Finalizar
Resultado: David tiene su certificado emitido por cofiacore-DC1-COFIACORE-CA en Personal → Certificados.
Certificado EFS emitido para david.soto visible en certmgr.msc
Paso 3 — Crear el archivo confidencial
David acaba de terminar un reporte de vulnerabilidades. Creamos el archivo con PowerShell para simular el escenario:
powershellNew-Item -ItemType Directory ` -Path "$env:USERPROFILE\Documents\Reportes-Confidenciales" ` -Force @" REPORTE DE VULNERABILIDADES - CONFIDENCIAL Cliente: XYZ Corporation Fecha: Marzo 2026 Ethical Hacker: David Soto - COFIACORE HALLAZGOS CRÍTICOS: 1. ESC1 en ADCS - Supply in the request habilitado 2. Kerberoasting posible - 15 service accounts con SPN 3. SMB Signing deshabilitado en servidores de archivos CONFIDENCIAL - NO DISTRIBUIR "@ | Out-File ` -FilePath "$env:USERPROFILE\Documents\Reportes-Confidenciales\Vulnerabilidades-Cliente-XYZ.txt" ` -Encoding UTF8
Creación del archivo confidencial de vulnerabilidades con PowerShell
Paso 4 — Cifrar el archivo
David no necesita conocimientos técnicos para esto. Click derecho en el archivo:
Propiedades → Opciones avanzadas → Cifrar contenido para proteger datos → Aceptar → Aplicar
Cuando Windows pregunta el alcance del cifrado:
Cifrado EFS activado en las propiedades avanzadas del archivo
Resultado final
powershellcipher /c "$env:USERPROFILE\Documents\Reportes-Confidenciales\Vulnerabilidades-Cliente-XYZ.txt"
Salida de cipher /c confirmando el cifrado del archivo con el certificado de david.soto
Al intentar abrir el archivo desde la cuenta de hugo.sandoval, otro usuario del dominio, el resultado es "no tiene permiso para abrir este archivo…":
Acceso denegado para hugo.sandoval al intentar abrir el archivo cifrado
Sin el certificado de David, el archivo es ilegible aunque hugo.sandoval tenga acceso físico a la carpeta.
Así es como ADCS debería funcionar.
El problema es que, en muchos entornos, pequeñas decisiones de configuración transforman este sistema de confianza en una de las superficies de ataque más peligrosas de Active Directory.
En la próxima publicación veremos exactamente cómo ocurre.
Wladimir Hernandez
CEO
CEO de Cofiacore con más de 10 años de experiencia en ciberseguridad ofensiva y defensiva. Especialista en pruebas de penetración web, análisis de vulnerabilidades y operaciones de Red Team.
