AD CS Domain Persistence
Este es un resumen de las técnicas de persistencia de dominio compartidas en https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf. Consulta para más detalles.
Forjar Certificados con Certificados de Autoridad Robados - DPERSIST1
¿Cómo puedes saber si un certificado es un certificado de CA?
Se puede determinar que un certificado es un certificado de CA si se cumplen varias condiciones:
El certificado está almacenado en el servidor de CA, con su clave privada asegurada por el DPAPI de la máquina, o por hardware como un TPM/HSM si el sistema operativo lo admite.
Tanto los campos Emisor como Sujeto del certificado coinciden con el nombre distinguido de la CA.
Una extensión "Versión de CA" está presente exclusivamente en los certificados de CA.
El certificado carece de campos de Uso Extendido de Clave (EKU).
Para extraer la clave privada de este certificado, la herramienta certsrv.msc en el servidor de CA es el método compatible a través de la GUI integrada. No obstante, este certificado no difiere de otros almacenados en el sistema; por lo tanto, se pueden aplicar métodos como la técnica THEFT2 para la extracción.
El certificado y la clave privada también se pueden obtener utilizando Certipy con el siguiente comando:
Al adquirir el certificado de la CA y su clave privada en formato .pfx, se pueden utilizar herramientas como ForgeCert para generar certificados válidos:
El usuario objetivo de la falsificación de certificados debe estar activo y ser capaz de autenticarse en Active Directory para que el proceso tenga éxito. Falsificar un certificado para cuentas especiales como krbtgt es ineficaz.
Este certificado falsificado será válido hasta la fecha de finalización especificada y siempre que el certificado de la CA raíz sea válido (generalmente de 5 a 10+ años). También es válido para máquinas, por lo que combinado con S4U2Self, un atacante puede mantener persistencia en cualquier máquina del dominio siempre que el certificado de la CA sea válido. Además, los certificados generados con este método no pueden ser revocados ya que la CA no tiene conocimiento de ellos.
Confianza en Certificados de CA Falsos - DPERSIST2
El objeto NTAuthCertificates está definido para contener uno o más certificados de CA dentro de su atributo cacertificate, que utiliza Active Directory (AD). El proceso de verificación por el controlador de dominio implica verificar el objeto NTAuthCertificates en busca de una entrada que coincida con la CA especificada en el campo Emisor del certificado de autenticación. La autenticación procede si se encuentra una coincidencia.
Un atacante puede agregar un certificado de CA autofirmado al objeto NTAuthCertificates, siempre que tengan control sobre este objeto AD. Normalmente, solo los miembros del grupo Enterprise Admin, junto con Domain Admins o Administradores en el dominio raíz del bosque, tienen permiso para modificar este objeto. Pueden editar el objeto NTAuthCertificates utilizando certutil.exe con el comando certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA126, o mediante la Herramienta de Salud de PKI.
Esta capacidad es especialmente relevante cuando se utiliza en conjunto con un método previamente descrito que implica ForgeCert para generar certificados dinámicamente.
Configuración Maliciosa - DPERSIST3
Las oportunidades de persistencia a través de modificaciones de descriptores de seguridad de los componentes de AD CS son abundantes. Las modificaciones descritas en la sección "Escalada de Dominio" pueden ser implementadas maliciosamente por un atacante con acceso elevado. Esto incluye la adición de "derechos de control" (por ejemplo, WriteOwner/WriteDACL/etc.) a componentes sensibles como:
El objeto de computadora AD del servidor de CA
El servidor RPC/DCOM del servidor de CA
Cualquier objeto o contenedor AD descendiente en
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMINIO>,DC=<COM>(por ejemplo, el contenedor de Plantillas de Certificados, el contenedor de Autoridades de Certificación, el objeto NTAuthCertificates, etc.)Grupos de AD con derechos delegados para controlar AD CS de forma predeterminada o por la organización (como el grupo Cert Publishers integrado y cualquiera de sus miembros)
Un ejemplo de implementación maliciosa implicaría a un atacante, que tiene permisos elevados en el dominio, agregando el permiso WriteOwner a la plantilla de certificado User por defecto, siendo el atacante el principal para el derecho. Para explotar esto, el atacante primero cambiaría la propiedad de la plantilla User a ellos mismos. A continuación, se establecería el mspki-certificate-name-flag en 1 en la plantilla para habilitar ENROLLEE_SUPPLIES_SUBJECT, permitiendo a un usuario proporcionar un Nombre Alternativo del Sujeto en la solicitud. Posteriormente, el atacante podría inscribirse utilizando la plantilla, eligiendo un nombre de administrador de dominio como nombre alternativo, y utilizar el certificado adquirido para autenticarse como el AD.
Última actualización