Una web WordPress comprometida puede mostrar redirecciones, crear usuarios desconocidos, enviar correo no solicitado o modificar archivos sin que el sitio deje de cargar. El primer objetivo no es borrar una línea sospechosa, sino conservar evidencias y limitar el alcance.
La respuesta debe distinguir entre una infección del sitio, una cuenta robada y un problema del servidor o de una dependencia. Cada escenario exige comprobaciones diferentes.
Señales que merecen investigación
Revisa cambios inesperados en usuarios, plugins, temas, tareas programadas y archivos modificados recientemente. También observa picos de CPU, redirecciones que solo aparecen para ciertos visitantes, avisos del navegador y mensajes salientes que el sitio no debería generar.
Una única señal no prueba el origen. Un plugin actualizado puede cambiar muchos archivos legítimos, por lo que la comparación debe apoyarse en copias conocidas y registros.
Contener sin destruir información
Si hay indicios claros, limita temporalmente las funciones afectadas y conserva una copia del estado encontrado. Cambia las credenciales desde un dispositivo confiable y revisa administradores, FTP, bases de datos y claves de API. No ejecutes herramientas de limpieza sobre la única copia del sitio.
Cuando el sitio procesa pagos o datos personales, valora la necesidad de activar el plan interno de incidentes. La contención puede incluir una página de mantenimiento, pero debe tener una duración y un responsable.
Separar código, contenido y configuración
Compara el núcleo, los plugins y los temas con versiones legítimas y revisa el contenido subido. Las carpetas de medios deberían contener formatos esperados; un archivo ejecutable entre imágenes necesita explicación. Examina también wp-config.php, reglas del servidor y tareas cron.
Una base de datos puede contener usuarios añadidos, opciones modificadas o scripts almacenados. Limpiar solo archivos no basta si la persistencia está en los datos o en otra cuenta del mismo alojamiento.
Restaurar no es lo mismo que limpiar
Una restauración desde una copia anterior al incidente puede ser la vía más clara, pero primero hay que confirmar la fecha y revisar el origen de la intrusión. Si se restaura una copia comprometida, el problema reaparece. Tras recuperar, actualiza componentes, elimina accesos innecesarios y cambia secretos.
Después comprueba formularios, usuarios, redirecciones, tareas programadas y registros. Mantén una copia de la evidencia antes de eliminarla para poder explicar qué ocurrió.
Reducir la probabilidad de repetición
Protege administradores con MFA, limita privilegios, mantiene plugins necesarios y aplica actualizaciones con un procedimiento probado. Usa copias separadas y verifica restauraciones; una copia conectada con las mismas credenciales puede quedar expuesta durante el mismo incidente.
La monitorización ayuda a detectar cambios, pero no reemplaza la revisión de permisos ni el mantenimiento. Si el compromiso afecta a otras aplicaciones del servidor, la respuesta debe abarcar todo el entorno.
Credenciales y persistencia
Rota contraseñas de administradores, hosting, FTP, base de datos y servicios externos después de contener el incidente. Si una clave se reutilizaba en varios lugares, considera comprometidos todos ellos. Revisa usuarios, claves de aplicación y tareas cron; una puerta de entrada puede seguir activa aunque se haya eliminado el archivo visible.
Comprueba los registros desde el periodo anterior a la primera señal. La hora de modificación de un archivo no siempre coincide con el momento del acceso, pero puede ayudar a ordenar la investigación.
Comunicar y cerrar el incidente
Documenta qué se observó, qué se aisló, qué se restauró y qué controles se han cambiado. Si se trataron datos personales, la organización debe valorar sus obligaciones conforme al contexto y a la normativa aplicable. No publiques acusaciones sobre el origen del ataque sin evidencias.
Después de recuperar el sitio, repite las pruebas con una copia limpia y supervisa los cambios. La ausencia de una redirección visible no demuestra por sí sola que el entorno esté limpio.
La limpieza debe terminar con una decisión
Tras revisar el alcance, decide si se restaura desde una copia conocida, se reconstruye la instalación o se limpia con apoyo especializado. Mantener archivos dudosos por miedo a perder una modificación puede conservar la persistencia.
Valida la solución desde una copia separada y cambia las credenciales antes de devolver el sitio a producción. La recuperación debe dejar una lista de controles y responsables, no solo una página que vuelve a cargar.
Qué no demuestra una revisión superficial
Que la portada cargue o que una herramienta no encuentre un patrón concreto no prueba que la instalación esté limpia. La intrusión puede afectar a una cuenta, una tarea cron, la base de datos o una integración externa. Compara varias fuentes y conserva el contexto de cada hallazgo.
La respuesta debe cerrar el acceso inicial y revisar las rutas que el atacante pudo utilizar, no limitarse a eliminar el síntoma más visible.
La recuperación termina cuando se han revisado accesos, dependencias y copias, no cuando desaparece la alerta del navegador. Mantén seguimiento durante los días posteriores para detectar una nueva persistencia.
Compara el estado recuperado con una instalación legítima y revisa las diferencias manualmente. La automatización puede ayudar a localizar cambios, pero no decide por sí sola qué archivo es malicioso.
El alcance debe quedar documentado antes de cerrar el incidente.
Una vez cerrado el incidente, conserva el informe, la copia del estado inicial y las decisiones tomadas durante la respuesta. Esa trazabilidad ayuda a distinguir una reinfección de una falsa alarma y evita repetir acciones sin saber qué funcionó.