Lesson 1 of 1 in Building the Timeline
When Did It Start
Every later decision depends on one date, and the file that tells you is rarely the one you expect.
3 min read
Not yet reviewed
You know how they got in. The next question decides everything practical: when. Which backup is safe to restore, how long they have had access, and whether the data they could reach changed in that window — all three hang off a single date.
Three clocks, and they disagree
A Linux file carries three timestamps, and knowing which is which is most of this chapter.
Can be forged trivially
mtime — when the contents last changed. `touch -d` rewrites it.
atime — when it was last read. Often disabled entirely.Harder to forge
ctime — when the inode last changed: permissions, owner, links, or mtime itself.
Updating mtime with `touch` UPDATES ctime, and there is no flag to stop it.This is why a file whose mtime is older than its ctime is worth a second look. Somebody set the mtime back, and the act of setting it left a mark they could not set back.
$ stat -c '%n mtime=%y ctime=%z' /var/www/html/index.php
/var/www/html/index.php mtime=2026-03-02 09:14:11 ctime=2026-08-14 02:19:47
# The contents claim to be from March. The inode changed this morning.
An attacker who backdates a webshell to blend in with its neighbours leaves exactly this. They cannot avoid it from userspace, and most do not try, because most do not know.
Reading the filesystem in time order
$ find /var/www -type f -printf '%T@ %TY-%Tm-%Td %TH:%TM %p\n' | sort -rn | head -5
1755138000 2026-08-14 02:20 /var/www/html/uploads/avatars/a7.php
1755137880 2026-08-14 02:18 /var/www/html/index.php
1741000000 2026-03-02 09:14 /var/www/html/config/app.php
1740999000 2026-03-02 09:10 /var/www/html/composer.json
1740998000 2026-03-02 09:08 /var/www/html/composer.lock
Two files changed this morning and everything else is from March. The gap is the incident, and the earlier of the two is where it began — 02:18, which matches the answered request you found in the access log at 02:17.
Note
Corroboration is the whole method. One artefact is a guess; two artefacts from different sources agreeing on a minute is a finding. The access log and the filesystem do not know about each other, so when they agree you can write it down.
What has been cleaned
Their shell history would settle it. Can I just read ~/.bash_history?
Read it, yes. Trust it, no. It is a plain file owned by the user, so it can be edited or emptied like any other — and a competent attacker sets HISTFILE=/dev/null before typing anything, so there was never a history to delete.
I do it in the first command, along with unset HISTFILE. If you find my history intact, either I was careless or I wanted you to read it.
Take care
Absence is not innocence. An empty history, a log with a gap, a missing file — these are findings, not dead ends. Write down what is missing and when the gap starts; a truncated log usually ends at the moment somebody decided to truncate it.
A file's mtime is two months old and its ctime is this morning. What is the most likely explanation?
touch -d then set mtime back. But touching the file also updates ctime, and userspace cannot set ctime — so the pair disagrees in exactly this direction.Two dates now go in your notes: the earliest artefact you can defend, and the latest. Everything between them is the compromise window, and the backup you restore from must predate the first.