I am currently working through the Nebula challenges on exploit-exercises.com, and one of the challenges relies on a script being run by cron.

This is run by another user (flag03) and the user I am logged in as (level03) doesn't have privileges to run crontab -u flag03 to view the job.

The hint clearly indicates the script is run by cron. Additionally, it is the only script in the /home/flag03 directory, so we would likely investigate further.

However, if this was the real world, I wouldn't know that this script was being run by cron.

Therefore the question is, how would I detect that the task was being run from the perspective of an unprivileged user?

I have tried the following:

while true; do ps au | grep <scriptname> | grep -v grep; done;

This allows me to see processes that run for a significant length of time, but not ones that exit almost immediately. It also presumes I know the name of the script.

The specific environment is Ubuntu. I can't use apt-get, but I have access to gcc.

Any ideas?

  • 1
    Can you look at anything under /var/log/? Look for log messages about cron tasks. – slm Jun 6 '14 at 18:09
  • No, unfortunately no permissions or not relevant (grep -ri cron / or find / -name cron) – Cybergibbons Jun 6 '14 at 19:15

Which version of Ubuntu? If it's using systemd, you could rely on the cron cgroup created by systemd I guess, as all processes started by cron will be a direct child.

One of the option to get this information is to use the ps command with something like:

ps -eo user,pid,cmd,unit | grep cron.service | grep flag03
  • Why does this not suffer from the same issue as the suggestion in the question i.e. short lived processes will be missed. – Cybergibbons Dec 20 '16 at 14:39
  • Indeed, but you could mix that with the idea from @piroux and add a inotify watch on the files in /sys/fs/cgroup/systemd/system.slice/cron.service/ – Bigon Dec 20 '16 at 15:27
  • inotify won't work on those files, but a busy loop starting one second before each minute that watches the contents of /sys/fs/cgroup/systemd/system.slice/cron.service/cgroup.procs and retrieves the corresponding command line from /proc/pid/cmdline should be able to capture the commands, especially if you slow down everything by allocating a lot of RAM to evict most things from the cache. – Stéphane Chazelas Sep 30 at 18:51

You can't. The closest you can get is:

inotifywait -m /home/flag03/script

That won't show execution but it will show when script is opened or accessed.


Maybe using inotifywait in the /proc/[0-9]+ directories would let you have a better glimpse of short run processes.


Looking at the challenge this method of attack would assume that you can run a script and watch what runs on the box, so I would write a script that simply does a dump of ps -eaf every couple of seconds, this would catch a cron, eventually, since crons run once every minute.

This vector of attack would require you to watch for this script running, note the location of the script, and dig in deeper.

  • Isn't that pretty much the one-liner I posted in the question? – Cybergibbons Jun 9 '14 at 8:13
  • @Cybergibbons - more or less. I'd modify the script slightly and there are other ways to watch for processes running, so if this wasn't successful in finding any cronjobs, I might dig in deeper with those. – slm Jun 9 '14 at 11:58

In this specific case, the file is located on /var/spool/cron/crontabs/flag03, and you can read it with the nebula account.

But level03 doesn't have enough privileges to access it.

while true; do ps aux | egrep -v "grep|tail|aux" | tail -n 1; sleep 1; done

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.