Si cree que han hackeado su web WordPress, es posible que alguien haya accedido a una parte de ella sin su permiso y haya cambiado algo: archivos, contenidos, usuarios o ajustes.
Un hackeo puede afectar a:
- lo que ven los visitantes en la web
- adónde se envía a los visitantes cuando hacen clic en un enlace o en un resultado de búsqueda
- quién puede iniciar sesión en el escritorio de WordPress
- los emails que envía la web
- los datos de los clientes, los pedidos o los envíos de formularios
- cómo tratan la web Google y los navegadores
- otras webs alojadas en la misma cuenta
Descubrir un hackeo es estresante, sobre todo cuando la web sostiene su negocio. Sin embargo, no significa necesariamente que sus contenidos o datos se hayan perdido o los hayan robado. En muchos casos, la web se puede limpiar, proteger y devolver a la normalidad.
Lo más importante en la primera hora es no borrarlo todo y empezar de cero. Los cambios precipitados pueden destruir las pruebas necesarias para entender cómo entró el atacante y dejar el problema real donde está.
Esta guía explica las señales habituales de un hackeo, los primeros pasos seguros para contenerlo, qué evitar y cuándo es mejor pedir soporte especializado.
¿Qué señales indican que han hackeado una web WordPress?
Algunos hackeos son evidentes. Otros están pensados para pasar desapercibidos el mayor tiempo posible.
Entre las señales habituales están:
- los visitantes son redirigidos a webs sin relación o de spam
- Google o el navegador muestran un aviso de que el sitio es peligroso o puede estar hackeado
- aparecen en Google páginas que usted no ha creado, a menudo en otro idioma
- la página de inicio se ha sustituido por un mensaje o una imagen
- ya no puede iniciar sesión con su contraseña habitual
- aparecen nuevas cuentas de administrador en la lista de usuarios
- la web envía emails de spam o su proveedor de hosting le avisa de spam saliente
- el proveedor de hosting ha suspendido la cuenta o ha puesto archivos en cuarentena
- la web se ha vuelto mucho más lenta sin un motivo evidente
- un plugin de seguridad o el escáner del hosting informa de archivos modificados o sospechosos
- los clientes hablan de ventanas emergentes, descargas o páginas de pago extrañas
Una sola de estas señales no demuestra un hackeo. Una redirección puede deberse a un plugin mal configurado, y una web lenta puede necesitar simplemente una optimización.
Pero si ve varias, o algo que no sabe explicar, trate la situación como un posible incidente de seguridad hasta saber más.
¿Por qué hackean las webs WordPress?
WordPress en sí se mantiene de forma activa y se publican actualizaciones de seguridad con regularidad. La mayoría de los compromisos se producen a través de lo que lo rodea.
Plugins o temas desactualizados
Un plugin o un tema con una vulnerabilidad conocida es una de las vías de entrada más habituales. Cuando una vulnerabilidad se hace pública, hay herramientas automatizadas que analizan gran cantidad de webs en busca de instalaciones sin actualizar.
Esto se aplica también a los plugins instalados pero desactivados y a los temas que no se usan. Sus archivos siguen en el servidor.
Contraseñas débiles o reutilizadas
Una contraseña de administrador, de hosting o de SFTP corta, común o reutilizada en otros servicios puede adivinarse u obtenerse de una filtración de datos en otro lugar.
Temas y plugins "nulled" o pirateados
Los temas y plugins premium descargados gratis de fuentes no oficiales a veces contienen código oculto que da acceso a la web a otra persona. Además, dejan de recibir actualizaciones de seguridad.
Accesos compartidos u olvidados
Las cuentas antiguas de antiguos proveedores, compañeros o agencias, los accesos compartidos y las credenciales enviadas por email pueden convertirse en una vía de entrada.
Otras webs en la misma cuenta de hosting
Si varias webs comparten una cuenta de hosting, el compromiso de una de ellas a veces puede extenderse a las demás.
Un dispositivo comprometido
Un malware en un ordenador que se usa para gestionar la web puede capturar las contraseñas mientras se escriben. Es uno de los motivos por los que las contraseñas deben cambiarse desde un dispositivo de confianza.
Lo primero: no se deje llevar por el pánico y no lo borre todo
Cuando se descubre un hackeo, es natural querer eliminar todo rastro lo antes posible.
Borrar la web, reinstalar WordPress o restaurar el backup más antiguo que encuentre puede parecer una medida decidida. En la práctica, puede:
- destruir las pruebas que muestran cómo entró el atacante
- borrar pedidos, mensajes o registros recientes
- dejar abierta la vulnerabilidad original
- dejar puertas traseras ocultas en archivos que no se han sustituido
- dejar infectadas otras webs de la misma cuenta
Un enfoque más tranquilo es más eficaz. El primer objetivo es contener el incidente, después entenderlo y solo entonces limpiar y proteger la web.
¿Qué debe hacer de inmediato?
Estos primeros pasos son sobre todo de organización. No necesita conocimientos técnicos para darlos.
1. Registre lo que está viendo
Reúna:
- capturas de pantalla de todo lo que sea extraño
- las URL afectadas
- la fecha y la hora aproximada en que notó el problema
- los emails de su proveedor de hosting, de Google o de WordPress
- los avisos recibidos de clientes
- cualquier cambio reciente en la web del que tenga conocimiento
A partir de ahora, anote lo que hace, con la hora. Este registro será útil para quien investigue el incidente.
2. Cambie las contraseñas desde un dispositivo limpio
Si sospecha que su propio ordenador puede estar infectado, use otro dispositivo de confianza.
Cambie, en este orden de prioridad:
- la contraseña del panel de control del hosting
- las contraseñas de SFTP o FTP
- las contraseñas de las cuentas de administrador de WordPress
- la cuenta de email vinculada al administrador de WordPress, si puede estar afectada
- la contraseña de la base de datos, si usted o su desarrollador pueden actualizarla con seguridad
Use contraseñas largas y únicas y active la autenticación en dos pasos siempre que esté disponible, sobre todo en la cuenta de hosting.
Cambiar la contraseña de la base de datos también exige actualizar wp-config.php con el nuevo valor; de lo contrario, la web dejará de funcionar. Si no sabe cómo hacerlo, pida a su proveedor de hosting o a su desarrollador que se encargue.
3. Revise con atención las cuentas de administrador
En WordPress, abra:
Users → All Users (Usuarios → Todos los usuarios)
Después filtre por el perfil Administrador.
Busque cuentas que no reconozca, direcciones de email inesperadas o usuarios creados recientemente.
Antes de eliminar un administrador desconocido:
- haga una captura de pantalla o anote el nombre de usuario, la dirección de email y cualquier otro dato visible
- valore cambiar primero su contraseña o su perfil, en lugar de borrarlo de inmediato
Cuando borra un usuario de WordPress, WordPress pregunta qué hacer con el contenido que ese usuario creó. Elegir la opción equivocada puede borrar páginas o entradas. Anotar antes los datos también conserva pruebas útiles.
4. Conserve una copia del estado actual
Antes de limpiar o sustituir nada, pida a su proveedor de hosting o a su desarrollador que haga una copia completa de:
- los archivos de la web
- la base de datos
- los logs del servidor y de acceso disponibles
Esta copia puede estar infectada, así que no debe restaurarse sobre la web en producción. Su finalidad es apoyar la investigación.
5. Informe a su proveedor de hosting
Su proveedor de hosting puede:
- confirmar si se ha detectado malware
- decirle qué archivos se han puesto en cuarentena
- compartir los logs de acceso
- comprobar si se han visto afectadas otras webs de la cuenta
- ayudarle a restringir el acceso temporalmente
- informarle sobre los backups disponibles
Algunos proveedores pueden suspender la cuenta para proteger su infraestructura. Si ocurre, pregunte qué necesitan de usted para restablecer el acceso.
6. Revise las demás webs de la misma cuenta
Si la cuenta de hosting contiene otras webs, bases de datos de prueba o copias antiguas del sitio, también hay que revisarlas. Una instalación antigua y olvidada es un escondite habitual de archivos maliciosos.
¿Por qué no basta con restaurar un backup?
Un backup puede ser muy útil durante la recuperación, pero restaurarlo rara vez es por sí solo una solución completa.
Hay tres motivos principales:
- La vulnerabilidad sigue ahí. Si el atacante entró por un plugin desactualizado o una contraseña débil, la web restaurada tiene el mismo punto débil y puede volver a ser comprometida.
- El backup puede estar ya infectado. Algunos hackeos permanecen ocultos durante semanas o meses antes de hacerse visibles. Un backup hecho durante ese tiempo puede contener el código malicioso.
- Se pueden perder datos recientes. Los pedidos, envíos de formularios, registros de usuarios y contenidos creados después del backup se sobrescribirán.
Una restauración puede seguir formando parte de la solución. Debe usarse junto con una investigación de la vía de entrada, una revisión de los archivos restaurados y un plan para recuperar los datos recientes.
D4Hub puede ayudarle a valorar qué backup es adecuado y cómo combinarlo con una limpieza como es debido.
¿Cómo se encuentra y se corrige la vía de entrada?
Limpiar los síntomas visibles sin cerrar la vía de entrada es uno de los motivos más habituales por los que una web vuelve a ser hackeada poco después de la limpieza.
Una investigación correcta suele analizar:
- qué plugins y temas están instalados, incluidos los inactivos, y si están actualizados
- si alguno tiene vulnerabilidades conocidas
- si algún tema o plugin procede de una fuente no oficial
- qué cuentas de usuario existen y cuáles se han usado recientemente
- si se han modificado archivos del núcleo de WordPress, de los plugins o de los temas
- si hay archivos PHP donde no debería haberlos, como la carpeta uploads
- si la base de datos contiene scripts, enlaces u opciones inesperadas inyectados
- si se han añadido tareas programadas
- qué muestran los logs de acceso del servidor en torno al momento del compromiso
Una vez identificada la causa, la solución puede implicar actualizar o sustituir componentes, eliminar software abandonado, restablecer credenciales, revisar los permisos de los archivos y mejorar la configuración del hosting.
Revise Google Search Console
Si su web está conectada a Google Search Console, abra la propiedad y vaya a:
Security & Manual Actions → Security Issues (Seguridad y acciones manuales → Problemas de seguridad)
El informe puede indicar si Google ha detectado contenido hackeado, malware u otros problemas de seguridad, con URL de ejemplo.
Estas URL son muestras, no una lista completa. Una vez limpiada y protegida toda la web, puede solicitar una revisión desde el mismo informe.
Si no sabe quién gestiona Search Console para su web, consúltelo con su agencia, su desarrollador o su equipo de marketing. Nuestra guía sobre qué hacer cuando Google ha marcado su web como peligrosa explica este proceso con más detalle.
¿Y si pueden haber quedado expuestos datos personales?
Si la web almacena datos personales, como cuentas de clientes, pedidos, envíos de formularios o suscriptores de la newsletter, un hackeo también puede ser una violación de la seguridad de los datos personales.
Según el RGPD, los responsables del tratamiento por lo general deben notificarlo a la autoridad de control competente en un plazo de 72 horas desde que tienen constancia de la violación de datos personales, salvo que sea improbable que constituya un riesgo para las personas. En algunos casos, también hay que informar a las personas afectadas. Las normas pueden ser distintas en otros países.
Que esto se aplique a su incidente depende de qué datos estaban implicados y a qué pudo acceder el atacante. Hable lo antes posible con su Delegado de Protección de Datos o su asesor jurídico, y compártales la información que está reuniendo sobre el incidente.
El soporte técnico puede ayudar a establecer qué era accesible, pero la valoración jurídica deben hacerla los responsables de protección de datos de su organización.
¿Qué debe evitar?
Evite:
- borrar la web o reinstalarlo todo antes de conservar una copia
- restaurar un backup antiguo sin comprobar su fecha y su contenido
- cambiar las contraseñas desde un dispositivo que puede estar comprometido
- borrar usuarios desconocidos sin anotar sus datos
- instalar varios plugins de seguridad a la vez
- copiar código de limpieza encontrado en foros sin entenderlo
- dar el problema por resuelto porque la página de inicio se ve normal
- compartir contraseñas, logs o backups por email normal o en foros públicos
- olvidarse de las demás webs de la misma cuenta de hosting
- hacer varios cambios a la vez sin anotar lo que ha hecho
Cambie una sola cosa cada vez y lleve un registro. Si tiene dudas sobre un paso, detenerse suele ser más seguro que seguir.
¿Cuándo debe pedir soporte especializado?
Pida soporte técnico cuando:
- la web redirige a los visitantes a páginas sin relación
- Google o los navegadores muestran un aviso de seguridad
- han aparecido administradores desconocidos
- ya no puede iniciar sesión
- el proveedor de hosting ha suspendido la cuenta
- la web gestiona pagos, suscripciones o datos personales
- no sabe cuándo empezó el compromiso
- no tiene un backup del que esté seguro de que está limpio
- varias webs comparten la misma cuenta de hosting
- el problema vuelve después de una limpieza
- no se siente cómodo trabajando con archivos, bases de datos o logs
No necesita identificar el malware ni la vía de entrada antes de pedir ayuda.
¿Qué información debe reunir?
Antes de abrir una solicitud de soporte, reúna lo que tenga fácilmente a mano:
- la URL de la web
- capturas de pantalla de los síntomas
- cuándo notó el problema por primera vez
- los mensajes de su proveedor de hosting, de Google o de los clientes
- lo que ya ha cambiado o probado, con las horas aproximadas
- si puede acceder a WordPress y al panel del hosting
- el nombre del proveedor de hosting
- si hay backups disponibles y de qué fechas
- si la web gestiona pedidos, suscripciones o datos personales
- si otras webs comparten la misma cuenta de hosting
No se preocupe si no puede aportarlo todo. No envíe contraseñas, claves privadas ni logs completos en un mensaje no protegido: D4Hub puede indicarle cómo compartir el acceso con seguridad.
Cómo puede ayudarle D4Hub
El objetivo no es solo eliminar las señales visibles del hackeo. Una respuesta completa debe contener el incidente, eliminar el contenido malicioso, cerrar la vía de entrada y reducir el riesgo de que vuelva a ocurrir.
Según la situación, D4Hub puede ayudarle a:
- valorar los síntomas y confirmar si la web está comprometida
- conservar una copia de los archivos, la base de datos y los logs antes de la limpieza
- revisar los usuarios, los archivos, el contenido de la base de datos y las tareas programadas
- coordinarse con su proveedor de hosting
- eliminar código malicioso, páginas de spam, redirecciones y puertas traseras
- identificar la vía de entrada, como un plugin vulnerable o credenciales expuestas
- actualizar o sustituir los componentes vulnerables
- valorar los backups y planificar una restauración sin perder datos recientes
- revisar otras webs de la misma cuenta de hosting
- probar los formularios, el acceso, el checkout y otras funciones importantes
- acompañarle en la revisión de Google Search Console cuando sea necesario
- recomendar medidas como actualizaciones, backups y control de accesos para reducir el riesgo en el futuro
Puede solicitar ayuda en cualquier momento: justo después de notar algo extraño, después de que su proveedor de hosting haya hecho un análisis o tras un primer intento de limpieza que no funcionó del todo.
Si algún paso de esta guía le parece poco claro o arriesgado, no tiene por qué hacerlo solo.
Abrir un ticket de soportePara usuarios con experiencia técnica: una primera revisión técnica
Las siguientes comprobaciones están pensadas para personas que se manejan con SSH, SFTP, WP-CLI y paneles de hosting. Ayudan a reunir pruebas e identificar zonas sospechosas, pero no sustituyen una limpieza de seguridad completa.
Antes de empezar, haga una copia completa de los archivos y de la base de datos y guárdela fuera de la web. Haga primero comprobaciones de solo lectura y no modifique ni borre nada hasta haber anotado lo que ha encontrado.
En una web comprometida, los plugins y los temas pueden contener código malicioso que se ejecuta cada vez que se carga WordPress. Al ejecutar comandos de WP-CLI, puede añadir --skip-plugins --skip-themes para no cargarlos.
Liste las cuentas de administrador
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themesCompare los resultados con las personas que deberían tener acceso de administrador. Anote cualquier cuenta desconocida y su fecha de registro antes de actuar.
Verifique los archivos del núcleo de WordPress
wp core verify-checksums --skip-plugins --skip-themesCompara los archivos del núcleo con las sumas de verificación oficiales de su versión de WordPress. Informa de los archivos modificados y de los archivos que no deberían estar en las carpetas del núcleo.
No revisa la carpeta wp-content, donde se guardan los plugins, los temas y los archivos subidos.
Verifique los archivos de los plugins
wp plugin verify-checksums --all --skip-plugins --skip-themesFunciona con los plugins publicados en el directorio oficial de WordPress.org. Los plugins premium y a medida no pueden verificarse así y aparecerán como tales: esto no es, por sí solo, una señal de infección.
Encuentre los archivos modificados recientemente
Desde la carpeta raíz de la instalación de WordPress, liste los archivos PHP modificados en los últimos 7 días:
find . -type f -name "*.php" -mtime -7Cambie el número para cubrir el periodo que sospecha. Las actualizaciones legítimas también modifican archivos, así que compare los resultados con las fechas de actualización conocidas. Los atacantes también pueden alterar las fechas de modificación, por lo que una fecha antigua no demuestra que un archivo sea seguro.
Busque archivos PHP en la carpeta uploads
La carpeta uploads normalmente contiene imágenes y documentos, no código PHP:
find wp-content/uploads -type f -name "*.php"Cualquier resultado merece un examen más detallado. Algunos plugins crean ahí archivos PHP de forma legítima, a menudo pequeños archivos de protección, así que revise el contenido y la ubicación antes de sacar conclusiones.
Revise las tareas programadas
wp cron event list --skip-plugins --skip-themesBusque eventos con nombres desconocidos que no correspondan a WordPress ni a los plugins que usa.
Invalide las sesiones abiertas
Después de cambiar las contraseñas, puede sustituir las claves de seguridad y los salts en wp-config.php:
wp config shuffle-saltsEsto cierra la sesión de todos los usuarios, incluido cualquier atacante con una sesión activa. Asegúrese de tener una contraseña de administrador que funcione antes de ejecutarlo.
Guarde en privado los logs o resultados que reúna. Pueden contener direcciones IP, nombres de usuario y otra información sensible, así que no los publique en foros ni en hilos de soporte.
D4Hub puede hacer o revisar estas comprobaciones, interpretar los resultados y decidir con usted el siguiente paso seguro.
Preguntas frecuentes
¿Debo desconectar la web?
Depende de lo que esté haciendo el hackeo. Si se está redirigiendo a los visitantes, mostrándoles contenido malicioso o pidiéndoles datos de pago, restringir el acceso temporalmente puede protegerlos.
Su proveedor de hosting o un especialista pueden ayudarle a elegir un método que limite los daños sin destruir pruebas, por ejemplo una página de mantenimiento o restricciones de acceso en lugar de borrar la web.
¿Un plugin de seguridad limpiará la web?
Un plugin de seguridad puede ayudar a detectar patrones maliciosos conocidos y archivos modificados. Puede que no encuentre todas las puertas traseras, que no reconozca correctamente el código a medida o que no identifique cómo entró el atacante.
Puede ser una herramienta útil durante la investigación, pero no debe considerarse la respuesta completa.
¿Basta con cambiar las contraseñas?
Cambiar las contraseñas es un paso esencial, pero no elimina los archivos maliciosos, el contenido inyectado en la base de datos ni los plugins vulnerables. Un atacante que dejó una puerta trasera puede seguir pudiendo volver a entrar.
Las contraseñas deben cambiarse como parte de una limpieza más amplia.
¿Cómo entró el atacante?
Las vías de entrada más habituales son plugins o temas desactualizados, contraseñas débiles o reutilizadas, software "nulled" y cuentas antiguas que nunca se eliminaron. A veces la causa es otra web de la misma cuenta de hosting.
Identificar la causa exacta suele requerir revisar los archivos, los usuarios y los logs del servidor, por eso es importante conservarlos antes de la limpieza.
¿Pueden volver a hackear la web después de la limpieza?
Sí, si no se cierra la vía de entrada. Por eso una respuesta completa incluye actualizar o sustituir los componentes vulnerables, eliminar el software que no se usa, proteger los accesos y mantener backups periódicos y probados.
¿Tengo que informar a mis clientes?
Si pueden haber quedado expuestos datos personales, puede tener la obligación legal de notificarlo a la autoridad de control y, en algunos casos, a las personas afectadas. Hable con su Delegado de Protección de Datos o su asesor jurídico, que pueden valorar la situación con la información técnica reunida.
¿Puede ayudarme D4Hub si ya he intentado arreglarlo?
Sí. Explique qué ha cambiado, restaurado o borrado y cuándo. Esta información ayuda a reconstruir el incidente y a decidir el siguiente paso seguro.