Cómo auditar logs de WordPress para encontrar malware
Cuando analizo un sitio WordPress comprometido, lo primero que hago es revisar los logs. Los archivos de registro son tu mejor aliado para detectar qué ha pasado, cuándo entró el atacante y qué acciones realizó. En mi experiencia, muchos administradores ignoran completamente estos archivos, lo que les impide identificar infecciones hasta que es demasiado tarde.
Los logs de WordPress no están habilitados por defecto, y esa es precisamente la razón por la que tantos sitios caen sin que nadie se dé cuenta. Aquí te enseño cómo configurarlos, dónde encontrarlos y cómo interpretarlos para detectar actividad maliciosa antes de que cause daños irreversibles.
¿Por qué los logs son críticos en la seguridad de WordPress?
Los logs son el registro de eventos de tu sitio. Sin ellos, es como tener una tienda sin cámaras de vigilancia: cualquiera puede entrar, robar y marcharse sin dejar rastro. Un atacante que inyecta un backdoor, modifica archivos o ejecuta consultas maliciosas deja huellas en los logs si están configurados correctamente.
Cuando no auditas logs regularmente, los malwares pueden vivir en tu servidor durante meses sin que lo sepas. He visto sitios de clientes con cryptominers ejecutándose 24/7, robando recursos, mientras el propietario no tenía ni idea. Los logs habrían mostrado exactamente cuándo se instaló el script malicioso y desde dónde.
Además, los logs te permiten:
- Identificar intentos de acceso no autorizados al wp-admin
- Detectar inyecciones SQL y XSS en tiempo real
- Encontrar plugins o temas modificados maliciosamente
- Rastrear cambios no autorizados en la base de datos
- Cumplir requisitos legales de auditoría (RGPD, AEPD)
- Análisis forense después de una brecba de seguridad
Habilitando debug y logging en WordPress
Lo primero es activar los logs. WordPress tiene un sistema nativo de debug que, sorprendentemente, está deshabilitado por defecto. Accede a tu archivo wp-config.php (en la raíz de tu instalación) y busca esta sección:
define(‘WP_DEBUG’, false);
Cámbialo por:
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
El parámetro WP_DEBUG_DISPLAY en false es importante: hace que los errores se registren en un archivo en lugar de mostrarse públicamente en tu sitio (lo que sería un riesgo de seguridad).
Una vez guardado, WordPress creará automáticamente un archivo de log en /wp-content/debug.log. Este archivo contendrá todos los errores de PHP, advertencias y mensajes de depuración de plugins y temas.
Los diferentes tipos de logs en WordPress
WordPress genera varios tipos de logs, y cada uno cuenta una historia diferente:
1. Debug.log (PHP errors)
Este es el más obvio. Contiene errores de PHP, advertencias y notificaciones. Si un plugin malicioso intenta ejecutar código, aquí aparecerán sus errores. Cuando reviso un sitio comprometido, busco patrones como:
- Llamadas a funciones no definidas (típico de backdoors que intentan ejecutar comandos del sistema)
- Errores de permisos en archivos (alguien intentó escribir un webshell)
- Warnings de conexión a bases de datos externas (comunicación con servidores de comando y control)
2. Logs del servidor (Apache/Nginx)
Estos están a nivel de servidor, no de WordPress. Contienen:
- Access logs: Cada solicitud HTTP (GET, POST) con IP, timestamp, navegador, código de respuesta
- Error logs: Errores del servidor, intentos de acceso a archivos inexistentes, errores de permiso
En Apache, busca en /var/log/apache2/access.log o /var/log/apache2/error.log. En Nginx, en /var/log/nginx/access.log.
3. Logs de la base de datos MySQL
Si habilitaste el query logging en MySQL, verás cada sentencia SQL ejecutada. Esto es especialmente útil para detectar inyecciones SQL. Para habilitarlo en MySQL, añade esto a /etc/mysql/mysql.cnf:
general_log = 1
general_log_file = /var/log/mysql/mysql.log
Ten cuidado: el query logging impacta en el rendimiento. Úsalo solo durante auditorías, no en producción permanentemente.
4. Logs de plugins de seguridad
Si tienes Wordfence, Sucuri o similar instalados, generan sus propios logs. Estos son especialmente valiosos porque esos plugins ya filtran eventos sospechosos por ti. Wordfence CLI permite analizar logs desde la terminal:
wordfence-cli scanner scan –verbose
Dónde encontrar los logs de WordPress
El archivo debug.log está en /wp-content/debug.log (suponiendo que tu instalación de WordPress está en la raíz).
Lo puedes consultar vía:
- SFTP/FTP: Conecta a tu servidor y descarga el archivo directamente
- SSH: Usa comandos como tail -f /path/to/wp-content/debug.log para ver el final del archivo en tiempo real
- Panel de control: Si tienes cPanel, busca File Manager y navega a wp-content
- WP-CLI: wp eval ‘echo file_get_contents( WP_CONTENT_DIR . «/debug.log» );’
Para los logs del servidor (Apache/Nginx), necesitarás acceso SSH o a través de tu proveedor de hosting.
Señales de malware en los logs: qué buscar
Ya tienes los logs. Ahora vamos a lo importante: detectar el malware. Aquí están los patrones que yo busco siempre:
Intentos de ejecución de comandos del sistema
Los backdoors intentan ejecutar comandos como exec(), system(), shell_exec(), passthru(). Si ves errores como:
Fatal error: Call to undefined function exec()
Significa que alguien está intentando ejecutar comandos. Busca el archivo fuente en el mensaje de error.
Accesos a archivos sospechosos en access.log
En los logs de Apache/Nginx, busca patrones como:
- wp-admin/upload.php?param=… – Upload de archivos no autorizado
- wp-admin/admin-ajax.php?action=malicious_action – AJAX manipulation
- GET /wp-content/uploads/2024/01/shell.php – Acceso a webshell inyectado
- POST /index.php?id=1′ OR ‘1’=’1 – Inyección SQL clásica
También busca códigos de respuesta sospechosos: 403 (acceso denegado), 500 (error interno, a menudo por malware), 200 para archivos que no deberían estar ahí.
Cambios en la base de datos
Si tienes MySQL general log habilitado, busca:
- ALTER TABLE – Modificación de estructura de tablas
- INSERT INTO wp_posts desde IPs raras o a horas inusuales
- UPDATE wp_options SET option_value – Cambio de configuraciones críticas
- DROP TABLE – Eliminación destructiva (ransomware)
Modificaciones de archivos
Si tu hosting registra cambios de archivos, busca:
- Archivos PHP nuevos en /wp-content/uploads/ (zona típica para inyectar webshells)
- Cambios en wp-config.php o .htaccess en fechas sospechosas
- Plugins o temas con fechas de modificación reciente sin que los hayas actualizado
Herramientas para automatizar el análisis de logs
Analizar logs manualmente es tedioso. Estas herramientas lo hacen más fácil:
WP-CLI con grep
Si tienes WP-CLI instalado, puedes extraer información rápidamente:
tail -500 /path/to/wp-content/debug.log | grep «Fatal|Warning|Notice»
Esto te muestra los últimos 500 líneas del log, filtrando solo errores relevantes.
Wordfence CLI
Si tienes Wordfence (gratuito), la herramienta CLI es excelente:
wordfence-cli firewall view-live
Te muestra en tiempo real qué está intentando bloquear el firewall.
MalCare y Sucuri
Si usas estos plugins de seguridad premium, generan reportes visuales de los logs. Recomiendo especialmente MalCare por su interfaz de análisis forense.
Google Search Console y Google Analytics
No son logs técnicos, pero son señales. Si ves un aumento repentino de:
- Advertencias de malware en GSC
- Tráfico desde URLs raras
- Redirecciones no autorizadas
Eso significa que Google ha detectado algo. Ve a los logs del servidor para confirmarlo.
Análisis forense: paso a paso
Aquí está mi metodología cuando encuentro un sitio comprometido:
Paso 1: Recolecta todos los logs
Descarga los logs de al menos 30 días atrás (o más, si tienes espacio). El malware puede estar dormido y activarse después.
Paso 2: Identifica el timeline
Busca la primera aparición de actividad sospechosa. ¿Cuándo comenzó? ¿Hubo un cambio de plugin, una actualización, un pico de tráfico antes?
Paso 3: Traza la IP del atacante
En access.log, filtra por IPs que hayan accedido a wp-admin o uploads justo antes del evento. Algunos atacantes usan proxies, pero otros dejan rastros claros.
Paso 4: Analiza el payload
¿Qué archivos modificaron? ¿Qué parámetros enviaron en POST? Esto te dice qué tipo de malware instalaron.
Paso 5: Identifica el vector de entrada
¿Fue un plugin desactualizado? ¿Una contraseña débil de wp-admin? ¿Una vulnerabilidad de temas? Esto es crítico para evitar que vuelva a pasar.
Configuración defensiva: logs para el futuro
Una vez limpies el malware, implementa logging defensivo para detectar futuros ataques rápidamente:
- Habilita WP_DEBUG_LOG permanentemente
- Configura rotación de logs (con logrotate en Linux) para que no ocupen demasiado espacio
- Activa alertas en tu hosting si un archivo .php se crea en wp-content/uploads/
- Usa un plugin como Activity Log para registrar cambios en WordPress (qué usuario cambió qué, cuándo)
- Implementa reglas en .htaccess para bloquear acceso directo a archivos sospechosos
- Monitoriza los logs regularmente (mínimo semanal)
Si tu sitio es crítico, un Sistema de Detección de Intrusiones (IDS) como Fail2Ban puede bloquear automáticamente IPs que intenten ataques comunes:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
Errores comunes que cometen los administradores
En mi experiencia auditando cientos de sitios, estos son los errores que veo constantemente:
- No rotar los logs: El debug.log crece infinitamente si no lo limpias. Puedes usar un cron job: 0 0 * * * > /path/to/wp-content/debug.log
- Ignorar los warnings: «Un warning no es un error grave». Error. Los warnings son a menudo el primer signo de malware.
- No correlacionar logs: Mirar solo debug.log y no cruzarlo con access.log. Necesitas ver la imagen completa.
- Acceso inseguro a logs: Si dejas debug.log visible públicamente, los atacantes ven qué plugins tienes. Usa .htaccess: Deny from all
- No archivar logs antiguos: Después de 30-90 días, descarga los logs a almacenamiento seguro. Los atacantes a menudo los borran para cubrir sus huellas.
Protegiendo los propios logs
Un detalle importante: los atacantes intentan borrar logs para no dejar rastro. Protégelos:
- Hace que wp-content/debug.log no sea legible por el servidor web (permisos 600)
- Copia los logs regularmente a un almacenamiento remoto (S3, Google Cloud)
- Usa un servicio de log centralizado como ELK Stack o Splunk para empresas
Técnicamente, puedes configurar Syslog en WordPress para enviar logs directamente a un servidor syslog remoto, lejos del sitio comprometido:
define(‘WP_DEBUG_LOG’, ‘/dev/log’);
Esto envía los logs al demonio syslog en lugar de a un archivo local.
Integración con herramientas de monitoreo SIEM
Para sitios empresariales, recomiendo integrar WordPress con un SIEM (Security Information and Event Management). Esto centraliza todos los logs (WordPress, servidor, firewall, base de datos) en un único panel para análisis automático de amenazas.
Incluso sin SIEM, un simple script bash que revise los logs diariamente y te envíe un resumen es muy útil:
#!/bin/bash
LOG_FILE=»/var/www/html/wp-content/debug.log»
ERRORS=$(grep -i «fatal|error» «$LOG_FILE» | wc -l)
if [ $ERRORS -gt 10 ]; then
mail -s «Alerta: $ERRORS errores en WordPress» admin@tudominio.com < «$LOG_FILE»
fi
Conclusión: auditoría de logs como hábito de seguridad
Auditar logs regularmente no es complicado, pero es la diferencia entre detectar un malware en 24 horas o descubrirlo cuando ya ha robado datos de clientes. He visto el daño que causa la negligencia.
Mi recomendación es sencilla: habilita logging hoy, revisa los logs semanalmente, crea alertas automáticas y archiva logs históricos. Es como un sistema inmunológico para tu WordPress.
Si descubres actividad sospechosa en los logs y no sabes cómo proceder, o si necesitas una auditoría forense profesional, en ManuelFolgar.com disponemos de herramientas especializadas y experiencia en decenas de casos de compromiso. Contacta conmigo para una auditoría de seguridad completa de tu sitio WordPress.
Referencias técnicas
Para más información sobre logging en WordPress y seguridad web: