WordPress hackeado: síntomas, qué hacer primero y cómo limpiarlo

Respuesta corta: si tienes un WordPress hackeado, no borres cosas a lo loco. Primero haz una copia de cómo está, cambia todas las contraseñas (WordPress, hosting, FTP/SFTP y base de datos) y cierra todas las sesiones. Después busca por dónde entraron, reinstala núcleo, plugins y tema desde fuentes limpias, revisa usuarios y base de datos, y pide a Google desde Search Console que vuelva a revisar la web.

Esta es la guía de referencia de nuestro blog para cuando tienes un WordPress hackeado. Aquí tienes el orden de trabajo completo y, para cada síntoma concreto, un enlace a la guía que lo explica a fondo.

Qué significa que un WordPress esté hackeado

Casi ningún hackeo actual busca romper tu web. Lo que buscan es usarla: tu dominio tiene antigüedad, enlaces y confianza en Google, y eso vale dinero. Por eso la mayoría de webs hackeadas siguen funcionando con normalidad y el dueño tarda semanas en enterarse.

Lo que suele hacer el atacante con una web WordPress comprometida:

• Spam SEO: inyecta texto y enlaces de farmacia, casinos o réplicas para posicionar sus webs. Lo explicamos en spam de casinos y farmacia en WordPress.
• Hack japonés: genera miles de páginas en japonés que se indexan en Google con tu dominio. Ver el hack japonés en WordPress.
• Cloaking: enseña el spam solo a Google y a ti te muestra la web limpia. Ver cloaking: tu web enseña spam solo a Google.
• Enlaces ocultos en el pie, el tema o entradas antiguas, invisibles para el visitante. Ver enlaces ocultos a casinos en WordPress.
• Usuarios administradores nuevos para volver a entrar cuando quieran. Ver hay un administrador en mi WordPress que no he creado.
• Puertas traseras: ficheros PHP escondidos que permiten ejecutar código aunque cambies las contraseñas.
• Redirecciones a estafas, normalmente solo para visitas que llegan desde Google o desde el móvil.
• Envío de spam por correo desde tu propio servidor, que acaba metiendo tu dominio en listas negras.

¿Y por dónde entran? En WordPress, la mayoría de las veces por uno de estos caminos:

• Un plugin o tema con una vulnerabilidad conocida que no se ha actualizado. Ver cómo saber si tus plugins son vulnerables.
• Un plugin retirado del repositorio o abandonado, que ya no recibe parches. Ver plugins abandonados o retirados.
• Temas o plugins de pago descargados de webs «nulled», que muchas veces ya traen la puerta trasera de serie.
• Contraseñas reutilizadas o filtradas, sin segundo factor.
• Accesos que nadie revocó: un antiguo proveedor, un becario, una cuenta de soporte.
• Información expuesta que facilita el ataque, como un debug.log público con rutas y versiones.

Cómo saber si te pasa

Estos son los síntomas que más vemos y lo que suelen indicar:

Comprobaciones rápidas desde fuera

1. Busca en Google site:tudominio.com y añade términos típicos: site:tudominio.com viagra, site:tudominio.com casino. Mira también si aparecen títulos en japonés o chino.
2. En Search Console revisa «Seguridad y acciones manuales» → «Problemas de seguridad», el informe de páginas indexadas (una subida repentina es mala señal), los sitemaps enviados y «Ajustes» → «Usuarios y permisos» por si hay propietarios que no conoces.
3. Usa la inspección de URL de Search Console, «Probar URL publicada» y «Ver página probada»: es el HTML que recibe Google desde sus servidores.
4. Abre la web desde el móvil, en ventana privada, entrando desde un resultado de Google. Muchas redirecciones solo saltan así.
5. Compara desde terminal lo que recibe un visitante y lo que recibe alguien que dice ser Googlebot:

curl -s https://tudominio.com/ -o visitante.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://tudominio.com/ -o googlebot.html
diff <(grep -oE 'href="https?://[^"]+"' visitante.html | sort -u) <(grep -oE 'href="https?://[^"]+"' googlebot.html | sort -u)
curl -sI https://tudominio.com/wp-content/debug.log

Si el diff enseña enlaces que solo recibe Googlebot, tienes cloaking. Si el último comando devuelve 200, tu debug.log está a la vista de cualquiera.

Comprobaciones desde dentro con wp-cli

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --fields=name,status,version,update
wp option get users_can_register
wp option get default_role
ls -la wp-content/mu-plugins/
find . -name "*.php" -mtime -15 -not -path "./wp-content/cache/*" | head -50

verify-checksums compara los ficheros del núcleo con los oficiales de WordPress.org y avisa de los modificados y de los que sobran. La versión para plugins solo funciona con plugins del repositorio oficial. Si users_can_register vale 1 y default_role es administrator, cualquiera puede registrarse como administrador: es un truco clásico de los atacantes. Las fechas de modificación se pueden falsear, pero siguen siendo una buena pista.

Qué hacer primero (la primera hora)

1. Haz una copia de cómo está ahora, ficheros y base de datos, y guárdala fuera de la carpeta pública. Sirve para entender qué ha pasado y para volver atrás si la limpieza rompe algo.
2. Cambia todas las contraseñas: administradores de WordPress, panel del hosting, FTP/SFTP, usuario de la base de datos (y actualiza wp-config.php) y el correo del administrador.
3. Cierra todas las sesiones regenerando las claves de seguridad (salts). Revisa también las contraseñas de aplicación.
4. Revisa los administradores y quita el rol a los que no reconozcas.
5. Si la web hace daño a las visitas (redirige a estafas o descarga cosas), ponla en mantenimiento desde el servidor mientras limpias.
6. Avisa a quien corresponda: el hosting, el cliente y, si se han expuesto datos personales, valora la notificación a la AEPD (hay 72 horas de plazo desde que lo sabes; tienes la guía en aepd.es).

wp db export ../antes-de-limpiar.sql
tar czf ../ficheros-antes-de-limpiar.tgz --exclude=./wp-content/cache .
wp config shuffle-salts
wp user application-password list admin

Ejecuta estos comandos desde la raíz de WordPress; las copias quedan un nivel por encima, fuera de lo que se sirve por web. Cambia admin por cada usuario administrador.

Cómo limpiar un WordPress hackeado paso a paso

1. Encuentra la puerta de entrada

Si no sabes por dónde entraron, volverán a entrar. Revisa:

• Los plugins y temas con vulnerabilidades conocidas en la versión que tienes instalada.
• Plugins retirados de WordPress.org o sin actualizar desde hace meses.
• Los logs de acceso del servidor en las fechas en que aparecieron los primeros ficheros o usuarios raros: peticiones POST a ficheros que no conoces, a xmlrpc.php o a admin-ajax.php con acciones de plugins concretos.

grep "POST" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

2. Reinstala el núcleo desde cero

wp core download --force --skip-content --version=$(wp core version)
wp core verify-checksums

Esto sobrescribe wp-admin y wp-includes con la versión oficial, pero no borra lo que sobra. Si verify-checksums dice «File should not exist», ese fichero no es de WordPress: revísalo y elimínalo.

3. Reinstala plugins y tema

Para los plugins del repositorio oficial:

wp plugin list --field=name | xargs -I % wp plugin install % --force

Los plugins y temas de pago descárgalos de nuevo desde la web del fabricante, nunca de una copia que tengas por ahí. Si usas un tema hijo, revisa a mano functions.php, header.php y footer.php: es donde más spam y enlaces ocultos encontramos. Borra los plugins y temas que no uses: desactivados siguen siendo ficheros accesibles.

4. Revisa lo que queda en wp-content y en la raíz

find wp-content/uploads -name "*.php"
find . -name ".htaccess" -exec ls -la {} \;
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content --include=*.php

En uploads no debería haber ningún PHP. Cada .htaccess debe tener sentido (ojo con las reglas que miran el User-Agent o el Referer). El grep da falsos positivos, porque hay plugins legítimos que usan esas funciones, pero un fichero con nombre raro y código ofuscado en una sola línea casi nunca es legítimo. Revisa también wp-config.php, la carpeta mu-plugins y cualquier fichero en la raíz que no reconozcas.

5. Limpia la base de datos

wp db prefix
wp option get siteurl
wp option get home
wp db query "SELECT ID, post_title, post_status, post_modified FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%display:none%' ORDER BY post_modified DESC LIMIT 50"
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%base64_decode%' OR option_value LIKE '%<script%'"

Cambia wp_ por el prefijo que te devuelva el primer comando. Revisa entradas, páginas, widgets y opciones. Hay plugins que guardan scripts legítimos en opciones (analítica, chat), así que mira cada resultado antes de tocar nada. Para los usuarios, sigue la guía de administradores desconocidos.

6. Cierra y avisa a Google

1. Actualiza núcleo, plugins y tema, y activa el segundo factor para todos los administradores.
2. En Search Console, elimina propietarios y sitemaps que no sean tuyos.
3. Haz que las URLs de spam devuelvan 404 o 410. Si son muchas y te urge, usa también la herramienta de retirada temporal.
4. En «Problemas de seguridad», marca que lo has corregido y pide la revisión. Explica qué has hecho; Google lo valora.

Errores habituales

• Restaurar una copia sin cerrar la puerta. La copia de hace una semana probablemente ya tenía la puerta trasera y el plugin vulnerable sigue ahí.
• Cambiar solo la contraseña de WordPress. Si tienen la del FTP o la de la base de datos, da igual.
• Limpiar lo visible y dar el caso por cerrado. El spam vuelve a aparecer a los dos días porque la puerta trasera regenera los ficheros.
• Desactivar el plugin vulnerable en vez de borrarlo. Sus ficheros siguen en el servidor.
• Olvidarse de Search Console. Sin pedir la revisión, el aviso puede seguir semanas en los resultados.

Cómo evitar que vuelva

• Actualiza con frecuencia y borra lo que no uses.
• Nada de temas ni plugins «nulled».
• Un usuario por persona, con el rol mínimo, y segundo factor para administradores.
• Desactiva el editor de ficheros del escritorio con define('DISALLOW_FILE_EDIT', true); en wp-config.php.
• Copias de seguridad fuera del servidor y probadas.
• Cierra el debug.log y cualquier fichero que no deba ser público.
• Vigila: cuanto antes lo detectas, menos páginas de spam indexa Google y menos cuesta limpiar.

Para agencias: detectar el hackeo antes que el cliente

Cuando llevas decenas de webs, nadie hace un site: de cada una cada semana. Para eso hicimos Jeffrey.

Una vez al día, Jeffrey descarga la portada de cada web como un visitante y como Googlebot, y avisa si encuentra:

• Spam de farmacia, casinos o apuestas en el texto, aunque esté escondido con CSS.
• Un bloque grande de texto en japonés o chino en una web que no está en esos idiomas (el hack japonés).
• Spam que solo recibe Googlebot y no el visitante: el aviso dice literalmente que la web enseña spam solo a Google.
• Enlaces a casinos, farmacia o apuestas, o enlaces ocultos a otras webs, en la portada y en hasta 4 páginas internas del menú y del pie.
• Un cambio brusco de portada (otro título y un contenido que no se parece en nada al anterior).
• El debug.log de WordPress accesible desde fuera.

También avisa si Google Safe Browsing marca la web como peligrosa. Y con el plugin de Jeffrey instalado, suma lo que se ve desde dentro: administradores nuevos o ascendidos (con aviso inmediato), plugins, temas o núcleo con vulnerabilidades conocidas, plugins retirados de WordPress.org o abandonados, y enlaces a casinos o farmacia dentro de entradas y comentarios.

Para ser claros: Jeffrey no analiza los ficheros del servidor en busca de malware ni comprueba su integridad. Vigila los síntomas que se ven desde fuera y el estado de WordPress, que es donde se nota un hackeo antes de que lo vea el cliente. La limpieza sigue siendo la de esta guía.

Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.

Preguntas frecuentes