¿Tu web WordPress redirige a un casino, muestra una página firmada por el atacante o Google la marca como peligrosa? Lo más urgente no es borrar archivos a ciegas. Es contener el ataque, guardar una copia del estado hackeado y recuperar el control de los accesos antes de reparar. Esta guía ordena las decisiones desde las primeras horas hasta los treinta días siguientes, con los comandos útiles y las obligaciones que no puedes pasar por alto (incluido el plazo de 72 horas del RGPD).
¿Aún no tienes claro si te han hackeado? Empieza por las comprobaciones para saber si tu web WordPress está hackeada. ¿Buscas el detalle técnico de la limpieza, archivo por archivo? Está en nuestro procedimiento paso a paso para limpiar una web WordPress hackeada. Este artículo es tu plan de respuesta: quién hace qué, en qué orden y cómo evitar la reinfección.
Los diez primeros minutos: contener sin borrar
Mientras el código malicioso siga activo, puede robar datos, enviar spam o infectar a tus visitantes. Pero borrarlo todo de inmediato destruye las huellas que permitirán encontrar la puerta de entrada. El equilibrio correcto:
- Desconecta la web para los visitantes: página de mantenimiento a nivel de servidor (una regla en
.htaccessque devuelva una página estática con código 503, o la opción de tu hosting), no con un plugin de WordPress que depende del código comprometido. - Avisa a tu hosting mediante un ticket: a veces ya ha detectado la infección, puede bloquear el envío de correos y tiene registros que tú no ves.
- Abre un registro del incidente fuera del servidor: hora, observación, acción, autor. Te servirá para el seguro, para un técnico externo, para una denuncia o para la autoridad de protección de datos.
- No restaures todavía una copia de seguridad: no sabes desde cuándo está comprometida la web ni si la copia está limpia.
Evaluar la gravedad para elegir el ritmo adecuado
No todos los hackeos exigen la misma urgencia. La siguiente tabla te ayuda a decidir a quién movilizar y qué va primero.
| Lo que observas | Riesgo principal | Prioridad | A quién movilizar |
|---|---|---|---|
| Redirecciones a webs dudosas, aviso de Google | Visitantes infectados, desindexación | Desconectar de inmediato | Hosting, tú o un técnico externo |
| Páginas de spam indexadas (farmacia, casino) | Posicionamiento, reputación | En el día | Tú, y después Search Console |
| Página de inicio desfigurada | Imagen de marca | Desconectar de inmediato | Hosting, técnico externo |
| Cuentas de clientes, formularios o pedidos expuestos | Brecha de datos personales | Inmediata, el plazo del RGPD ya corre | Delegado de protección de datos, AEPD, técnico externo |
| Formulario de pago modificado (tienda) | Robo de tarjetas | Inmediata | Pasarela de pago, banco, técnico externo |
| Rescate o archivos cifrados | Pérdida de datos | Inmediata, no pagues | Hosting, INCIBE (017), denuncia |
Guardar una copia del estado hackeado
Antes de cualquier reparación, descarga una copia completa: archivos (por SFTP o con un archivo comprimido generado por el hosting), base de datos (exportación SQL) y, si es posible, los registros de acceso del servidor de los últimos 30 días. Guárdala fuera del servidor, aparte de tus copias de seguridad sanas, y márcala claramente como «infectada» para no restaurarla nunca por error. Es la que te permitirá fechar la intrusión y, por tanto, elegir una copia anterior.
Para fechar la intrusión, busca en esa copia los archivos PHP modificados recientemente y la fecha de creación de las cuentas desconocidas. Aquí la regla de las copias de seguridad 3-2-1 marca toda la diferencia: sin una copia externa antigua, solo queda la limpieza.
Recuperar los accesos, del más amplio al más concreto
Cambia las contraseñas desde un equipo limpio, empezando por lo que da más poder: un atacante que conserve el acceso a tu correo o al área de cliente del hosting puede volver a empezar.
- El correo que recibe los restablecimientos de contraseña, después el área de cliente del hosting y el registrador del dominio (activa la autenticación en dos pasos).
- Cuentas SFTP y SSH, panel de control (cPanel, Plesk) y usuario de la base de datos, y después actualiza
wp-config.php. - Las claves y salts de WordPress, lo que cierra todas las sesiones abiertas, incluida la del atacante.
- Todas las cuentas de administrador, y después las contraseñas de aplicación y las claves de API de los plugins (pagos, envío de correos, copias remotas).
Con WP-CLI, las comprobaciones básicas caben en unos pocos comandos:
# Nuevas claves y salts: se cierran todas las sesiones
wp config shuffle-salts
# Cuentas de administrador: localiza las que no reconoces
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Tareas programadas: una tarea desconocida puede reinfectar la web
wp cron event list --fields=hook,next_run_relative,recurrence
# Direcciones de la web: aquí puede esconderse una redirección
wp option get siteurl
wp option get homeReparar: qué sustituir, qué revisar
El principio: todo lo que se puede reinstalar desde una fuente oficial se sustituye, no se limpia línea a línea. Solo lo que es tuyo (contenidos, medios, ajustes, tema a medida) se revisa a mano.
| Elemento | Acción | Comando o método |
|---|---|---|
| Núcleo de WordPress | Reinstalar tal cual | wp core verify-checksums y después wp core download --force --skip-content |
| Plugins y temas | Eliminar y reinstalar desde wordpress.org o desde el desarrollador | wp plugin verify-checksums --all, nunca versiones «nulled» |
| Carpeta uploads | No debe haber ningún archivo PHP | find wp-content/uploads -name "*.php" |
| mu-plugins y drop-ins | Comprobar cada archivo | wp-content/mu-plugins, object-cache.php, advanced-cache.php |
| .htaccess y wp-config.php | Comparar con una versión sana | Redirecciones, auto_prepend_file, inclusiones desconocidas |
| Base de datos | Buscar scripts inyectados | Tablas wp_options y wp_posts: etiquetas <script>, eval, base64 |
| Usuarios | Eliminar las cuentas desconocidas | Reasignar sus contenidos, comprobar los perfiles modificados |
Los escondites clásicos de una puerta trasera están justo donde nadie mira: un archivo de nombre inofensivo en uploads, un mu-plugin que no aparece en la lista de plugins, una tarea cron que vuelve a crear el archivo eliminado. Si no encuentras cómo entró el atacante (plugin vulnerable, contraseña reutilizada, acceso FTP robado), la web volverá a ser hackeada en pocos días: es el momento de recurrir a un profesional.
El plan de respuesta, paso a paso
Salir de las listas negras y del aviso de Google
Una vez limpia la web, y solo entonces, vuelve a ponerla en línea y consigue que retiren los avisos:
- Google Search Console: el informe «Problemas de seguridad» enumera lo que Google ha detectado. Corrígelo todo, en todas las páginas, y después haz clic en «Solicitar revisión» describiendo el problema, lo que has hecho y el resultado. Google indica que una revisión por software malicioso o contenido hackeado tarda entre unos días y unas semanas: no envíes otra solicitud mientras la primera esté en curso. Más detalles en nuestra guía sobre el aviso de «sitio peligroso».
- Páginas de spam indexadas: deja que respondan 404 o 410 y usa la herramienta de retirada temporal para las más visibles. El método completo está en nuestro artículo sobre el spam SEO y la desindexación.
- Otras listas: comprueba el dominio en servicios de análisis como VirusTotal o Sucuri SiteCheck, y la IP desde la que salen tus correos en las listas antispam si tus mensajes acaban en la carpeta de spam. Cada lista tiene su propio procedimiento de exclusión.
Notificar: AEPD, personas afectadas, denuncia
Si el atacante pudo acceder a datos personales (cuentas de clientes, formularios de contacto, pedidos, lista de suscriptores), se trata de una brecha de datos personales según el RGPD. El artículo 33 obliga a notificarla a la Agencia Española de Protección de Datos (AEPD) en las 72 horas siguientes a tener conocimiento de ella, salvo que sea improbable que suponga un riesgo para las personas. Si el riesgo es alto (contraseñas, datos bancarios, datos sensibles), el artículo 34 obliga además a informar a las personas afectadas. En cualquier caso, documenta la brecha en tu registro interno. Nuestro artículo sobre el RGPD, los registros y la seguridad de WordPress detalla qué conviene conservar.
- Notificación incompleta: puedes notificar en las 72 horas con lo que sabes y completarla después. Más vale una notificación parcial a tiempo que una perfecta fuera de plazo.
- Tienda online: avisa a tu pasarela de pago si el proceso de compra pudo modificarse. Te dirá qué hacer con las tarjetas.
- Ayuda y denuncia: INCIBE atiende gratis en la línea 017 y te orienta sobre los pasos a seguir; la aseguradora suele pedir una denuncia ante la Policía Nacional o la Guardia Civil.
Los treinta días siguientes: que no vuelvan a hackearte
Una web limpiada sin corregir la causa suele reinfectarse. Durante el mes siguiente:
- Actualiza todo lo pendiente, elimina los plugins que no uses y sustituye los plugins abandonados.
- Activa la autenticación en dos pasos en todas las cuentas que puedan publicar o administrar.
- Repite las comprobaciones de integridad cada semana y vigila la aparición de nuevos administradores.
- Prueba a restaurar una copia de seguridad, de verdad, en un entorno de pruebas.
- Redacta un breve informe posincidente: causa, duración, coste, qué faltó.
Lo que WP Masquerade puede hacer, y lo que no hace
Seamos claros: WP Masquerade no es una herramienta de limpieza. No busca malware, no filtra el tráfico como un cortafuegos y no hace copias de seguridad de tu web. Para la reparación, usa un escáner (Wordfence, MalCare, Sucuri) o un profesional, y la herramienta de copias de seguridad que prefieras.
Entra en juego después, para reducir las probabilidades de un nuevo incidente y avisarte antes. La versión gratuita cambia la dirección de la página de acceso, bloquea XML-RPC y elimina las huellas que delatan WordPress ante los bots. WP Masquerade Pro añade la autenticación en dos pasos obligatoria por perfil, la limitación de intentos de acceso, el control de integridad del núcleo, el registro de actividad de los administradores y las alertas de plugins vulnerables, que a menudo habrían permitido corregir el fallo antes del ataque.
Después de la limpieza, cierra las puertas
Empieza por la versión gratuita y pasa a Pro para la autenticación en dos pasos, la integridad del núcleo y las alertas de vulnerabilidades: desde 59 € + IVA al año para un sitio, 149 € + IVA para 10 sitios.
Preguntas frecuentes
¿Hay que restaurar una copia de seguridad o limpiar la web?
Restaura si tienes una copia anterior a la intrusión y conoces la fecha de esta. Si no, limpia o reconstruye. En ambos casos, corrige la vía de entrada y cambia todos los accesos; si no, el atacante volverá.
¿Cuánto tarda Google en retirar el aviso?
Tras una solicitud de revisión en Search Console, Google habla de entre unos días y unas semanas para el software malicioso y el contenido hackeado. El plazo depende de la calidad de la limpieza: cualquier problema pendiente hace que la revisión no se supere.
¿Tengo que avisar a la AEPD por un simple spam SEO?
No, si no se ha podido consultar ni copiar ningún dato personal. Pero un atacante que ha podido añadir páginas a menudo ha tenido acceso a la base de datos: comprueba lo que contiene (cuentas, pedidos, formularios) antes de concluir, y anota tu análisis en el registro de brechas.
¿Basta con cambiar las claves y salts de WordPress?
No. Eso cierra las sesiones abiertas, pero un atacante que conoce una contraseña, tiene una cuenta de administrador oculta o una puerta trasera vuelve a entrar enseguida. Los salts son una pieza de un conjunto: contraseñas, cuentas, archivos y tareas programadas.
¿Cuándo recurrir a un profesional?
Cuando no encuentras la puerta de entrada, cuando la web se reinfecta tras la limpieza, cuando hay datos de clientes o de pago en juego, o cuando la web genera tu facturación. Pide un informe por escrito: causa, archivos afectados, medidas adoptadas.
En resumen
- Primero contener (web desconectada a nivel de servidor), después borrar.
- Guarda una copia del estado hackeado, fuera del servidor, para fechar la intrusión.
- Cambia los accesos del más amplio (correo, hosting) al más concreto (cuentas de WordPress), y después los salts.
- Reinstala el núcleo, los plugins y los temas desde la fuente; revisa uploads, mu-plugins, cron, .htaccess y la base de datos.
- Datos personales afectados: notificación a la AEPD en un plazo de 72 horas.
- Sin corregir la causa, la reinfección es probable.
Fuentes
- WordPress.org: FAQ My site was hacked (enlace externo, se abre en una pestaña nueva)
- Google: informe de problemas de seguridad (enlace externo, se abre en una pestaña nueva)
- RGPD, artículo 33: notificación de una violación de la seguridad de los datos personales a la autoridad de control (en inglés) (enlace externo, se abre en una pestaña nueva)
- WP-CLI: wp config shuffle-salts (enlace externo, se abre en una pestaña nueva)
