Una intrusión rara vez empieza en WordPress. Antes suelen aparecer rastros en el servidor: accesos anómalos, errores repetidos, picos de autenticación fallida o bloqueos del WAF. Si esos indicios pasan desapercibidos, el impacto se amplía y la investigación se vuelve más difícil.
La monitorización de logs y análisis forense en WordPress consiste en centralizar y revisar registros del sitio, servidor, base de datos y firewall para detectar patrones anómalos, confirmar si hubo un incidente y preservar evidencias. Bien aplicada, permite reaccionar antes, acotar el impacto y documentar qué ocurrió con precisión.
Qué revisar primero si sospechas un incidente
Empieza por los registros de acceso, autenticación, errores y bloqueo del WAF. Si el sitio ya muestra síntomas, este paso tarda entre 10 y 20 minutos cuando los logs están a mano y centralizados. La clave es congelar la evidencia antes de tocar plugins, limpiar archivos o reiniciar servicios.
Qué logs mirar en los primeros 15 minutos
Revisa primero estos puntos, en este orden:
- Logs de acceso del servidor web: muestran qué IP pidió qué URL, a qué hora y con qué código de respuesta.
- Logs de autenticación: registran intentos de inicio de sesión, fallos y accesos con privilegios altos.
- Logs del WAF o firewall: enseñan qué peticiones se bloquearon y por qué regla.
- Logs de errores de WordPress: ayudan a ver cambios extraños, avisos de PHP y fallos al cargar funciones.
- Logs de base de datos: sirven para detectar consultas raras, cambios de usuarios o tablas tocadas fuera de lo normal.
La intrusión suele dejar huella antes en el servidor que en el panel de WordPress. Un caso habitual: el atacante prueba muchas contraseñas, no entra al panel, pero deja un pico de errores 403 y 404 en el servidor.
Lo que omiten la mayoría de guías sobre este punto es la secuencia temporal. Un solo evento puede no significar nada. Tres eventos seguidos en dos minutos ya cuentan otra historia.
La primera foto útil sale de la hora exacta del primer evento raro. Sin esa marca temporal, luego cuesta unir accesos, cambios y bloqueos.
Qué no borrar antes de analizar
No borres nada antes de copiar los registros. Tampoco reinicies servicios para "ver si se arregla". Ese gesto borra contexto y suele romper la cadena temporal.
Haz una copia de estos elementos antes de tocar el sitio:
- logs de Apache o Nginx
- logs de PHP-FPM si existen
- logs de WordPress o del plugin de seguridad
- exportación del WAF o firewall
- listado de usuarios con rol alto
- copia de archivos modificados en las últimas 24 a 72 horas
Este paso tarda entre 15 y 30 minutos si el acceso al hosting es claro. Si el panel está limitado, puede llevar más. Lo que suele bloquear a muchos equipos es querer "limpiar" primero. Esa prisa deja el caso cojo.
Qué logs te dan la foto real del ataque
La foto completa sale de unir varias fuentes, no de una sola. WordPress por sí solo enseña una parte del problema. El servidor, la base de datos y el firewall completan lo que falta.
La evidencia visual de esa diferencia se aprecia muy bien cuando un acceso normal queda rodeado de bloqueos, intentos fallidos y cambios de rol en pocos minutos.
Logs de WordPress que sí aportan señales
Empieza por los registros que muestran actividad dentro del propio sitio:
- Altas y bajas de usuarios: crean una pista clara cuando aparece un admin nuevo.
- Cambios de rol: un editor que pasa a administrador sin motivo es una señal seria.
- Inicio y cierre de sesión: ayudan a ver horarios extraños o accesos desde IPs nuevas.
- Ediciones de entradas, plugins o ajustes: muestran cambios que pueden abrir una puerta al atacante.
El error más frecuente en este punto es confiar solo en el plugin de seguridad. Ese plugin ayuda, pero no ve todo. Si un atacante usa credenciales robadas por SSH, FTP o el panel del hosting, la pista puede estar fuera de WordPress.
La mayoría de guías dicen mirar el panel. Lo que no mencionan es que el ataque real suele verse en los bordes: autenticación, red y archivos.
Logs del servidor y la base de datos
Revisa el servidor web para detectar patrones anómalos:
- muchas peticiones a
/wp-login.php
- accesos repetidos a
/xmlrpc.php
- picos de 404 hacia rutas raras
- subidas a
/wp-content/uploads/ con nombres extraños
- errores 500 o 502 tras cambios de archivo
En base de datos, busca consultas fuera de horario, cambios en wp_users, wp_usermeta y tablas de opciones. También conviene vigilar insertos masivos en entradas o comentarios, porque a veces el malware se oculta ahí.
Un cambio en `wp_usermeta` suele pesar más que veinte avisos genéricos del navegador. Ese patrón aparece mucho en accesos con escalada de privilegios.
| Fuente |
Qué revela |
Señal sospechosa |
Tiempo útil |
| WordPress |
Usuarios, roles, cambios internos |
Admin nuevo o rol elevado |
10-15 min |
| Servidor web |
Rutas, IPs, códigos HTTP |
Picos de 404, 403 o POST raros |
15-20 min |
| Base de datos |
Cambios en tablas clave |
Inserciones masivas o cambios en usuarios |
20-30 min |
| WAF o firewall |
Bloqueos y reglas activadas |
Ataques repetidos desde la misma IP |
10-15 min |
Un análisis útil empieza por consultas y patrones concretos, no por una revisión genérica. En los logs de acceso busca secuencias de peticiones a /wp-login.php, /xmlrpc.php y rutas inexistentes que generen errores 403 y errores 404 en ráfaga. En los logs de autenticación, fíjate en cinco o más fallos seguidos sobre la misma cuenta, cambios de IP en minutos o accesos fuera de horario. En el servidor web y en PHP-FPM, un pico de procesos, errores repetidos o respuestas 500 tras una subida de archivos suele indicar actividad sospechosa.
En la base de datos, las consultas a wp_users o wp_usermeta fuera de ventana normal ayudan a detectar escaladas de privilegios antes de que el daño sea visible en WordPress.
Cómo detectar intrusiones sin buscar solo malware conocido
La detección útil no empieza por una firma de malware. Empieza por comportamiento raro. Eso funciona mejor porque muchos ataques cambian la forma del archivo, pero repiten la misma secuencia de acciones.
La clave es mirar patrones. Un salto de privilegios, un pico de peticiones o una subida de archivos fuera de horario dicen más que una cadena aislada.
Picos de 404 y rutas raras
Los picos de 404 muestran intentos de localizar rutas ocultas o paneles expuestos. Si aparecen muchas peticiones a /wp-admin/, /xmlrpc.php, /phpmyadmin/ o rutas inventadas, merece una revisión más seria.
Busca esto en una ventana corta, de 5 a 15 minutos:
- muchas URLs fallidas desde la misma IP
- varios países o rangos IP distintos en poco tiempo
- secuencias de 404 seguidas de un 200
- peticiones a archivos que no deberían existir
Esto funciona bien en teoría, pero en la práctica el patrón temporal manda. Diez errores repartidos en un día suelen ser ruido. Diez errores en dos minutos pintan otra cosa.
Cambios de usuario y privilegios
Un cambio de usuario suele ser más grave que una página rota. Si alguien crea un admin nuevo, cambia el correo de recuperación o eleva un rol, el caso ya va tarde.
Revisa estos puntos:
- creación de usuarios administradores
- cambios en el correo del perfil
- restablecimientos de contraseña no solicitados
- inicios de sesión desde IPs nunca vistas
- saltos de rol de editor a administrador
Un ejemplo concreto: un comercio electrónico mostró varios fallos de acceso durante la noche y, después, un admin creado con correo externo. El problema no estaba en el tema ni en un plugin. Estaba en una credencial reutilizada.
Más de un incidente serio empieza con una contraseña válida, no con un archivo infectado. Por eso los eventos de autenticación pesan tanto.
Peticiones POST y carga de archivos
Las peticiones POST envían datos al servidor. Cuando aparecen en masa hacia formularios, endpoints raros o subidas de archivos, pueden señalar abuso o inyección.
Revisa si ves:
- cargas de archivos con extensiones extrañas
- formularios enviados muchas veces seguidas
- peticiones POST a rutas que no tienen sentido comercial
- archivos recién creados en carpetas de subida
Los datos del CERT y de organismos como INCIBE y ENISA insisten en una idea simple: detectar pronto reduce el impacto. INCIBE publica guías y avisos útiles para España, y ENISA mantiene referencias claras sobre respuesta a incidentes y riesgos actuales.
La combinación de POST anómalos y archivos nuevos en uploads suele aparecer antes que el malware visible. Si se detecta tarde, el atacante ya ha ganado tiempo.
Cómo montar alertas y correlación con SIEM o WAF
Centralizar logs sirve para detectar antes y para cruzar señales que por separado parecen pequeñas. Un SIEM o un stack de logs no solo guarda información. También la ordena, la compara y dispara alertas cuando se repite un patrón.
Cuándo usar SIEM y cuándo
Un stack ligero basta si el sitio es pequeño, tiene pocos accesos y el equipo revisa alertas cada día. Un SIEM merece la pena cuando hay varias sedes, mucho tráfico, requisitos de auditoría o respuesta rápida.
La diferencia práctica es esta: un stack simple te enseña eventos. Un SIEM te avisa cuando varios eventos forman una historia.
| Opción |
Coste de entrada |
Alertas |
Correlación |
Cuándo encaja |
| Graylog |
Medio |
Sí |
Media |
Equipos pequeños con necesidad real de alertas |
| Elastic Stack |
Medio-alto |
Sí |
Alta |
Entornos con muchos eventos y necesidad de buscar rápido |
| Splunk |
Alto |
Sí |
Muy alta |
Empresas con auditoría, varios sistemas y equipo de seguridad |
Qué reglas dan alertas útiles de verdad
Las alertas buenas no son las que más ruido hacen. Son las que enseñan una acción rara con contexto.
Empieza con estas reglas:
- más de 10 fallos de login en 5 minutos
- creación de admin nuevo
- cambio de rol a administrador
- subida de archivo PHP en carpetas de medios
- 50 o más 404 desde la misma IP
- bloqueos repetidos del WAF sobre la misma ruta
Los equipos que afinan menos de 8 reglas útiles suelen revisar más y descubrir menos. Es una cifra práctica, no mágica. Más reglas sin criterio acaban agotando al equipo.
OWASP recomienda vigilar autenticación, control de acceso y entradas anómalas como parte del control continuo de seguridad.
El mejor aviso no dice solo "fallo de login". Dice quién, desde dónde, contra qué cuenta y cuántas veces.
Qué herramientas elegir según tu nivel y presupuesto
La herramienta correcta depende del volumen, del presupuesto y del tiempo que puede dedicar el equipo. Si solo almacena logs, no resuelve el problema completo. Si centraliza, alerta y permite buscar rápido, ya aporta valor real.
Matriz rápida
| Nivel |
Herramientas típicas |
Qué resuelve |
Límite habitual |
| Sencillo |
Logs del hosting, plugin de actividad, alertas por correo |
Visión básica y reacción temprana |
Poca correlación y poca retención |
| Medio |
Graylog, Elastic Stack, WAF con registro |
Alertas, búsquedas y cruce de eventos |
Requiere ajuste y revisión periódica |
| Enterprise |
Splunk, SIEM corporativo, integración con EDR y WAF |
Correlación avanzada y cumplimiento |
Coste alto y gestión más compleja |
Qué aporta cada enfoque a seguridad web
Un plugin de actividad ayuda a ver quién hizo qué dentro de WordPress. Un WAF ayuda a frenar ataques antes de que entren. Un SIEM une ambas capas y añade contexto.
Para una tienda online, el orden lógico suele ser este: WAF, logs del servidor, actividad de WordPress y centralización. Ese orden reduce el tiempo de diagnóstico y evita mirar solo la punta del iceberg.
Los entornos con WooCommerce suelen necesitar más control sobre usuarios, pedidos y cambios de configuración. Ahí la correlación vale más que una sola alerta suelta.
Cómo conservar evidencias sin romper la cadena de custodia
Si el caso puede acabar en auditoría o en una investigación interna, la evidencia debe conservarse con integridad. Eso significa copiar, registrar quién accede y evitar cambios innecesarios. Sin eso, el material pierde valor.
La retención mínima razonable para un sitio con exposición real suele moverse entre 30 y 90 días. Si hay alto tráfico, campañas o sospecha de incidente, 180 días da más margen. Ese rango no es capricho. Ayuda a cruzar una intrusión lenta con su origen.
Qué retención mínima conviene guardar
Guarda al menos esto:
- logs de acceso del servidor durante 90 días
- logs de autenticación durante 90 días
- eventos del WAF durante 90 días
- copias de errores y actividad de WordPress durante 30 a 90 días
- registros de cambios administrativos durante 180 días si hay auditoría
La AEPD y el marco del RGPD no piden una cifra única para todos los casos, pero sí control, finalidad y conservación ajustada. AEPD publica guías útiles sobre tratamiento y seguridad, y CCN-CERT ofrece referencias prácticas para entornos con requisitos altos en España.
Cómo documentar accesos y cambios
Registra cada acción sobre la evidencia como si fuera una cadena corta de entrega. Eso incluye quién la copia, cuándo, desde dónde y con qué herramienta.
Usa esta ficha mínima:
| Campo |
Valor a guardar |
| Fecha y hora |
Momento exacto de la extracción |
| Responsable |
Nombre o identificador interno |
| Origen |
Servidor, WAF, WordPress, base de datos |
| Método |
Copia comprimida, exportación, captura |
| Hash |
SHA-256 del archivo exportado |
| Observaciones |
Cambios, faltas o incidencias |
El hash sirve como huella digital. Si el archivo cambia, la huella cambia. Es como precintar una caja y comprobar luego si sigue intacta.
Cómo evitar sobrescritura y rotación
Configura rotación con margen y exportación fuera del servidor. Si los logs rotan cada día y el incidente se detecta tarde, desaparecen justo los datos que más interesan.
Los errores típicos aquí son muy humanos: dejar el disco corto, no ampliar retención y no exportar a un repositorio seguro. Eso pasa mucho en hosting compartido y también en VPS mal mantenidos.
Si el almacenamiento está al límite, la rotación borra antes de tiempo. Ese fallo convierte una sospecha en un agujero de información.
La preservación de evidencias no termina con copiar los ficheros, sino con mantener la trazabilidad de cada paso. Lo ideal es exportar los logs del servidor, del WAF, del firewall y de la base de datos a un repositorio independiente, generar una huella SHA-256 y registrar quién accedió, cuándo y desde qué sistema. Si el incidente puede escalar, conviene trabajar sobre copias y no sobre los originales, evitando editar el sitio comprometido hasta completar la extracción.
En una investigación real, conservar también la hora exacta del primer evento, la IP origen y el estado de los servicios ayuda a reconstruir la cronología con mayor precisión en el análisis forense informático.
La retención debe adaptarse al riesgo y a la criticidad del entorno. En una instalación de seguridad en WordPress con tráfico moderado, suele ser razonable guardar logs de acceso, logs de autenticación y eventos del WAF al menos 90 días, mientras que los cambios administrativos y los logs de servidor web pueden conservarse 180 días si hay auditoría o comercio electrónico. En entornos con base de datos sensible, también conviene guardar registros de cambios en tablas clave y una política clara de rotación para no perder pruebas antes de tiempo.
Esta gestión de retención es especialmente útil cuando hay que correlacionar una incidencia de hace semanas con una oleada posterior de intentos de acceso o con cambios de rol que no se detectaron al momento.
Qué hacer después: limpieza, hardening y prevención continua
Después del análisis, toca cerrar la brecha y dejar el sitio más difícil de tocar. Si no haces esta parte, el incidente se repite. La respuesta útil no acaba en encontrar al intruso.
Qué revisar antes de restaurar copias
Antes de restaurar una copia, comprueba tres cosas:
- que la copia sea anterior al incidente
- que no incluya archivos inyectados o usuarios extraños
- que la contraseña y los accesos ya estén cambiados
Un sitio limpio pero con las mismas credenciales sigue siendo una puerta abierta. Eso se ve cada semana en casos de recuperación rápida que vuelven a caer al poco tiempo.
Qué controles alinean WordPress con ISO/IEC 27001
Los marcos ISO/IEC 27001, ENS y NIS2 empujan en la misma dirección: controlar accesos, registrar eventos, responder con método y revisar después.
Aplica estos controles:
- MFA para cuentas administrativas
- contraseñas únicas y largas
- permisos mínimos por rol
- WAF activo con registros guardados
- copias externas y probadas
- revisiones periódicas de plugins y temas
- alertas sobre cambios de archivos y usuarios
La prevención continua funciona mejor cuando alguien la revisa cada semana. Sin revisión, el sistema solo acumula logs y no mejora la seguridad.
Este método no es el mejor encaje si el sitio solo necesita mantenimiento básico sin exposición real, no tiene historial de incidentes y no debe pasar auditorías. En ese caso, basta con copias de seguridad, actualizaciones y un control de accesos sencillo. Si el objetivo es solo instalar una herramienta suelta, primero hace falta ordenar el proceso completo.
Preguntas frecuentes sobre monitorización y análisis forense
¿Cómo puedo revisar los logs de WordPress?
La forma más directa es entrar en el hosting y buscar actividad, errores y acceso. Primero revisa el panel del servidor, luego los logs del plugin de seguridad si existe, y después los registros de Apache, Nginx o PHP. Si el sitio usa WooCommerce o varias cuentas admin, conviene guardar una copia antes de tocar nada. Así el análisis forense digital conserva contexto útil.
¿Qué software se utiliza para el análisis forense?
Los más usados combinan búsqueda, correlación y preservación. Elastic Stack, Graylog y Splunk son opciones conocidas para centralizar logs; Wireshark y herramientas de hash ayudan en la parte de evidencia; y plugins de actividad en WordPress aportan contexto interno. La elección depende del volumen, del presupuesto y del tiempo de revisión. Un entorno pequeño no necesita la misma carga que una tienda grande.
¿Cómo puedo escanear mi sitio de WordPress para detectar problemas?
Conviene usar varias capas, no una sola. Un escáner de archivos revisa firmas, pero también hace falta mirar cambios de permisos, archivos nuevos en uploads, usuarios sospechosos y picos de tráfico raros. Si el malware cambia de nombre o se oculta en una base de datos, el escaneo por firma puede no verlo. La monitorización de logs ayuda justo en ese hueco.
¿Cuánto tiempo debo guardar los logs de seguridad?
Lo razonable suele ir de 30 a 90 días, y en casos con auditoría o riesgo alto puede subir a 180 días. El plazo correcto depende del negocio, del volumen y de la posible necesidad legal. Si un incidente se detecta tarde, una retención corta deja la investigación ciega. Por eso conviene guardar acceso, autenticación y WAF durante más tiempo que los errores simples.
¿Qué señales indican una escalada de privilegios?
Una escalada de privilegios aparece cuando una cuenta normal pasa a admin o cuando se crean accesos nuevos sin motivo claro. También se ve en cambios de correo, restablecimientos repetidos y ediciones administrativas fuera de horario. En logs, ese patrón suele ir unido a varios fallos de acceso previos. La secuencia vale más que un evento aislado.
¿Sirve un plugin de seguridad para hacer análisis?
Sirve como parte del cuadro, pero no como única fuente. Un plugin enseña actividad dentro de WordPress, pero no ve todo lo que pasa en servidor, base de datos o WAF. Si el incidente entra por otra vía, la historia queda incompleta. Lo correcto es combinar el plugin con logs de red, autenticación y cambios de archivos.
¿Qué hacer si los logs ya se han perdido?
Hay que reconstruir con lo que quede: copias de seguridad, registros del hosting, alertas por correo, historial del WAF y cambios en archivos o usuarios. También conviene guardar una cronología de lo ocurrido desde el primer síntoma. Si falta evidencia crítica, el análisis pierde fuerza. Aun así, suele quedar suficiente para acotar el alcance y decidir el siguiente paso.
Qué hacer ahora para no perder la próxima pista
La respuesta útil es montar una visión completa, no revisar solo WordPress. Primero centraliza logs de acceso, autenticación, base de datos y WAF. Después define alertas simples, guarda retención suficiente y registra cada extracción con fecha, origen y hash. Cuando llegue el siguiente aviso, el sitio no empezará de cero.
