# Restoring a Backup Restores the Entry Point ## Claim A clean backup reverts the payload of a compromise but preserves whatever let the attacker in, so restoring from backup without finding and closing the entry point doesn't end an incident — it schedules the next one. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies to any compromise where the vulnerability is in the environment (an outdated or abandoned plugin, an exposed upload path, weak credentials) rather than in the specific files an attacker dropped. - Strongest where the visible symptom (defaced files, a planted index page) is a byproduct of the compromise rather than the compromise itself — removing the symptom feels like a fix and isn't one. - Breaks down where the backup genuinely predates the vulnerability's introduction (a version before the flawed plugin was installed) — there, restoration and remediation coincide. - Does not by itself identify the entry point; it only explains why skipping that step produces reinfection rather than resolution. ## Evidence > [!quote] ID:rw_01m1h2emydshp9ph6v7p97g46s > "And then what I was still wary, but then the next day, all the files were back again. All those weird-named files came back into the server. So that, OK, there's obviously a hole here somewhere. So we then needed to find what was the hole that somebody was getting in through and being able to upload files." Rick Curran, describing a real cleanup: deleting the obfuscated PHP files scattered across the server made the site look fixed for one day, then the same files reappeared. The pivot from removal to root-cause investigation only happened because the reinfection was visible. The actual vulnerability, found afterward, was an abandoned plugin with an unfiltered upload path on a six-to-seven-year-old site — update automation had nothing to report because there was nothing left to update. ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — home for incident-response and hosting-security patterns this claim belongs with. - [[3. Resources/Permanent Notes/Checksum Verification Closes the Gap Auto-Update Status Leaves Open]] — extends; that note names the gap between "auto-update reported success" and "this install is actually patched," and this one names the same gap from the restoration side: "the backup restored cleanly" and "the hole is closed" are equally different claims. ## Tests / falsifiers - Track incident write-ups where a restored backup was followed by reinfection within days versus ones where it wasn't — if reinfection is rare after backup-only remediation, the claim overstates the risk. - A case where the backup itself is old enough to predate the vulnerable plugin's installation would show the claim doesn't apply once restoration and remediation happen to be the same action. ## Source - [[3. Resources/Readwise/Articles/The Website Hack That Looked Fixed Until the Malicious Files Came Back]] — Melapress Security Stories interview with Rick Curran. Vendor content (Melapress, via Patchstack); the "3,000 plugins closed" figure cited by the host is unsourced and should be verified before repeating. The cleanup account itself is a first-person practitioner narrative, not documented incident data.