AD CS Domain Escalation
Este es un resumen de las secciones de técnicas de escalación de las publicaciones:
Plantillas de Certificado Mal Configuradas - ESC1
Explicación
Plantillas de Certificado Mal Configuradas - ESC1 Explicadas
Los derechos de inscripción son otorgados a usuarios de bajo privilegio por la CA Empresarial.
No se requiere aprobación del gerente.
No se necesitan firmas de personal autorizado.
Los descriptores de seguridad en las plantillas de certificado son excesivamente permisivos, permitiendo a los usuarios de bajo privilegio obtener derechos de inscripción.
Las plantillas de certificado están configuradas para definir EKUs que facilitan la autenticación:
Se incluyen identificadores de Uso Extendido de Clave (EKU) como Autenticación de Cliente (OID 1.3.6.1.5.5.7.3.2), Autenticación de Cliente PKINIT (1.3.6.1.5.2.3.4), Inicio de Sesión con Tarjeta Inteligente (OID 1.3.6.1.4.1.311.20.2.2), Cualquier Propósito (OID 2.5.29.37.0), o sin EKU (SubCA).
La capacidad para que los solicitantes incluyan un subjectAltName en la Solicitud de Firma de Certificado (CSR) es permitida por la plantilla:
Active Directory (AD) prioriza el subjectAltName (SAN) en un certificado para la verificación de identidad si está presente. Esto significa que al especificar el SAN en un CSR, se puede solicitar un certificado para suplantar a cualquier usuario (por ejemplo, un administrador de dominio). Si un SAN puede ser especificado por el solicitante se indica en el objeto AD de la plantilla de certificado a través de la propiedad
mspki-certificate-name-flag. Esta propiedad es una máscara de bits, y la presencia de la banderaCT_FLAG_ENROLLEE_SUPPLIES_SUBJECTpermite la especificación del SAN por el solicitante.
La configuración descrita permite a los usuarios de bajo privilegio solicitar certificados con cualquier SAN de su elección, habilitando la autenticación como cualquier principal de dominio a través de Kerberos o SChannel.
Esta función a veces se habilita para soportar la generación en tiempo real de certificados HTTPS o de host por productos o servicios de implementación, o debido a una falta de comprensión.
Se observa que crear un certificado con esta opción genera una advertencia, lo cual no ocurre cuando se duplica una plantilla de certificado existente (como la plantilla WebServer, que tiene habilitado CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) y luego se modifica para incluir un OID de autenticación.
Abuso
Para encontrar plantillas de certificado vulnerables puedes ejecutar:
Para abusar de esta vulnerabilidad para hacerse pasar por un administrador se podría ejecutar:
Luego puedes transformar el certificado generado a formato .pfx y usarlo para autenticarte usando Rubeus o certipy nuevamente:
Los binarios de Windows "Certreq.exe" y "Certutil.exe" se pueden utilizar para generar el PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
La enumeración de plantillas de certificados dentro del esquema de configuración del bosque de AD, específicamente aquellas que no requieren aprobación o firmas, que poseen un EKU de Autenticación de Cliente o Inicio de Sesión con Tarjeta Inteligente, y con la bandera CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT habilitada, se puede realizar ejecutando la siguiente consulta LDAP:
Plantillas de Certificado Mal Configuradas - ESC2
Explicación
El segundo escenario de abuso es una variación del primero:
Se otorgan derechos de inscripción a usuarios de bajo privilegio por la CA Empresarial.
Se desactiva el requisito de aprobación del gerente.
Se omite la necesidad de firmas autorizadas.
Un descriptor de seguridad excesivamente permisivo en la plantilla de certificado otorga derechos de inscripción de certificados a usuarios de bajo privilegio.
La plantilla de certificado está definida para incluir el EKU de Cualquier Propósito o ningún EKU.
El EKU de Cualquier Propósito permite que un atacante obtenga un certificado para cualquier propósito, incluyendo autenticación de cliente, autenticación de servidor, firma de código, etc. La misma técnica utilizada para ESC3 se puede emplear para explotar este escenario.
Los certificados con sin EKUs, que actúan como certificados de CA subordinada, pueden ser explotados para cualquier propósito y también pueden ser utilizados para firmar nuevos certificados. Por lo tanto, un atacante podría especificar EKUs o campos arbitrarios en los nuevos certificados utilizando un certificado de CA subordinada.
Sin embargo, los nuevos certificados creados para autenticación de dominio no funcionarán si la CA subordinada no es confiable por el objeto NTAuthCertificates, que es la configuración predeterminada. No obstante, un atacante aún puede crear nuevos certificados con cualquier EKU y valores de certificado arbitrarios. Estos podrían ser potencialmente abusados para una amplia gama de propósitos (por ejemplo, firma de código, autenticación de servidor, etc.) y podrían tener implicaciones significativas para otras aplicaciones en la red como SAML, AD FS o IPSec.
Para enumerar las plantillas que coinciden con este escenario dentro del esquema de configuración del Bosque AD, se puede ejecutar la siguiente consulta LDAP:
Plantillas de Agente de Inscripción Mal Configuradas - ESC3
Explicación
Este escenario es como el primero y el segundo, pero abusando de un EKU diferente (Agente de Solicitud de Certificado) y 2 plantillas diferentes (por lo tanto, tiene 2 conjuntos de requisitos),
El EKU de Agente de Solicitud de Certificado (OID 1.3.6.1.4.1.311.20.2.1), conocido como Agente de Inscripción en la documentación de Microsoft, permite a un principal inscribirse para un certificado en nombre de otro usuario.
El “agente de inscripción” se inscribe en tal plantilla y utiliza el certificado resultante para co-firmar un CSR en nombre del otro usuario. Luego envía el CSR co-firmado a la CA, inscribiéndose en una plantilla que permite “inscribirse en nombre de”, y la CA responde con un certificado que pertenece al “otro” usuario.
Requisitos 1:
Se otorgan derechos de inscripción a usuarios de bajo privilegio por la CA Empresarial.
Se omite el requisito de aprobación del gerente.
No hay requisito de firmas autorizadas.
El descriptor de seguridad de la plantilla de certificado es excesivamente permisivo, otorgando derechos de inscripción a usuarios de bajo privilegio.
La plantilla de certificado incluye el EKU de Agente de Solicitud de Certificado, permitiendo la solicitud de otras plantillas de certificado en nombre de otros principales.
Requisitos 2:
La CA Empresarial otorga derechos de inscripción a usuarios de bajo privilegio.
Se omite la aprobación del gerente.
La versión del esquema de la plantilla es 1 o excede 2, y especifica un Requisito de Emisión de Política de Aplicación que requiere el EKU de Agente de Solicitud de Certificado.
Un EKU definido en la plantilla de certificado permite la autenticación de dominio.
No se aplican restricciones para agentes de inscripción en la CA.
Abuso
Puedes usar Certify o Certipy para abusar de este escenario:
Los usuarios que están autorizados a obtener un certificado de agente de inscripción, las plantillas en las que se permite a los agentes de inscripción inscribirse, y las cuentas en nombre de las cuales el agente de inscripción puede actuar pueden ser restringidos por las CA empresariales. Esto se logra abriendo el certsrc.msc complemento, haciendo clic derecho en la CA, haciendo clic en Propiedades, y luego navegando a la pestaña “Agentes de Inscripción”.
Sin embargo, se observa que la configuración predeterminada para las CA es “No restringir agentes de inscripción.” Cuando la restricción sobre los agentes de inscripción es habilitada por los administradores, configurarla en “Restringir agentes de inscripción,” la configuración predeterminada sigue siendo extremadamente permisiva. Permite el acceso a Todos para inscribirse en todas las plantillas como cualquier persona.
Control de Acceso a Plantillas de Certificado Vulnerables - ESC4
Explicación
El descriptor de seguridad en las plantillas de certificado define los permisos específicos que los principales de AD poseen con respecto a la plantilla.
Si un atacante posee los permisos requeridos para alterar una plantilla e instituir cualquier mala configuración explotable descrita en secciones anteriores, se podría facilitar la escalada de privilegios.
Los permisos notables aplicables a las plantillas de certificado incluyen:
Propietario: Otorga control implícito sobre el objeto, permitiendo la modificación de cualquier atributo.
ControlTotal: Habilita autoridad completa sobre el objeto, incluida la capacidad de alterar cualquier atributo.
EscribirPropietario: Permite la alteración del propietario del objeto a un principal bajo el control del atacante.
EscribirDacl: Permite el ajuste de controles de acceso, potencialmente otorgando a un atacante ControlTotal.
EscribirPropiedad: Autoriza la edición de cualquier propiedad del objeto.
Abuso
Un ejemplo de un privesc como el anterior:
ESC4 es cuando un usuario tiene privilegios de escritura sobre una plantilla de certificado. Esto puede, por ejemplo, ser abusado para sobrescribir la configuración de la plantilla de certificado para hacer que la plantilla sea vulnerable a ESC1.
Como podemos ver en la ruta anterior, solo JOHNPC tiene estos privilegios, pero nuestro usuario JOHN tiene el nuevo borde AddKeyCredentialLink hacia JOHNPC. Dado que esta técnica está relacionada con certificados, también he implementado este ataque, que se conoce como Credenciales Sombra. Aquí hay un pequeño adelanto del comando shadow auto de Certipy para recuperar el hash NT de la víctima.
Certipy puede sobrescribir la configuración de una plantilla de certificado con un solo comando. Por defecto, Certipy sobrescribirá la configuración para hacerla vulnerable a ESC1. También podemos especificar el -save-old parámetro para guardar la configuración antigua, lo que será útil para restaurar la configuración después de nuestro ataque.
Vulnerable PKI Object Access Control - ESC5
Explanation
La extensa red de relaciones interconectadas basadas en ACL, que incluye varios objetos más allá de las plantillas de certificados y la autoridad de certificación, puede afectar la seguridad de todo el sistema AD CS. Estos objetos, que pueden afectar significativamente la seguridad, abarcan:
El objeto de computadora AD del servidor CA, que puede ser comprometido a través de mecanismos como S4U2Self o S4U2Proxy.
El servidor RPC/DCOM del servidor CA.
Cualquier objeto o contenedor AD descendiente dentro de la ruta de contenedor específica
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Esta ruta incluye, pero no se limita a, contenedores y objetos como el contenedor de Plantillas de Certificados, el contenedor de Autoridades de Certificación, el objeto NTAuthCertificates y el Contenedor de Servicios de Inscripción.
La seguridad del sistema PKI puede verse comprometida si un atacante de bajo privilegio logra tomar el control de cualquiera de estos componentes críticos.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Explanation
El tema discutido en el post de CQure Academy también toca las implicaciones de la bandera EDITF_ATTRIBUTESUBJECTALTNAME2, como lo describe Microsoft. Esta configuración, cuando se activa en una Autoridad de Certificación (CA), permite la inclusión de valores definidos por el usuario en el nombre alternativo del sujeto para cualquier solicitud, incluidas las construidas a partir de Active Directory®. En consecuencia, esta disposición permite a un intruso inscribirse a través de cualquier plantilla configurada para la autenticación de dominio—específicamente aquellas abiertas a la inscripción de usuarios no privilegiados, como la plantilla de Usuario estándar. Como resultado, se puede asegurar un certificado, lo que permite al intruso autenticarse como un administrador de dominio o cualquier otra entidad activa dentro del dominio.
Note: El enfoque para agregar nombres alternativos en una Solicitud de Firma de Certificado (CSR), a través del argumento -attrib "SAN:" en certreq.exe (denominado “Pares de Nombre y Valor”), presenta un contraste con la estrategia de explotación de SANs en ESC1. Aquí, la distinción radica en cómo se encapsula la información de la cuenta—dentro de un atributo de certificado, en lugar de una extensión.
Abuse
Para verificar si la configuración está activada, las organizaciones pueden utilizar el siguiente comando con certutil.exe:
Esta operación emplea esencialmente acceso remoto al registro, por lo tanto, un enfoque alternativo podría ser:
Herramientas como Certify y Certipy son capaces de detectar esta mala configuración y explotarla:
Para alterar estas configuraciones, asumiendo que se posee derechos administrativos de dominio o equivalentes, se puede ejecutar el siguiente comando desde cualquier estación de trabajo:
Para deshabilitar esta configuración en su entorno, se puede eliminar la bandera con:
Después de las actualizaciones de seguridad de mayo de 2022, los certificados emitidos recientemente contendrán una extensión de seguridad que incorpora la propiedad objectSid del solicitante. Para ESC1, este SID se deriva del SAN especificado. Sin embargo, para ESC6, el SID refleja el objectSid del solicitante, no el SAN.
Para explotar ESC6, es esencial que el sistema sea susceptible a ESC10 (Mapeos de Certificados Débiles), que prioriza el SAN sobre la nueva extensión de seguridad.
Control de Acceso de Autoridad de Certificación Vulnerable - ESC7
Ataque 1
Explicación
El control de acceso para una autoridad de certificación se mantiene a través de un conjunto de permisos que rigen las acciones de la CA. Estos permisos se pueden ver accediendo a certsrv.msc, haciendo clic derecho en una CA, seleccionando propiedades y luego navegando a la pestaña de Seguridad. Además, los permisos se pueden enumerar utilizando el módulo PSPKI con comandos como:
Esto proporciona información sobre los derechos principales, a saber, ManageCA y ManageCertificates, que se correlacionan con los roles de “administrador de CA” y “gerente de certificados” respectivamente.
Abuso
Tener derechos de ManageCA en una autoridad de certificación permite al principal manipular configuraciones de forma remota utilizando PSPKI. Esto incluye activar el flag EDITF_ATTRIBUTESUBJECTALTNAME2 para permitir la especificación de SAN en cualquier plantilla, un aspecto crítico de la escalación de dominio.
La simplificación de este proceso se puede lograr mediante el uso del cmdlet Enable-PolicyModuleFlag de PSPKI, que permite modificaciones sin interacción directa con la GUI.
La posesión de derechos de ManageCertificates facilita la aprobación de solicitudes pendientes, eludiendo efectivamente la salvaguarda de "aprobación del gerente de certificados de CA".
Se puede utilizar una combinación de los módulos Certify y PSPKI para solicitar, aprobar y descargar un certificado:
Ataque 2
Explicación
En el ataque anterior, se utilizaron los permisos Manage CA para habilitar el flag EDITF_ATTRIBUTESUBJECTALTNAME2 para realizar el ataque ESC6, pero esto no tendrá ningún efecto hasta que el servicio CA (CertSvc) sea reiniciado. Cuando un usuario tiene el derecho de acceso Manage CA, también se le permite reiniciar el servicio. Sin embargo, no significa que el usuario pueda reiniciar el servicio de forma remota. Además, ESC6 puede no funcionar de inmediato en la mayoría de los entornos parcheados debido a las actualizaciones de seguridad de mayo de 2022.
Por lo tanto, aquí se presenta otro ataque.
Requisitos previos:
Solo permiso
ManageCAPermiso
Manage Certificates(puede ser otorgado desdeManageCA)La plantilla de certificado
SubCAdebe estar habilitada (puede ser habilitada desdeManageCA)
La técnica se basa en el hecho de que los usuarios con el derecho de acceso Manage CA y Manage Certificates pueden emitir solicitudes de certificado fallidas. La plantilla de certificado SubCA es vulnerable a ESC1, pero solo los administradores pueden inscribirse en la plantilla. Así, un usuario puede solicitar inscribirse en la SubCA - lo cual será denegado - pero luego emitido por el gerente posteriormente.
Abuso
Puedes otorgarte a ti mismo el derecho de acceso Manage Certificates agregando tu usuario como un nuevo oficial.
El SubCA template se puede habilitar en la CA con el parámetro -enable-template. Por defecto, el template SubCA está habilitado.
Si hemos cumplido con los requisitos previos para este ataque, podemos comenzar solicitando un certificado basado en la plantilla SubCA.
Esta solicitud será denegada, pero guardaremos la clave privada y anotaremos el ID de la solicitud.
Con nuestro Manage CA y Manage Certificates, podemos emitir la solicitud de certificado fallida con el comando ca y el parámetro -issue-request <request ID>.
Y finalmente, podemos recuperar el certificado emitido con el comando req y el parámetro -retrieve <request ID>.
NTLM Relay to AD CS HTTP Endpoints – ESC8
Explicación
En entornos donde AD CS está instalado, si existe un punto de inscripción web vulnerable y al menos una plantilla de certificado está publicada que permite inscripción de computadoras de dominio y autenticación de clientes (como la plantilla Machine por defecto), ¡se vuelve posible que cualquier computadora con el servicio de spooler activo sea comprometida por un atacante!
Varios métodos de inscripción basados en HTTP son compatibles con AD CS, disponibles a través de roles de servidor adicionales que los administradores pueden instalar. Estas interfaces para la inscripción de certificados basada en HTTP son susceptibles a ataques de retransmisión NTLM. Un atacante, desde una máquina comprometida, puede suplantar cualquier cuenta de AD que se autentique a través de NTLM entrante. Al suplantar la cuenta de la víctima, estas interfaces web pueden ser accedidas por un atacante para solicitar un certificado de autenticación de cliente utilizando las plantillas de certificado User o Machine.
La interfaz de inscripción web (una aplicación ASP más antigua disponible en
http://<caserver>/certsrv/), por defecto solo admite HTTP, lo que no ofrece protección contra ataques de retransmisión NTLM. Además, permite explícitamente solo la autenticación NTLM a través de su encabezado HTTP de Autorización, haciendo que métodos de autenticación más seguros como Kerberos sean inaplicables.El Servicio de Inscripción de Certificados (CES), el Servicio Web de Política de Inscripción de Certificados (CEP) y el Servicio de Inscripción de Dispositivos de Red (NDES) por defecto admiten autenticación negociada a través de su encabezado HTTP de Autorización. La autenticación negociada admite tanto Kerberos como NTLM, permitiendo a un atacante reducir a NTLM la autenticación durante los ataques de retransmisión. Aunque estos servicios web habilitan HTTPS por defecto, HTTPS por sí solo no protege contra ataques de retransmisión NTLM. La protección contra ataques de retransmisión NTLM para servicios HTTPS solo es posible cuando HTTPS se combina con enlace de canal. Lamentablemente, AD CS no activa la Protección Extendida para la Autenticación en IIS, que es necesaria para el enlace de canal.
Un problema común con los ataques de retransmisión NTLM es la corta duración de las sesiones NTLM y la incapacidad del atacante para interactuar con servicios que requieren firma NTLM.
Sin embargo, esta limitación se supera al explotar un ataque de retransmisión NTLM para adquirir un certificado para el usuario, ya que el período de validez del certificado dicta la duración de la sesión, y el certificado puede ser utilizado con servicios que exigen firma NTLM. Para instrucciones sobre cómo utilizar un certificado robado, consulte:
AD CS Account PersistenceOtra limitación de los ataques de retransmisión NTLM es que una máquina controlada por el atacante debe ser autenticada por una cuenta víctima. El atacante podría esperar o intentar forzar esta autenticación:
Force NTLM Privileged AuthenticationAbuso
Certify’s cas enumera puntos de AD CS HTTP habilitados:
La propiedad msPKI-Enrollment-Servers es utilizada por las Autoridades de Certificación (CAs) empresariales para almacenar los puntos finales del Servicio de Inscripción de Certificados (CES). Estos puntos finales pueden ser analizados y listados utilizando la herramienta Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Abuso con Certify
Abuso con Certipy
La solicitud de un certificado es realizada por Certipy por defecto basada en la plantilla Machine o User, determinada por si el nombre de la cuenta que se está retransmitiendo termina en $. La especificación de una plantilla alternativa se puede lograr mediante el uso del parámetro -template.
Se puede emplear una técnica como PetitPotam para forzar la autenticación. Al tratar con controladores de dominio, se requiere la especificación de -template DomainController.
No Security Extension - ESC9
Explicación
El nuevo valor CT_FLAG_NO_SECURITY_EXTENSION (0x80000) para msPKI-Enrollment-Flag, conocido como ESC9, impide la inclusión de la nueva extensión de seguridad szOID_NTDS_CA_SECURITY_EXT en un certificado. Esta bandera se vuelve relevante cuando StrongCertificateBindingEnforcement está configurado en 1 (la configuración predeterminada), lo que contrasta con una configuración de 2. Su relevancia aumenta en escenarios donde un mapeo de certificado más débil para Kerberos o Schannel podría ser explotado (como en ESC10), dado que la ausencia de ESC9 no alteraría los requisitos.
Las condiciones bajo las cuales la configuración de esta bandera se vuelve significativa incluyen:
StrongCertificateBindingEnforcementno se ajusta a2(siendo la predeterminada1), oCertificateMappingMethodsincluye la banderaUPN.El certificado está marcado con la bandera
CT_FLAG_NO_SECURITY_EXTENSIONdentro de la configuración demsPKI-Enrollment-Flag.Cualquier EKU de autenticación de cliente está especificado por el certificado.
Los permisos de
GenericWriteestán disponibles sobre cualquier cuenta para comprometer a otra.
Escenario de Abuso
Supongamos que John@corp.local tiene permisos de GenericWrite sobre Jane@corp.local, con el objetivo de comprometer Administrator@corp.local. La plantilla de certificado ESC9, en la que Jane@corp.local tiene permiso para inscribirse, está configurada con la bandera CT_FLAG_NO_SECURITY_EXTENSION en su configuración de msPKI-Enrollment-Flag.
Inicialmente, el hash de Jane se adquiere utilizando Credenciales en Sombra, gracias a GenericWrite de John:
Subsequentemente, el userPrincipalName de Jane se modifica a Administrator, omitiendo intencionadamente la parte del dominio @corp.local:
Esta modificación no viola las restricciones, dado que Administrator@corp.local sigue siendo distinto como el userPrincipalName de Administrator.
A continuación, se solicita la plantilla de certificado ESC9, marcada como vulnerable, como Jane:
Se observa que el userPrincipalName del certificado refleja Administrator, desprovisto de cualquier “object SID”.
El userPrincipalName de Jane se revierte a su original, Jane@corp.local:
Intentar la autenticación con el certificado emitido ahora produce el hash NT de Administrator@corp.local. El comando debe incluir -domain <domain> debido a la falta de especificación de dominio del certificado:
Weak Certificate Mappings - ESC10
Explanation
Dos valores de clave de registro en el controlador de dominio se refieren a ESC10:
El valor predeterminado para
CertificateMappingMethodsbajoHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schanneles0x18(0x8 | 0x10), previamente configurado como0x1F.La configuración predeterminada para
StrongCertificateBindingEnforcementbajoHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdces1, previamente0.
Case 1
Cuando StrongCertificateBindingEnforcement está configurado como 0.
Case 2
Si CertificateMappingMethods incluye el bit UPN (0x4).
Abuse Case 1
Con StrongCertificateBindingEnforcement configurado como 0, una cuenta A con permisos de GenericWrite puede ser explotada para comprometer cualquier cuenta B.
Por ejemplo, teniendo permisos de GenericWrite sobre Jane@corp.local, un atacante busca comprometer Administrator@corp.local. El procedimiento refleja ESC9, permitiendo que se utilice cualquier plantilla de certificado.
Inicialmente, el hash de Jane se recupera utilizando Shadow Credentials, explotando el GenericWrite.
Subsequently, Jane's userPrincipalName is altered to Administrator, deliberately omitting the @corp.local portion to avoid a constraint violation.
A continuación, se solicita un certificado que habilite la autenticación del cliente como Jane, utilizando la plantilla User predeterminada.
Jane's userPrincipalName es luego revertido a su original, Jane@corp.local.
Autenticarse con el certificado obtenido generará el hash NT de Administrator@corp.local, lo que requiere la especificación del dominio en el comando debido a la ausencia de detalles del dominio en el certificado.
Caso de abuso 2
Con el CertificateMappingMethods que contiene el bit flag UPN (0x4), una cuenta A con permisos de GenericWrite puede comprometer cualquier cuenta B que carezca de la propiedad userPrincipalName, incluidas las cuentas de máquina y el administrador de dominio incorporado Administrator.
Aquí, el objetivo es comprometer DC$@corp.local, comenzando por obtener el hash de Jane a través de Shadow Credentials, aprovechando el GenericWrite.
El userPrincipalName de Jane se establece en DC$@corp.local.
Se solicita un certificado para la autenticación del cliente como Jane utilizando la plantilla User predeterminada.
El userPrincipalName de Jane se revierte a su original después de este proceso.
Para autenticar a través de Schannel, se utiliza la opción -ldap-shell de Certipy, indicando el éxito de la autenticación como u:CORP\DC$.
A través de la shell LDAP, comandos como set_rbcd habilitan ataques de Delegación Constrainida Basada en Recursos (RBCD), comprometiendo potencialmente el controlador de dominio.
Esta vulnerabilidad también se extiende a cualquier cuenta de usuario que carezca de un userPrincipalName o donde no coincida con el sAMAccountName, siendo el Administrator@corp.local un objetivo principal debido a sus privilegios LDAP elevados y la ausencia de un userPrincipalName por defecto.
Relaying NTLM to ICPR - ESC11
Explicación
Si el servidor CA no está configurado con IF_ENFORCEENCRYPTICERTREQUEST, puede realizar ataques de relé NTLM sin firmar a través del servicio RPC. Referencia aquí.
Puedes usar certipy para enumerar si Enforce Encryption for Requests está deshabilitado y certipy mostrará las vulnerabilidades ESC11.
Escenario de Abuso
Es necesario configurar un servidor de retransmisión:
Nota: Para los controladores de dominio, debemos especificar -template en DomainController.
O usando el fork de impacket de sploutchy:
Shell access to ADCS CA with YubiHSM - ESC12
Explicación
Los administradores pueden configurar la Autoridad de Certificación para almacenarla en un dispositivo externo como el "Yubico YubiHSM2".
Si un dispositivo USB está conectado al servidor CA a través de un puerto USB, o un servidor de dispositivos USB en caso de que el servidor CA sea una máquina virtual, se requiere una clave de autenticación (a veces denominada "contraseña") para que el Proveedor de Almacenamiento de Claves genere y utilice claves en el YubiHSM.
Esta clave/contraseña se almacena en el registro bajo HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword en texto claro.
Referencia en aquí.
Escenario de abuso
Si la clave privada de la CA está almacenada en un dispositivo USB físico cuando obtuviste acceso a la shell, es posible recuperar la clave.
Primero, necesitas obtener el certificado de la CA (esto es público) y luego: