Skip to contentExploitQuest
Join free
LearnDigital Forensics & Incident Response

Lesson 1 of 1 in Getting Back, and Writing It Down

Which Backup Is Safe

The timeline was not academic - this is the decision it exists for, and rebuilding usually beats cleaning.

3 min read

Not yet reviewed

You have a compromise window: an earliest defensible artefact, and a latest. Restoring means choosing a backup from before the earliest, and that is the entire reason the previous chapters happened in that order.

Clean, or rebuild

Cleaning in place

You must find every mechanism. Missing one loses everything.
You are trusting tools that may themselves have been modified.
Cheap, fast, and its failure is silent.

Rebuilding

A new host, from your own configuration, restoring only data.
You need only be right about one date.
Slower, and its failure is loud - the machine does not come up.

Rebuild whenever you can. Cleaning asks you to prove a negative on a machine you no longer trust; rebuilding asks you to be right about the compromise date, which you have just spent a chapter establishing.

Restore data, not the system. Database dumps, uploaded files and content come back from backup; packages, configuration and code come back from your own repository, freshly installed. That distinction is what stops a backdoor riding along inside a directory nobody inspects.

Take care

Rotate every credential that machine held before the new one is exposed, not after. Deploy keys, API tokens, database passwords, the mail relay. Assume all of them are known, because you cannot prove otherwise - the same reasoning as the last chapter, applied to something you can actually fix.

Then close the entry point

You know how they got in, because you found it in the access log. If that was a traversal in an upload handler, the rebuilt machine has the same traversal. Restoring a clean copy of vulnerable code produces a clean copy of the same incident, on a schedule set by whoever is scanning you.

Your timeline puts the earliest artefact at 02:18 on the 14th. Backups run nightly at 03:00. Which do you restore?

The write-up

The report is the deliverable. Not the shell commands and not the clever grep - the document that says what happened, which somebody who was not there can act on.

1. What happened, in one paragraph, in plain language.
2. The timeline: what, when, and which artefact says so.
3. What was reachable, and what we can and cannot say was taken.
4. What we changed, and what is still outstanding.
  1. Line 1Written for the person who has to decide something, not for another engineer. If it opens with a CVE number, it is the wrong document.
  2. Line 2Every claim carries its evidence - "02:18, index.php modified, per stat ctime" - so a reader can check you rather than trust you.
  3. Line 3The honest-answer sentence from the previous chapter goes here verbatim. This is the line that will be quoted back to you.
  4. Line 4The part everybody omits, and the only part that prevents a repeat. An incident with no changes listed taught nobody anything.

Tip

Write it the same day, even badly. A rough report while the details are fresh is worth more than a polished one next week, because next week you will not remember which of two timestamps you trusted, or why.

That is the loop closed: preserve, triage, find the entry, build the timeline, find the persistence, bound the loss, rebuild, write it down. The lab for this course hands you a box and asks for all eight.