Remove malware from a website

Malware on a website is nearly always one of four classes: a php file that runs commands (shell), a spam SEO payload that injects hidden text into pages, a phishing clone of the site you already run, or a redirector that sends visitors elsewhere. The class names the cleanup: isolate, then remove payload and fix the hole, then verify.

Isolate first

• Take the site offline for inspection. Put it behind a "closed for maintenance" page or unpublish the domain at the edge; do not keep feeding a live payload while you clean.
• Lock the obvious accounts now: change the host/control-panel password, the database password, the FTP/SFTP key, and every CMS admin password.
• Do not delete the infected copies yet. Keep an untouched copy (a zip outside the web root) so you can diff against it and hand it to an expert with a full story.

Find the payload

1. Start from the infection, not the whole site. A redirect to example.cn or an injected eval() in an index file is the visible signal; that file is the doorway, not the whole invasion.
2. Diff files against a known-good copy. Compare file list and hashes over the last update you trust. Any PHP file that is new, or an old file that changed without you changing it, is suspicious.
3. Read the logs for the entry. The error log and host access log show the request that comes in and the wp-admin path that creates a new admin, which tells you the exploit class.
4. Scan with a scanner you trust by hand, then verify. The real value is the file list: a plugin that dies on a file_put_contents line names the file to look at.

Common payload locations:

Clean and harden

1. Delete the payload file and the directory that hosted a .php in uploads if the host allows uploads there.
2. Replace core and themes from clean copies. Reinstall WordPress core, and reinstall the theme and plugins fresh. Preserve only the custom code you actually wrote (a copy of your theme functions.php and any child-theme snippets), and re-add it by hand after the clean install.
3. Reset secrets. New salts, new DB password, new admin password, revoke any SSH key you did not create.
4. Cut the entry route: remove the plugin that carried the exploit, restrict wp-admin by IP if you are the only admin, and empty the uploads of .php files.

# banish PHP from uploads
<FilesMatch "\.php">
  Require all denied
</FilesMatch>

1. Clean the database text. Remove the injected eval(base64_decode rows and any cross-site script payload from the wp_options and wp_posts tables.

Verify removal

• Run the site under the scanner again and diff the file list; zero new files and zero hits is the pass.
• Test the real pages you care about in a private window with scripts off: no redirect, no overlays.
• Watch the logs for one cycle: a single attacker probe that suddenly works again is the sign the other half of the entry point is still open.
• Check the browser reputation tools and the block-list status of the domain in a search console.

Prevention

• Keep core, plugins and themes on the current secure branch and remove scripts no one uses. Reinfection rides the same unpatched door.
• Enforce per-site accounts: each where FTP, SFTP, SSH and DB get a separate password, and the owner rotates them on a schedule.
• Keep a clean restore point and an offsite file backup that you have tested restores from. Back up before site changes.
• Never upload a ZIP and unzip it in the web root from an admin panel; payloads love an unzip service.

When to involve a professional

If any of these are true, stop cleaning and hand the site to a professional response team: money or identity data left on the site, Phishing text targeting your customers, or a domain used to send spam (check the block-list). They will quarantine the payload, keep the evidence, and supervise the restore of data you may not be able to explain. Do not delete files before an expert copies them for list.