Cron

Cron is the standard, built-in way Linux systems run something on a schedule. It's used constantly for entirely mundane reasons: log rotation, backups, certificate renewal, health checks. A cron entry is a completely normal thing to find on nearly any Linux host.

This technique covers an adversary adding their own entry into that same, ordinary mechanism. Once a scheduled task is created, it runs on its own, at the interval the attacker set, with no further action needed and no ongoing connection required to keep it alive.

With write access to a crontab, either a user's own or a system-wide one, an attacker adds an entry pointing at whatever they want to run again: a reverse shell, a script that re-establishes other footholds, or a download-and-execute command. The entry sits alongside legitimate ones, doing exactly what cron is designed to do.

This is a durable, low-maintenance technique. Once written, it survives a reboot and doesn't depend on any process staying alive in memory, which makes it attractive as a way to guarantee a way back in even if the original access method is closed off.

Data source: file-integrity records on the cron spool carrying the editing process id, plus process-execution records for that same process and for the job the daemon runs

{
  "file": {
    "path": "crontabs/tmp.Xa7Qk2"
  },
  "host": {
    "name": "web-example"
  },
  "user": {
    "name": "svc_ledger"
  },
  "event": {
    "action": "opened-file",
    "module": "auditd"
  },
  "process": {
    "args": [
      "crontab",
      "-"
    ],
    "name": "crontab",
    "parent": {
      "name": "dash"
    }
  }
}

Prebuilt Elastic rule: Cron Job Created or Modified (written for endpoint file events)

Filter file creation and rename events against the known cron job directories, then read the actual entry rather than just noting that a file changed. A cron line pointing at a well-known administrative script in an expected location is routine; one invoking a shell directly, referencing a script in a temp or world-writable directory, or using an encoded or unusually long command reads very differently. Key on process, account and cron location, not destination path: crontab writes a temp file then renames it, so its events never carry the final path.

Correlating with the account and process that made the change matters too: a package manager or configuration tool writing a cron entry as part of an install is expected; an interactive shell session creating one, especially shortly after an unusual login, is a much stronger signal. Prove the job ran by matching its command in an execution parented by cron; parent alone matches legitimate jobs.

Cron entries are created constantly by entirely legitimate processes: package installations, configuration management tools, and routine administrative scripting all write to these locations as a normal part of operation.

The distinguishing signal is what the entry actually does and how it got there, not that a cron file changed at all. An entry created by a known package manager, pointing at a standard, expected script, is routine. The same file change made by an interactive session, pointing at something unfamiliar or clearly built to disguise itself among real entries, is not.

• MITRE ATT&CK: T1053.003 Scheduled Task/Job: Cron
• Elastic Security: Cron Job Created or Modified

1 scenario in this catalog covers T1053.003. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →