Análisis forense de logs de acceso para investigar brechas de seguridad

El análisis forense de logs de acceso es una pieza clave para investigar brechas de seguridad en servidores web, aplicaciones y redes. En este artículo, desde la experiencia en hosting, servidores e infraestructura, describo un flujo práctico: recolección, preservación, análisis y correlación de evidencia en logs de acceso (Apache, Nginx, proxies y CDN). Incluye ejemplos reales, comandos y buenas prácticas para obtener conclusiones válidas y reproducibles.

Por qué los logs de acceso son esenciales en una investigación

Los logs de acceso registran interacciones entre clientes y servicios: IP origen, timestamp, recurso solicitado, código HTTP, user-agent y, en muchos casos, tiempo de respuesta y referer. Estos datos permiten:

• Reconstruir la cadena de eventos previos y posteriores a la brecha.
• Identificar direcciones IP maliciosas, patrones automatizados y vectores de explotación.
• Correlacionar actividad entre servidores y servicios (por ejemplo, web + API + proxy).

Preparación y preservación de evidencia

Antes de analizar en profundidad, es imprescindible preservar la integridad de los logs para mantener una cadena de custodia. Pasos recomendados:

• Crear copias forenses de los ficheros: usar hashing (sha256) y almacenar copias en un repositorio seguro y de solo lectura.
• Registrar metadatos: ruta original, propietario, fecha de creación de la copia, hash y persona que realizó la copia.
• Si el sistema sigue en producción, evitar sobrescribir logs. Girar los ficheros (logrotate) y recopilar los rotados antes de cualquier limpieza.

Comandos útiles:

cp /var/log/nginx/access.log /forensics/nginx_access_2026-06-01.log
sha256sum /forensics/nginx_access_2026-06-01.log > /forensics/hashes.txt

Formatos comunes y campos relevantes

Conocer el formato facilita el parsing:

• Apache (combined): %h %l %u %t «%r» %>s %b «%{Referer}i» «%{User-Agent}i»
• Nginx (default access_log combined): similar, configurable con «log_format»

Campos críticos para análisis forense:

• IP origen y puerto
• Timestamp y zona horaria
• Método HTTP y URI
• Código de respuesta y tamaño
• User-Agent y Referer

Proceso de análisis: pasos prácticos

1. Aislar ventanas temporales relevantes

Identifica el intervalo en el que ocurrió la brecha (por ejemplo, cuando se detectó tráfico anómalo o un cambio de archivos). Filtra logs por timestamp para reducir el ruido.

# Ejemplo con awk (formato: [01/Jun/2026:12:34:56 +0000])
awk -v d="01/Jun/2026:12" '$4 ~ d' access.log > slice.log

2. Buscar indicadores iniciales

Prioriza búsquedas por:

• Errores 500/403/404 en patrones inusuales
• Requests a endpoints sensibles (wp-login.php, xmlrpc.php, /admin, /api/…)
• Secuencias de URLs que contienen payloads (eval, base64,

# Buscar acceso a wp-login.php y múltiples intentos
grep "wp-login.php" slice.log | awk '{print $1}' | sort | uniq -c | sort -nr

3. Identificación de IPs y patrones automatizados

Detecta IPs con alta frecuencia de peticiones, patrones de user-agent sospechosos o comportamiento de fuerza bruta:

# IPs con más solicitudes en el intervalo
awk '{print $1}' slice.log | sort | uniq -c | sort -nr | head

Patrones de user-agent falsos o generados por herramientas automatizadas pueden indicar scanners o bots.

4. Correlación entre sistemas

Correlaciona entradas de logs web con registros de proxies, WAF, bases de datos y sistemas de autenticación. Esto ayuda a confirmar acciones (por ejemplo, una inyección seguida de un cambio en DB).

Utiliza timestamps normalizados (UTC) durante la correlación para evitar errores por zonas horarias.

Herramientas prácticas para análisis

Desde simples utilidades Unix hasta plataformas centralizadas:

• Comandos shell: grep, awk, sed, sort, uniq, cut, jq para JSON.
• Herramientas de línea de comandos: goaccess (estadísticas), mitmproxy para análisis de tráfico intermedio.
• Solucciones SIEM/ELK: Elasticsearch + Logstash + Kibana o alternativas gestionadas para búsquedas y visualizaciones a gran escala.

Ejemplo de parsing de log combinado a JSON con awk/jq para ingesta en SIEM:

# Línea ejemplo Apache combined
# 91.121.45.67 - - [01/Jun/2026:12:34:56 +0000] "GET /wp-login.php HTTP/1.1" 200 452 "-" "Mozilla/5.0"
# Script simple (conceptual) para convertir a CSV/JSON antes de ingestar

Indicadores de compromiso habituales y cómo detectarlos

Algunos IOCs frecuentes en logs de acceso:

• Exploración de directorios y archivos comunes (/wp-admin/, /backup/, .env)
• Altas tasas de 4xx/5xx desde la misma IP
• Requests con payloads inusuales: cadenas codificadas en base64, secuencias SQLi o comandos shell
• Solicitudes POST inusuales hacia endpoints que deberían ser GET

Comparar con escenarios documentados de MITRE ATT&CK ayuda a clasificar técnicas y tácticas usadas por el atacante (MITRE ATT&CK).

Ejemplo real (caso simplificado)

Supongamos: se detecta un archivo modificado en /var/www/html/index.php. Pasos mínimos:

• Determinar el momento del cambio (mtime) en el sistema de ficheros.
• Filtrar logs de acceso ±5 minutos alrededor del mtime.
• Buscar requests que escribieran o ejecutaran scripts (POST a endpoints de upload o requests con cadenas sospechosas).

Comando de ejemplo:

# obtener mtime
stat -c %y /var/www/html/index.php
# filtrar logs (simplificado)
awk -v t="01/Jun/2026:12:34" '$4 ~ t' /forensics/nginx_access_2026-06-01.log | grep -E "(POST|upload|php\?|base64)"

Si se detecta una IP responsable, se procede a bloquearla, consultar listas de reputación y revisar si existen peticiones previas asociadas.

Buenas prácticas posteriores al análisis

• Aplicar mitigaciones inmediatas: bloqueo de IPs maliciosas, actualización de software, restauración desde respaldos verificados.
• Documentar todo: hallazgos, comandos usados, hashes y decisiones tomadas. Esto es clave para auditoría y posibles acciones legales.
• Revisar y mejorar la recolección de logs: aumentar nivel de detalle, agregar logs de aplicación y de base de datos, y centralizar en un SIEM.

Para procedimientos formales de respuesta a incidentes y guías de actuación, consultar las recomendaciones del NIST (especialmente el SP 800-61) y recursos de OWASP sobre respuesta a incidentes: NIST SP 800-61 y OWASP.

Limitaciones y riesgos del análisis de logs

Los logs pueden ser incompletos o manipulados por el atacante si el acceso ha sido profundo. Por eso:

• No confíes únicamente en logs locales: extrae también datos de proxies, CDN y registros de red.
• Considera la posibilidad de que timestamps o registros hayan sido alterados; valida con hashes y con registros externos (por ejemplo, logs de balanceadores o proveedor de CDN).

Conclusión

El análisis forense de logs de acceso combina técnica, metodología y documentación. Siguiendo un flujo: preservar evidencia, filtrar ventanas temporales, identificar IOCs, correlacionar entre sistemas y documentar decisiones, se puede reconstruir una brecha y aplicar mitigaciones eficaces. Implementar logging centralizado, normalizar timestamps a UTC y mantener procedimientos de respuesta alineados con estándares como NIST reduce el tiempo de respuesta y mejora la trazabilidad de incidentes. Para investigaciones complejas, apoya el análisis con plataformas SIEM y consulta matrices de amenazas como MITRE ATT&CK para clasificar tácticas y adaptar contramedidas.