At job scheduled
The at command was run — scheduling a command to execute once, later.
What it detects
The at command was run — scheduling a command to execute once, later. It is cron's forgotten sibling and attackers reach for it for that reason: most estates monitor /etc/cron* and crontab -e; far fewer watch the at-job spool.
A one-shot future execution is useful in an intrusion in ways a recurring job is not. It runs after the session that created it has closed, so the process has no living parent to trace back to; it can be timed for hours after the operator has gone; and it fires once and leaves nothing behind to find on a later sweep. Common uses are delayed payload execution, a timed cleanup that removes tooling after the fact, and a callback scheduled as a fallback in case the primary channel is cut.
Complements linux.persistence.cron_job_added, which watches the cron paths.
MITRE ATT&CK mapping
- T1053.002Scheduled Task/Job: At· Execution
False positives and triage
at has real administrative uses — scheduling a reboot or a maintenance script for a quiet hour, deferring a long job. It is also invoked by batch and by some packaging scripts. The distinguishing questions:
* Is at used at all in this estate? On most hosts the answer is no, which makes any use worth a look and makes this rule cheap to run. * What was scheduled, and for when? Read the job body out of the spool — /var/spool/cron/atjobs on Debian and Ubuntu, /var/spool/at on RHEL family. A payload path in /tmp, a shell one-liner, or anything fetching from the network is the finding. A timing far outside working hours is corroboration. * Who scheduled it? A service account with no interactive login history using at is the case that matters.
Note this fires on the at client, not on the job running later — atd executing the job is a separate event, and pairing the two shows you what was actually run.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 55%. Source: rules/linux/at_job_scheduled.yaml, licensed under the Apache License 2.0.
id: linux.persistence.at_job_scheduled
version: 1.0.0
status: stable
severity: medium
confidence: 0.55
platforms: [linux]
mitre_techniques: [T1053.002]
description: |
The `at` command was run — scheduling a command to execute once, later. It is
cron's forgotten sibling and attackers reach for it for that reason: most estates
monitor `/etc/cron*` and `crontab -e`; far fewer watch the at-job spool.
A one-shot future execution is useful in an intrusion in ways a recurring job is
not. It runs after the session that created it has closed, so the process has no
living parent to trace back to; it can be timed for hours after the operator has
gone; and it fires once and leaves nothing behind to find on a later sweep. Common
uses are delayed payload execution, a timed cleanup that removes tooling after the
fact, and a callback scheduled as a fallback in case the primary channel is cut.
Complements `linux.persistence.cron_job_added`, which watches the cron paths.
match:
process_name_any:
- at
false_positive_guidance: |
`at` has real administrative uses — scheduling a reboot or a maintenance script for
a quiet hour, deferring a long job. It is also invoked by `batch` and by some
packaging scripts. The distinguishing questions:
* Is `at` used at all in this estate? On most hosts the answer is no, which makes
any use worth a look and makes this rule cheap to run.
* What was scheduled, and for when? Read the job body out of the spool —
`/var/spool/cron/atjobs` on Debian and Ubuntu, `/var/spool/at` on RHEL family.
A payload path in /tmp, a shell one-liner, or anything fetching from the network
is the finding. A timing far outside working hours is corroboration.
* Who scheduled it? A service account with no interactive login history using `at`
is the case that matters.
Note this fires on the `at` client, not on the job running later — `atd` executing
the job is a separate event, and pairing the two shows you what was actually run.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.