IoC en los logs: qué buscar en `access.log` tras un ataque

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Analizar el access log tras un ataque web es la forma más directa de reconstruir qué pasó, cuándo y por dónde entraron. Antes de restaurar nada, ese fichero (junto al error.log y el registro del WAF) contiene la línea temporal del incidente. Esta guía forma parte de nuestro recorrido sobre respuesta a incidentes DFIR cuando una web ha sido hackeada y se centra en los indicadores de compromiso (IoC) que dejan huella en los accesos HTTP.

La lógica es sencilla: un atacante necesita interactuar con tu servidor, y cada interacción deja una fila en el log. El reto no es la falta de datos, sino separar la señal del ruido de tráfico legítimo, bots de buscadores y escáneres oportunistas.

Analizar el access log tras un ataque web: patrones que delatan

Estos son los indicadores que revisamos primero en un peritaje. No todos implican compromiso por sí solos, pero su combinación en una ventana temporal estrecha suele marcar el vector de entrada.

Subida y uso de webshells

• Peticiones POST a ficheros PHP dentro de /wp-content/uploads/, /images/ o rutas donde no debería ejecutarse código.
• Respuestas 200 a scripts con nombres extraños o aleatorios (wp-x1.php, up.php, radio.php) que no forman parte del CMS.
• Un mismo fichero PHP recibido primero por POST (subida) y luego consultado repetidamente por GET desde la misma IP.

Fuerza bruta y abuso de autenticación

• Ráfagas de POST a wp-login.php o /administrator/ desde una o pocas IP, con muchos 200/302 seguidos.
• Uso intensivo de xmlrpc.php, habitual en ataques de amplificación y credential stuffing contra WordPress.

Inyecciones y recorrido de rutas

• Cadenas de path traversal (../../, ..%2f) apuntando a /etc/passwd o a ficheros de configuración.
• Patrones de SQLi en la query string (UNION SELECT, OR 1=1, information_schema).
• Payloads codificados en base64, eval(, system( o cmd= como parámetros GET/POST.

Reconocimiento y exfiltración

• User-Agent de herramientas conocidas de escaneo (sqlmap, nikto, wpscan) o cadenas vacías/manipuladas.
• Descargas anómalas de exportaciones de base de datos, ficheros .sql o .zip grandes hacia una IP externa.
• Volumen de peticiones muy por encima de la media desde un único origen en horario atípico.

Cómo trabajar el log sin perderte

Un enfoque metódico rinde más que leer miles de líneas a mano. Recomendamos:

• Acota la ventana con la fecha aproximada del primer síntoma y trabaja hacia atrás para localizar la primera intrusión.
• Correlaciona fuentes: el access.log te da la petición, el error.log confirma la ejecución y el registro del WAF/ModSecurity aporta la regla que saltó.
• Filtra por código de estado: los 200 a scripts desconocidos y los 500 repetidos son especialmente reveladores.
• Preserva antes de filtrar: copia el log original con su marca temporal. Las técnicas forenses de adquisición y su orden de volatilidad están recogidas en el NIST SP 800-86, referencia obligada para no invalidar la evidencia.

Herramientas como grep, awk o un analizador tipo GoAccess aceleran mucho el filtrado, pero el criterio para interpretar los patrones es lo que convierte una lista de líneas en un relato del ataque.

Del hallazgo a la decisión

Detectar IoC en los logs es solo la mitad del trabajo. Una webshell activa no tiene la misma urgencia que un escaneo fallido de hace un mes, y confundirlos hace perder tiempo crítico. Por eso conviene pasar del inventario de señales a un orden de prioridad claro: lo explicamos en del IoC a la respuesta: cómo priorizar las señales de un informe. Y cuando el análisis confirma persistencia, la vía más segura no es limpiar en caliente sino restaurar el WordPress desde cero.

El marco general de detección y análisis que seguimos está alineado con el NIST SP 800-61. Si el volumen de logs te supera o necesitas una lectura experta, en contacto te ayudamos a interpretar la evidencia.