Day 3: Did You SIEM? - Advent of Cyber 2025

Después de jugar en el equipo rojo ayer, hoy volvemos a ponernos el sombrero de Blue Team. La seguridad de Wareville ha sido comprometida y nuestro trabajo es investigar qué ha pasado.

Para ello, utilizaremos Splunk, una de las herramientas SIEM (Security Information and Event Management) más potentes del mercado. Analizaremos los logs del servidor web y del firewall para reconstruir el ataque paso a paso, desde el reconocimiento inicial hasta la exfiltración de datos.

Room: Splunk Basics - Did you SIEM?
Dificultad: Medium
Objetivo: Identificar la IP del atacante, trazar sus movimientos y cuantificar el daño utilizando Splunk.

Disclaimer: Las imágenes utilizadas en este post son propiedad de TryHackMe y se utilizan con fines educativos para ilustrar la resolución del reto.

🔍 Análisis Inicial en Splunk

Al acceder a la instancia de Splunk, lo primero que hacemos es buscar todos los eventos disponibles en el índice principal.

index=main

Splunk nos muestra dos tipos de fuentes de datos (sourcetype):

• web_traffic: Logs de conexiones al servidor web.
• firewall_logs: Logs de tráfico permitido o bloqueado por el firewall.

Visualizando la Línea de Tiempo

Para entender cuándo ocurrió el ataque, visualizamos el volumen de tráfico por día. Un pico inusual de actividad suele ser el primer indicador de un incidente.

index=main sourcetype=web_traffic | timechart span=1d count | sort by count | reverse

Esta consulta nos muestra los días con mayor actividad. Observamos un pico claro en una fecha específica, lo que responde a una de las preguntas del reto.

Pregunta: Which day was the peak traffic in the logs? (Format: YYYY-MM-DD)
Respuesta: 2025-10-12

🕵️‍♂️ Cazando al Atacante (Anomaly Detection)

Sabemos que los atacantes suelen utilizar herramientas automatizadas que dejan huellas en el User-Agent. Vamos a filtrar el tráfico legítimo (navegadores comunes como Mozilla, Chrome, Safari) para quedarnos con lo sospechoso.

index=main sourcetype=web_traffic user_agent!=*Mozilla* user_agent!=*Chrome* user_agent!=*Safari* user_agent!=*Firefox*

Al analizar los resultados, vemos un client_ip que destaca por encima de las demás, realizando miles de peticiones con un User-Agent extraño.

Con esto, ya tenemos la respuesta a otra pregunta:

Pregunta: What is the attacker IP found attacking and compromising the web server?
Respuesta: 198.51.100.55

⛓️ Reconstruyendo la Cadena de Ataque (Kill Chain)

Ahora que tenemos la IP del atacante (198.51.100.55), vamos a filtrar todos los logs por esta IP para ver exactamente qué hizo.

1. Reconocimiento y Escaneo de Vulnerabilidades

El atacante comenzó buscando archivos de configuración expuestos (.env, .git) y probando vulnerabilidades de Path Traversal (intentar acceder a directorios superiores con ../).

Para contar cuántos intentos de Path Traversal hubo, buscamos patrones como .. o redirect en la URL:

sourcetype=web_traffic client_ip="198.51.100.55" AND path="*..\/..\/*" OR path="*redirect*" | stats count by path

Observamos muchas peticiones hacia /etc/passwd, fichero el cual contiene las contraseñas hasheadas del sistema. Con esto, descubrimos otra pregunta del reto:

Pregunta: How many path traversal attempts to access sensitive files on the server were observed?
Respuesta: 658

2. Explotación (SQL Injection)

Posteriormente, vemos intentos de inyección SQL. El atacante utilizó herramientas automatizadas como Havij y sqlmap. Podemos ver payloads clásicos como SLEEP(5), que indican un ataque de SQL Injection basado en tiempo.

Para ver las peticiones que se hicieron con herramientas como Havij o sqlmap podemos usar:

sourcetype=web_traffic client_ip="198.51.100.55" AND user_agent IN ("*sqlmap*", "*Havij*") | table _time, path, status

En la pestaña de Events, podemos ver detalladamente el uso de cada herramienta, de este modo tenemos la respuesta a la siguiente pregunta:

Pregunta: What is the count of Havij user_agent events found in the logs?
Respuesta: 993

3. Ejecución y Exfiltración (C2)

Finalmente, el ataque tuvo éxito. Vemos peticiones a archivos sospechosos como shell.php y bunnylock.bin, lo que sugiere que lograron subir una Web Shell y ejecutar un ransomware o malware.

Para confirmar la exfiltración de datos, cruzamos la información con los logs del firewall (firewall_logs). Buscamos conexiones salientes desde nuestro servidor comprometido (10.10.1.5) hacia la IP del atacante.

sourcetype=firewall_logs src_ip="10.10.1.5" AND dest_ip="198.51.100.55" AND action="ALLOWED" | stats sum(bytes_transferred)

Esta consulta suma todos los bytes que salieron de nuestra red hacia el atacante, confirmando el robo de información.

Con esta información podemos responder a la pregunta:

Pregunta: Examine the firewall logs. How many bytes were transferred to the C2 server IP from the compromised web server?
Respuesta: 126167

Conclusión

El análisis de logs con herramientas como Splunk es fundamental para cualquier equipo de respuesta a incidentes. Hoy hemos podido ver de forma sencilla y breve:

1. Detectar una anomalía basada en el volumen de tráfico.
2. Identificar la IP maliciosa filtrando tráfico legítimo.
3. Reconstruir paso a paso las fases del ataque (Reconocimiento -> Explotación -> Exfiltración).

La visibilidad es poder. Si no puedes ver lo que ocurre en tu red, no puedes defenderla. El uso de esta herramienta nos ayuda mucho en esa tarea.

Porque recordad, que en ciberseguridad la frase de "ojos que no ven, corazón que no siente" no aplica. Aquí, si no lo ves y no actúas, las consecuencias pueden ser devastadoras.

Mañana publicaré el writeup del Día 4: AI in Security - Old sAInt Nick, donde exploraremos el papel de la Inteligencia Artificial en la ciberseguridad.

Si te perdiste la entrada de ayer sobre Ingeniería Social y Phishing, puedes leer el Día 2: Merry Clickmas aquí. Y si quieres empezar desde el principio, tienes el Día 1: Shells Bells.

¡Nos vemos mañana! 🎄

~ Xhetic