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

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.

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.