find recently modified files after an incident

something feels off, now what

you log into a box and something's weird. maybe a process you don't recognize, maybe a cron job fired at 3am, maybe your homelab vm is just acting sluggish for no reason. before you panic or start nuking things, ask the one question that actually moves you forward: what changed, and when.

on linux, "what changed" usually means "what got modified recently." and the fastest way to check that in the two places attackers love most, /etc and /usr/bin, is one line of find.

the command

find /etc /usr/bin -mtime -1 -type f 2>/dev/null

this is dead simple once you break it apart:

find /etc /usr/bin tells find to search two directories. /etc is your system config, everything from cron jobs to ssh settings to user accounts lives there. /usr/bin is where a huge chunk of your executable binaries live. these are the two spots where a compromise tends to leave fingerprints, either a modified config or a swapped-out binary.

-mtime -1 means "modified within the last 1 day." find's time math is a little backwards from what you'd expect, -mtime -1 means less than 1 day ago, +1 would mean more than 1 day ago. if you want the last hour instead of the last day, swap this for -mmin -60.

-type f restricts results to actual files, not directories. you usually don't care that a folder's timestamp updated, you care about the file inside it.

2>/dev/null just throws away permission-denied errors so your output isn't buried in noise. it doesn't hide real results, only the "can't read this" complaints.

why these two folders specifically

attackers, malware, and sketchy install scripts all gravitate toward the same real estate. /etc is where persistence lives, think /etc/cron.d, /etc/passwd, /etc/ssh/sshd_config, systemd unit files. /etc/passwd changing when you didn't add a user is a five-alarm fire. a new file in /etc/cron.d you don't recognize is worth reading immediately.

/usr/bin matters because that's where common tools like ls, curl, ps, and netstat live. a classic move for hiding malware is replacing one of these with a trojanized version that lies to you, for example a fake ps that just doesn't show the malicious process. if /usr/bin/ls shows a modification time from yesterday and you didn't update your system yesterday, that's not a coincidence you want to ignore.

reading the output without losing your mind

run this after a normal patch day and you'll get a flood of results, package updates touch tons of files. that's expected. the goal isn't zero output, it's context. cross-reference against your patch history:

cat /var/log/apt/history.log
# or on rpm-based systems
rpm -qa --last | head -20

if find shows a file changed but your package manager has no record of touching it, that's your signal to actually look at the file. also worth widening the net a bit once you've triaged the quick check:

find / -mtime -1 -type f \
  -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null

this scans the whole filesystem instead of just two folders, excluding the virtual filesystems that constantly churn and aren't useful here.

going a level deeper

mtime can be faked by anyone who knows what they're doing, a competent attacker can reset a file's modified timestamp with touch. so treat this as a first pass, not gospel. pair it with -newer against a known-good reference file, check ctime as well with -ctime since that tracks metadata changes and is slightly harder to spoof cleanly, and compare file hashes against a package manager's database:

debsums -c
# or
rpm -Va

these tools check installed files against cryptographic hashes recorded at install time. if a binary's hash doesn't match what the package manager expects, that's a much stronger signal than a timestamp alone.

the takeaway

this one-liner isn't magic, it's a fast triage step, the equivalent of glancing around a room to see what's out of place before you start dusting for prints. run it regularly enough on your own systems that you know what "normal" looks like after a routine update, so the day something actually is wrong, you'll spot it immediately instead of drowning in noise. bookmark this command, pair it with hash verification, and you've got a real first response habit instead of a guessing game.