spot a backdoor suid binary by comparing timestamps

why suid binaries are the quiet backdoor of choice

a suid root binary is one of those things that sounds boring until you realize what it actually means. when a file has the setuid bit set and it's owned by root, it runs as root no matter who launches it. your unprivileged user account, some cron job, whatever, doesn't matter. the binary executes with root permissions the second it's called. that's incredibly useful for things like passwd which needs root access to update a system file. it's also incredibly useful for an attacker who wants a permanent, no-password way back into root without touching sudoers or messing with ssh keys.

drop a copy of bash somewhere quiet, flip the suid bit, and now any local user, including a low-privilege webshell account, can run that binary and land in a root shell. no exploit needed, no privilege escalation chain, just a single planted file sitting there waiting.

the core idea: compare against install time

the good news is suid binaries that are supposed to be on your system don't just appear randomly. they were installed when the os was installed, or when a package manager put them there. that means they all share roughly the same timestamp, the install date. anything suid that showed up after that date is suspicious by definition.

/etc/hostname is a convenient reference point because it's almost always written once at install/provision time and rarely touched again. so the plan is simple: find every suid file on disk, then filter out anything older than or equal to that reference file. what's left is new.

breaking down the command

find / -perm -4000 -type f -newer /etc/hostname 2>/dev/null

here's what each piece is doing:

find / starts the search at the root of the filesystem, so nothing gets skipped just because it's tucked away in a weird directory.

-perm -4000 tells find to match files where the setuid bit (4000 in octal) is set. this is the actual "runs as owner regardless of caller" flag.

-type f restricts results to regular files, since suid on a directory doesn't mean the same thing and just adds noise.

-newer /etc/hostname is the filter that does the real work. it only returns files with a modification time newer than the reference file. this is what separates "installed with the os" from "planted later."

2>/dev/null just throws away permission-denied errors from directories you can't read, so your output stays readable.

confirming what you found

let's say the command spits out something like /tmp/.cache/bash. a hidden directory inside /tmp is already a red flag, legit software doesn't usually live there. next step is to actually look at the timestamp instead of just trusting the find output blindly:

stat -c '%y' /tmp/.cache/bash

this prints the exact modification time in human-readable form. if it lines up with a date you don't recognize, especially something recent, that's your confirmation. you can also run file /tmp/.cache/bash to check it's actually a copy of bash or another shell, and ls -la on the file to double check ownership and the permission bits themselves (you're looking for an s where the execute bit for owner normally sits, like -rwsr-xr-x).

false positives to expect

this isn't a perfect signal on its own. some legitimate packages get updated after install and will show up as "newer" even though they're fine. things like sudo, ping, or mount updated during a routine patch cycle can trigger this too. that's fine, the goal isn't "everything in this list is malicious," it's "everything in this list deserves a second look." cross reference against your package manager's file list, for example on debian based systems dpkg -S /path/to/binary will tell you if a legit package owns that file. if the binary isn't owned by any package, that's a much bigger red flag than a late timestamp alone.

the takeaway

suid binaries are powerful precisely because they bypass the normal "who am i" check, which makes them a favorite persistence trick. the fix isn't complicated: periodically run this find command, keep a known-good baseline of your legit suid files somewhere safe, and diff against it. better yet, automate it as a cron job that emails you when something new shows up. one command, run regularly, turns a silent backdoor into something you catch before it gets used against you.