¿WordPress hackeado? El checklist de lo que ningún escáner puede ver

Por qué un escaneo limpio no significa un sitio limpio

Un plugin de seguridad, una comprobación de integridad de archivos y una auditoría de administradores responden a la misma pregunta: ¿qué hay en el servidor? Detectan un archivo plantado, un archivo del núcleo modificado, un administrador desconocido. Lo que no pueden saber es si la persona que usa una cuenta de administrador real es el administrador. Si un atacante usa tu sesión o tus contraseñas, cada cambio que hace parece tuyo: los registros muestran tu cuenta y, cuando el ataque se ejecuta dentro de tu propio navegador, también tu dirección IP.

Así que, cuando el servidor está limpio, el trabajo no ha terminado. Revisa los lugares de abajo, y hazlo desde un dispositivo de confianza.

1. Las extensiones del navegador

Una extensión puede leer y cambiar cada página que abres, incluido wp-admin, mientras tienes la sesión iniciada. Las extensiones se venden, y un nuevo dueño puede publicar una actualización que actúa en silencio sobre los sitios que administras: añadir un administrador, instalar un plugin, editar un archivo del tema… todo con tu sesión, desde tu navegador y tu IP. Es la explicación más común de «se hizo desde mi propia cuenta».

Abre la página de extensiones del navegador (chrome://extensions en Chrome) en cada equipo que use un administrador. Quita todo lo que no reconozcas, no uses o que pida «leer y cambiar todos tus datos en todos los sitios web» sin una razón clara. A partir de ahora, trabaja en wp-admin desde un perfil del navegador aparte, sin extensiones.

2. El equipo del administrador

El malware que roba contraseñas (infostealers) copia las contraseñas guardadas en el navegador y las cookies de sesión de cada sitio donde estás conectado. Una cookie de sesión robada es una sesión que ya pasó la verificación en dos pasos, así que el 2FA no detiene a quien la tiene. Estas infecciones suelen venir de un programa pirata, una actualización falsa o un CAPTCHA falso que te pidió pegar un comando.

Analiza cada equipo que haya iniciado sesión en wp-admin, en el hosting o en el correo. Hasta que estés seguro de que un dispositivo está limpio, da por conocida cualquier contraseña guardada en su navegador y cambia las contraseñas desde otro dispositivo.

3. Lo que el sitio dejó en tu propio navegador

Un service worker registrado mientras estabas en wp-admin vive en tu navegador, no en el servidor, y sigue funcionando cuando el sitio ya está limpio. Tu navegador también guarda las cookies y los scripts en caché del sitio.

En el navegador de cada administrador, abre el sitio y ve a Herramientas para desarrolladores → Aplicación (Application) → Almacenamiento → Borrar datos del sitio. Eso elimina sus service workers, cookies y archivos en caché para ese sitio.

4. Hosting, SFTP, SSH y la base de datos

Tu cuenta de hosting está por encima de WordPress. Un atacante que entró ahí puede crear un usuario del panel de control, una cuenta FTP o SFTP, una clave SSH en authorized_keys, un usuario de base de datos con acceso remoto o una tarea cron en el panel del hosting que reescribe archivos cada hora. Nada de eso se ve desde dentro de WordPress, así que ningún plugin de WordPress puede avisar de ello.

Entra en el panel del hosting y revisa todos los usuarios, cuentas FTP, claves SSH, usuarios de base de datos y tareas programadas. Elimina lo que no creaste y cambia las contraseñas del hosting, SFTP y la base de datos.

5. El buzón de correo

El buzón que recibe los restablecimientos de contraseña de WordPress, y los avisos del hosting y del registrador, es la llave de todo lo demás. Una regla de reenvío que copia los correos de restablecimiento a una dirección externa, o un filtro que archiva las alertas de seguridad antes de que las veas, sobrevive a cualquier cambio de tu contraseña de WordPress.

Revisa las reglas de reenvío, los filtros, las contraseñas de aplicación, las apps conectadas y el correo y teléfono de recuperación. Activa la verificación en dos pasos y cierra todas las demás sesiones.

6. Google, Search Console y Tag Manager

Tras una intrusión, los atacantes suelen añadirse como propietarios en Google Search Console o Bing Webmaster Tools. Desde ahí pueden enviar sitemaps de spam, pedir a Google que elimine tus páginas reales y leer tus datos de búsqueda, y un propietario sigue siéndolo después de limpiar el sitio. La comprobación de integridad SEO de Relvato avisa de un nuevo token de verificación en el sitio, pero la lista de propietarios está en la cuenta de Google, no en tu servidor.

El otro es Google Tag Manager: quien puede publicar un contenedor puede poner un script en todas las páginas sin tocar el servidor. Revisa los usuarios en Search Console (Configuración → Usuarios y permisos), Bing Webmaster Tools, Tag Manager y Analytics, y quita a quien no conozcas.

7. Registrador del dominio, DNS y CDN

Quien controla el dominio decide adónde apuntan el sitio y su correo. Revisa los usuarios y tokens de API en el registrador, el proveedor de DNS y el CDN (sobre todo Cloudflare), y activa la verificación en dos pasos y el bloqueo de transferencia del registrador. La monitorización DNS de Relvato avisa de un cambio de servidores de nombres o de correo, pero no puede ver quién tiene acceso a esas cuentas.

8. Claves de despliegue, integraciones y copias de seguridad

Si el sitio se despliega desde GitHub u otro repositorio, revisa sus claves de despliegue, los secretos de CI y quién puede hacer push. Revisa las integraciones que tienen una llave del sitio: servicios de copias de seguridad, monitores de disponibilidad, cuentas en la nube de maquetadores, contraseñas de aplicación que creaste para Zapier o una app móvil.

Y las propias copias de seguridad: restaurar una hecha después de la intrusión restaura la intrusión. En Relvato, la página de Seguridad del sitio muestra cuándo pasaron por última vez todas las comprobaciones de integridad a la vez; una copia de ese periodo es la más segura para restaurar.

Protégelo en este orden

El orden importa porque cada cuenta puede restablecer la siguiente. Empieza por el dispositivo: un equipo de confianza o uno recién limpiado. Luego el buzón de correo, porque recibe todos los demás restablecimientos. Después las cuentas del registrador, DNS y CDN, y luego los usuarios de hosting, SFTP, SSH y base de datos. Después WordPress: elimina administradores y contraseñas de aplicación desconocidos, cambia la contraseña de cada administrador y genera nuevas claves de seguridad en wp-config.php para cerrar todas las sesiones existentes. Por último, las consolas de terceros: Search Console, Tag Manager, analítica y herramientas de despliegue.

En cada paso, usa la opción «cerrar todas las sesiones» donde exista. Cambiar una contraseña no termina una sesión que ya fue robada.

Qué revisa Relvato, y qué no puede ver

Relvato revisa el sitio desde fuera, como un visitante, y a través de su plugin de WordPress, que informa de lo que hay en el servidor, nunca del contenido de los archivos. Detecta archivos plantados y código ejecutado desde la base de datos, administradores ocultos en la pantalla de usuarios, contraseñas de aplicación, service workers registrados por código inyectado, cambios de DNS y nuevos tokens de verificación de Search Console. Cuando ve señales de un hackeo, muestra este checklist al lado y puede poner el sitio en cuarentena durante 48 horas.

No puede ver tu navegador, tu equipo ni las cuentas de esta lista. Nada que se ejecute en un servidor puede. Esa parte te toca revisarla a ti, y a menudo es donde empezó el ataque.