Malware recovery for a UK marketing agency
Spam pages in Google, a server that kept timing out, and administrator accounts nobody on the team had created. This is what was actually on the site and how it came off.
What the agency was seeing
They did not find this through a security scan. They found it the way most people do, by noticing that something was wrong with their own website.
Pages they never wrote
Search results were filling up with pages the team had never published. Anyone clicking them landed somewhere else.
The site kept timing out
Normal traffic was enough to return a 504 error. The server was busy serving files that had no business being there.
Access they did not give
There were administrator accounts on the site that nobody at the agency had created or recognised.
Quick numbers
What was actually on the server
A scanner reports a number. It does not tell you what the number is made of. This is what the files turned out to be once they were read.
Around 12,000 malicious files spread through the WordPress core, the theme, the plugins and the uploads folder
More than 346 ZIP archives holding malicious content, sitting in folders that should only ever hold images
Webshells saved with no file extension at all, one of them named simply C
Administrator accounts created by the attacker, not by anyone at the agency
Extra tables added to the database that WordPress itself never uses
The same backdoor copied into several folders, so deleting one of them changed nothing
Two of the places it was hiding.
A folder named theme, sitting right next to the real themes folder. One letter apart. The admin dashboard never shows it.
An unknown file dropped into mu-plugins. WordPress runs everything in that folder on every request. There is no activate or deactivate button for it.
How the cleanup ran
A full backup before touching anything
Files and database copied off the server first. If a cleanup breaks something, you need the broken version to compare against.
Find out how they got in
Access logs, file dates and plugin versions read side by side until the entry point and the date it opened were clear.
Remove every malicious file
Core files replaced with clean originals. Theme, plugins and uploads cleaned folder by folder, by reading the files, not by trusting a scanner to guess.
Clean the database
Attacker tables dropped. Accounts the team never created removed. Every remaining user and role checked by hand.
Close the way back in
Every password changed, the database password included. Security salts regenerated. File editing switched off, xmlrpc blocked, .htaccess rebuilt from a clean copy and Wordfence configured properly.
Fix the timeouts, then watch
The 504 traced to .htaccess rules and LiteSpeed cache settings and corrected. The site was then monitored for a week before I called it finished.
Where it ended up
The agency ran this between 13 and 25 September 2025, with monitoring for a week after that. Their own SEO team applied 410 responses to the spam URLs, and Google started dropping those pages from search.
The site loads normally again, with no 504 errors under regular traffic
Not one malicious file left anywhere on the server
The attacker accounts and the extra database tables are gone
Spam URLs now return 410, so search engines remove them instead of recrawling them
Hardening in place so the same route cannot be used a second time
A written handover of what was found, what was removed and what was changed
Who did the work
I led this cleanup and did the file and database work. Ali and the team handled hosting access and the retests. The agency’s own SEO team dealt with the search side once the server was clean.
Seeing any of this on your own site?
Spam pages you did not write, sudden timeouts, or an admin account you do not recognise. Send me the site address and I will tell you what I can see before you pay anything.