privilege escalation via writable cron jobs
ls -l /etc/cron.d/backupprivilege escalation is rarely an exploit
most people picture privilege escalation as some fancy zero day, a hollywood-style hack that pops root in three seconds. in reality it's usually way more boring than that. it's a file permission someone forgot about. it's a script running as root that a regular user can edit. cron jobs are one of the most common ways this happens, and the scary part is you can check your own box for this exact issue in about five seconds.
the command
ls -l /etc/cron.d/backupthis just lists the permissions on a specific cron job file, in this case one named "backup." cron.d is where system services and admins drop scheduled tasks that run automatically, often as root. the output looks something like this:
-rwxrwxrwx 1 root root 210 jan 3 09:15 /etc/cron.d/backupbreaking that down: the first character tells you it's a regular file. the next nine characters are the permission bits, three sets of three, for owner, group, and everyone else. rwx means read, write, execute. if you see "w" in that "everyone else" slot, that means literally any user on the system, even a low privileged one, can edit that file.
why a writable cron job is a big deal
cron jobs run on a schedule as whatever user owns them. a ton of backup scripts, monitoring scripts, and maintenance tasks are set up to run as root because root needs to touch protected directories or system files. if a low privileged user can write to that cron file, they can swap out the command it runs. next time cron fires, whatever they wrote executes with root's permissions. no exploit needed, no fancy payload, just someone forgetting to lock down a file after setting it up in a hurry.
this is why "privilege escalation" is rarely dramatic. it's almost always a misconfiguration that's been sitting there for months, waiting for someone to notice it. attackers love these because they're quiet, reliable, and don't trip any antivirus alarms.
how to actually check your own system
don't just check one file, check everything cron related. run this to scan your whole cron setup:
ls -l /etc/cron.d/
ls -l /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/
ls -l /etc/crontab
crontab -l -u rootlook for any "w" permission outside of the owner column. also check the scripts those cron jobs actually call, not just the cron file itself. a cron file can be locked down tight but if it calls a script sitting in a world-writable folder, you've got the same problem one layer deeper.
find / -writable -type f 2>/dev/null | grep -i cronthis catches writable files anywhere with "cron" in the path, which is a decent quick sweep if you don't want to check directory by directory.
how to fix it
the fix is almost always permission hygiene, not some complicated patch. lock cron files down so only root can write to them:
chmod 644 /etc/cron.d/backup
chown root:root /etc/cron.d/backup644 means the owner can read and write, everyone else can only read. that's the standard for cron files and there's rarely a good reason to loosen it. do the same for any scripts referenced inside those cron jobs, and double check the directories those scripts live in aren't world-writable either, since a locked file inside an unlocked folder can still get replaced.
if you're managing more than a handful of machines, this is exactly the kind of thing that config management tools or a simple weekly audit script can catch automatically before it turns into a real problem.
the takeaway
privilege escalation isn't magic, it's usually a permission someone left open. run ls -l across your cron directories this week, actually look at the output instead of skimming it, and fix anything writable by someone other than root. it takes two minutes and it closes one of the most common, least glamorous ways attackers move from "regular user" to "root" on a box that was never meant to let that happen.