Credenciales SFTP o SSH robadas llevan el incidente fuera de WordPress. Reinstalar plugins o cambiar admins no elimina un acceso que sigue existiendo en el sistema o la cuenta de hosting. Trata cada clave o contraseña expuesta como comprometida y usa registros de acceso/archivos para acotar el periodo.
Revoca la vía antigua antes de investigar con ella
Desactiva o rota la cuenta/clave expuesta y termina sesiones activas. No sigas administrando producción con la misma credencial que investigas.
Revisa el historial de autenticación
Consulta IP/origen, horarios, logins correctos/fallidos y auditoría disponible. Correlaciónalo con modificaciones de archivos y ventanas de despliegue.
Busca persistencia por encima de WordPress
Revisa authorized_keys, perfiles shell, cron/systemd/tareas del proveedor, hooks y webs hermanas escribibles. wp-content limpio no basta.
Separa claves de despliegue y cuentas humanas
Identifica CI/CD, backup y agencias que reutilicen credenciales. Rota secretos dependientes sin romper automatizaciones en silencio.
Reconstruye archivos desde fuentes fiables
Compara aplicación con repositorio/paquetes conocidos. Conserva uploads/contenido aparte y analízalos en vez de confiar en ejecutables modificados.
Comprueba que la credencial antigua ya falla
Prueba la revocación desde un cliente externo y vigila nuevos logins. Documenta propietarios, caducidad y mínimo privilegio de las nuevas claves.
Usa rotación de credenciales tras el compromiso y recuperación del panel si también dudas del hosting.
Comprueba dónde se guardaba la credencial
Revisa portátiles de desarrollo, secretos CI, gestores de contraseñas, entregas antiguas de agencia y scripts de backup que puedan contener la misma credencial SFTP/SSH. Rotar la clave en servidor sin retirar las copias expuestas deja una vía predecible para otro incidente.