En el post de hoy vamos a explotar las relaciones de confianza de un solo sentido, desde el punto de vista inbound.
Si aún no lo has visto, echa un vistazo primero a este post, en el que te explico lo básico de las relaciones de confianza en un active directory, las distintas relaciones que tienen los bosques y cómo explotar una relación de confianza bidireccional.
Recordemos que en las relaciones de confianza de un solo sentido, todos los usuarios del dominio en el que se confía tienen acceso a los recursos del dominio que confía, pero no al revés.
Dependiendo de la perspectiva la relación de confianza puede ser inbound (el otro dominio confía en mi dominio, por lo que los usuarios de mi dominio tienen acceso a los recursos del otro dominio) o outbound (mi dominio confía en el otro dominio, por lo que los usuarios del otro dominio tienen acceso a los recursos de mi dominio).
Relaciones Inbound
En este ejemplo podemos ver que nuestro dominio, dev.*****.io, tiene una relación de confianza inbound con el dominio subsidiary.external. Por tanto, los usuarios de nuestro dominio pueden acceder a los recursos de subsidiary.external:
Podemos enumerar por tanto el dominio contrario a través de esta relación de confianza. Para enumerarlo estoy utilizando commandos de PowerSploit.
Veamos que ordenadores hay asociados a este dominio:
Otra de las cosas interesantes que podemos enumerar es si hay grupos en el otro dominio que contengan usuarios que no pertenezcan a ese dominio.
Vemos que hay un miembro que pertenece al grupo de administradores y que no pertenece a ese dominio. Para ver que es ese miembro tan solo temenos que usar el comando ConvertFrom-SID de powershell e introducir el SSID.
El grupo “Subsidiary Admins” de nuestro dominio pertenece al grupo de administradores del dominio externo. Si tenemos acceso a alguno de los usuarios de este grupo, entonces podremos acceder al dominio externo con permisos de administración.
Caso 1: Conocemos usuario y contraseña de un miembro del grupo de confianza
Tan solo tenemos que utilizar el comando Get-DomainGroupMember para buscar el grupo “Subsidiary Admins” en nuestro dominio. En este caso obtenemos que el usuario jadams pertenece a este grupo. Asumiendo que sabemos sus credenciales, podemos usar la función make_token de Cobalt Strike (o la homónima en el C&C que estés utilizando) para poder acceder a los recursos de ad.subsidiary.external.
Caso 2: Conocemos usuario y las claves RC4/AES de un miembro del grupo de confianza
En caso de que no sepamos la contraseña pero tengamos las claves RC4 o AES del usuario (las hemos obtenido con mimikatz por ejemplo), entonces podemos utilizar Rubeus para pedir un ticket a Kerberos. Sin embargo, necesitaremos un par de pasos extras, ya que al estar solicitando un ticket para un dominio externo, necesitamos una clave de inter-realm que Rubeus no genera automáticamente.
En primer lugar, necesitamos un ticket TGT para nuestro usuario en nuestro dominio. Lo solicitamos con el comando asktgt de Rubeus:
