Website Hacked Again After Cleaning? Why the Malware Keeps Coming Back

Delete the hacker's files, change the password, and the website is fixed. That is the belief most owners carry into a cleanup. It is also why so many of them are back on the phone to their host a fortnight later, looking at the same spam pages and the same redirect, in a worse mood. A cleanup that only removes what you can see is not a repair. It is an interval.

Over the past few weeks the security press has carried write-ups of a WordPress backdoor that researchers named SC, built so that deleting it achieves nothing ^[1]. It is the clearest illustration I have read of why the belief fails. So I will use it as the thread and take the myth apart one piece at a time.

Consider a composite case, assembled from a pattern rather than from any one customer. A chimney sweep in County Roscommon, heading into the autumn rush when every booking counts, gets a text from a regular: the booking link on the website sent their phone to a fake prize survey. A freelancer is called in, deletes a strange plugin, runs a scanner and reports all clear. Three weeks later the same text arrives from a different customer. Nothing was fixed. Something was removed.

Myth One: The Hack Is the File You Deleted

What the owner sees, the spam page or the redirect, is the payload. What keeps the attacker in is persistence: the hidden mechanisms that put the payload back. Think of the payload as the broken window and persistence as the spare key the burglar had cut on the way out.

SC takes persistence further than most. According to GBHackers' summary of the research, it creates "at least eight interdependent persistence points" ^[1]. They include:

• A small settings file that tells the server to run the attacker's loader before every page request
• Hidden PHP files carrying the restoration logic
• Two "drop-in" files that WordPress loads automatically, one of which holds a compressed copy of the backdoor
• A must-use plugin, an ordinary plugin copy, and a short implant in the active theme
• A full copy of the code stored in a randomly named row of the WordPress database
• On servers that support it, a copy held in shared memory, which survives the files being deleted

Each piece can rebuild the others. In the report's words, "deleting the visible plugin is not remediation", because the removal itself triggers the recovery, which can happen "within seconds" ^[1]. The malware also hides from the plugins screen, can create a hidden administrator account and, on shops, can switch on card skimming at checkout.

For the sweep, deleting the strange plugin was exactly the move the attacker planned for. For a shop, the stakes are higher still. A skimmer quietly copies customers' card details while the production environment looks perfectly normal to everyone, the owner included.

Myth Two: A Clean Scan Means a Clean Site

Scanners are useful. They are also narrow. Most work by comparing files against patterns already known to be malicious. Code stored in a database row, held in memory, or written to look like an ordinary caching file can pass straight through.

Google's own guidance for hacked sites warns that "there may be multiple, independent hacks in place", and tells owners to "continue to search for others" after fixing the first ^[2]. The WordPress.org guide to hacked sites makes a similar point about tools: it recommends combining remote scanners with plugin-based ones, because "each are designed to look and report on different things" ^[3].

Treat a clean scan as a smoke alarm that has stopped beeping. Good news, but not a structural survey. The cost of confusing the two is simple: you tell your customers the problem is sorted, and the next customer to find out otherwise tells you.

Myth Three: A New Password Locks Them Out

Passwords matter. But on most small business sites the way in was never the password. It was an unpatched plugin, and if that is how the attacker arrived, a new admin password leaves the door wide open. They do not need your login. They simply come back the way they came.

Patchstack's report on WordPress security in 2026 counted a little over 11,000 new vulnerabilities across the WordPress ecosystem in 2025, up by roughly two fifths on the year before, with about nine in ten found in plugins ^[4]. Close to half had no fix available at the moment they were made public. For the flaws attackers went after hardest, the median gap between disclosure and mass exploitation was around five hours. Those are figures from one security vendor's own database, so the exact numbers will vary by source, but the direction is not in dispute.

Timing matters too. WordPress.org is blunt about it: change your passwords after the site is clean, and "if you only changed them when you discovered the hack, change them again now" ^[3]. That means every access point, including the hosting panel, the database and file access, and every user account, not just yours. The same guide recommends scanning your own computer, because a trojan on the owner's laptop can capture logins as they are typed ^[3]. And a new password on your account does nothing about a hidden administrator account you cannot see.

Myth Four: Last Night's Backup Takes You Back to Before the Hack

A backup restores the site as it was when the backup ran. That is the whole deal. The awkward question is when the attacker actually got in, because it is very rarely the day somebody noticed.

Google's guide makes the point that working out "when the hack first took place" is how you decide "what backups might still be clean" ^[2]. Roll back to a backup taken after the foothold went in, and you restore the backdoor faithfully, along with everything else. Restore a genuinely clean backup but leave the vulnerable plugin in place, and you have reset the clock rather than stopped it. Google puts it plainly: "If an infected file remains on the server, your site is more likely to get hacked again" ^[5].

One limitation is worth knowing in advance. No backup can tell you when an infection started. That is a forensic question, answered from server logs and file dates, and sometimes the honest answer is that it began before your oldest restore point. In that case the clean route is a fresh install, with only content you have verified carried over. Google's guide describes exactly this for an outdated backup: "Upload and restore only the known clean files or database" ^[5]. Our complete guide to WordPress security and backups covers how restore points and retention should be set up before you ever need them.

Myth Five: Once Google Lifts the Warning, It Is Over

Google's warning is a symptom too. Clearing it before the site is genuinely clean makes the next round slower.

Google's Search Console help says a security review "can take from a few days to a few weeks to complete", and that submitting a request when the issue has not been fixed "can cause longer turnaround time for the next request, or even get you marked as a repeat offender" ^[6]. So a rushed cleanup risks a second infection and makes the second recovery longer than the first.

The business cost compounds as well. A regular who hits a red warning once will usually text you and wait. A new customer who found you on Google and hits it twice books somewhere else and never says why. We have written separately about the search fallout of a hacked website, and it is the strongest argument for doing the cleanup properly the first time.

How to Clean a Hacked Website So It Stays Clean, in Five Steps

The order matters more than any single step. Rotating passwords before the site is clean, for example, simply hands the new ones to whatever is still running.

1. Contain and snapshot. Put the site into maintenance mode and take one full copy of the infected site, because WordPress.org recommends keeping that bad copy for reference before anything is changed ^[3].
2. Identify the entry point. Find out which plugin, theme or account let the attacker in, and roughly when, so you know which restore points can be trusted.
3. Rebuild from known-good sources. Install fresh copies of WordPress, your theme and your plugins from their original sources, delete anything you do not use, and verify the database for unknown admin users, odd settings and scheduled tasks you did not create.
4. Rotate every credential after the clean. Change every password and access key for every person who can log in, and run a virus scan on the computers used to manage the site.
5. Verify, then watch. Rescan, load the site logged out on a phone and a laptop, keep watching for several weeks, and only then ask Google for a review.

For a brochure site with a handful of pages and no customer accounts, step three often makes the rest unnecessary. Rebuilding fresh and carrying over verified text and photos is frequently faster and more certain than a forensic cleanup. At the other end of the scale, a larger organisation with its own security staff and a retained incident response firm is right to call in that specialist, who will go deeper into logs and memory than any hosting support desk is set up to go. Most businesses sit between those two.

What a Host Should Bring to a Cleanup

Whoever hosts your site should make the five steps easier, not leave you to do them alone. In practice that means a few specific things:

• Several restore points, so you can roll back past the date the infection started rather than only to last night
• A safety snapshot before any restore, so a wrong guess about the clean date is not destructive
• Scanning at server level, outside WordPress, where malware that hides from the plugins screen can still be seen
• Attack traffic blocked before it reaches WordPress, so repeated break-in attempts burn out at the server
• People who will read the logs with you, in your time zone, when step two needs answering

On Web60, most of that list is simply part of the platform. Every site gets automatic nightly backups with one-click restore, manual on-demand backups, and automatic pre-restore safety snapshots. The server-level hardening, fail2ban intrusion prevention and automatic malware scanning built into Web60 sit outside WordPress itself, and a one-click staging environment means a rebuilt site can be verified before it is deployed to production. Support is handled by an Irish-based team of real people.

The limitation deserves stating plainly. Automated scanning, ours included, catches known patterns. A backdoor engineered like SC to impersonate a caching file is exactly the kind of thing any automated tool can miss, which is why steps two and three need a human. And no host can patch a plugin its developer has not fixed yet. When that happens, the safe move is to deactivate and replace the plugin, not wait for an update.

If a rebuild is where you land, the AI website builder in Web60 gives you a fresh WordPress install in about a minute, ready for the verified content you choose to bring across, all inside the same €60 a year.

The Second Infection Is the Lesson

A reinfection is rarely bad luck. It is the attacker's persistence doing its job, an entry point nobody closed, or a backup that was restored without first asking when the trouble began. Each of those has a fix, and none of them is complicated once the order is right.

If your site has been hacked before, one test tells you most of what you need to know. Can anyone name the way in, and can you see that it has been closed? When the answer to both is yes, the cleanup is finished.

Frequently Asked Questions

Why does my WordPress site keep getting hacked after it was cleaned?

Usually for one of two reasons. Either the attacker left persistence behind, hidden files, database entries or admin accounts that rebuild the malware, or the original entry point, most often an outdated plugin, was never closed. Removing the visible malware without dealing with both gives you a short break, not a fix.

Will restoring a backup remove malware from my website?

Only if the backup was taken before the attacker got in, and only if you also close the vulnerability they used. A backup from after the infection began will restore the backdoor along with everything else. Working out when the compromise started, using server logs and file dates, tells you which restore points can be trusted.

When should I change my passwords after my website is hacked?

Twice. Change them as soon as you discover the hack to cut off obvious access, then change them again once the site is verified clean. Include every user account, the hosting panel, the database and any file access, and scan the computers you use to manage the site in case a trojan is capturing logins.

How long does Google take to remove a hacked site warning?

Google says a security review in Search Console can take from a few days to a few weeks. Requesting a review before the site is genuinely clean can slow down your next request and risks the site being treated as a repeat offender, so verify the cleanup thoroughly first.

Should I rebuild my website instead of cleaning it?

For a small brochure site with no customer accounts, rebuilding on a fresh install and carrying over only verified text and images is often faster and more certain than a forensic cleanup. For shops with order histories or customer accounts, a careful cleanup is usually necessary to keep that data, ideally done by someone who can read the server logs.

Sources