Stolen SFTP or SSH credentials move the incident outside WordPress. Reinstalling plugins or changing admin passwords cannot remove access that still exists at the operating-system or hosting-account layer. Treat every exposed key/password as compromised and use login/file evidence to bound the period of access.
Revoke the old path before investigating from it
Disable or rotate the exposed account/key and terminate active sessions if possible. Do not continue administering production with the same credential you are trying to investigate.
Review authentication history
Check source addresses, timestamps, successful/failed logins and commands/audit data available from the provider. Correlate with file modifications and deployment windows.
Inspect persistence above WordPress
Review authorized_keys, shell profiles, cron/systemd/provider tasks, deployment hooks and writable sibling sites. A clean wp-content directory is not enough.
Separate deployment keys from human accounts
Identify CI/CD, backup and agency integrations using the same credentials. Rotate downstream secrets without breaking automation silently.
Rebuild affected files from trusted sources
Compare application files with known-good repository/vendor packages. Preserve user uploads/content separately and scan them rather than trusting modified executables.
Verify that old credentials truly fail
Test revocation from an external client and monitor new authentication events. Then document the new key owners, expiry/rotation policy and least-privilege scope.
Use post-compromise credential rotation for the wider account list and control-panel recovery if hosting access is also suspect.
Check where the credential was stored
Review developer laptops, CI secrets, password managers, old agency handoffs and backup scripts that may contain the same SFTP/SSH credential. Rotating the server-side key without removing exposed copies leaves a predictable path to the next incident.