En esta ocasión vengo a resolver una máquina especializada en ciberseguridad defensiva como analista de SOC dentro del equipo de Blue Team.
La máquina se llama «Web Investigation» 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.
A tener en cuenta como contexto de resolución del laboratorio:
| ESCENARIO Usted es un analista de ciberseguridad que trabaja en el Centro de Operaciones de Seguridad (SOC) de BookWorld, una extensa librería online famosa por su amplia selección de literatura. BookWorld se enorgullece de ofrecer una experiencia de compra fluida y segura a los entusiastas de los libros de todo el mundo. Recientemente, se le ha encomendado la tarea de reforzar la postura de ciberseguridad de la empresa, supervisar el tráfico de la red y garantizar que el entorno digital permanezca a salvo de amenazas. Una noche, a última hora, se activa una alerta automática por un pico inusual en las consultas a la base de datos y el uso de recursos del servidor, lo que indica una posible actividad maliciosa. Esta anomalía hace temer por la integridad de los datos de los clientes y los sistemas internos de BookWorld, lo que provoca una investigación inmediata y exhaustiva. Como analista principal en este caso, se le pide que analice el tráfico de red para descubrir la naturaleza de la actividad sospechosa. Sus objetivos incluyen identificar el vector del ataque, evaluar el alcance de cualquier posible violación de datos y determinar si el atacante obtuvo más acceso a los sistemas internos de BookWorld. |
Lo primero es descargamos el fichero de evidencias en nuestra máquina bajo la carpeta que hemos creado del laboratorio. A continuación la descomprimimos dentro e introducimos la contraseña que nos proporciona el laboratorio.
Se nos descargará un fichero .pcap (Packet Capture) que abriremos y ejecutaremos con la herramienta Wireshark (aunque puedes usar otras como Tshark, Tcpdump o NetworkMiner).
Wireshark es una herramienta que te permite ver todo lo que pasa en una red, como si estuvieras espiando el tráfico de datos que viaja entre dispositivos.
Al ejecutar el fichero con Wireshark, se nos abrirá un panel con todo el tráfico y registro de logs que se produjeron en la red:
Estructura del contenido
PREGUNTA 1: Conociendo la IP del atacante, podemos analizar todos los registros y acciones relacionados con esa IP y determinar el alcance del ataque, la duración del mismo y las técnicas utilizadas. ¿Puede facilitarnos la IP del atacante?
Damos por hecho por la pregunta que se ha producido un ataque, para ello empezaremos por usar los filtros de Wireshark, ya que el listado de paquetes es muy largo.
Sabiendo que, un atacante comienza normalmente por hacer un escaneo de puertos de la máquina víctima mediante nmap por TCP SYN (por ejemplo, así lo hicimos con la máquina Sightless de HTB), podemos filtrar de entre los registros.
Sabemos que nmap con la comunicación TCP SYN va a intentar contactar con uno o más de nuestros puertos, y que al estar este cerrado (entendiendo que hemos securizado bien esa petición), no se va a realizar el «three way handshake» con la petición ACK (acknowledgement).
¿Qué significa esto?
Cuando una máquina quiere iniciar una conexión con otra en una red, sigue un proceso llamado Three-Way Handshake (el saludo de 3 pasos de TCP):
1️⃣ SYN → La máquina A envía un paquete con la flag SYN activada para iniciar la conexión.
2️⃣ SYN-ACK → La máquina B responde con SYN y ACK activados si el puerto está abierto.
3️⃣ ACK → La máquina A envía un paquete con ACK activado para completar la conexión.
Pero si un atacante está escaneando puertos con Nmap usando TCP SYN (modo stealth):
- Envía solo SYN, pero si el puerto está cerrado, no recibe el SYN-ACK.
- En cambio, el sistema de la víctima responde con RST (Reset) o no responde.
- Esto nos ayuda a detectar el escaneo, porque hay muchos SYN sin ACK de vuelta.
Por tanto, vamos a afinar en la búsqueda por aquellos paquetes cuyo protocolo sea TCP pero de info no incluya ACK:
tcp.flags.syn == 1 && tcp.flags.ack == 0Haciendo ese filtro vemos que sólo se muestra los paquetes TCP que tienen activada la flag SYN y no tienen activada la flag ACK.
Ahora vamos a ver en la columna de IP source u origen, aquella/s que estén enviando ese tipo de petición, y vemos una sospechosa que es la que más registros tiene y peticiones hace al puerto web 80, que es la 111.224.250.131, por lo que deducimos que es esta la IP atacante.
Podemos verlo también desde la opción de Estadísticas – Conversaciones – TCP.
PREGUNTA 2: Si se sabe que el origen geográfico de una dirección IP es de una región que no tiene negocios ni tráfico esperado con nuestra red, esto puede ser un indicador de un ataque dirigido. ¿Se puede determinar la ciudad de origen del atacante?
En este caso, sabiendo ya la IP atacante, podemos ir a IPLocation.net en el navegador y buscar por esa IP si encuentra más información, y vemos la ciudad Shijiazhuang:
PREGUNTA 3: Identificar el script explotado permite a los equipos de seguridad saber exactamente qué vulnerabilidad se utilizó en el ataque. Este conocimiento es fundamental para encontrar el parche o la solución adecuada para cerrar la brecha de seguridad y evitar futuros ataques. ¿Puede facilitarnos el nombre del script PHP vulnerable?
Sabemos que el atacante 111.224.250.131 intentó acceder al puerto 80 (HTTP). Para ver sus peticiones, aplicamos este filtro en Wireshark:
http.request && ip.src == 111.224.250.131Y ahora vamos a analizar en la parte de «Info» aquellas peticiones GET sospechosas, por ejemplo a archivos .php, técnicas de fuerza bruta o SQLi, etc.
Efectivamente vemos que donde más peticiones GET está haciendo es al buscador interno de la web intentando ejecutar SQLi inyección de código para acceder a información de nuestra base de datos. Por tanto, el nombre del script PHP que está intentando atacar es el /search.php.
PREGUNTA 4: Establecer la cronología de un ataque, empezando por el intento inicial de explotación, ¿Cuál es el URL de petición completa del primer intento de SQLi por parte del atacante?
Si en ese mismo listado, vamos subiendo (ya que está ordenado por fecha), veremos que el primer intento de SQLi a esa página, se hace a esta URL: /search.php?search=book%20and%201=1;%20–%20-
Si ese payload incluido en ese fichero .php lo traducimos a SQL, sería algo como:
SELECT * FROM book WHERE titulo = 'book' AND 1=1; -- -
¿Qué está haciendo este payload?
1️⃣ book AND 1=1;
bookes un valor normal de búsqueda.AND 1=1es una condición siempre verdadera, lo que sugiere que el atacante está probando si el parámetro es vulnerable a SQL Injection.- Si la consulta devuelve resultados normalmente, significa que la inyección es posible.
2️⃣ -- - (Comentario en SQL)
--en SQL significa que todo lo que viene después es un comentario, por lo que se ignora cualquier código SQL adicional.- Esto es útil si hay restricciones en la consulta original, permitiendo al atacante manipularla sin errores.
¿Por qué es peligroso?
Si el parámetro search no está sanitizado, el atacante podría modificar la consulta y eventualmente:
- Extraer datos confidenciales (usuarios, contraseñas).
- Modificar información en la base de datos.
- Obtener acceso al sistema mediante ejecución de comandos SQL.
PREGUNTA 5: ¿Puede proporcionar la URL de solicitud completa que se utilizó para leer las bases de datos disponibles del servidor web?
Si analizamos de nuevo todas las peticiones anteriores donde se están haciendo ataques SQLi a la bbdd, vemos una petición, después del http/1.1 donde supuestamente el atacante ha dejador de probar (probablemente automatizado).
Al analizarla haciendo un follow – http stream, vemos la etiqueta de «information schema» la cual contiene los nombres de todas las bases de datos que son los que se muestran al lado, lo que confirma que la inyección SQL funcionó y el atacante extrajo con éxito los nombres de las bases de datos.
/search.php?search=book%27%20UNION%20ALL%20SELECT%20NULL%2CCONCAT%280x7178766271%2CJSON_ARRAYAGG%28CONCAT_WS%280x7a76676a636b%2Cschema_name%29%29%2C0x7176706a71%29%20FROM%20INFORMATION_SCHEMA.SCHEMATA--%20-
PREGUNTA 6: Es crucial evaluar el impacto de la violación y el acceso a los datos, incluido el daño potencial a la reputación de la organización. ¿Cuál es el nombre de la tabla que contiene los datos de los usuarios del sitio web?
Al volver al listado de peticiones, y seguida de la anterior que está solicitando los nombres de las bases de datos, vemos el nombre de las tablas de la base de datos de la empresa (que suponemos que es «bookworld_db»):
y de las cuales, suponemos que los datos de los usuarios se encuentran en la tabla «customers».
PREGUNTA 7: Los directorios de sitios web ocultos al público podrían servir de punto de acceso no autorizado o contener funcionalidades sensibles no destinadas al acceso público. ¿Puede facilitar el nombre del directorio descubierto por el atacante?
Volvemos a fijarnos en el historial de registros filtrados por la IP atacante, y después de los ataques de SQLi y de la petición que probablemente le de las credenciales, se ve como el atacante ha realizado fuzzing para descubrir directorios ocultos.
Vemos que ha hecho muchas solicitudes al directorio admin, por lo que vamos a filtrar la consulta por que tiene un método POST y nos filtra efectivamente ese directorio con intento de acceso con distintos usuarios y contraseñas:
http.request.method == POST
PREGUNTA 8: Saber qué credenciales se utilizaron nos permite determinar el alcance del compromiso de la cuenta. ¿Cuáles son las credenciales utilizadas por el atacante para iniciar sesión?
Relacionado con el punto anterior, vemos todos los envíos del atacante por POST, y en este caso nos interesa saber el último que hizo y que por tanto fue exitoso:
Por lo que las credenciales utilizadas fueron: admin:admin123!
PREGUNTA 9 : Necesitamos determinar si el atacante obtuvo más acceso o control de nuestro servidor web. ¿Cuál es el nombre del script malicioso subido por el atacante?.
Si filtramos por el último POST hecho por el atacante, vemos que se relaciona con una carga de una shell en bash, que le permitirá establecer una reverse shell y ejecutar el fichero malioso: NVri2vhp.php
http.request.method == POST && ip.src == 111.224.250.131
Y con esto daríamos por concluida la máquina.
Un laboratorio muy interesante de análisis de logs como analista de SOC.
| 📌 Resumen de la resolución de la máquina «Web Investigation» El análisis comenzó con la identificación de la IP del atacante ( 111.224.250.131) mediante el filtro de paquetes SYN sin ACK en Wireshark, lo que reveló un escaneo de puertos. Luego, se rastreó su origen geográfico en China y se identificó el primer intento de SQL Injection (SQLi) en el script vulnerable /search.php, donde utilizó consultas como UNION SELECT database() para extraer los nombres de las bases de datos. Posteriormente, el atacante listó las tablas dentro de la base de datos bookworld_db, descubriendo una tabla llamada customers, que probablemente contenía información de usuarios. A continuación, realizó fuzzing para encontrar directorios ocultos, identificando /admin como accesible, e intentó autenticarse mediante ataques de fuerza bruta. Se confirmó que logró entrar utilizando las credenciales admin:admin123!.Tras obtener acceso al panel de administración, el atacante subió un script malicioso ( NVri2vhp.php), que contenía una reverse shell en Bash, permitiéndole tomar el control remoto del servidor. La respuesta HTTP 200 OK confirmó que el archivo fue subido exitosamente, lo que significa que el servidor quedó completamente comprometido. Este análisis demuestra la importancia de implementar medidas de seguridad como validación de entradas para evitar SQLi, uso de credenciales seguras, restricciones en la subida de archivos y monitoreo de tráfico sospechoso para prevenir accesos no autorizados. 🚀🔍 |
Te dejo este vídeo explicativo paso a paso que me ha ayudado a entender y resolver este laboratorio.
