Active Directory Certificate Services (ADCS)

Introduction to ADCS

ADCS es el rol que maneja la emisión de certificados para usuarios, equipos y servicios en la red de Active Directory. Este servicio, si está mal configurado, puede presentar vulnerabilidades que los atacantes podrían explotar para elevar privilegios o acceder a información sensible.

Algunas de las posibles vulnerabilidades que puede tener ADCS son:

  1. Delegación de privilegios en la emisión de certificados: Si ciertos usuarios tienen permisos para emitir certificados para otros, un atacante podría abusar de estos privilegios para obtener permisos elevados.

  2. Mala configuración en las plantillas de certificados: Configuraciones incorrectas en las plantillas de certificados podrían permitir que un atacante solicite un certificado en nombre de otro usuario, incluso uno con privilegios elevados.

  3. NTLM Relaying en HTTP: Si el ADCS acepta autenticación NTLM en lugar de Kerberos, un atacante podría redirigir las solicitudes para ganar acceso.


Componentes principales:

  • CA (Certification Authority): Emite y gestiona certificados. Puede haber múltiples CAs en una jerarquía.

  • Certificate Templates: Definen la configuración, permisos y requisitos para emitir certificados.

  • CES (Certificate Enrollment Server): Permite renovar certificados mediante solicitudes HTTPS.

  • Certificate Enrollment Policy Web Server: Proporciona información sobre la política de inscripción de certificados.

  • CA Web Enrollment: Permite que hosts fuera del dominio o con otros sistemas operativos renueven certificados.

  • NDES (Network Device Enrollment Service): Permite a dispositivos de red obtener certificados sin conexión.


Formatos de certificados X.509:

  • PEM: Certificado DER codificado en base64; puede almacenar múltiples claves sin protección por contraseña.

  • DER: Certificado en formato binario crudo.

  • PFX/P12 (PKCS#12): Almacena claves privadas con protección por contraseña.

  • P7B (PKCS#7): Almacena certificados de cadena, pero no claves privadas.


Principales atributos de certificados:

  • Subject: Entidad a la que se emite el certificado.

  • Issuer: Normalmente la CA.

  • SAN: Nombre alternativo del sujeto.

  • Validity Period: Periodo de validez del certificado.

  • EKU (Extended Key Use): Define usos específicos del certificado.

  • OID (Object Identifier): Indica el propósito o escenario de uso del certificado.

OID

Uso del certificado

1.3.6.1.5.5.7.3.1

Autenticación de servidor

1.3.6.1.5.5.7.3.2

Autenticación de cliente

1.3.6.1.5.5.7.3.3

Firma de código

1.3.6.1.5.5.7.3.4

Correo electrónico seguro

Proceso de CSR (Certificate Signing Request):

  1. El cliente envía una solicitud de certificado (CSR).

  2. La CA verifica los permisos del cliente para emitir el certificado solicitado.

  3. Si los permisos coinciden, la CA genera y firma el certificado con su clave privada.

  4. El certificado firmado es devuelto al cliente.


Checking Misconfigured Templates

Herramienta que utilizaremos para la escalada de privilegios con los ADCS.

Para verificar si existen plantillas mal configuradas, las cuales podemos abusar, podemos hacer uso del siguiente comando para que nos lo muestre en la terminal.

Ejemplo de cómo debería salirnos si existe una plantilla mal configurada en el ADCS que podemos intentar explotar. En este ejemplo, nos aparece que podemos realizar la explotación ESC7.


KDC_ERR_PADATA_TYPE_NOSUPP

Es posible que en algún momento obtengamos este mensaje de error al intentar autenticarnos con el certificado PFX del usuario que estamos impersonando, lo que indica que el KDC no admite el tipo de autenticación proporcionado.

KDC_ERR_PADATA_TYPE_NOSUPP

“…when a domain controller doesn’t have a certificate installed for smart cards…” is probably the most common reason for KDC_ERR_PADATA_TYPE_NOSUPP. If the DC doesn’t have a “Domain Controller”, “Domain Controller Authentication”, or another certificate with the Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1) installed, the DC isn’t properly set up for PKINIT and authentication will fail.

Also, according to Microsoft, “This problem can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted in order to get Domain Controller or Domain Controller Authentication certificates for the domain controller.” At least in some cases we’ve been able to auth via PKINIT to a DC even when the CA is not reachable, so this situation may be hit and miss.

If you run into a situation where you can enroll in a vulnerable certificate template but the resulting certificate fails for Kerberos authentication, you can try authenticating to LDAP via SChannel using something like PassTheCert. You will only have LDAP access, but this should be enough if you have a certificate stating you’re a domain admin.

Nos encontramos con varios blogs que mencionan el error KDC_ERR_PADATA_TYPE_NOSUPP, el cual ocurre cuando el controlador de dominio no soporta PKINIT. Esto impide que autenticarnos directamente con el certificado PFX.

Como alternativa, podemos utilizar PassTheCert para autenticarnos a LDAP a través de SChannel con nuestro certificado. Aunque esto solo nos daría acceso a LDAP, podría ser suficiente si el certificado nos identifica como Administrador de Dominio.

Lo primero que haremos será extraer la clave privada y el certificado desde el archivo PFX que obtuvimos del usuario Administrator. Para ello, utilizamos Certipy de la siguiente manera. A continuación, haremos uso de la herramienta PassTheCert.py para autentifcarnos con el certificado obtenido.

Con PassTheCert, utilizamos la clave privada y el certificado generado anteriormente para autenticarnos. En este ejemplo. se nos mostraría el resultado del comando whoami.

Para poder escalar privilegios y buscar otras maneras. podemos obtener una consola LDAP Shell con el parámetro -action ldap-shell.

Para ver varios ejemplos del uso de PassTheCert y de cómo logramos obtener acceso al sistema como el usuario Administrator podemos comprobar el siguiente blog.

ESC1

Domain Users Enrollment

Solicitud del certificado con SAN alternativo.

Probar el UPN como administrator@dominio.htb o sino administrator.

En caso de recibir error de The NETBIOS connection with de remote host timed out, probar de nuevo a ejecutarlo.

Autenticación con certificado.

Domain Computers (Machine Account)

En algunas ocasiones, es posible que exista la ESC1 pero solamente se pueda realizar a través de algún Domain Computer. En este resultado de adPEAS se comprueba que solamente los Domain Computers tienen permisos de enrollment sobre la plantilla vulnerable para realizar el ESC1.

Por lo tanto, hay que disponer de las credenciales de un equipo, que se pueden obtener de diversas maneras. En caso de que podemos añadir nuevas máquinas al dominio, podemos realizar lo siguiente a través de la herramienta de PowerView.py.

Una vez dispongamos de acceso a autenticarnos como un Domain Computer, realizaremos el ataque. Sustituir Gzzcoo$ por el nombre del PC y la contraseña Gzzcoo123 por la correspondiente.

Autenticación con certificado.


ESC2

Solicitud del certificado con SAN alternativo.

Autenticación con certificado.

Verificación.


ESC3

Solicitar un certificado.

Solicitar un certificando suplantando al Administrator.


ESC4

En caso de recibir error de The NETBIOS connection with de remote host timed out, probar de nuevo a ejecutar los comandos.

Atacando a la plantilla vulnerable a ESC4.

Verificar plantilla ESC4 después de la modificación.

Abusando de la plantilla modificada.

Recuperando el hash NTLM del usuario Administrator.

Volviendo la plantilla ESC4 al estado original.


ESC5

Solicitar el certificado del Domain Admin.

Emitir el certificado solicitado.

En este caso, aprobamos la solicitud anterior especificando el ID de la solicitud con la opción -issue-request 10.

Recuperar el certificado emitido.

Autenticarse con el certificado del Administrator.


ESC6

Solicitud de certificado con UPN alternativo, en este caso, el usuario Administrator.


ESC7

Requisitos previos

Para que esta técnica funcione, el usuario también debe tener el derecho de acceso Administrar certificados y la plantilla de certificado SubCA debe estar habilitada. Con el derecho de acceso Administrar CA, podemos cumplir con estos requisitos previos.

La técnica se basa en el hecho de que los usuarios con el derecho de acceso Administrar CA y Administrar certificados pueden emitir solicitudes de certificado fallidas. La plantilla de certificado SubCA es vulnerable a ESC1, pero solo los administradores pueden inscribirse en la plantilla. Por lo tanto, un usuario puede solicitar inscribirse en la SubCA (que será denegada) pero luego el administrador la emitirá.

Si solo tiene el derecho de acceso Administrar CA, puede otorgarse el derecho de acceso Administrar certificados agregando a su usuario como un nuevo funcionario.

La plantilla SubCA se puede habilitar en la CA con el parámetro -enable-template. De manera predeterminada, la plantilla SubCA está habilitada.

Ataque

Si hemos cumplido con los requisitos previos para este ataque, podemos comenzar solicitando un certificado basado en la plantilla SubCA.

Esta solicitud será rechazada, pero guardaremos la clave privada y anotaremos el ID de la solicitud.

Con Administrar CA y Administrar certificados, podemos emitir la solicitud de certificado fallida con el comando ca y el parámetro -issue-request.

Y finalmente, podemos recuperar el certificado emitido con el comando req y el parámetro -retrieve . Obtenemos el certificado del Administrator.


ESC8

Certipy relay

Realizar la Autenticación Coercion (desde otra terminal)

Esto nos dará el certificado y la clave privada del usuario.

Solicitar un TGT como máquina de equipo (o Domain Controller)

Esto nos dará el hash NTLM del usuario, que podemos usar para autenticarnos.

Dependiendo de la situación, ahora tenemos 2 ataques posibles...

DCSync (si disponemos de permisos de Administradores del dominio)

Realizando DCSync Attack utilizando el hash NTLM como Domain Controller.

Silver Ticket (utilizando el hash NTLM de una cuenta de equipo)

Creación del Silver Ticket

Realizando PassTheTicket con PsExec


ESC9

Requisitos:

  • GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B.

En este caso 'hacker' dispone de los privilegios sobre 'victim'. El usuario 'victim' tiene permisos para realizar el ESC9.

Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.

Utilizamos Certipy para actualizar el UPN de la cuenta 'victim', asignándole el valor de Administrator. Esto nos permite asociar cualquier certificado emitido a 'victim' con la identidad de Administrator:

Solicitamos un certificado utilizando la plantilla vulnerable. Este certificado se emitió con el UPN de Administrator, habilitando su uso para autenticación con privilegios elevados.

Posteriormente, restauramos el UPN de 'victim' a su valor original para minimizar evidencias de la modificación realizada.

Seguidamente utilizamos el certificado emitido para autenticarnos y verificamos que obtenemos el hash NTLM del usuario "Administrator".


ESC10

Caso 1

Requisitos:

  • GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B.

En este caso 'hacker' dispone de los privilegios sobre 'victim'. El usuario 'victim' tiene permisos para realizar el ESC10.

Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.

Modificar el UPN del usuario 'victim' al usuario Administrator.

Solicitud del certificado.

Revertiremos los cambios del usuario 'victim' (para asegurarse de que solo el administrador coincida con el certificado)

Autenticarse como usuario Administrator.

Caso 2

Requisitos:

  • GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B sin que disponga un userPrincipalName (cuentas de máquina y administrador de dominio integrado Administrador.

En este caso 'hacker' dispone de los privilegios sobre 'victim' y deseamos comprometer el Domain Controller DC$@domain.htb.

Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.

Modificamos el UPN del usuario 'victim' a 'DC$@dominio.htb'.

Solicitamos un certificado como 'victim' para obtener el certificado del Domain Controller (DC).

Revertir los cambios de 'victim' (para asegurarse de que solo el administrador coincida con el certificado).

Autenticación con el certificado del DC.

Creación de una nueva cuenta de equipo.

Abusar de RBCD (Resource Based Constrained Delegation) para impersonar al Administrator.

Autenticarse utilizando el TGT del usuario Administrator.


ESC11

Configuramos el relay

Autenticación Coerce con PetitPotam

Certipy recibe autenticación del DC de AD

A continuación, se deberá realizarlos pasos del ESC8


ESC12


ESC13

Desde sistemas tipo UNIX, esta solicitud de extracción en Certipy (Python) permite identificar una plantilla de certificado con una política de emisión, es decir, con la propiedad msPKI-Certificate-Policy no vacía. Además, verifica si esta política de emisión tiene un enlace de grupo OID a un grupo en la propiedad msDS-OIDToGroupLink.

Si se encuentra una plantilla vulnerable, no hay ningún requisito de emisión particular, el principal puede inscribirse y la plantilla indica el EKU de autenticación del cliente; solicite un certificado para esta plantilla con Certipy (Python) como de costumbre:

Luego, el certificado se puede usar con Pass-the-Certificate para obtener un TGT y autenticarse como el principal controlado, pero con sus privilegios agregados a los del grupo vinculado.


ESC14

Scenario A: Write altSecurityIdentities on Target

Comprobar que con el usuario (userA) tengamos permisos de escritura en el atributo altSecurityIdentities en el usuario TARGET (userB).

Crearemos un nuevo Domain Computer.

Autenticamos con el Domain Computer recién creado para obtener su PFX.

Obtener el .crt del certificado PFX del Domain Computer recién creado.

Script para obtener el X509 a travésdel issuer y el serial.

Resultado obtenido al ejecutar el script.

Modificamos el atributo altSecurityIdentities del userB a través del userA ya que disponemos de permisos y le asignamos el valor X509 anteriormente obtenido.

Una vez modificado, nos autenticamos con el PFX del Domain Computer creado impersonando al userB, obtenemos su hash NTLM y su TGT (.ccache).


ESC15


ESC16

Output:

Scenario A: UPN Manipulation (Requires StrongCertificateBindingEnforcement = 1 (Compatibility) or 0 (Disabled) on DCs, and attacker has write access to a "victim" account's UPN)

# Step 1: Read initial UPN of the victim account (Optional - for restoration).

Step 2: Update the victim account's UPN to the target administrator's sAMAccountName.

Step 3: (If needed) Obtain credentials for the "victim" account (e.g., via Shadow Credentials).

En caso de disponer de las credenciales de victim, pasar directamente al paso 4.

Step 4: Request a certificate as the "victim" user from any suitable client authentication template (e.g., "User") on the ESC16-vulnerable CA.

En caso de haber realizado el Shadow Credentials (Step 3) realizar los siguientes pasos.

En caso de disponer de las credenciales de victim y no haber realizado el Step 3, realizar lo siguiente:

Step 5: Revert the "victim" account's UPN.

Step 6: Authenticate as the target administrator.


References

Última actualización

¿Te fue útil?