Introduction

When malware comes back after a cleanup, the first cleanup was incomplete. Something still has access. It might be a forgotten admin user, a backdoored plugin, exposed hosting credentials, a writable deployment path, or a reinfection source outside the web root. The goal is not to clean the same files again. The goal is to remove persistence and close the original compromise path so the site cannot be recontaminated.

Symptoms

  • Malicious files or redirects return after an earlier cleanup
  • Security scans look clean briefly, then new indicators appear again
  • Suspicious admin users, cron jobs, or modified files reappear
  • Search engines or browsers flag the site again after temporary recovery
  • The problem returns after logins, deployments, or plugin updates

Common Causes

  • The attacker still has valid access through hosting, WordPress, SFTP, database, or API credentials
  • A hidden backdoor, scheduled task, or modified include path survived the earlier cleanup
  • An outdated plugin, theme, or custom component remains vulnerable
  • The restored backup already contained compromised files or database content
  • Another connected system continues writing malicious content back into the site

Step-by-Step Fix

  1. Treat the reinfection as proof that the original access path is still open, and preserve evidence before deleting more files.
  2. Compare file changes, timestamps, user activity, and logs to determine what reappeared first and from where.
  3. Review WordPress users, hosting accounts, SSH or SFTP access, database users, API keys, and deployment credentials for anything unauthorized or over-privileged.
  4. Search for persistence mechanisms such as backdoored plugins, modified core files, malicious cron jobs, startup scripts, or writable hidden paths.
  5. Patch or remove the vulnerable component that allowed the original compromise, rather than relying on repeated file cleanup alone.
  6. Rotate every credential that could have been exposed, including admin passwords, hosting access, database secrets, mail credentials, and API tokens.
  7. Restore from a known clean source only after you have verified the backup itself is not already compromised.
  8. Monitor file integrity, admin activity, outbound requests, and security alerts closely after recovery to catch any remaining persistence quickly.
  9. Keep a written incident record so future cleanup work includes the real compromise path, not just the visible malware artifacts.