Tarde o temprano, durante el período de pentest, surge la tarea de comprometer todo el bosque, siempre que exista algún derecho en uno de los dominios. En esos momentos, surgen muchas preguntas sobre los fideicomisos, sus propiedades y los ataques en sí. Intentemos resolverlo todo.
La confianza entre dominios se utiliza para autenticar a los usuarios de un dominio en el controlador de otro dominio. En otras palabras, para que los usuarios del dominio A puedan tener acceso a los recursos del dominio B. La estructura del dominio puede ser de dos tipos:
- Árboles de dominio
- bosques de dominio.
Al crear un árbol de dominios entre dominios, por defecto se establecen confianzas transitivas. Todas las computadoras tienen en común:
- catálogo global
- espacio de nombres
- esquema
Los árboles de dominio se pueden combinar en bosques. Al crear un bosque de dominio, se establecen confianzas transitivas y todas las computadoras en el bosque comparten lo siguiente:
La siguiente tabla muestra los tipos de confianza entre dominios y sus propiedades.
Más claramente, los tipos de fideicomisos entre dominios se ilustran en la imagen a continuación.
Transitividad
La transitividad es necesaria para definir la confianza fuera de los dos dominios entre los que se formó, y se utiliza para expandir las relaciones de confianza con otros dominios. Si agregamos un dominio secundario al dominio, se establece una relación de confianza bidireccional entre los dominios primario y secundario. Estas relaciones son transitivas, es decir si el dominio A confía en el dominio D y el dominio D confía en el dominio E, entonces el dominio A también confía en el dominio E.
La confianza no transitiva puede usarse para negar la confianza con otros dominios.
Dirección
Una ruta de relación de confianza es una serie de relaciones de confianza entre dominios en los que se deben recibir solicitudes de autenticación. En otras palabras, antes de autenticar a un usuario, se determina la confianza entre dominios. Para que los usuarios del dominio A accedan a los recursos del dominio D, el dominio D debe confiar en el dominio A.
La dirección de la confianza es de dos tipos:
La confianza unidireccional es una ruta de autenticación unidireccional que se crea entre dos dominios. En la confianza unidireccional entre el dominio A y el dominio B, los usuarios del dominio B tienen acceso a los recursos del dominio A. Sin embargo, los usuarios del dominio A no tienen acceso a los recursos del dominio B. Este tipo de confianza no es transitiva.
La confianza bilateral es una combinación de dos relaciones de confianza unidireccionales. En la confianza bidireccional entre los dominios A y B, sus usuarios tienen acceso a los recursos de ambos dominios. Este tipo de confianza es transitiva.
La dirección de la confianza es siempre opuesta a la dirección de acceso. Diagrama representativo de Microsoft a continuación:
Enlaces para tipos de confianza más detallados:
Kerberos entre dominios de confianza
Considera un ejemplo. El cliente está intentando acceder al servidor.
Desde los puntos 1 a 3, las acciones estándar ocurren cuando se usa el protocolo Kerberos.- La contraseña se convierte en un hash NTLM, la marca de tiempo se cifra con un hash y se envía a KDC como un autenticador en la solicitud del ticket TGT (AS-REQ). El controlador de dominio (KDC) verifica la información del usuario y crea un ticket TGT.
- El ticket TGT se cifra, firma y envía al usuario (AS-REP). Solo el servicio Kerberos (KRBTGT) puede abrir y leer datos de un ticket TGT.
- Un usuario envía un ticket TGT a un controlador de dominio cuando solicita un ticket TGS (TGS-REQ). El controlador de dominio abre un ticket TGT y verifica la suma de control PAC.
Los cambios comienzan desde el punto 4: aparece un ticket TGT entre reinos, el llamado ticket de referencia, que está encriptado / firmado con una clave entre reinos creada a partir de una contraseña confiable. Se establece una contraseña confiable cuando se establece la confianza y ambos controladores de dominio la conocen. Usando el ticket TGT entre reinos, un usuario del dominio 1 puede solicitar un ticket TGS para acceder a los recursos del dominio 2.
NTLM entre dominios de confianza
- El cliente envía una solicitud de autenticación directamente al recurso en sí, ubicado en otro dominio, al que desea acceder.
- El servidor recibe una solicitud del cliente y le envía una respuesta CHALLENGE_MESSAGE, que contiene una secuencia aleatoria de 8 bytes. Se llama el desafío del servidor.
- El cliente, después de recibir la secuencia de Desafío del servidor del servidor, cifra esta secuencia con su contraseña y luego envía al servidor una respuesta que contiene 24 bytes.
- El servidor envía una solicitud y respuesta al controlador de su dominio B.
- En el caso de la autenticación entre confianzas, se realiza la siguiente lógica:
- Dirección comprobada Relaciones de confianza.
- Las credenciales del cliente se envían al dominio A para autenticarse.
- Si no hay una relación de confianza, entonces se verifica la transitividad con el dominio A.
- Verificación de transitividad entre dominios
- Si hay transitividad entre dominios, se envía una solicitud de autenticación al siguiente dominio en la ruta de confianza. Este controlador de dominio repite el proceso, verificando las credenciales del usuario contra su base de datos de cuentas de seguridad.
- Si no hay transitividad, se devuelve un mensaje de acceso denegado al cliente.
6-8. La respuesta con la decisión de autenticar al cliente.
Ataques entre fideicomisos entre dominios
Entonces, para llevar a cabo un ataque, necesitamos información sobre las relaciones de confianza en nuestro dominio.
Listado de fideicomisos
Existen 3 métodos principales para enumerar los fideicomisos en un dominio:
- a través de la API Win32;
- a través de métodos .NET;
- a través de LDAP.
API Win32
La enumeración se realiza llamando a la función DsEnumerateDomainTrusts , que devuelve la estructura DS_DOMAIN_TRUSTSA . Con este método, se devuelven el SID y el GUID del dominio de destino, las banderas y los atributos que caracterizan la confianza actual en el dominio.
BloodHound recopila información utilizando el método API Win32.
.Net
Se utiliza el método GetCurrentDomain del espacio de nombres [System.DirectoryServices.ActiveDirectory.Domain], que devuelve una instancia de la clase System.DirectoryServices.ActiveDirectory.Domain . Esta clase implementa el método GetAllTrustRelationships , que devuelve todas las confianzas para el dominio actual.
([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()
El uso de este método se implementa en el módulo Get-DomainTrust en PowerView.
Una de las ventajas de este método es su simplicidad. La información es fácil de leer y comprender, pero su volumen es mucho menor que cuando se hace la enumeración por otros métodos.
LDAP
La información de confianza del dominio se almacena en Active Directory como una clase de objeto de la clase TrustedDomain .
Ejemplo de uso:
dsquery * -filter "(objectClass=trustedDomain)" -attr *
PowerView usa este método por defecto.
Con información sobre dominios y tipos de confianza, puede ir directamente al ataque en sí. Considere 2 opciones:
- Logramos comprometer el dominio y tenemos derechos de administrador de dominio.
- No tenemos derechos de administrador de dominio.
Con derechos de administrador para uno de los dominios.
Dependiendo del dominio que se vio comprometido, se pueden distinguir varios vectores de ataque:
Vale la pena señalar que para la implementación exitosa de todos los vectores, es necesaria la confianza bilateral entre dominios.
1. Operación Historia SID
El historial SID se introdujo para facilitar la migración de usuarios de un dominio a otro. El atributo contiene los objetos SID anteriores. Cada vez que un objeto se mueve de un dominio a otro, se crea un nuevo SID, que se convierte en un objectSID. El SID anterior se agrega a la propiedad sIDHistory.
Cada bosque tiene un grupo de usuarios Administradores de empresa que existe solo en el dominio raíz y tiene derechos de administrador local en los controladores de dominio de todos los dominios secundarios del bosque. Este ataque fue demostrado por primera vez por Sean Metcalf en BlackHat USA 2015 . La esencia del ataque es que estamos emitiendo un boleto dorado con la adición de un SID adicional del grupo Administradores de empresa. Esto se realiza agregando ExtraSids en la estructura KERB_SID_AND_ATTRIBUTES , que se envía en la estructura KERB_VALIDATION_INFO .
Demo de ataque:
Impacket tiene un script que automatiza todo esto.
2. Golden Ticket + Enterprise Admin Group
Al tener derechos de administrador en el dominio raíz, podemos crear un Golden Ticket con la adición de un usuario al grupo Administradores de empresa (519).
Kerberos::golden /domain:<domain> /sid:<domain_SID> /krbtgt:<ntlm_hash_krbtgt_user> /user:<user> /groups:500,501,513,512,520,518,519 /ptt
Como se describió anteriormente, Enterprise Admin tiene derechos de administrador local para dominios secundarios DC. Por lo tanto, podremos comprometer todos los dominios secundarios en el bosque.
3. Operación de tickets de confianza
Para acceder a un recurso utilizando el protocolo Kerberos, necesita un ticket TGS, que está encriptado con el hash NTLM de la contraseña de la cuenta de servicio. Un controlador de dominio solo almacena hash de contraseñas de usuario para su dominio, por lo que cuando un usuario del dominio A necesita acceder a un recurso en el dominio B, se usa una clave entre reinos. Esta clave se crea sobre la base de una contraseña de confianza, que se establece al crear relaciones de confianza entre dominios en el mismo bosque. En la base de datos de contraseñas (NTDS.dit) en el controlador de dominio, puede encontrar usuarios con el signo $ al final. Su contraseña también se usa para crear claves entre reinos. Para crear un ticket TGT entre reinos, necesitamos un hash de contraseña de esta cuenta.
Kerberos::golden /user:<user> /domain:<domain> /sid:<sid_domain> /sids:<extra_sid_entrprice_admin_group_from _another_domain> /aes256:<aes256_trust_user_password> /service:krbtgt /target:<target_domain> /ptt
Demo de ataque:
El ataque es especialmente relevante cuando el servicio IS notó una amenaza y cambió la contraseña krbtgt 2 veces. En este caso, podremos crear tickets dorados usando una contraseña confiable entre dominios.
4. Error de impresora
El Protocolo remoto del sistema de impresión de Windows (MS-RPRN) tiene el método RpcRemoteFindFirstPrinterChangeNotification (Ex) habilitado de manera predeterminada, que le permite forzar la autenticación en cualquier computadora que ejecute el servicio Spooler en el host especificado utilizando el protocolo Kerberos o NTLM. En el caso de c NTLM, podemos ejecutar NTLM-relay, o comenzar a descifrar la contraseña de la computadora (nunca desmarcar). En el caso de Kerberos, se necesita una máquina comprometida con delegación ilimitada. Entonces podemos recoger un boleto de TGT y desarrollar un ataque.
Demo de ataque:
La siguiente figura muestra los pasos que se muestran en el video.
No tenemos derechos de administrador de dominio.
Un poco de teoría Carlos Garsia en su informe dio una excelente tabla que ilustra las propiedades de los diferentes tipos de grupos.
De las características, vale la pena considerar que los grupos AD Domain Local y AD Global se replican sin miembros del grupo en el catálogo global, y los grupos AD Universal se replican con los usuarios.
Debido a la forma en que el Catálogo global enumera los grupos, los resultados de un vínculo de retroceso [es decir, la búsqueda de memb pueden variar, dependiendo de si busca en el Catálogo global (puerto 3268) o el dominio (puerto 389), el tipo de grupos a los que pertenece el usuario (grupos globales versus grupos locales de dominio).
En el caso de que no tengamos derechos de administrador de dominio, enumeramos los objetos. Estamos interesados en:
- Usuarios de otro dominio que tienen derechos de administrador local en máquinas de nuestro dominio.
- Usuarios de otros dominios que son miembros de grupos de dominio de usuario. Grupos que contienen usuarios de otro dominio.
- Directores extranjeros de ACL.
1. Usuarios de otro dominio que tienen derechos de administrador local en máquinas de nuestro dominio
Busque usuarios de otro dominio que sean administradores locales en hosts en nuestro dominio en BloodHound:
MATCH (c:Computer) OPTIONAL MATCH p1 = (u1)-[:AdminTo]->(c) WHERE NOT u1.domain = c.domain WITH p1,c OPTIONAL MATCH p2 = (u2)-[:MemberOf*1..]->(:Group)-[:AdminTo]->(c) WHERE NOT u2.domain = c.domain RETURN p1,p2
Comando en PowerView :
Get-NetLocalGroupMember <server>
2. Usuarios de otros dominios, que consisten en grupos de dominio de usuario. Grupos que contienen usuarios de otro dominio
Como se mencionó anteriormente, los usuarios que son miembros de solo grupos universales se replican en el catálogo global. Para demostrar esta característica, consultaremos grupos en el catálogo global que contengan al menos un usuario y una solicitud ldap directa al controlador de dominio.
Get-DomainGroup -Properties name, grouptype, member, DistinguishedName -LDAPFilter '(member=*)' -SearchBase "GC://jet.lab"
Al ejecutar una consulta al catálogo global, solo vemos un grupo de Universal Group con el tipo AD Universal del dominio one.jet.lab.
Si ejecutamos una consulta LDAP directa a one.jet.lab, veremos otros grupos con el tipo AD Domain local y AD Global.
Es importante tener esto en cuenta al enumerar usuarios y grupos.
Comandos en PowerView :
Get-DomainForeignUser -Domain <Domain> Get-DomainForeignGroupMember -Domain <Domain>
3. Directores extranjeros de ACL
El descriptor de seguridad ntSecurityDescriptor (https://docs.microsoft.com/en-us/windows/win32/adschema/a-ntsecuritydescriptor) es accesible para todos los usuarios de dominios de confianza y se replica en el catálogo global. Por lo tanto, podemos consultar todos los DACL para todos los objetos en dominios de confianza y filtrar usuarios de otros dominios.
Get-DomainObjectAcl -Domain jet.lab -ResolveGuids | ?{$_.SecurityIdentifier -like 'SID_Domain*'}
Entonces, logramos identificar al usuario Mike del dominio forestc.lab, que tenía derechos para el Grupo Global en el dominio jet.lab.
El filtrado PS SID y la autenticación selectiva se utilizan para la protección entre bosques. Un ataque entre bosques con SID Filtering habilitó dirkjan en su blog . También el 9 de julio, Microsoft lanzó una actualización que deshabilita la delegación TGT entre bosques de forma predeterminada. Ahora todo, la historia con delegación ilimitada y compromiso de un bosque de otro usando el protocolo Kerberos ya no funciona.