¿Redirecciones inesperadas, picos de CPU o penalización en Google tras una actualización? Un WordPress comprometido puede provocar pérdida de tráfico, reputación y costes de recuperación; quien gestiona el sitio necesita acciones inmediatas, reproducibles y seguras para confirmar, contener y recuperar control.
La respuesta a la búsqueda "wordpress hackeado como saber si tienes malware" es:
- si se sospecha que un WordPress está hackeado, buscar páginas o redirecciones extrañas, usuarios admin desconocidos, picos de CPU, contenido spam o avisos en Google
- revisar fechas de archivos modificados y logs de acceso
- ejecutar escáneres (Wordfence/Sucuri) y comandos wp‑cli para listar cambios
Aislar el sitio, restaurar backups y contactar soporte profesional permite contener la infección en menos de 24 horas.
Resumen del proceso
La guía permite confirmar una infección y contenerla en menos de 24 horas siguiendo pasos prácticos y reproducibles.
- Aislar el sitio: desconectar o poner en modo mantenimiento.
- Recopilar evidencias: copiar logs y hacer snapshot del sistema.
- Detectar IOCs: buscar eval(base64), iframes, cron maliciosos y usuarios extraños.
- Limpiar archivos y base de datos con wp‑cli y consultas MySQL controladas.
- Restaurar desde backup verificado y aplicar hardening.
Prioridades 0–24h
El responsable aísla el servidor y cambia credenciales en el primer tramo.
El técnico copia access.log y error.log antes de cualquier limpieza.
La decisión de restaurar depende de la verificación del backup y la ausencia de backdoors en la base de datos.
Resultado esperado
Al seguir los pasos se reduce la probabilidad de reinfección y se preserva la trazabilidad para forense.
La restauración segura toma entre 3 y 7 horas en instalaciones medianas.
La prioridad inicial es detener la actividad maliciosa y preservar evidencia digital para análisis forense.
El responsable desconecta la web o aplica un .htaccess que devuelva 503 para usuarios anónimos.
El técnico hace un snapshot y copia los logs al menos en dos ubicaciones distintas.
Comandos básicos desde SSH
El administrador lista procesos y conexiones para detectar picos de CPU o procesos desconocidos.
Top -b -n 1 | head -n 20
ss -tunap | head -n 40
El responsable detecta uploads masivos o scripts en /tmp y carpetas públicas.
Copiar y conservar logs
El técnico copia access y error logs con timestamps y hashes para integridad.
Mkdir -p /root/forense/$(date +%Y%m%d-%H%M)
cp /var/log/apache2/access.log /root/forense/$(date +%Y%m%d-%H%M)/access.log
sha256sum /root/forense/* > /root/forense/checksums.txt
El archivo de logs contiene la trazabilidad del compromiso y debe conservarse sin modificar.
Paso 2: confirmar infección con wp‑cli y SSH
Con wp‑cli y comandos shell se confirma la infección buscando archivos y entradas de base de datos maliciosas.
La comprobación incluye find para archivos recientes, grep para firmas y wp‑cli para usuarios y opciones.
Si aparecen eval(base64_decode) o iframes extraños en archivos y en la DB, la probabilidad de infección es alta.
Buscar archivos modificados
El administrador lista archivos modificados en los últimos 7 días y prioriza los que están fuera de /uploads.
Find /var/www/html -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p/n' | sort -r
Si hay cientos de cambios en horas concretas, eso indica actividad automatizada o un actor que escaló permisos.
Buscar firmas maliciosas en archivos
El técnico usa grep con regex para localizar funciones de ofuscación comunes.
Grep -RInE "eval/s(|base64_decode(|gzinflate(|str_rot13(|preg_replace/s(.*//e)" /var/www/html || true
Una coincidencia en wp‑config.php o en functions.php suele ser una puerta trasera crítica.
Inspección de usuarios y crons
El responsable lista usuarios administradores y revisa si hay cuentas inusuales.
Wp user list --format=csv
crontab -l
wp cron event list --fields=hook,next_run
Encontrar un cron que llame a un fichero externo o una cuenta admin con email extraño indica compromiso persistente.
Muchos ataques dejan backdoors tanto en archivos como en la base de datos (wp_options, cron y user_meta). Limpiar solo archivos sin revisar la DB o las tareas programadas suele producir reinfección.
Además de las búsquedas pasivas, conviene usar wp‑cli y comandos SSH concretos para verificar la integridad y limpiar de forma reproducible. Ejemplos útiles: verificar integridad de core/plugins/temas con wp core verify‑checksums y wp plugin verify‑checksums --all; exportar la base de datos antes de tocarla con wp db export /root/forense/db-$(date +%F_%H%M).sql; buscar y reemplazar entradas en la DB con wp search-replace "<iframe" "" --skip-columns=guid --dry-run y luego sin --dry-run cuando se valide; regenerar las salts de wp-config.php con wp config shuffle-salts; comprobar archivos core comparando checksums locales con una copia limpia descargada con wp core download --path=/tmp/wp-core-clean --force y sha256sum para detectar cambios; y poner archivos sospechosos en cuarentena con mv /var/www/html/wp-content/uploads/suspect.php /root/forense/quarantine/ && chmod 600 /root/forense/quarantine/suspect.php.
Para cuentas, eliminar admins sospechosos con wp user delete 123 --reassign=1 y forzar reseteo de contraseñas masivo con wp user list --role=administrator --field=ID | xargs -n1 -I% wp user update % --user_pass=$(openssl rand -base64 18). Estas acciones reproducibles reducen errores manuales y permiten auditar cada paso.
Análisis forense de logs y trazabilidad
Los access.log y error.log permiten reconstruir la secuencia del ataque y localizar IOCs con precisión horaria.
Una correlación clara entre timestamps de modificaciones de archivos y entradas en access.log confirma el vector de subida.
Si se observan múltiples POST a wp‑admin/admin‑ajax.php desde la misma IP, eso es una señal de explotación automatizada.
Comandos para agrupar IPs y endpoints
El analista agrupa peticiones por IP y cuenta rutas repetidas para priorizar bloqueos.
Awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -n 20
awk '{print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -n 20
Un pico de más de 50 POST sospechosos en 5 minutos requiere bloqueo inmediato y captura de paquetes si es posible.
Detectar subida de ficheros y correlación
La correlación entre un POST con código 200 y la aparición de un fichero nuevo en /wp-content/uploads confirma subida maliciosa.
Awk '$9==200 {print $1,$4,$7}' /var/log/apache2/access.log | grep '12/Jun/2026:10:' | head
La evidencia de logs debe empaquetarse con checksums para envío al hosting o a un equipo forense.
Indicadores de compromiso y ejemplos
Las firmas más fiables incluyen funciones de ofuscación, iframes con dominios externos y entradas maliciosas en wp_options.
La detección de cualquier eval(base64_decode(...)) en archivos PHP es una IOC con alta probabilidad de backdoor.
También son IOCs usuarios admin sin relación, crons que llaman URLs externas y entradas extrañas en user_meta.
Regex útiles para detección
Se aportan patrones para búsqueda rápida en servidores y repositorios de código.
(eval/s(|base64_decode(|gzinflate(|str_rot13(|preg_replace/s(.//e)|]+src=|document.write(|window.location/s=)
Una coincidencia no siempre es infección; conviene revisar el contexto del fichero y el autor del plugin.
Ejemplos de código malicioso
Cuando este tipo de cadenas aparece en wp‑config.php o index.php, la infección es crítica y persistente.
Comparativa de escáneres: local vs remoto
La elección entre escaneo local y remoto depende de si se necesita inspección de la DB y de tareas cron.
Un escáner local que revisa archivos y base de datos detecta backdoors internos; los remotos solo ven señales externas.
La combinación de ambos reduce falsos negativos, pero puede multiplicar falsos positivos sin correlación con logs.
| Herramienta |
Detección local |
DB/cron |
Falsos positivos |
Tiempo típico |
| Wordfence (plugin) |
Sí |
Parcial |
Medio |
10–60 min |
| Sucuri (remoto + servicio) |
Limitado |
No |
Bajo |
20–120 min |
| WPScan (CLI) |
No (vulns) |
No |
Bajo |
5–30 min |
Interpretación de resultados
Un escaneo que devuelve muchas coincidencias requiere correlación con logs y timestamps de ficheros.
Si un archivo reportado como malicioso mostró cambios antes de la primera entrada en access.log, conviene sospechar falsos positivos.
Para decisiones críticas, exportar los hallazgos a un paquete forense y revisarlo con el hosting.
Los escáneres devuelven artefactos que conviene interpretar con ejemplos reales y criterio. Por ejemplo, un escaneo de Wordfence puede listar “Modified file: /wp-includes/class-wp.php” con un hash diferente; antes de eliminar, correlacione ese hallazgo con la fecha de modificación (mtime) y con access.log para ver si la modificación coincide con una petición POST que subió el fichero. Un informe remoto de Sucuri puede devolver “Malicious redirect detected on /wp-content/themes/twentyxx/header.php -> http://malicious.example/”, mientras que WPScan mostrará vulnerabilidades conocidas en plugins pero no backdoors. Falsos positivos comunes: archivos minificados legítimos que contienen cadenas parecidas a base64 o plugins que usan eval() para compatibilidad; en esos casos abra el archivo y revise la sección señalada y compare con la versión oficial del repositorio.
Si un escáner local marca cientos de archivos, priorice por mtime y por coincidencia con entradas en access.log/error.log antes de tomar decisiones destructivas.
Limpieza segura y restauración
Limpiar sin auditar la base de datos y los crons casi siempre deja puertas traseras funcionales.
La secuencia segura es: snapshot forense, aislar el sitio, limpiar archivos, revisar DB, validar backup y restaurar.
Restaurar desde un backup sin verificar la fecha relativa a la primera IOC puede reintroducir la misma puerta trasera.
Pasos y comandos para limpieza
El técnico mueve archivos sospechosos a cuarentena y restaura archivos core desde una copia limpia.
Wp core download --path=/tmp/wp-core-clean --force
sha256sum /var/www/html/wp-includes/.php /tmp/wp-core-clean/wp-includes/.php | sort
Para la DB, se busca en wp_options y user_meta entradas con iframes o scripts y se corrigen con consultas controladas.
Mysql -u user -p -D bd -e "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<iframe%';"
Validar backups y criterios de restauración
Un backup válido debe ser anterior a la primera IOC y contener logs o permitir reconstruirlos.
Si el backup es reciente y desconocido, restaurarlo solo tras escanear la copia fuera del entorno de producción.
Un backup de referencia limpio suele estar entre 7 y 30 días antes del incidente para la mayoría de instalaciones.
La evidencia práctica muestra que restauraciones hechas sin validar la DB reinfectan el sitio en menos de 72 horas.
La recomendación principal es restaurar solo desde copias verificadas y rehacer contraseñas, llaves y permisos después de la restauración.
Hardening y monitorización post‑incidente
Aplicar controles de acceso y reglas de WAF reduce notablemente la probabilidad de reinfección.
Cambiar credenciales, activar 2FA y ajustar permisos de ficheros son pasos inmediatos tras la limpieza.
Configurar alertas cada 5 minutos para cambios en ficheros sensibles permite detectar reapariciones tempranas.
Ajustes técnicos concretos
El responsable aplica permisos razonables y restringe acceso a wp‑config.php.
Chmod 640 /var/www/html/wp-config.php
find /var/www/html -type d -exec chmod 755 {} /;
find /var/www/html -type f -exec chmod 644 {} /;
Las reglas básicas de firewall y WAF bloquean IPs con comportamiento malicioso repetido.
Monitorización práctica
Se recomiendan herramientas que integren integridad de ficheros y alertas por correo o webhook.
Configurar un WAF como Cloudflare o ModSecurity y complementarlo con alertas de Wordfence o una solución externa mejora la detección.
El Reglamento General de Protección de Datos (RGPD) establece normas para la protección de datos personales; la Directiva NIS2 amplía las obligaciones de ciberseguridad para operadores y proveedores de servicios en la UE.
(La evidencia indica que limpiar sin auditar la DB funciona bien en teoría, pero en la práctica deja puertas traseras. Para recuperar confianza en producción, conviene un análisis forense completo antes de volver a publicar.)
Errores que arruinan la recuperación
Restaurar el último backup sin verificar la fecha respecto a la primera IOC reintroduce la infección.
Confiar solo en un escáner externo y borrar archivos señalados sin auditar la base de datos causa reinfecciones.
Cambiar únicamente contraseñas sin revisar permisos o crons deja vectores abiertos.
Errores técnicos frecuentes
Copiar un backup sobre producción antes de analizarlo puede borrar evidencia útil para forense.
Eliminar usuarios sospechosos sin revisar user_meta puede dejar sesiones activas con privilegios.
Usar FTP sin SFTP ni llaves expone credenciales y facilita el reparto de accesos maliciosos.
Errores organizativos
No notificar al hosting o a Google con evidencia reduce la probabilidad de que bloqueen dominios de phishing rápidamente.
No informar a responsables legales tras robo de datos personales incumple plazos del RGPD.
No conservar logs impide reconstruir la cadena de eventos y complica contratar servicios forenses.
Cuándo NO aplica este método
No aplicar estos pasos si el sitio está en un entorno de staging no público, si el proveedor de hosting ya ha intervenido y bloqueado el sitio, o si las anomalías se explican por cambios recientes de tema, CDN o reglas de caché. En esos casos, seguir las instrucciones del hosting y aportar logs es más eficaz.
Si se necesita asistencia profesional con urgencia, se puede solicitar una revisión forense que incluya logs y backups.
Preguntas frecuentes sobre mantenimiento WordPress
¿Cómo detectar malware en WordPress?
Buscar cambios en archivos, redirecciones no autorizadas y cuentas admin desconocidas permite detectar malware.
También comprobar access.log para POSTs masivos y grep para eval(base64) confirma indicios.
Si aparecen IOCs en archivos y DB, la probabilidad de infección es alta.
¿Cómo limpiar WordPress de malware?
Limpiar implica aislar el sitio, conservar logs y limpiar archivos y base de datos con wp‑cli y consultas SQL.
Restaurar desde backup solo tras verificar que es anterior a la primera IOC.
Verificar crons, permisos y usuarios antes de volver a producción.
¿Cómo saber si me han instalado un backdoor?
Detectar entradas extrañas en wp_options, crons que llaman URLs externas o eval(base64) en archivos indica backdoor.
También comprobar cambios de ficheros fuera de horarios de mantenimiento y usuarios admin desconocidos.
Si se encuentra un backdoor, asumir persistencia hasta comprobar la DB.
¿El escáner remoto es suficiente?
No; un escáner remoto detecta listas negras y phishing, pero no inspecciona cron ni DB.
Combinar escaneo remoto y local mejora la detección y reduce falsos negativos.
Para decisiones críticas, exportar hallazgos y revisar logs cronológicos.
Normalmente entre 3 y 7 horas para limpieza y restauración controlada en instalaciones medianas.
Casos complejos con forense toman entre 3 y 14 días según alcance y backups disponibles.
La duración depende del número de plugins y de la disponibilidad de backups verificados.
¿Qué hacer si Google marca el sitio como malicioso?
Solicitar revisión en Google Search Console tras limpiar y aportar la evidencia de limpieza.
Enviar la URL a Google Safe Browsing y esperar revisión, que suele tardar entre 24 y 72 horas.
Mantener al hosting informado para acelerar desbloqueo.
Siguientes pasos y recursos
Para referencias técnicas se pueden consultar OWASP Top Ten (2021) y documentación de INCIBE sobre incidentes en España.
OWASP Top Ten
INCIBE
Matt Mullenweg y organizaciones como Automattic y WordPress.org recomiendan mantener core y plugins actualizados.
Registro legal: RGPD (2016) y Directiva NIS2 (2022) establecen obligaciones para notificar incidentes con datos personales.
Si se necesita apoyo técnico con logs y backups, solicitar revisión forense profesional antes de restaurar.
