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

tktkkame — Wed, 21 Oct 2026 01:46:16 +0000

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

Time	What happened
02:23	A file is dropped on `web03`
02:23	Its mtime is rewritten to 2018-04-02
02:24	It's executed (`apache2 → sh → .update`)
Investigation	`stat` shows contradictory timestamps

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.

One SSH key, one cron line: a 5-minute persistence audit

tktkkame — Wed, 21 Oct 2026 01:46:15 +0000

The scenario is fictional (RFC 5737 IPs). Detection only; no attack steps.

You found the intrusion, killed the process, changed the password. Done? Attackers plan to be locked out. Within minutes of getting in they build a second and third way back.

What you'll learn

The two classic persistence spots: SSH keys and cron
Baseline diffs that find them in minutes
How to tell admin changes from attacker changes
Why you preserve before you clean

The story at a glance

Time	What happened
02:20	Root login succeeds after brute force
02:26	An unknown key appears in root's `authorized_keys`
02:27	A cron entry runs every minute
Later	Password reset and process kill don't help

Keys: diff against a saved baseline

find / -name authorized_keys -exec sha256sum {} \; | sort > /var/lib/keys_base.txt   # normal times
find / -name authorized_keys -exec sha256sum {} \; | sort > /var/lib/keys_now.txt    # investigation
diff /var/lib/keys_base.txt /var/lib/keys_now.txt

In my sandbox test only root's file showed up in the diff.

Cron: new files and fetch-and-execute

find /etc/cron.d /var/spool/cron -type f -exec sha256sum {} \; | sort
grep -REl 'curl[^|]*\|[[:space:]]*(ba)?sh' /etc/cron.d /etc/crontab /var/spool/cron

The grep flagged the fake malicious cron and ignored a legit backup job. Legit tools sometimes use curl | bash, so check whether the destination is yours.

Normal vs. attack

	Normal	Attack
Changed by	config management (ansible), uid 0	`www-data` (uid 33) with euid 0
Path	change ticket exists	from the web server process
When	maintenance window	minutes after intrusion

Catch it live: auditd (from the book, not sandbox-tested)

-w /root/.ssh/authorized_keys -p wa -k ssh_key_change
-w /etc/crontab -p wa -k cron_persist
-w /etc/cron.d/ -p wa -k cron_persist
-w /var/spool/cron/ -p wa -k cron_persist
-w /etc/systemd/system/ -p wa -k systemd_persist

Preserve first, clean later

Copy files, hash, record stat times and who changed them. Only then remove the key line and the cron file.

Takeaways

Assume redundancy: keys, cron, systemd, profile.d, other users' ~/.ssh. Save the baseline before you need it.

Next: SSH that skipped the bastion.

Adapted from chapters 26 and 9 of my Japanese book on server defense.

DEV Community: tktkkame

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

What you'll learn

The story at a glance

Three clocks

One-line detector

False positives

Fact vs. inference

Takeaways

One SSH key, one cron line: a 5-minute persistence audit

What you'll learn

The story at a glance

Keys: diff against a saved baseline

Cron: new files and fetch-and-execute

Normal vs. attack

Catch it live: auditd (from the book, not sandbox-tested)

Preserve first, clean later

Takeaways