Los ataques Kerberos, como Kerberoasting y ASREPRoasting, se pueden realizar en distintas confianzas, según la dirección de la confianza. En una situación en la que se encuentre en un dominio con una confianza de dominio/bosque entrante o bidireccional, es probable que pueda realizar varios ataques para ganar terreno. A veces, no puede escalar privilegios en su dominio actual, pero en su lugar puede obtener un ticket Kerberos y descifrar un hash para un usuario administrativo en otro dominio que tenga privilegios de administrador de dominio/empresa en ambos dominios.
Podemos utilizar PowerView para enumerar cuentas en un dominio de destino que tengan SPN asociados a ellas.
Enumeración de cuentas para SPN asociados mediante Get-DomainUser
Vemos que hay una cuenta con un SPN en el dominio de destino. Una comprobación rápida muestra que esta cuenta es miembro del grupo de administradores de dominio en el dominio de destino, por lo que si podemos usar Kerberoast y descifrar el hash sin conexión, tendríamos derechos de administrador completos en el dominio de destino.
Realicemos un ataque Kerberoasting en la confianza mediante Rubeus. Ejecutamos la herramienta como lo hicimos en la sección Kerberoasting, pero incluimos el indicador /domain: y especificamos el dominio de destino.
Kerberoasting con Rubeus usando el indicador /domain
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/202212: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 falla, ampliaremos rápidamente nuestro acceso para controlar por completo dos dominios aprovechando un ataque bastante estándar y abusando de la dirección de autenticación y la configuración de la confianza del bosque bidireccional.
Reutilización de contraseñas de administrador y membresía de grupos
De vez en cuando, nos encontraremos con una situación en la que existe una confianza de bosque bidireccional administrada por administradores de la misma empresa. Si podemos tomar el control del Dominio A y obtener contraseñas de texto sin formato o hashes NT para la cuenta de administrador incorporada (o una cuenta que sea parte del grupo Administradores de empresa o Administradores de dominio en el Dominio A), y el Dominio B tiene una cuenta con muchos privilegios con el mismo nombre, entonces vale la pena verificar la reutilización de contraseñas en los dos bosques. En ocasiones, me encontré con problemas en los que, por ejemplo, el Dominio A tenía un usuario llamado adm_bob.smith en el grupo Administradores de dominio y el Dominio B tenía un usuario llamado bsmith_admin. A veces, el usuario usaba la misma contraseña en los dos dominios y, al ser propietario del Dominio A, instantáneamente me otorgaba derechos de administrador completos para el Dominio B.
También podemos ver usuarios o administradores del Dominio A como miembros de un grupo en el Dominio B. Solo Domain Local Groups permiten entidades de seguridad de fuera de su bosque. Podemos ver un Administrador de dominio o Administrador de empresa del Dominio A como miembro del grupo de Administradores integrado en el Dominio B en una relación de confianza de bosque bidireccional. Si podemos tomar el control de este usuario administrador en el Dominio A, obtendremos acceso administrativo completo al Dominio B en función de la membresía del grupo.
Podemos utilizar la función Get-DomainForeignGroupMember de PowerView para enumerar grupos con usuarios que no pertenecen al dominio, también conocidos como foreign group membership. Probemos esto con el dominio FREIGHTLOGISTICS.LOCAL con el que tenemos una confianza de bosque bidireccional externa.
El resultado del comando anterior muestra que el grupo de administradores integrado FREIGHTLOGISTICS.LOCAL tiene como miembro la cuenta de administrador integrada del dominio INLANEFREIGHT.LOCAL. Podemos verificar este acceso mediante el cmdlet Enter-PSSession para conectarnos a través de WinRM.
Acceder a DC03 mediante 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> whoamiinlanefreight\administrator[ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL]: PS C:\Users\administrator.INLANEFREIGHT\Documents> ipconfig /allWindows 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
A partir del resultado del comando anterior, podemos ver que nos autenticamos correctamente en el controlador de dominio en el dominio FREIGHTLOGISTICS.LOCAL usando la cuenta de administrador del dominio INLANEFREIGHT.LOCAL a través de la confianza de bosque bidireccional. Esto puede ser una victoria rápida después de tomar el control de un dominio y siempre vale la pena verificar si existe una situación de confianza de bosque bidireccional durante una evaluación y si el segundo bosque está dentro del alcance.
Historial de abuso de SID - Cross Forest
El historial de SID también se puede utilizar de forma indebida en una confianza de bosque. Si se migra un usuario de un bosque a otro y no está habilitado el filtrado de SID, es posible agregar un SID del otro bosque, y este SID se agregará al token del usuario cuando se autentique en la confianza. Si el SID de una cuenta con privilegios administrativos en el bosque A se agrega al atributo de historial de SID de una cuenta en el bosque B, suponiendo que se pueda autenticar en todo el bosque, entonces esta cuenta tendrá privilegios administrativos al acceder a los recursos en el bosque asociado.
En el diagrama a continuación, podemos ver un ejemplo del usuario jjones que se migra del dominio INLANEFREIGHT.LOCAL al dominio CORP.LOCAL en un bosque diferente. Si el filtrado de SID 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 recursos compartidos, etc.) en el dominio INLANEFREIGHT.LOCAL, entonces conservará sus derechos administrativos/acceso mientras INLANEFREIGHT.LOCAL sea miembro del nuevo dominio, CORP.LOCAL en el segundo bosque.
Este ataque se tratará en profundidad en un módulo posterior que se centrará más en atacar las confianzas de AD.
Caso práctico
RDP a 10.129.80.246 (ACADEMY-EA-MS01)
user "htb-student"
password "Academy_student_AD!"
Realiza un ataque Kerberoasting entre bosques y obtén el TGS del usuario mssqlsvc. Descifre el ticket y envíe la contraseña en texto claro de la cuenta como respuesta.
Enumeración de cuentas para SPN asociados mediante Get-DomainUser
