Cómo analizar logs de WordPress hackeado (2026)

En pocas palabras: Detectar un hackeo en WordPress requiere cruzar access.log, error_log de PHP y el log de actividad interno para ubicar IP, endpoint y hora exacta del ataque. Invicti (2024) documentó así el exploit CVE-2023-6961 en WP Meta SEO, que creó un usuario admin no autorizado vía XSS en el header Referer.

Analizar logs de WordPress hackeado significa revisar access.log, error_log de PHP y el log de actividad del sitio para ubicar la IP del atacante, el endpoint vulnerado y el momento exacto de la intrusión. Con unos pocos comandos de grep podés reconstruir el ataque completo en minutos, sin pagar un forense externo.

Pensá el log del servidor como una cámara de seguridad que grabó todo, pero en un idioma que hay que aprender a leer: cada línea es un visitante, con su IP, la URL que pidió, el código de respuesta que recibió y el segundo exacto en que tocó la puerta. Existen tres registros clave (access.log, error_log de PHP y el log de actividad interno de WordPress) y cada uno te muestra una capa distinta de lo que pasó. Mirar uno solo es como ver la mitad de una película.

¿Qué tipos de logs existen en un hosting WordPress y para qué sirve cada uno?

Vamos por orden. Un hosting WordPress genera básicamente cuatro registros útiles para investigar un hackeo: el access log del servidor, el error log de PHP, el log de actividad de WordPress y los logs de conexión SFTP o FTP. Cada uno documenta una capa distinta de lo que pasó, y ninguno te da la película completa por sí solo.

• Access log (Apache o Nginx): anota cada solicitud HTTP que llega al servidor: IP de origen, URL pedida, código de estado (200, 404, 500) y user-agent. Es el primer lugar donde aparece el patrón de ataque.
• Error log de PHP: guarda los errores fatales y warnings que dispara el código. Un webshell mal escrito suele romper algo, y ese «algo» queda anotado acá.
• Log de actividad de WordPress: si tenés algún plugin de auditoría activo, registra creación de usuarios, instalación de plugins y ediciones de archivos desde el propio panel.
• Log de FTP/SFTP: muestra quién subió o modificó archivos por fuera del panel de WordPress, algo típico cuando el atacante ya tiene credenciales robadas.

Ninguno de los cuatro alcanza solo. El truco está en cruzarlos: el access log te dice quién tocó la puerta, el error log te dice qué se rompió adentro, y el log de actividad te dice qué hizo esa persona una vez dentro del panel.

¿Dónde encontrar los archivos de log en tu hosting o panel de control?

En hosting compartido con cPanel, los logs suelen estar en Estadísticas > Logs de acceso sin procesar (Raw Access Logs), mientras que el error_log de PHP aparece dentro de la carpeta pública o del Administrador de archivos, según cómo lo configure cada proveedor. Lo explicamos a fondo en tener backups listos ante un ataque.

Si tenés acceso SSH, podés bajar el archivo directo con scp o mirarlo en vivo con tail -f access.log. Eso sí: no todos los planes de hosting compartido dan acceso SSH, y ahí la calidad del soporte técnico de tu proveedor marca la diferencia entre resolver esto en una hora o perder el día entero pidiendo capturas de pantalla por ticket de soporte.

Si tu hosting no expone logs de ningún tipo, pedilos directamente. Es información que te pertenece, y cualquier proveedor serio te la va a dar sin drama.

¿Qué patrones sospechosos buscar en el log de acceso (access.log)?

Para analizar logs de WordPress hackeado en el access.log hay que buscar cinco patrones: intentos repetidos de login a wp-login.php desde la misma IP, requests directos a wp-config.php, códigos 404 o 500 en cascada sobre rutas de plugins que no tenés instalados, IPs con geolocalización rara para tu audiencia y picos de tráfico fuera del horario habitual del sitio.

Según explica Google Search Central en su guía para webmasters con sitios hackeados, hay dos métodos comunes: la inserción de contenido oculto (enlaces de spam farmacéutico que solo ven los rastreadores) y el redireccionamiento selectivo de usuarios que llegan desde buscadores. Si entrás directo a tu sitio y anda bien, pero el mismo link desde Google te tira a una página rara, tenés ese segundo caso. Google también recomienda revisar los archivos de configuración como el .htaccess de Apache buscando reglas que no agregaste vos, y rastrear en el código fuente términos como «eval», «decode» y «escape», típicos de JavaScript malicioso ofuscado.

Un ejemplo concreto: en el análisis publicado por Invicti sobre un ataque vía CVE-2023-6961 en el plugin WP Meta SEO, el equipo detectó que la IP del propio administrador (80.97.26.93) generaba un POST a /wp-admin/user-new.php seguido de un GET a /wp-admin/users.php?update=add&id=2, con el Referer apuntando a la página metaseo_broken_link del plugin. Esa secuencia probaba que el admin, sin saberlo, había ejecutado el payload XSS que le creó un usuario nuevo.

Fijate que este caso sirve como plantilla para cualquier plugin, no solo para WP Meta SEO: el patrón es siempre el mismo (IP legítima del admin + Referer con código inyectado + creación o modificación de usuario inmediatamente después). Regla práctica que te podés llevar de acá: si en el access.log ves un POST a user-new.php que vos no hiciste, no pierdas tiempo tratando de entender primero cuál fue el vector exacto. Cambiá contraseñas ya, y recién después investigás con calma qué plugin lo permitió.

¿Cómo se sabe que dos IPs distintas son el mismo atacante? Por el user-agent idéntico y la actividad secuencial. Si dos IPs usan exactamente el mismo navegador y una arranca justo donde termina la otra, es la misma persona cambiando de conexión.

¿Cómo detectar malware o webshells revisando el error_log de PHP?

El error_log de PHP delata un webshell cuando aparecen errores fatales repetidos en archivos que vos no subiste, generalmente con nombres aleatorios dentro de /wp-content/uploads/ o en plugins «must-use» que nunca instalaste. Cubrimos ese tema en detalle en activar la autenticación en dos pasos.

• Archivos PHP en /wp-content/uploads/: esa carpeta es para imágenes y documentos, no para código. Si el error_log marca un archivo .php ahí adentro, es sospechoso.
• Plugins «must-use» desconocidos: según WPBeginner, los mu-plugins cargan automático y no aparecen en la lista normal de plugins, así que son un escondite cómodo para el atacante.
• Funciones peligrosas: eval() o base64_decode() ejecutándose en archivos que no reconocés son casi siempre webshell.
• Archivos que imitan el core: un wp-load.php duplicado o un wp-something.php en una carpeta donde no debería estar.

Esa «actualización automática» que instaló un plugin de File Manager nunca la pediste vos. Si aparece un plugin utilitario que no reconocés, ese es el primer sospechoso, no el último recurso.

¿Cómo usar grep y awk para filtrar logs y encontrar actividad maliciosa?

grep y awk permiten filtrar miles de líneas de log en segundos: con un solo comando podés contar cuántas veces una IP intentó loguearse, aislar todos los requests a xmlrpc.php o cortar el log al rango horario exacto del ataque.

Subís el access.log a tu servidor o lo bajás a tu máquina, corrés el primer grep para ver los intentos de login, cruzás esa IP contra el error_log, después revisás si esa misma IP tocó algún archivo por FTP, y tenés una línea de tiempo completa del ataque sin haber pagado un centavo en herramientas.

• Contar intentos de login por IP: grep «wp-login.php» access.log | awk ‘{print $1}’ | sort | uniq -c | sort -nr
• Aislar ataques a XML-RPC: grep «xmlrpc.php» access.log | wc -l
• Filtrar por rango horario: awk ‘/08:00:00/,/09:00:00/’ access.log
• Buscar código malicioso en el error log: grep -iE «eval\(|base64_decode» error_log

Ejemplo hipotético: supongamos que corrés el primer comando y te devuelve algo así:

47 203.0.113.15
12 198.51.100.22
3 192.0.2.8

Ese 47 al lado de una sola IP ya te dice bastante: no es un visitante que se equivocó de contraseña un par de veces, es fuerza bruta automatizada. Las otras dos IPs del ejemplo, con 12 y 3 intentos, probablemente sean ruido de bots genéricos que escanean todo internet, no un ataque dirigido a tu sitio en particular. Con esa IP sospechosa (203.0.113.15 en el ejemplo) ya podés ir al error_log a buscar si logró entrar (un 200 seguido de redirección) o si quedó afuera.

Ojo: estos comandos suponen que tenés acceso SSH o al menos una copia local del archivo. Si tu panel solo te deja descargar el log comprimido, primero descomprimilo con gunzip. Más contexto en reforzar las cabeceras HTTP de seguridad.

¿Qué registra el log de actividad de WordPress y cómo complementa al log del servidor?

El log de actividad de WordPress, cuando tenés un plugin de auditoría instalado, registra qué usuario hizo qué adentro del panel: login, cambios de contraseña, instalación de plugins, edición de archivos. El log del servidor te dice desde dónde entraron; el de actividad te dice qué tocaron una vez adentro.

En el caso documentado por Bogdan Calin en el blog de Invicti (2024), cruzar el access.log con el patrón de comportamiento del admin permitió reconstruir toda la cadena: el atacante inyectó el payload XSS en el header Referer, el administrador real visitó la página vulnerable del plugin WP Meta SEO, el navegador del admin ejecutó el script sin que nadie lo tocara a mano, y ese mismo script creó un usuario administrador nuevo con id=2. Nada de esto se ve mirando un solo log por separado.

Si no usás ningún plugin de auditoría, no hay drama: reconstruís lo mismo cruzando el access.log con el error_log y con la fecha de modificación de los archivos. Es más manual, pero llegás al mismo lugar.

¿Conviene limpiarlo vos mismo o llamar a un experto?

No hay una respuesta única para todos los casos, pero sí un par de criterios que ayudan a decidir rápido en lugar de dar vueltas:

• Si el sitio procesa pagos o guarda datos de usuarios: conviene sumar un experto aunque tengas el tiempo y las ganas de hacerlo vos. El riesgo legal y reputacional de una limpieza incompleta pesa más que el ahorro.
• Si no tenés acceso SSH ni te sentís cómodo editando archivos y bases de datos: WPBeginner lo plantea sin vueltas: un backdoor mal removido reinfecta el sitio. Mejor pagar la limpieza que repetirla tres veces.
• Si es un blog personal, sin backups críticos en juego y sabés moverte en la terminal: podés seguir esta guía de punta a punta sin drama.
• Si los logs muestran indicios de backdoor fuera de la carpeta de WordPress (un cron job raro, archivos en otra parte del hosting), sumale una revisión profesional aunque hayas limpiado todo lo demás vos mismo. Es justamente el escenario donde más se falla al limpiar sin ayuda.

¿Qué hacer después de confirmar la intrusión en los logs?

Una vez que identificaste la IP, el endpoint y el momento del ataque en los logs, el orden correcto es contener el daño, cambiar todas las credenciales, limpiar los archivos comprometidos, reinstalar desde cero y recién después reforzar la seguridad del hosting.

• Contené el daño primero: según la guía de WPBeginner, lo más rápido es activar el modo «Under Attack» de Cloudflare o el modo mantenimiento del panel mientras limpiás, para que los visitantes no sigan expuestos.
• Cambiá todas las credenciales, dos veces: una apenas detectás el hackeo y otra después de limpiar, porque el atacante pudo haber visto lo que tipeaste mientras el sitio seguía infectado.
• No reinstales solo WordPress: WPBeginner insiste en esto: si el backdoor vive fuera de la carpeta de WordPress, en otro directorio del hosting o en un cron job, reinstalar solo el CMS no sirve de nada.
• Regenerá las claves secretas (salts) de wp-config.php: esto cierra sesión a cualquiera que tenga una cookie robada, incluso después de cambiar la contraseña.
• Pedí revisión en Google Search Console: si tu sitio quedó marcado con una advertencia de seguridad en los resultados de búsqueda, resolvé el problema en la sección Problemas de seguridad y después solicitá una revisión manual.

El error más caro acá es apurar el último paso. Google puede tardar varios días en sacar la advertencia, y pedir revisión con el sitio todavía infectado solo atrasa todo. Para más detalles técnicos, mirá aplicar hardening con Patchstack.

Tabla comparativa: qué log mirar según lo que necesitás encontrar

Errores comunes al analizar logs de un WordPress hackeado

• Borrar los logs antes de analizarlos: muchos, apenas ven algo raro, reinician el hosting o limpian todo de una. Sin el log, perdés la única prueba de cómo entró el atacante y no podés cerrar el agujero real.
• Mirar solo el access.log: el access log te dice quién tocó la puerta, no qué rompió adentro. Si no cruzás con error_log y con la fecha de modificación de archivos, te queda la mitad de la historia.
• Confundir tráfico de bots legítimos con ataque: un pico de 404 de Googlebot probando URLs viejas no es un hackeo, es indexación normal. Filtrá por user-agent antes de asustarte.
• Reinstalar WordPress y dar el caso por cerrado: como marca WPBeginner, si el backdoor está afuera de la carpeta de WP, seguís infectado aunque el sitio «se vea» limpio.

Preguntas Frecuentes

¿Cómo sé si mi WordPress fue hackeado?

Los signos más comunes son una advertencia de Google o del navegador sobre tu sitio, redirecciones a páginas extrañas, enlaces de spam que no pusiste vos, usuarios administradores que no reconocés y archivos modificados en fechas que no coinciden con tu actividad. Revisar el access.log y el error_log confirma o descarta la sospecha en minutos.

¿Dónde están los logs de WordPress en mi hosting?

En cPanel están dentro de Estadísticas > Logs de acceso sin procesar; en hosting con acceso SSH podés leerlos directo con tail o grep. Si tu proveedor no los expone en el panel, pedíselos por ticket de soporte.

¿Qué debo buscar en el access.log para detectar un hackeo?

Buscá intentos repetidos de login a wp-login.php desde la misma IP, requests a wp-config.php o xmlrpc.php, códigos 404/500 en cascada sobre plugins que no tenés instalados y picos de tráfico en horarios inusuales. Cualquiera de estos patrones, sobre todo combinado con otro, es señal de actividad maliciosa.

¿Cómo veo los logs del servidor desde cPanel o el panel de hosting?

Entrá a cPanel, andá a la sección Métricas o Estadísticas y buscá «Raw Access Logs» o «Logs de acceso sin procesar»; ahí podés descargar el archivo comprimido del día o del mes. El error_log de PHP suele estar en la raíz de tu carpeta pública o accesible desde el Administrador de archivos.

¿Qué diferencia hay entre el log de acceso, el log de errores y el log de actividad de WordPress?

El log de acceso registra cada solicitud HTTP al servidor: quién, qué URL, cuándo. El log de errores de PHP registra fallas de código, típicas de un webshell mal escrito. El log de actividad de WordPress, si tenés un plugin de auditoría, registra acciones dentro del panel, como creación de usuarios o instalación de plugins. Los tres juntos arman la reconstrucción completa del ataque.

Conclusión

Analizar logs de WordPress hackeado no requiere herramientas caras ni conocimientos de forense digital. Con acceso al access.log, al error_log de PHP y un puñado de comandos de grep, cualquiera puede reconstruir cómo entró un atacante, qué endpoint explotó y qué hizo una vez adentro, tal como mostró el caso real de CVE-2023-6961 en WP Meta SEO analizado por Invicti. El paso que la mayoría se salta es el más importante: guardar una copia del sitio infectado antes de tocar nada, porque esa evidencia es la que te permite diagnosticar el sitio comprometido mediante logs del servidor en vez de adivinar. Si tu hosting no te da acceso fácil a esos archivos, es momento de replantearte el proveedor.

Fuentes

• Google Search Central Blog – Sitios hackeados: ayuda para webmasters
• Invicti Security – Analizando access logs de un hackeo de WordPress con NotebookLM (caso CVE-2023-6961)
• WPBeginner – Guía para principiantes: cómo arreglar tu sitio WordPress hackeado
• AyudaWP – Qué hacer si te han hackeado el WordPress
• Medium – Análisis de logs de sitios WordPress comprometidos