# Cleaning up an infected site: the method, and why restoring isn't always enough

> Reinstalling a backup looks like the fastest shortcut, but that speed only pays off if the backup is genuinely clean. Here's how to choose between a targeted manual cleanup and a restore, and why an old infection makes that choice harder than it looks.

- Source canonique : [https://allaux.fr/en/securite/nettoyer-un-site-infecte](https://allaux.fr/en/securite/nettoyer-un-site-infecte)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> The choice comes down to one question first: how long has the infection been active, and is there a backup that's known for certain to predate it? Without a clear answer, a targeted manual cleanup of the files and database stays more reliable than a restore that might just reinstall the problem after a delay.

## Two approaches, one question to settle first

Restoring a backup puts the site back exactly as it was on a given date. That's fast, but it only works if that date is before the very start of the infection, not just before the problem was noticed: those are almost always two different dates.

A targeted manual cleanup means pinpointing the injected code and any accounts or access the attacker added, then removing them without starting from scratch. It takes more time to investigate, but it doesn't depend on a clean backup existing.

The two approaches aren't always at odds: an old, reliable backup can still serve as a reference point for comparing files, even if it isn't used as-is to bring the site back online.

## A documented example of the gap between a flaw and its discovery

In 2014, Sucuri documented the campaign known as SoakSoak, linked to a flaw in the Slider Revolution plugin for WordPress. A fix had already been released by the developer in February 2014, but mass exploitation of the flaw was only observed between September and December that same year, notably through themes that bundled an outdated copy of the plugin without the site owner's knowledge.

That case makes a simple point: when an infection is noticed says nothing about when it actually started. A backup that's several weeks, or even several months, old can therefore already contain malicious code that stayed dormant until it activated.

## The partial-restore trap

> An infection can sit in both the files, as injected code or an added file, and the database, in content or configuration fields depending on the CMS. Restoring only the files, or only the database, while assuming the problem is fixed, is one of the most common mistakes: whichever part wasn't restored can be enough to reinject the infection into the other as soon as the site goes back online.

## A place a simple file comparison won't cover

On PrestaShop, comparing the core files against a clean install of the same version reveals modified core files. But the override system, which legitimately lets a class or controller be extended without touching the original file, falls outside that automated comparison: a file placed in override/ is expected to hold custom code, so a malicious override blends in without triggering an obvious discrepancy. That folder deserves a line-by-line read, not just an automated diff.

## The step-by-step method

- **Checking whether the site is still compromised** — The checks that tell you the infection has really gone, before calling the cleanup finished. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Before cleanup, the first two hours** — The exact order of first actions once a compromise is confirmed. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))
- **After cleanup, what needs to change** — The structural habits that prevent a repeat in the short term. ([/securite/se-proteger-apres-un-nettoyage](/securite/se-proteger-apres-un-nettoyage))

## FAQ

### Is a backup that's several months old automatically reliable?

No. It's only reliable if it predates the very start of the infection, which is rarely known for certain. A backup's age is a clue, not a guarantee.

### Should I restore the files or the database first?

Neither on its own is enough. An infection affecting both won't go away if only one side is fixed: the files and database need to be checked, and if necessary restored, together.

### How do I know how long my site has been infected?

File modification dates give a first clue, though treat them with caution since they can be altered, alongside the history of available backups, access logs if they were kept, and when the first symptoms were flagged by customers or by Google.

### Does manual cleanup require knowing how to code?

Yes, to reliably tell legitimate code apart from injected code, particularly in a folder like override/ where custom code is expected. That's why this step usually falls to a developer rather than an automated cleaning tool on its own.

### Can an automated cleaning scanner replace a manual cleanup?

It can remove already-known malware signatures, but it often misses custom-built code or a legitimate override hijacked for malicious purposes. Useful alongside a manual check, not instead of one.