A file backdated to 2018 with touch, caught by one line

The scenario is fictional (RFC 5737 IPs). Only run these on systems you own.

"This file was last modified in 2018, so it's old, ignore it." Have you ever reasoned like that? mtime is writable by anyone with touch. What attackers forget is the clock they can't write.

What you'll learn

• The three timestamps on a Linux file (mtime, ctime, birth)
• Which one touch -d can forge, and which it can't
• A one-line detector, tested in a sandbox
• How to separate false positives (package updates, archive extraction)

The story at a glance

Three clocks

Modify: 2018-04-02 09:00:00   <- mtime (content), forgeable
Change: 2026-01-20 02:23:41   <- ctime (metadata), set by the kernel
 Birth: 2026-01-20 02:23:41   <- creation time (filesystem dependent)

Rewriting mtime with touch -d updates ctime to "now". The forger stamps their own forgery.

One-line detector

find /dev/shm /tmp /var/tmp -type f -printf '%C@ %T@ %p\n' \
  | awk '$1-$2>86400*30 {print $3}'

Flags files whose ctime is 30+ days newer than mtime. In my sandbox test, the forged file was flagged and a normal file was not (5/5 checks passed).

For ext4, debugfs -R "stat <inode>" /dev/sda1 | grep crtime shows creation time directly (from the book; not covered by the automated test).

False positives

Package updates, tar/zip extraction (preserves mtime, so ctime = extraction time) and restores all trigger it. Never conclude from this alone. Correlate with execution records and location (/dev/shm, /tmp).

Fact vs. inference

• Fact: mtime 2018-04-02, ctime 2026-01-20 02:23.
• Fact: executed at 02:24 (auditd).
• Inference: mtime was forged (basis: ctime/birth contradiction).

Takeaways

• touch forges mtime/atime, not ctime or birth.
• ctime > mtime by a wide margin is the marker. Correlate before concluding.

Next: persistence, one key and one cron line.

Adapted from chapters 28 and 30 of my Japanese book on server defense for SOC, CSIRT and forensics.