Una copia puede parecer limpia porque la redirección o spam aún no se había activado. Puede contener una puerta trasera dormida, plugin vulnerable, administrador robado o tarea. El atacante también puede permanecer fuera mediante hosting, DNS o una web vecina.
No repitas la misma restauración sin conservar la cronología de reinfección.
Define qué significaba limpia
Registra fecha, fuente, archivos y base incluidos y cómo se probó. Un escáner o una portada normal no bastan.
Comprueba si incluye:
- raíz completa y ocultos;
- base y usuarios;
- mu-plugins;
- uploads y PHP desconocido;
- cron o hosting;
- webs vecinas.
Conserva el estado reinfectado antes de sobrescribir de nuevo.
Define también qué datos comerciales no pueden perderse entre la fecha de la copia y el corte: pedidos, formularios, usuarios, reservas o comentarios. Restaurar todo el volcado antiguo puede limpiar código y borrar actividad legítima. Planifica una migración selectiva y revisada cuando exista esa diferencia.
Construye una cronología precisa
Anota fin de restauración, cambios DNS o caché y primer síntoma. Registra actualizaciones, logins, cron y peticiones intermedias.
Si aparece inmediatamente, puede estar en archivos, base o caché. Tras un intervalo, revisa cron y accesos externos. Después de la primera petición, puede activarse bajo demanda.
Usa una zona horaria común manteniendo las fechas originales.
Registra quién pudo acceder durante la ventana y qué secretos continuaron vigentes. Si el mismo administrador, SFTP o token de despliegue siguió activo, la reinfección no demuestra que la copia estuviera contaminada; puede reflejar un acceso externo todavía abierto.
Analiza la copia sin conexión
Restaura en un entorno aislado sin red pública. Compara núcleo y paquetes, revisa código propio, base y eventos programados.
No abras páginas sospechosas en el navegador habitual ni permitas correos, webhooks o tareas externas.
Calcula hashes de archivos inesperados y ponlos en cuarentena. Trata la copia como evidencia no confiable, no como release desplegable.
Parchea antes de publicar
Actualiza o sustituye núcleo, plugins y temas vulnerables desde fuentes verificadas dentro del aislamiento. Retira componentes sin soporte y revisa cargas y autenticación propias.
Limpia usuarios, contraseñas de aplicación, opciones, cron y scripts de base. Rota salts y credenciales en orden.
No expongas la versión antigua ni para una prueba breve.
Desactiva correos, pagos, webhooks y cron externos en el entorno aislado. Sustituye sus secretos por valores de prueba para que una tarea dormida no contacte con clientes o sistemas reales durante la revisión.
Verifica la procedencia de la copia
Confirma qué sistema creó el archivo y si se ejecutó dentro del WordPress comprometido. Un plugin puede empaquetar fielmente malware y alguien con panel puede sustituir la copia o cambiar la retención.
Compara hashes con registros del proveedor. Revisa destino, claves de cifrado y cuenta de restauración. Si no es fiable, reconstruye aplicaciones y migra solo contenido revisado.
Revisa persistencia externa
Inspecciona usuarios y sesiones del panel, FTP o SFTP, claves de despliegue, cron de servidor, correo, DNS y CDN. Revisa cada instalación compartida.
Una copia limpia no revoca cPanel robado ni una puerta trasera en staging.
Coordina la rotación con dispositivos y automatización para no volver a robar secretos nuevos.
Realiza la rotación empezando por correo de recuperación y paneles maestros y después por credenciales dependientes. Documenta quién actualiza cada integración y confirma que el valor anterior deja de funcionar sin escribirlo en el informe.
Trata caché y varios orígenes
La CDN puede conservar una respuesta infectada y un balanceador restaurar solo un nodo. Compara origen y ruta pública con métodos autorizados.
Purga después de verificar el origen y confirma código y configuración en cada nodo.
Una respuesta limpia intermitente no prueba nada.
Antes del corte, compara hashes, configuración y versión de base en todos los orígenes. Congela escrituras durante la sincronización final para evitar que el nodo antiguo acepte pedidos o formularios que no lleguen al reconstruido.
Verifica más allá del intervalo anterior
Repite dispositivo, referrer y ruta originales y monitoriza archivos y base. Ejecuta cron y flujos administrativos permitidos.
Observa más tiempo que el intervalo entre restauración y reinfección. Revisa usuarios, tareas, conexiones y alertas.
Ensaya una restauración adicional de la nueva copia limpia en aislamiento. Así demuestras que la siguiente recuperación no depende de archivos temporales o secretos presentes únicamente en el servidor reparado.
Cuándo pedir limpieza de reinfección
Solicita ayuda si fallan varias restauraciones o no se confía en la copia. Envía cronología, síntomas públicos y fecha, no el archivo ni credenciales.
Una recuperación fiable limpia antes de desplegar, cierra accesos externos y demuestra que la ruta original ya no funciona.