pspy spots root cron jobs for Linux privesc

the process list you can't see is the one biting you

every linux box runs stuff you never asked about. cron jobs, systemd timers, backup scripts, log rotators, all quietly firing on a schedule as root. most admins never watch this layer because it "just works." the problem is when one of those root jobs touches a file that's writable by a regular user. that's a straight line from low priv to root, and it's a line attackers look for constantly. this post is about how to find that line on your own machines before someone else does.

what pspy actually does

pspy is a tool that watches process activity on linux in real time, without needing root. it does this by reading process info from /proc, which is mostly world readable, so it can see commands being launched, their arguments, and when they run, even if you don't have permission to see the cron files that triggered them.

run it like this:

./pspy64

let it sit. it'll start printing every process that spawns on the box, timestamped, including the ones fired off by root's crontab. this is the part that matters for defenders: if pspy can see it as an unprivileged user, so can anyone else who gets a foothold on your system.

how the exposure actually happens

the scenario in the wild usually looks like this: a sysadmin sets up a cron job as root to run a backup or maintenance script, something like /opt/scripts/backup.sh. the cron entry itself might be locked down fine. but the script file it points to has loose permissions, maybe group-writable, maybe world-writable, because it got created in a hurry or inherited permissions from a shared directory.

an attacker who gets a low-priv shell runs pspy, watches the process list, and spots that script executing as root on a schedule. they check the permissions on the file. if it's writable, they can append something like this:

echo 'cp /bin/bash /tmp/r; chmod +s /tmp/r' >> /opt/scripts/backup.sh

next time cron fires that script as root, it copies bash to a new binary and sets the setuid bit on it. now there's a root shell sitting in /tmp waiting for anyone to run it. no exploit, no cve, just a permissions mistake and patience.

how to find this on your own systems before anyone else does

run pspy on your own boxes as a low-priv user, the same way an attacker would. if you see root-owned cron jobs or timers firing, note every script and binary they touch. then check permissions on each one:

ls -la /opt/scripts/backup.sh
find / -writable -user $(whoami) 2>/dev/null

also audit the cron files directly if you have access, and check systemd timers with:

systemctl list-timers --all
crontab -l -u root

anything root executes on a schedule needs to be owned by root, not writable by group or world, and living in a directory that's also locked down. a script sitting in a shared /tmp or /opt/scripts with 777 perms is the exact gap pspy is built to expose.

locking it down for real

fix permissions first: chmod 700 on scripts root runs, owned by root, no group or world write. audit the parent directories too, a locked script in an open directory still isn't safe if someone can replace the whole file. next, get visibility on your own box the way an attacker would. install auditd or a simple process monitor so root-level cron executions get logged, and review that log on a schedule instead of never. finally, treat any script referenced by a root cron job as sensitive infrastructure, not a random file some admin dropped in a shared folder five years ago.

the takeaway

pspy doesn't create a vulnerability, it just makes an existing one visible fast. the actual exposure is a root job pointed at a file regular users can edit. run pspy against your own systems, find every root-triggered script, and lock the permissions down before someone else does the same audit with worse intentions.