WordPress hackeado: 12 señales y cómo comprobarlas

Las señales más claras de que su WordPress ha sido hackeado son cuentas de administrador que nadie ha creado, archivos PHP donde solo debería haber imágenes y páginas de spam o redirecciones que usted nunca ve en su propia pantalla. Casi todas pasan desapercibidas a propósito: al atacante le interesa que la web siga funcionando, así que se esconde de los administradores con la sesión iniciada y solo muestra su contenido a los buscadores o a determinados visitantes.

A continuación encontrará 12 señales, agrupadas según dónde se detectan y cada una con una forma concreta de comprobarla. Varias comprobaciones usan WP-CLI, la línea de comandos de WordPress. El gestor de archivos y la herramienta de base de datos de su hosting también sirven, aunque son más lentos.

¿WordPress hackeado? Señales que notan sus visitantes

1. Redirecciones solo en el móvil o desde Google

Muchas infecciones redirigen solo a una parte de los visitantes: a quienes navegan con el móvil o a quienes llegan desde una búsqueda en Google. Las políticas de spam de Google describen ambos trucos: el encubrimiento o cloaking (mostrar un contenido a los buscadores y otro a los usuarios) y la redirección de los usuarios móviles a un dominio de spam. Usted escribe su dirección en el ordenador, ve la web de siempre y no se entera.

Cómo comprobarlo: desde el móvil, con datos móviles y sin iniciar sesión, busque su web y pulse en el resultado. Desde un terminal, compare una petición normal con la de un «visitante móvil que llega desde Google»:

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' \
  -e 'https://www.google.com/' https://example.com/

Un 301 o 302 hacia un dominio ajeno que aparece solo en el segundo resultado es una señal de alarma seria. Las redirecciones por JavaScript no se detectan así, de modo que revise también el código fuente de la página en busca de scripts que no reconozca.

2. Avisos del navegador o del antivirus

Si el navegador muestra un aviso a pantalla completa de «sitio engañoso», o sus clientes le cuentan que el antivirus ha bloqueado su web, lo normal es que una lista de bloqueo ya haya detectado malware o phishing en su dominio. Cómo comprobarlo: consulte su dominio en el estado de sitios de Navegación segura de Google y pida una captura de pantalla del aviso exacto.

Señales en los resultados de búsqueda de Google

3. Páginas de spam en los resultados de site:

Las páginas inyectadas de casinos, farmacias o imitaciones de marca suelen aparecer en Google antes de que usted las vea en ningún otro sitio. Cómo comprobarlo: busque site:example.com y fíjese en títulos en otros idiomas o en temas que nunca ha publicado. Añadir palabras como casino, viagra o loan acota la búsqueda.

4. Problemas de seguridad en Search Console

Si su web está verificada en Google Search Console, abra Seguridad y acciones manuales → Problemas de seguridad. Ahí enumera Google los problemas que ha detectado, como contenido hackeado o malware. Cómo comprobarlo: asegúrese de que la propiedad está verificada y de que sus mensajes llegan a alguien que los lee. Un informe vacío es una buena noticia, no una prueba.

Señales en el servidor y en la cuenta de hosting

5. Suspensión del hosting o CPU disparada

Los proveedores de hosting suspenden las cuentas que envían spam, sirven páginas de phishing o sobrecargan el servidor. Un pico de CPU sin más visitas puede indicar que en su cuenta se está ejecutando un minero de criptomonedas o un script de spam. Cómo comprobarlo: lea entero el mensaje del proveedor (a menudo cita archivos concretos) y revise los gráficos de recursos del panel de control. Con acceso SSH, ps aux --sort=-%cpu | head muestra los procesos que más consumen.

6. Spam saliente e IP en listas negras

Si sus correos empiezan a rebotar, o recibe rebotes de mensajes que nunca envió, puede que un script esté enviando spam a través de su servidor. Cómo comprobarlo: pregunte a su proveedor si ha cambiado el volumen de correo saliente y consulte la dirección IP de su servidor en un comprobador público de listas de bloqueo.

7. Archivos PHP en wp-content/uploads

La carpeta de subidas debería contener imágenes y documentos, no código. Un archivo PHP en ella suele ser una web shell, una puerta trasera que permite al atacante ejecutar comandos. Cómo comprobarlo:

find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

Algunos plugins colocan un index.php vacío en sus carpetas para impedir que se listen los directorios. Abra cada resultado y mire qué contiene en realidad.

8. Archivos del núcleo modificados

A los atacantes les gusta esconder código en los archivos del núcleo de WordPress, porque nadie los lee. Cómo comprobarlo: wp core verify-checksums compara sus archivos del núcleo con las sumas de verificación oficiales de WordPress.org y avisa de cada archivo que no coincide (referencia del comando). wp plugin verify-checksums --all hace lo mismo con los plugins, pero solo con los alojados en WordPress.org.

9. Cambios inesperados en .htaccess o wp-config.php

Bastan unas pocas líneas añadidas a .htaccess para redirigir a los visitantes según la página de procedencia o el navegador. Una línea en wp-config.php, o un ajuste auto_prepend_file en .user.ini, puede cargar malware antes incluso de que arranque WordPress. Cómo comprobarlo: compare ambos archivos con su última copia de seguridad fiable y busque después los trucos habituales de ofuscación y de carga previa:

grep -rnE --include='*.php' 'eval\(|base64_decode\(|gzinflate\(|str_rot13\(' . | head -50
grep -rn 'auto_prepend_file' --include='.htaccess' --include='.user.ini' --include='php.ini' .

Los plugins legítimos también usan algunas de estas funciones, así que tome cada coincidencia como una pista, no como un veredicto.

Señales en el escritorio de WordPress

10. Administradores desconocidos

Crear una cuenta de administrador nueva es la forma clásica de conservar el acceso, y hay malware que incluso oculta su cuenta en la pantalla Usuarios. Cómo comprobarlo:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes

Las dos opciones --skip impiden que el código normal de plugins y temas, incluido el malware que se esconda en él, filtre la lista. Los plugins must-use y wp-config.php se siguen cargando, así que revíselos también (señales 9 y 11). Si WP-CLI muestra más administradores que la pantalla Usuarios, algo está ocultando una cuenta. Compruebe además en cada perfil de administrador si hay contraseñas de aplicación que nadie de su equipo haya creado.

11. Plugins que nadie ha instalado

Busque plugins con nombres genéricos, sin autor o sin descripción, que nadie del equipo recuerde haber instalado. Los plugins must-use de wp-content/mu-plugins se cargan automáticamente y es fácil pasarlos por alto. Cómo comprobarlo: wp plugin list muestra los plugins normales junto con los must-use y los drop-ins, como object-cache.php; wp plugin list --status=must-use,dropin muestra solo estos dos últimos grupos.

12. Tareas cron extrañas

El malware suele programarse a sí mismo para volver aunque usted lo borre. Cómo comprobarlo:

wp cron event list --fields=hook,next_run_relative,recurrence

Investigue cada hook que no pueda asociar a un plugin que utilice. Las tareas cron del servidor también cuentan: crontab -l o la sección de cron del panel de hosting las muestran.

Qué hacer en la primera hora

Si una o varias de estas señales apuntan a un hackeo, la hora siguiente decide cuánto podrá averiguar todavía. Actúe con calma y en este orden:

1. No borre nada a la desesperada. Eliminar el archivo sospechoso o el administrador desconocido destruye pruebas y rara vez acaba con toda la infección, porque los atacantes suelen dejarse más de una vía para volver.
2. Conserve las pruebas. Haga una instantánea o copia de seguridad completa de archivos y base de datos tal como están tras el hackeo, y descargue los registros de acceso y de errores del servidor web, que muchos proveedores solo guardan durante un tiempo limitado. Guarde la copia sin conexión y etiquétela como infectada.
3. Cambie las contraseñas desde un dispositivo limpio. Empiece por la cuenta de hosting y siga con SFTP/SSH, la base de datos y todos los administradores de WordPress. Si su propio ordenador pudiera estar comprometido, use otro, y active la autenticación de dos factores para todos los administradores.
4. Avise a su proveedor de hosting. Puede ver los registros del servidor, las demás webs de la misma cuenta y el correo saliente, y a menudo aislar el sitio con rapidez.
5. Anote la hora. Apunte cuándo tuvo constancia del hackeo por primera vez y qué ha observado hasta ahora.

El último punto es clave para el RGPD. Si el atacante pudo llegar a datos de clientes, a mensajes de formularios de contacto, a cuentas de usuario o a pedidos, el hackeo suele ser una violación de la seguridad de los datos personales. El artículo 33 del RGPD obliga a notificarla a la autoridad de control (en España, la AEPD) sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella, salvo que sea improbable que constituya un riesgo. Nuestra guía sobre la notificación de brechas en 72 horas del RGPD explica cómo hacer esa valoración.

Con las pruebas a salvo, siga con nuestro plan paso a paso para eliminar malware de WordPress: contener el sitio, encontrar el punto de entrada, limpiar a partir de fuentes fiables y renovar todas las credenciales.

Security Audit & Compliance, el plugin de WordPress de secaudit.eu, revisa por usted varias de estas señales, entre ellas cuentas de administrador ocultas, eventos cron sospechosos, sumas de verificación del núcleo, cambios de archivos respecto a una línea base y spam SEO oculto. Detecta e informa; eliminar el malware sigue siendo tarea suya o de un profesional.

Preguntas frecuentes

¿Puede una web estar hackeada sin ninguna señal visible?

Sí. Muchas infecciones están pensadas para que el propietario no las vea: ignoran a los usuarios con la sesión iniciada, se dirigen solo a los buscadores o actúan únicamente en el servidor. Por eso las comprobaciones anteriores van más allá de echar un vistazo a la página de inicio.

¿Todo hackeo es una brecha de datos según el RGPD?

No todos, pero muchos sí. Si alguien ha accedido a datos personales, o si estos se han modificado, perdido o dejado de estar disponibles, hay una violación de la seguridad de los datos personales. Documente su valoración en cualquier caso: el artículo 33, apartado 5, exige registrar todas las brechas, también las que no se notifican.

¿Debo restaurar ya la copia de seguridad de ayer?

Solo cuando haya guardado el estado infectado y sepa, aunque sea de forma aproximada, cuándo empezó el ataque. Una copia hecha después de la intrusión también contiene la puerta trasera, y si restaura sin cerrar el punto de entrada, el atacante vuelve a entrar sin más.

Este artículo es información general, no asesoramiento jurídico.