La web de producción está actualizada, pero los archivos maliciosos vuelven. Un subdominio de staging olvidado todavía ejecuta un WordPress antiguo, un plugin vulnerable o una copia de una cuenta administradora. Si comparte propietario del hosting, credenciales de base o rutas de despliegue, el ataque puede regresar a producción.
Trata el staging como una aplicación completa, no como una copia inofensiva por estar oculta de los buscadores.
Descubre todas las copias de pruebas
Inventa subdominios, dominios adicionales, directorios, bases de datos, registros DNS, certificados SSL y copias del hosting. Consulta las raíces documentales del panel, no solo los enlaces visibles.
Busca nombres además de staging: dev, test, old, backup, carpetas con fechas y hosts temporales de migración. Contrasta el inventario con los instaladores del panel y las tareas de copia.
No examines dominios o servidores ajenos. Confirma con el proveedor el límite exacto de la cuenta autorizada.
Conserva y restringe el acceso
Si la copia abandonada está infectada, crea una instantánea de archivos y base y restringe inmediatamente su acceso en el servidor o el hosting. Una etiqueta noindex no es una medida de seguridad y no detiene bots.
Evita iniciar sesión en su panel WordPress desde un navegador habitual. Trabaja mediante acceso de recuperación o sobre una copia aislada.
Mantén una respuesta estática limpia para que la monitorización y el equipo no confundan el bloqueo con una caída accidental.
Compara los indicadores del ataque
Calcula hashes de los archivos sospechosos y compara rutas, cadenas del payload y horas de modificación con producción. Revisa los logs de acceso para localizar el endpoint vulnerable y las escrituras posteriores.
Un payload coincidente apoya una relación, pero no demuestra la dirección del movimiento. Ambas webs podrían haberse comprometido desde la misma cuenta de panel.
Correlaciona los datos con sesiones SFTP o del panel, tareas cron y propiedad de los archivos. Normaliza las zonas horarias antes de ordenar los eventos.
Identifica la confianza compartida
Comprueba si staging y producción comparten:
- contraseñas de administradores de WordPress;
- usuario o base de datos;
- salts y claves de autenticación;
- credenciales SFTP o de despliegue;
- un directorio padre escribible;
- caché de objetos o prefijo de tablas;
- secretos de webhooks o API.
Separa cada entorno. Rotar secretos de producción mientras staging conserva los mismos valores comprometidos puede invalidar toda la reparación.
Decide si reconstruir o retirar
Si staging ya no se necesita, conserva la evidencia y los datos requeridos y elimina su DNS público, host virtual y archivos mediante un proceso controlado y recuperable.
Si todavía es necesario, reconstrúyelo desde código de producción revisado y una base saneada. Actualiza los componentes, restringe el acceso, bloquea efectos secundarios de correo y pagos y asigna un responsable.
No clones sin control datos reales de clientes o pedidos. Aplica los requisitos de privacidad y conservación.
Impide que staging afecte a clientes reales
Sustituye claves de pago de producción por credenciales sandbox, redirige el correo saliente a un buzón de pruebas autorizado y desactiva webhooks, logística y analítica reales. Usa configuración específica por entorno en vez de corregir valores manualmente después de cada clonación.
Haz que los buscadores reciban autenticación o una respuesta restringida no indexable, no solo una indicación en robots.txt. Una copia pública puede exponer datos personales y contenido duplicado aunque no sea el origen del malware.
Limpia el límite completo de la cuenta
Inspecciona las webs vecinas, cron del hosting, configuración PHP, usuarios y artefactos de despliegue. Sustituye paquetes de confianza comprometidos y elimina puertas traseras y persistencia en base.
Corrige el componente vulnerable original y rota los accesos afectados después de asegurar los dispositivos de administración. Ajusta los permisos para que staging no pueda escribir en producción.
Verifica el aislamiento y la estabilidad
Comprueba que la web retirada ya no resuelve o que la reconstruida exige acceso autorizado. Confirma que no puede enviar correos reales, procesar pagos ni indexarse.
Monitoriza hashes de producción y logs de cuenta durante más tiempo que el intervalo anterior de reinfección. Ejecuta los despliegues y copias normales para demostrar que no restauran la versión antigua, y repite la prueba tras el siguiente despliegue.
Cuándo conviene una limpieza especializada
Solicita una evaluación si staging comparte bases, permisos o automatización con producción. Envía los nombres de subdominio y la cronología, nunca las credenciales.
Una reparación duradera elimina la entrada olvidada, separa los entornos y demuestra que producción permanece estable después de la actividad programada.