Finding Patient Zero With File Timestamps

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

You know the site is compromised. What you do not know is when it started, which matters more than it sounds — it determines which backup is safe to trust, how far back to read your logs, and how long anything sensitive was exposed. Your filesystem has been quietly recording that answer the whole time.

What the timestamps mean

Files carry several times and the distinctions matter. Modification time changes when the file contents change, and it is the one most tools show you by default. Change time records when the file's metadata was last altered — permissions, ownership, or the modification time itself. Access time records when it was last read, though many servers disable this for performance.

The useful property is that change time is much harder to fake than modification time. An attacker can trivially set a file's modification time to match its neighbours, and many do, but change time updates as a side effect of that very operation. A file whose modification time is old and whose change time is recent has been deliberately backdated, and that discrepancy is itself a strong finding.

Sorting the whole tree

The core technique is simple: list every file in the site sorted by modification time, newest first, and read the top of the list. On a site that has not been updated recently, that list starts with the things that changed most recently, which is exactly where an infection sits.

With shell access, a recursive find sorted by time gives you this in one command. Without shell access, most FTP clients can sort by date, and a recursive listing downloaded to a spreadsheet works too. The goal either way is one chronological list covering the whole site rather than folder-by-folder browsing, which is how files get missed.

Reading the clusters

What you are looking for is a cluster: a group of files all modified within the same few minutes, on a day when you did not touch the site. That is an automated process writing, and the earliest file in the cluster is usually where the compromise began.

Legitimate clusters exist too, so do not treat every group as malicious. A plugin update touches many files at once, and so does a core update or an automatic backup. The distinguishing feature is whether you can account for it — an update you performed appears in your update history, while a cluster at three in the morning on a day nothing was scheduled does not.

Establishing what normal looks like

A healthy WordPress install has a very predictable timestamp profile. Core files all share the timestamp of your last core update. Each plugin's files share the timestamp of that plugin's last update. Your theme changes when you edit it. The uploads directory grows as you add media, and older media never changes.

Against that background, anomalies are obvious: a single core file dated differently from the rest of core, a PHP file in uploads at all, a plugin file newer than its plugin's last update, or an old image whose modification time is last week. My guide on verifying core files against checksums covers proving the core case definitively rather than inferring it.

Building the timeline

Once you have the earliest suspicious timestamp, you have your investigative anchor. Take that time to your access logs and read everything in the surrounding window — my guide on reading access logs covers what to look for there. That combination, a file appearing at a specific minute plus the requests made in that minute, is how entry points actually get identified.

The date also tells you which backups predate the compromise, which is the difference between a restore that fixes things and one that quietly reinstalls the hack. My guide on backups versus cleanups covers why that distinction matters so much.

Where this technique runs out

Timestamps can be manipulated, so treat them as strong evidence rather than proof. A careful attacker will backdate files, though as noted, doing so usually leaves a change-time discrepancy that gives the game away. Database-resident malware has no file timestamp at all, which is why a clean file timeline does not mean a clean site — my guide on database malware covers that gap.

Restores, migrations and some backup tools also rewrite timestamps wholesale, which can flatten the very evidence you need. If your timeline looks uniform in a way that makes no sense, that is worth noticing rather than working around. And when the trail genuinely runs cold, reconstructing it from partial evidence is standard work for my malware removal service.

Common questions

What is the difference between modification time and change time?

Modification time updates when the file's contents change. Change time updates when its metadata changes, including its permissions or its modification time. Because backdating a file alters metadata, the change time updates as a result — so an old modification time with a recent change time means somebody tampered with the timestamp.

Can attackers fake timestamps?

Modification times, easily — and many do it specifically to blend into the surrounding files. Change times are much harder to control from a typical web shell. That is why comparing the two is worthwhile: the mismatch is often more revealing than either value on its own.

How do I list files by date without SSH?

Most FTP clients can sort a directory listing by modification date, and some can produce a recursive listing you can export. Failing that, your host's file manager usually shows dates. Getting one combined list for the whole site matters more than the tool you use to produce it.

What if all my files have the same timestamp?

That usually means a restore, a migration, or a backup tool rewrote them all at once. It destroys the timeline for investigative purposes, which is unhelpful but not sinister. In that case you will have to rely on log analysis and content comparison instead.

Does a clean file timeline mean the site is clean?

No. Malware stored in the database has no file timestamp at all, and neither does a compromised credential being used to log in legitimately. Timestamp analysis is excellent for finding file-based infections and tells you nothing about the rest, so treat a clean result as one finding among several.