After the malware cleanup: the 30 days that decide whether it comes back
A WordPress cleanup removes the payload. The entry point is what reinfects you. Here is the 30-day routine we run after every restoration.
The cleanup is the easy part. We can strip a WordPress site of injected PHP, scrub the database of spam links, and hand it back looking normal inside 48 hours, from $240.
The call we hate is the one that comes eleven days later. Same site, same symptoms, same customer, and now they think we did a bad job. Sometimes we did. More often the cleanup worked exactly as intended and nobody closed the door the attacker walked in through.
This is about the month after.
A cleanup removes the payload, not the reason
Almost every hacked WordPress site has two separate things on it. There’s the payload, which is what you noticed: the spam pages, the redirect to a pharmacy site, the miner eating your CPU, the phishing folder your host emailed you about. And there’s the entry point, which is how it got there.
Scanners are good at the first and mostly blind to the second. Wordfence will find an obfuscated eval block in a theme file. It won’t tell you the actual cause was a contact form plugin with an unauthenticated file upload, patched in April, still sitting at the old version because somebody switched auto-updates off in 2023.
Reinfection isn’t the malware coming back to life. It’s the same hole being used again, usually by an automated scanner that already has your domain on a list. Once a site has been exploited successfully, it gets revisited. That’s why the second hack tends to arrive faster than the first one did.
We’ve written separately about why WordPress sites keep getting hacked, which covers the causes. This one assumes the break-in already happened and the site came back clean this morning.
Day 0: rotate more than the WordPress password
Everyone changes the admin password. Almost nobody changes anything else, and the attacker rarely needed the admin password to begin with.
What we work through on every restoration:
- WordPress users. Delete the ones nobody recognises rather than demoting them, and look hard at any administrator created in the week before you noticed something wrong.
- The hosting control panel login, plus any panel users a developer or previous agency still has.
- SFTP and SSH passwords, and stale authorized_keys entries. We find forgotten keys on roughly a third of the servers we take over.
- The database user in wp-config.php. One line to change, skipped almost every time.
- The eight WordPress salts, also in wp-config.php. Changing them ends every active session, including the attacker’s.
- API keys sitting in plugin settings: payment gateways, SMTP credentials, shipping accounts, anything with a token in a text field.
SMTP credentials matter more than people expect. A compromised install with working mail settings is worth more to a spammer than the site itself, and mail abuse is what puts your domain on a blocklist. If the site sends transactional mail, our notes on SPF, DKIM and DMARC setup cover what to re-check after an incident.
Your backups may already be infected
This is the failure we see most, and it isn’t really anyone’s fault.
A site gets cleaned. A week later an update breaks something, the owner restores last month’s backup because it’s “from before the hack”, and the backdoor comes back with it. The restore worked perfectly. That was the problem.
Backdoors sit quietly. Someone who gets in through a plugin vulnerability will often plant a small file uploader somewhere harmless-looking and then do nothing for weeks. The damage you spotted in September may date from July. If your retention is 30 days and the intrusion is 60 days old, every backup you hold is contaminated, and none of them look it.
So after the cleanup, take a fresh full backup and label it as the first known-good copy. Keep the older ones for content recovery, but treat them as suspect and never restore one wholesale. Pull individual files or database rows out of them instead. We went through the practical side of that in backup strategies we’ve actually tested.
Days 1 to 7: watch before you harden
The instinct after a hack is to install a security plugin and switch on every option. Resist it for a week.
Aggressive hardening on day one hides the evidence you still need. Block PHP execution in uploads, add a WAF, rename the login URL and lock down file editing all on the same afternoon, and you’ll never learn which of those was load-bearing. You also won’t see the attacker try again, because the attempt fails silently.
Leave logging on and actually read it. Failed and successful admin logins with IPs, because a successful login from an unexpected country in week one means credentials are still out there. 404 patterns, because automated scanners go looking for the file they planted, and a burst of requests for something like /wp-content/uploads/2024/03/about.php tells you a backdoor used to live at that path and something still expects it. Outbound mail volume, because a jump usually means the site is relaying. File change alerts on wp-config.php, .htaccess and the theme directory.
Modification dates are worth an hour of anyone’s time. Sort the whole WordPress directory by modified time and read the top fifty entries. Legitimate changes cluster around update events. A single PHP file touched at 03:14 on a Tuesday when nothing else moved is the thing you’re looking for.
Days 7 to 30: the checks nobody enjoys
Week two onward is dull, and it’s where reinfections get caught.
Find out whether Google still thinks you’re dangerous. Search Console will show an outstanding manual action or security issue, and a “deceptive site” interstitial can outlive the cleanup by weeks if nobody requests a review. Your host’s scanner may also still have you flagged internally, which is a separate conversation with a separate support queue.
Look at your own search results for pages you didn’t write. Japanese keyword hacks and pharma injections often serve clean HTML to normal visitors and spam to Googlebot, so a site can look fine in a browser while the index fills with junk. A site: search on your domain takes thirty seconds.
Re-run a full scan at day 14 and again at day 30 rather than once. Signature databases move, and a backdoor nobody recognised on cleanup day can get flagged a fortnight later. That’s caught things for us more than once.
Then close the hole, assuming you found it. Update or drop the vulnerable component. If it’s a plugin the site depends on and the vendor has gone quiet, that plugin is a liability with a deadline on it, and replacing it costs less than the next incident. Our WordPress security audit mostly exists to answer that question properly.
When the site isn’t the problem
Sometimes we clean a site twice and it comes back a third time. At that point we stop looking at WordPress.
On shared hosting, one compromised account can reinfect its neighbours through world-writable directories or a shared PHP process. Five WordPress installs under one hosting account, one of them cleaned, means you cleaned one. The other four are still serving the same backdoor.
On a VPS the question is whether the attacker only ever had web-user access. A cron job owned by www-data that re-downloads a payload every night will beat any number of file cleanups. So will a modified system binary, though that’s rarer than forum threads make it sound.
We don’t guess at this. If two cleanups haven’t held, the next step is a look at the server rather than a third pass over the same files. Different job, different price. It’s also usually the point where we’ll say that rebuilding on a fresh box costs less than chasing it further.
What this costs
Our WordPress cleanup starts at $240 and most sites are back inside 48 hours. That covers the scrub, the credential rotation above, and a written note on what we think the entry point was.
The 30-day watch isn’t bundled in by default, because plenty of people would rather work through it themselves with a list like this one. When someone wants it handled, it runs through our compromise recovery bundle, which pairs the cleanup with a hardening pass and the follow-up scans.
We won’t promise a site can’t be hacked again. What we’ll say is that the ones that come back are nearly always the ones where the cleanup got treated as the finish line.
Next in the journal
- 22 Sep 2026 cPanel to CyberPanel without the downtime The auto-import moves files and databases. It does not move cron jobs, PHP versions, mail filters or grants. Here is the cutover sequence we…
- 01 Sep 2026 systemd timers vs cron: when we switch and when we don’t We run about 40 scheduled jobs across the servers we look after. Backups, log rotation, certificate renewals, a few sync scripts, the monitoring check…