It usually looks like this: pages you did not write appear on the site, the browser shows a warning, or search results carry "this site may harm your computer" next to your address. Sometimes there are no outward signs at all and the hosting company tells you — because spam is going out from your server.
What follows is an order of operations. It matters more than speed: several instinctive first moves destroy the evidence and make recovery longer.
What not to do straight away
-
Do not delete suspicious files on impulse. Until you know how they got in, deleting is tidying up symptoms. They come back the same way a day later.
-
Do not restore from a backup as the first move. If the backup was taken after the breach, you restore the breach along with the site. Find out when it started first.
-
Do not clear the logs. They are the only thing that can later tell you what happened.
First: limit the damage
-
Take a copy of the current state — files and database, exactly as they are, infection included. That is your material for the analysis.
-
Put a holding page up while you work. Better a "maintenance in progress" page than a site serving malware to visitors.
-
Change the passwords: hosting, control panel, database, admin panel, FTP, and the mailbox recovery is attached to. All of them, not only the ones that look related.
-
End the active sessions in the admin panel if you can — otherwise changing a password does not evict whoever is already inside.
Second: find the way in
Look at file modification dates — a group of files changed at the same moment is usually obvious. That is the time of the breach, and around it the web server logs show which requests came with it.
The most common entry points, in descending order:
-
An outdated CMS or plugin. Mass automated attacks do not pick a victim, they work through known vulnerabilities.
-
A weak or leaked administrator password.
-
An infected computer used to log into the admin panel or over FTP.
-
A neighbour on the hosting — on cheap plans sites are sometimes poorly isolated.
-
File upload without checking the type — a form through which something other than an image can be placed on the server.
Third: clean it out
More reliable than hunting for malicious files is redeploying from a known-clean source: a fresh CMS install, your code from the repository, updated dependencies. Content comes from the database, checked for foreign insertions: scripts inside text, and administrator accounts nobody created.
If you are cleaning by hand, check scheduled tasks (cron) and configuration files separately: that is where something is often left to restore access after the tidy-up.
Fourth: get back into search
This is the step people forget, and it decides how long the traffic loss lasts.
-
If browsers are showing a warning, request a review in the webmaster console after cleaning — it will not lift on its own for a long time.
-
Check whether pages you did not write have entered the index under your domain. They need removing, and their addresses need to return 404.
-
Check
robots.txtand the markup: a breach often adds hidden links and redirects visible only to a crawler.
Fifth: close the door
-
Update everything, and set up regular updates rather than "when we remember".
-
Turn on two-factor login for the admin panel and the hosting.
-
Configure backups that keep several weeks of history — a single "latest" copy is useless if the infection is older.
-
And check the backup restores. Unpack it on a test environment at least once. An untested backup is not a backup.
When to call for help
If payments pass through the site or customer personal data is stored on it, do not work through the incident alone: there it matters not only to clean up but to establish what was taken. The same applies if the infection returns after cleaning — that means the way in was never found.
If the site is infected right now and it is not clear where to start, we can help work through this order and find how they got in.
