Support
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Support es una máquina Windows de dificultad Fácil que cuenta con un recurso compartido SMB que permite la autenticación anónima. Después de conectarse al recurso compartido, se descubre un archivo ejecutable que se utiliza para consultar al servidor LDAP de la máquina los usuarios disponibles.
A través de ingeniería inversa, análisis de red o emulación, se identifica la contraseña que utiliza el binario para vincular el servidor LDAP y se puede utilizar para realizar más consultas LDAP. Se identifica un usuario llamado support en la lista de usuarios y se descubre que el campo info contiene su contraseña, lo que permite una conexión WinRM a la máquina. Una vez en la máquina, se puede recopilar información del dominio a través de SharpHound y BloodHound revela que el grupo Shared Support Accounts del que es miembro el usuario support tiene privilegios GenericAll en el controlador de dominio. Se realiza un ataque de delegación restringida basada en recursos y se recibe un shell como NT Authority\System.
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Support.
Lanzaremos una serie de scripts básicos para intentar buscar vulnerabilidades en los puertos que hemos encotrado expuestos.
Comprobaremos el nombre del dominio con el cual nos enfrentamos a través del siguiente comando.
Procederemos a añadir la entrada en nuestro archivo /etc/hosts
Procederemos a enumerar el servicio de SMB que hemos encontrado expuesto. Probaremos de listar los recursos compartidos para ver que encontramos. Nos descargaremos todo el contenido
Procederemos a conectarnos al recurso compartido (support-tools) y nos descargaremos todo el contenido del recurso compartido a nuestro equipo local.
Comprobamos que entre los archivos que hemos descargado
Abriremos el binario en la aplicación mencionada y iremos investigando como funciona por debajo la aplicación que hemos encontrado. Nos damos cuenta que en el archivo "LdapQuery" parece que se obtiene una contraseña a través de la función getPassword() del archivo Protected en el cual se utiliza el usuario parece ser (support\ldap).
Accediendo al contenido del archivo Protected nos damos cuenta que se envía una contraseña encodeada.
Volveremos al archivo de LdapQuery y haremos un breakpoint en el punto indicado y debuguearemos pasándole argumentos para la ejecución del programa.
Comprobaremos en la zona inferior que obtuvimos una variable nombrada password pero no nos aparece ningún contenido. Procederemos a debuguear el programa (Debug < Step Over) para ir al siguiente paso.
Comprobamos que al ir al siguiente paso en la variable password se almacena un valor que parece ser una contraseña sin encodear.
Comprobaremos en nuestra Kali utilizando la herramienta de netexec de ver si las credenciales obtenidas son válidas para el usuario ldap que es el que aparecía en el código del .exe analizado.
Una de las maneras que disponemos de enumerar el LDAP del servidor es mediante la herramienta de ldapdomaindump.
Otra de las maneras para enumerar LDAP, es a través del comando ldapsearch en el cuál podemos ir enumerando usuario por usuario a través del siguiente comando.
El siguiente comando procederemos a enumerar al usuario "support" para ver que información tiene. Nos damos cuenta que en el campo "Info" aparece una cadena de texto que parece inusual, más bien, parace de tratarse de una contraseña.
Una de las mejores maneras de enumerar LDAP es a través de BloodHound el cual recolectando toda la información del dominio podemos montarnos una BBDD con todo el dominio y ver que vías potenciales disponemos para escalar privilegios, etc.
Ene ste caso enumeramos des de Bloodhound al usuario "support" y nos damos cuenta que pertenece al grupo de usuarios de gestión remota, es decir "Remote Management Users". Por lo tanto, es un buen indicio que con dicho usuario podemos conectarnos al WinRM que encontramos expuesto a la hora de escanear los puertos con nmap.
Procederemos de validar con netexec de que con el usuario support y las credenciales encontradas en el campo "Info" de su usuario de LDAP són válidas o no para el acceso al WinRM.
Comprobamos que nos aparece como Pwn3d, por lo tanto, comprobamos que son credenciales válidas y además que tenemos acceso al WinRM, ya que si no tuvieramos acceso al WinRM, nos habría salido en [+] (indicando que las credenciales son válidas), pero no nos hubiera indicado el Pwn3d.
Una vez comprobado que si tenemos acceso, procederemos a conectarnos a la máquina víctima con el usuario "support" y sus respectivas credenciales. Comprobaremos que ganamos acceso y vemos el contenido de la flag de user.txt.
Procerderemos a enumerar al usuario "support" y comprobar de qué grupos es miembro. Nos damos cuenta que es miembro del grupo "Shared Support Accounts", un grupo un tanto inusual que miraremos de qué trata.
Des de Bloodhound buscaremos al grupo "Shared Support Accounts" y en "Node Info" haremos clickl a "Reachable High Value Targets" para intentar ver objetivos alcanzables de alto valor que podamos utilizar para escalar privilegios.
Comprobamos que existe relación entre el grupo "Shared Support Accounts" y si le damos a "Help" comprobamos que Bloodhound nos indica que todos los miembros de dicho grupo tiene control total sobre el equipo indicado.
Si accedemos a "Windows Abuse", Bloodhound nos mostrará unas pautas para intentar explotar la vulnerabilidad (RBCD Attack).
Un ataque de RBCD (Resource-Based Constrained Delegation) se aprovecha de la delegación basada en recursos en entornos de Active Directory para obtener acceso privilegiado. Este tipo de ataque usa la capacidad de un objeto en Active Directory para delegar acceso a otro recurso en el sistema, sin intervención administrativa directa.
En un escenario típico, el atacante compromete una cuenta que puede modificar ciertos atributos, como la propiedad de delegación en un objeto de computadora. Luego, configura ese objeto para que pueda autenticarse como cualquier usuario en un recurso específico, por ejemplo, para obtener el Ticket Granting Ticket (TGT) de una cuenta privilegiada y, así, escalar permisos.
Primero de todo, en nuestra Kali procederemos a descargarnos el Powermad para pasarlo al equipo que queremos comprometer des de Evil-WinRM.
Des del equipo que queremos comprometer, procederemos a subirnos el archivo .ps1, importaremos el módulo y procederemos a realizar el ataque.
Procederemos a crear con Powermad un equipo llamado "SERVICEA" y le asignaremos de contraseña '123456'
Procederemos a descargarnos PowerView a nuestra Kali, la pasaremos al equipo víctima e importaremos el módulo para tener los comandos disponibles.
Comprobaremos que el objeto de ordenador que hemos creado "SERVICEA" se ha creado correctamente. Comprobamos que se ha creado sin problemas y tenemos el SID del objeto, lo cual es su identificador.
Procederemos a realizar lo que nos queda para finalizar el RCBD Attack.
Al configurar el atributo ´msds-allowedtoactonbehalfofotheridentity' en el objeto de ordenador 'SERVICEA', le otorgamos la capacidad de actuar en nombre de otros usuarios dentro del controlador de dominio (dc). Este proceso se basa en la delegación de recursos (RBCD), que permite que un equipo pueda solicitar acceso a ciertos recursos como si fuera otro usuario.
Específicamente, al aplicar este cambio, SERVICEA obtiene permisos para solicitar un Ticket Granting Ticket (TGT) en nombre de otras cuentas, incluyendo aquellas con permisos elevados. En un entorno de ataque, este TGT permite que SERVICEA acceda a servicios o realice acciones en el dominio como si fuera el usuario original, logrando así una impersonación dentro del controlador de dominio.
Utilizaremos el siguiente comando para conseguir el Hash NTLM del equipo SERVICEA en el dominio de support.htb, le pasaremos la contraseña que hemos configurado anteriormente al crear el equipo en el dominio. Comprobaremos que obtenemos el hash, el que nos interesa es el de rc4_hmac.
Este comando en Rubeus permite realizar una impersonación de usuario mediante la función S4U (Service for User) en un ataque de delegación basada en recursos (RBCD), utilizando el hash NTLM de la cuenta SERVICEA$.
Al ejecutarlo, Rubeus solicita un Ticket Granting Service (TGS) para el usuario administrator en el servicio cifs del controlador de dominio (dc.support.htb), pero empleando los privilegios de la cuenta SERVICEA$. Esto permite que SERVICEA$ actúe en nombre de administrator, logrando así la impersonación del usuario con privilegios elevados y proporcionando acceso al controlador de dominio como si fuera administrator.
En pocas palabras, este comando usa los permisos de delegación configurados en SERVICEA$ para operar con los mismos privilegios de administrator en el dominio, asegurando un acceso privilegiado a los recursos.
Comprobamos que nos otorga el tiquet Kirbi codeado en Base64. Copiaremos el contenido del ticket.
En nuestra Kali, copiaremos el contenido del ticket en un archivo nombrado "ticket.kirbi.b64". Lo descodificaremos de Base64 y guardaremos el archivo como "ticker.kirbi".
Utilizaremos ticketConverter.py, este comando convierte un ticket kirbi en un ccache, lo que permite su uso en diferentes entornos y herramientas que gestionan la autenticación Kerberos.
En este comando, establecemos la variable de entorno KRB5CCNAME para que apunte al archivo de caché de tickets Kerberos (ticket.ccache), que contiene el ticket que obtuvimos anteriormente. Luego, ejecutamos psexec.py, lo que nos permite acceder a la máquina remota usando Kerberos para la autenticación (especificando -k), sin necesidad de proporcionar una contraseña (gracias a -no-pass).
Al especificar support.htb/administrator@dc.support.htb, logramos ejecutar comandos en el controlador de dominio con los privilegios del usuario administrator. Esto nos facilita el acceso a recursos y funciones del sistema con permisos elevados, culminando así el ataque RBCD de manera efectiva.
Comprobamos que ganamos acceso finalmente como usuario Administrador y obtenemos la flag de root.txt.
Primero de todo, procederemos a pasarnos el .exe a un equipo Windows para analizarlo con la siguiente herramienta .
Procederemos a realiar la explotación de dicha vulnerabilidad para realizar un escalado de privilegios. Para ello hemos seguido la guía de donde lo explica de manera detallada y te muestra que se tiene que realizar.
En nuestra Kali procederemos a descargarnos el binario de Rubeus.exe des de . Rubeus lo utilizaremos para solicitar y cargar un ticket de servicio (TGS), lo que permite al atacante utilizar 'SERVICEA' para actuar como un usuario privilegiado en un recurso determinado.
