Webstrike Lab – CyberDefenders [WriteUp]

En esta ocasión vengo a resolver una máquina especializada en ciberseguridad defensiva como analista de SOC dentro del equipo de Blue Team. Nivel 1 de SOC Analyst.

La máquina se llama «WebStrike Lab» 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.

En este laboratorio nos encargaremos de analizar el tráfico de red utilizando Wireshark para investigar el compromiso de un servidor web, identificar la implementación de un shell web, la comunicación del shell inverso y la exfiltración de datos.

A tener en cuenta como contexto de resolución del laboratorio:

ESCENARIO Se identificó un archivo sospechoso en el servidor web de una empresa, lo que activó las alarmas dentro de la intranet. El equipo de desarrollo señaló la anomalía, sospechando de una posible actividad maliciosa. Para abordar el problema, el equipo de redes capturó el tráfico crítico de la red y preparó un archivo PCAP para su revisión. Nuestra tarea consiste en analizar el archivo PCAP proporcionado para descubrir cómo apareció el archivo y determinar el alcance de cualquier actividad no autorizada.

En este caso no tenemos que descargarnos el fichero PCAP en nuestra máquina de pruebas, si no que automáticamente la plataforma te habilitar una pestaña en el navegador:

PREGUNTA 1. Identificar el origen geográfico del ataque facilita la implementación de medidas de bloqueo geográfico y el análisis de la inteligencia sobre amenazas. ¿Desde qué ciudad se originó el ataque?

💡 Nota: Las máquinas del laboratorio no tienen acceso a Internet. Para buscar la dirección IP y completar este paso, utilice un servicio de geolocalización de IP en su ordenador local fuera del entorno del laboratorio.

Una vez la plataforma despliega el laboratorio, nos dirigimos a /home/ubuntu/Desktop/Start here/Artifacts/ y abrimos el archivo PCAP.

Al abrirse el fichero vemos un listado largo de peticiones y analizando las estadísticas vemos que están simplificadas en el puerto web 80 desde la misma IP atacante que es la 117.11.88.124 a nuestra máquina víctima local 24.64.63.79.

Si analizamos esa IP atacante con la herramienta IPlocation , vemos que corresponde con una IP localizada en China (Tianjin).

PREGUNTA 2. Conocer el user-agent del atacante ayuda a crear reglas de filtrado robustas. ¿Cuál es el user-agent completo del atacante?

SI nos vamos al listado de todas las peticiones recogidas en el PCAP y vamos a la primera que hace la IP atacante de antes a nuestro servidor al puerto 80 http (el get) y desplegamos la opción de «Hypertext Transfer Protocol» vemos que el user-agent que se está utilizando es:

Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

PREGUNTA 3. Necesitamos determinar si se explotó alguna vulnerabilidad. ¿Cuál es el nombre del shell web malicioso que se cargó correctamente?

En este caso tenemos que empezar a filtrar del listado de peticiones que tiene un total de 355 paquetes, nos tenemos que quedar con aquellos cuyo protocolo sea http porque se ha realizado una subida/carga de un fichero malicioso, luego en el filtro de Wireshark pondremos:

http && ip.src == 117.11.88.124

De esta manera filtramos solo las peticiones http cuyo origen sea la IP maliciosa analizada al inicio.

Esto nos devuelve ya solo 22 paquetes, y como lo que se ha hecho es una carga de un fichero a la web, nos quedaremos con las peticiones POST de envío, que en este caso son 2:

Si analizamos la primera petición POST a través del stream http, vemos que se intentó cargar un fichero .php malicioso que contenía una reverse shell en bash, pero que la respuesta que le devolvió el servidor fue que el formato era inválido.

Y si pasamos a analizar la segunda petición por POST, vemos como de nuevo intenta subir a la ruta de la web llamada /reviews/upload.php un fichero php malicioso llamado «image.jpg.php«, pero esta vez, y sabiendo que el formato del intento anterior fue inválido al ser .php, ahora ha probado a inclur la extensión .jpg.php con el mismo payload, y efectivamente sí le funcionó.

PREGUNTA 4. Identificar el directorio donde se almacenan los archivos subidos es fundamental para localizar la página vulnerable y eliminar cualquier archivo malicioso. ¿Qué directorio utiliza el sitio web para almacenar los archivos subidos?

Si seguimos las peticiones siguientes a la subida del fichero malicioso por el método GET porque es desde donde se ejecutará el fichero que le ayudará al atacante a ganar acceso al servidor, vemos que el fichero se aloja en el directorio /reviews/uploads/

PREGUNTA 5. ¿Qué puerto, abierto en la máquina del atacante, fue el objetivo del shell web malicioso para establecer una comunicación saliente no autorizada?

Si analizamos el stream http de la subida del archivo malicioso, dentro de la reverse shell que inyecta, se referencia por un lado a la IP del atacante que será la que reciba la shell y por otro lado el puerto 8080 que usó mediante netcat (nc) para ponerse en escucha.

PREGUNTA 6. Reconocer la importancia de los datos comprometidos ayuda a priorizar las acciones de respuesta ante incidentes. ¿Qué archivo intentaba sustraer el atacante?

Sabemos que el puerto del atacante sobre el que estaba recibiendo la conexión con la máquina víctima era el 8080, por lo que vamos a filtrar las peticiones por tcp de ese puerto:

tcp.port == 8080

Si ahora analizamos el TCP stream, vemos el conjunto de interacciones que el atacante estuvo haciendo con la shell que se le abrió después de ejecutar la reverse shell en el servidor, y vemos que empieza preguntando quién es, después pregunta por el SO de la máquina, pregunta en directorio está, se mueve hacia la home y pide el fichero /etc/passwd donde se almacenan los usuarios de la máquina haciendo una petición por curl de ese fichero en su máquina local.

Y aquí terminaría el laboratorio. Muy interesante ver cómo se inyecta un fichero malicioso, se ejecuta una reverse shell y se itera hasta conseguir las credenciales.

📌 Resumen de la resolución de la máquina «WebStrike Lab» En este laboratorio nos ponemos en la piel de un analista de SOC (Blue Team) que recibe un PCAP para investigar el compromiso de un servidor web. Abrimos la captura con Wireshark y, usando filtros, identificamos rápidamente la IP atacante y su origen geográfico (Tianjin, China) gracias a un servicio de geolocalización de IP. Analizando la primera petición HTTP de esa IP, descubrimos también el user-agent del atacante, lo que nos ayuda a perfilar mejor el tipo de cliente que está usando. A partir de ahí, filtramos solo el tráfico HTTP de la IP maliciosa y nos centramos en las peticiones POST, donde vemos que el atacante intenta subir una webshell en PHP. El primer intento falla porque sube directamente un .php, pero en el segundo usa un nombre camuflado (image.jpg.php) y esta vez el servidor lo acepta. Siguiendo las peticiones posteriores, descubrimos que el archivo malicioso se guarda en el directorio /reviews/uploads/ y que, al ejecutarlo, abre una reverse shell desde la víctima hacia el atacante utilizando el puerto 8080 con nc (netcat) a la IP atacante. Por último, filtramos el tráfico del puerto 8080 y seguimos el TCP stream de la reverse shell. Ahí vemos los comandos que el atacante va lanzando una vez dentro del sistema: comprueba el usuario, el sistema operativo, recorre directorios y, sobre todo, intenta exfiltrar el contenido del archivo /etc/passwd usando curl para llevárselo a su máquina. Con todo esto, el laboratorio nos enseña de forma muy clara cómo, desde el punto de vista defensivo, se puede reconstruir paso a paso un ataque: subida de webshell, ejecución de reverse shell y exfiltración de datos analizando únicamente el tráfico de red con Wireshark. Recientemente trabajé en el ataque de subida de ficheros vulnerable mediante una reverse shell en la plataforma The Hackers Labs con la máquina Uploader, te recomiendo que la veas para así tener los dos puntos de vista, el del atacante y el defensivo.