> For the complete documentation index, see [llms.txt](https://g4b0.gitbook.io/g4b0-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://g4b0.gitbook.io/g4b0-docs/documentation/active-directory/attacking-domain-trusts-cross-forest-trust-abuse-from-linux.md). # Attacking Domain Trusts - Cross-Forest Trust Abuse - from Linux Misma metodologia que en windows pero con la direferencia en el uso de herraminetas de linux ### Cross-Forest Kerberoasting #### Usando GetUserSPNs.py Necesitamos las credenciales de un usuario que pueda autenticarse en el otro dominio y especificar el parámetro -target-domain en nuestro comando. Ejecutamos esta operación contra el dominio FREIGHTLOGISTICS.LOCAL ```bash GetUserSPNs.py -target-domain FREIGHTLOGISTICS.LOCAL INLANEFREIGHT.LOCAL/wley ``` Al ejecutar nuevamente el comando con la opción -request, obtenemos el ticket TGS. También podríamos agregar -outputfile para generar la salida directamente en un archivo que luego podríamos procesar con Hashcat. #### Usando flag -request y -outputfile ```bash GetUserSPNs.py -request -target-domain FREIGHTLOGISTICS.LOCAL INLANEFREIGHT.LOCAL/wley -outputfile hashtgs.txt ``` Podríamos intentar descifrar esto sin conexión usando Hashcat con el modo 13100. Si lo logramos, podríamos autenticarnos en el dominio FREIGHTLOGISTICS.LOCAL como administrador de dominio. Si conseguimos realizar este tipo de ataque durante una evaluación en un entorno real, también valdría la pena comprobar si esta cuenta existe en nuestro dominio actual y si se ha reutilizado la contraseña. Esto podría ser una ventaja rápida si aún no hemos podido escalar privilegios en nuestro dominio actual. Incluso si ya tenemos el control del dominio actual, sería conveniente añadir un hallazgo a nuestro informe si encontramos que se reutiliza la contraseña en cuentas con nombres similares en diferentes dominios. Supongamos que podemos realizar una prueba Kerberosa a través de una relación de confianza y que nos hemos quedado sin opciones en el dominio actual. En ese caso, también podría valer la pena intentar un Password Spray con la contraseña descifrada, ya que existe la posibilidad de que se pueda usar para otras cuentas de servicio si los mismos administradores están a cargo de ambos dominios. Aquí tenemos otro ejemplo de pruebas iterativas y de no dejar ningún cabo suelto. ### Cazando un Group Membership de otro dominio con Bloodhound-python Como se mencionó en la sección anterior, ocasionalmente podemos encontrar usuarios o administradores de un dominio como miembros de un grupo en otro dominio. Dado que solo los Grupos Locales de Dominio permiten usuarios externos a su bosque, no es raro ver a un usuario con altos privilegios del Dominio A como miembro del grupo de administradores integrado en el Dominio B cuando se trata de una relación de confianza bidireccional entre bosques. Si realizamos pruebas desde un host Linux, podemos recopilar esta información utilizando la implementación de BloodHound en Python. Esta herramienta nos permite recopilar datos de varios dominios, importarlos a la interfaz gráfica y buscar estas relaciones. En algunas evaluaciones, nuestro cliente puede proporcionarnos una máquina virtual que obtiene una IP de DHCP y está configurada para usar el DNS del dominio interno. En otras instancias, estaremos en un host de ataque sin DNS configurado. En este caso, necesitaríamos editar nuestro archivo resolv.conf para ejecutar esta herramienta, ya que requiere un nombre de host DNS para el controlador de dominio de destino en lugar de una dirección IP. Podemos editar el archivo de la siguiente manera usando permisos de superusuario. Aquí hemos comentado las entradas de servidor de nombres actuales y agregado el nombre de dominio y la dirección IP de ACADEMY-EA-DC01 como servidor de nombres. #### Agregar información de INLANEFREIGHT.LOCAL a /etc/resolv.conf ```bash G4b0x404@htb[/htb]$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "resolvectl status" to see details about the actual nameservers. #nameserver 1.1.1.1 #nameserver 8.8.8.8 domain INLANEFREIGHT.LOCAL nameserver 172.16.5.5 ``` #### Ejecutando bloodhound-python sobre INLANEFREIGHT.LOCAL ```bash bloodhound-python -d INLANEFREIGHT.LOCAL -dc ACADEMY-EA-DC01 -c All -u forend -p Klmcargo2 ``` Comprimiendo los archivos obtenidos ```bash zip -r ilfreight_bh.zip *.json ``` Repetimos el mismo proceso para FREIGHTLOGISTICS.LOCAL #### Agregar información de FREIGHTLOGISTICS.LOCAL a /etc/resolv.conf ```bash G4b0x404@htb[/htb]$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "resolvectl status" to see details about the actual nameservers. #nameserver 1.1.1.1 #nameserver 8.8.8.8 domain FREIGHTLOGISTICS.LOCAL nameserver 172.16.5.238 ``` #### Ejecutando bloodhound-python sobre FREIGHTLOGISTICS.LOCAL ```bash bloodhound-python -d FREIGHTLOGISTICS.LOCAL -dc ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL -c All -u forend@inlanefreight.local -p Klmcargo2 ``` Tras cargar el segundo conjunto de datos (ya sea cada archivo JSON por separado o como un único archivo zip), podemos hacer clic en Usuarios con pertenencia a grupos de dominios externos en la pestaña Análisis y seleccionar el dominio de origen INLANEFREIGHT.LOCAL. Aquí veremos que la cuenta de administrador integrada para el dominio INLANEFREIGHT.LOCAL es miembro del grupo de administradores integrado en el dominio FREIGHTLOGISTICS.LOCAL, como vimos anteriormente. #### Visualizando los derechos peligrosos a través de Bloodhound
Como se ha visto en las secciones anteriores, existen varias maneras de aprovechar las relaciones de confianza entre dominios para obtener acceso adicional e incluso realizar una maniobra de elusión y escalar privilegios en nuestro dominio actual. Por ejemplo, podemos tomar el control de un dominio con el que nuestro dominio actual tenga una relación de confianza y encontrar contraseñas reutilizadas en cuentas privilegiadas. Hemos visto cómo los derechos de administrador de dominio en un dominio secundario casi siempre implican la posibilidad de escalar privilegios y comprometer el dominio principal mediante el ataque ExtraSids. Las relaciones de confianza entre dominios son un tema bastante extenso y complejo. La introducción de este módulo nos ha proporcionado las herramientas para enumerar las relaciones de confianza y realizar algunos ataques estándar dentro y entre bosques. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://g4b0.gitbook.io/g4b0-docs/documentation/active-directory/attacking-domain-trusts-cross-forest-trust-abuse-from-linux.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.