Log Analysis — Compromised WordPress
cat access.log | grep “POST” | awk ‘{print $7}’ | sort | uniq -c | sort -nr
-
cat access.log: Inyecta el archivo en el flujo de datos.
-
grep “POST”: Destruye todo el ruido de lectura (GET). Solo me interesan las modificaciones y ejecuciones de código que el atacante envió al servidor.
-
awk ‘{print $7}’: Extrae exactamente la séptima columna (la URL de la petición), ignorando fechas, navegadores web y basura.
-
sort | uniq -c | sort -nr: Agrupa las URLs idénticas, las cuenta y te las escupe en orden descendente.
Plugins específicos instaló y activó a través de peticiones GET, modifica el filtro así
grep “action=activate” access.log | awk ‘{print $7}’ | cut -d’=’ -f3 | cut -d’&’ -f1
La Anatomía del Log en hoja de cálculo (limpiando separadores)
Columna 1 (IP del Cliente)
Muestra direcciones como 172.21.0.1 o 127.0.0.1 a lo largo de tu archivo. Es la coordenada de red de origen. En ciberseguridad y respuesta a incidentes, esta es la firma balística de tu enemigo; la pista principal que debes aislar para bloquear su nodo.
Columna 2 (Marca de Tiempo)
Extraído como [12/Jan/2021:15:52:41 +0000]. El sello temporal y zona horaria. Esto es vital para construir la “Línea de Tiempo del Incidente”.
Columna 3 (La Petición)
Muestra el método, la ruta y el protocolo. Ejemplo: “GET / HTTP/1.1”. Este es el vector de ataque puro. Te revela si el atacante simplemente escanea el entorno (GET) o si inyecta código, altera configuraciones e instala plugins maliciosos (POST). Aquí es donde reside la intención técnica de la bestia.
Columna 4 (Código de Estado HTTP)
Muestra números como 200 , 302 o 500.
Es el veredicto del servidor.
Un estado 200 significa que el atacante tuvo éxito en su ejecución; un 404 significa que exploró el vacío buscando backdoors inexistentes; un 500 indica que sus peticiones colapsaron un subproceso del servidor.
Columna 5 (Tamaño de la Respuesta)
Representado en bytes, como 5173. Indica el volumen exacto de datos que tu servidor entregó al host malicioso.
En un entorno de Blue Team, picos inusuales en esta columna son la prueba irrefutable de que te han exfiltrado la base de datos o extraído archivos voluminosos.
Columna 6 (User-Agent)
El disfraz del navegador. En tu log se lee “Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0”.
Es la cadena que usa la herramienta o el atacante para identificarse. En este incidente, tu atacante intentó camuflar sus escaneos emulando un sistema Linux con una versión específica de Firefox.
Si el atacante fuese un novato, esta columna a menudo los traiciona mostrando firmas literales como “Nmap” o “WPScan”.
{width=“6.267716535433071in”
height=“2.611111111111111in”}
{width=“6.267716535433071in”
height=“3.763888888888889in”}
+--------------------------------------------------------+ | Resumen de Actividad | | | | Se han procesado un total de 1,978 peticiones válidas | | a partir de los datos proporcionados. A continuación, | | se detallan los puntos clave: | | | | • Distribución por Código de Estado: La gran | | mayoría de las peticiones fueron exitosas (código | | 200), aunque se observa un volumen considerable de | | errores 404 (No encontrado) y 403 (Prohibido). | | | | • Concentración de Tráfico: Una única dirección IP | | (172.21.0.1) es responsable de más de la mitad de las | | peticiones totales, lo que sugiere una actividad | | intensa desde esa fuente específica. | | | | Top 5 Códigos de Estado | | | | 1. 200 (OK): 1,435 peticiones. | | | | 2. 404 (Not Found): 272 peticiones. | | | | 3. 403 (Forbidden): 163 peticiones. | | | | 4. 302 (Found/Redirect): 65 peticiones. | | | | 5. 304 (Not Modified): 22 peticiones. | | | | Top 5 Direcciones IP | | | | 1. 172.21.0.1: 1,024 peticiones. | | | | 2. 119.241.22.121: 249 peticiones. | | | | 3. 168.22.54.119: 168 peticiones. | | | | 4. 116.23.212.69: 141 peticiones. | | | | 5. 156.32.113.25: 71 peticiones. | +========================================================+
Contexto
Uno de nuestros sitios de WordPress ha sido comprometido, pero aún desconocemos cómo.
La hipótesis principal es que un plugin instalado era vulnerable a una ejecución remota de código que le dio al atacante acceso al sistema operativo del servidor.
Para “separar el grano de la paja”, lo primero es entender qué estamos buscando. En WordPress, los ataques suelen seguir este orden:
-
Reconocimiento: Buscan plugins vulnerables.
-
Autenticación: Intentan entrar al /wp-admin.
-
Explotación: Suben una webshell o modifican un plugin/tema.
Visión General (Estadísticas Rápidas)
Antes de leer líneas individuales, necesitamos saber quién es el más “ruidoso”.
En este log, tenemos una IP que destaca sobre las demás.
Hay que usar la terminal para identificar cuántas IPs únicas hay y cuántas peticiones ha hecho cada una. El comando que ya conoces es perfecto
cut -d’ ’ -f1 “Log Analysis — Compromised WordPress.log” | sort | uniq -c | sort -nr
{width=“6.267716535433071in”
height=“3.6666666666666665in”}
Identificar el panel de administración
Una de las preguntas del reto pide la URI del panel de inicio de sesión al que el atacante accedió.
Normalmente, en WordPress es wp-login.php o wp-admin, pero a veces los administradores usan plugins para cambiar esta URL por seguridad
Busca peticiones de la IP más sospechosa que tengan que ver con “login” o “admin”.
Busca una petición que contenga un Token. Los tokens suelen aparecer en la URL después de un signo de interrogación (ej. ?token=123…).
¿Cómo descartar la “paja”?
En un log de WordPress verás miles de peticiones a:
-
.css, .js, .png, .jpg (Esto es carga normal de la web). DESCÁRTALO.
-
Peticiones GET que devuelven 200 OK a páginas de blog. DESCÁRTALO.
Céntrarse
-
Peticiones POST: Representan intentos de inicio de sesión, envío de formularios o subida de archivos.
-
Peticiones a la carpeta /wp-content/plugins/: Aquí es donde suelen ocurrir las vulnerabilidades de RCE (Remote Code Execution).
Ejecuta este filtro para ver solo lo que “escribe” o “ejecuta” la IP sospechosa y dime qué encuentras:
grep “POST” “Log Analysis — Compromised WordPress.log” | awk ‘{print $1, $7, $9}’
-
¿Hay alguna URL de login que no sea la estándar de WordPress?
-
¿Hay algún parámetro largo y raro (el token) en alguna de esas URLs?
Presentación del desafío
-
Identifique la URI del panel de inicio de sesión de administrador al que el atacante obtuvo acceso (incluye el token)
-
¿Puedes identificar dos herramientas que utilizó el atacante?
-
El atacante intentó explotar una vulnerabilidad en ‘Contact Form 7’. ¿A qué CVE era vulnerable el plugin? (¡Investiga!)
-
¿Qué plugin se utilizó para obtener acceso?
-
¿Cuál es el nombre del archivo de shell web PHP?
-
¿Cuál fue el código de respuesta HTTP proporcionado al acceder a la consola web por última vez?