Reduce the risk of at on Linux by restricting who can submit jobs, removing the service if it is not needed, and monitoring the spool and execution of scheduled one-time tasks. Review at.allow and at.deny configuration, alert on new jobs from unusual accounts, and correlate job creation with privilege escalation or persistence.
How to reduce the attack surface of at on Linux
The fastest way to lower exposure is to treat at as a narrowly permitted scheduling capability, not a default utility. In practical terms, that means limiting who can submit jobs, confirming whether the daemon is actually needed, and making sure only the intended administrative group can interact with the command and its control files.
Because at creates deferred execution, the security question is not only “who can run it now?” but “who can cause code to run later under a more privileged context.” That is why MITRE ATT&CK Enterprise Matrix is useful here: scheduled execution is a common persistence and privilege-abuse pattern, so review any local policy that turns job submission into a durable foothold.
In the same vein, the main hardening decision is whether you need at at all. If the host does not rely on one-time scheduled tasks, removing the service or package eliminates a low-frequency but high-leverage execution path. If the utility must remain, keep the permissions model simple and explicit, and avoid broad allowlisting that turns a convenience feature into a persistence mechanism.
How to monitor at usage without drowning in noise
Detection should focus on job creation, not just command execution. Watch the at spool, look for new entries from accounts that do not normally schedule jobs, and correlate those events with other signs of privilege escalation or post-compromise activity. The highest-value alerts are the ones that show an unexpected account submitting a job that later executes a script, binary, or shell fragment.
That monitoring should also include the control files. A change to at.allow or at.deny is often more important than a single scheduled task, because it can indicate an attempt to widen or preserve access. Baseline the normal submitters, then alert on drift, especially where the change coincides with a new admin session, a service account login, or a recent configuration change on the host.
For teams already tracking persistence tradecraft, Persistence Techniques Guide helps place at alongside other deferred-execution methods such as cron, launch agents, and service-based persistence. That broader view matters because defenders often miss at when they only hunt the more obvious scheduled-task mechanisms.
When to investigate further after an at job appears
An at job becomes materially suspicious when it is created by an unusual user, appears soon after a privilege change, or launches a command that reaches outside the system’s normal maintenance pattern. Investigate the job contents, the submitting account, the parent process, and any files or network activity the job touches at execution time. A single at entry may be benign; a cluster of entries from a newly privileged account is not.
If the host runs sensitive workloads, treat a suspicious at submission as a possible persistence indicator first and a convenience feature second. Review whether the job was used to re-establish access, stage follow-on commands, or time execution for off-hours activity. The question is not just whether the job ran, but whether it fits the host’s normal operational rhythm.
Risk and Threat Considerations
at is attractive to attackers because it can turn a brief foothold into delayed execution that blends into routine administration. If the utility is enabled broadly, an intruder who gains a low-privilege account may use it to stage a later payload, survive a session ending, or trigger code after privilege conditions change.
Failure mechanism: Weak allowlist and denylist control, combined with poor monitoring of the spool, lets an attacker submit a job that looks operationally ordinary until it executes. If that job is created from an account that later becomes privileged, the execution path can become a persistence or escalation step rather than a standalone event.
Impact: Unnoticed at jobs can lead to deferred malicious execution, delayed detection, and repeated access to the host. In the worst case, the job becomes a bridge from initial access to persistence, command execution, or follow-on tampering on the same system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1053 — Scheduled Task/Job | at is a Linux scheduled job mechanism and can support persistence or delayed execution. |
| Recommendation — Monitor scheduled jobs for persistence indicators and investigate unusual job submission patterns. | ||
| CIS Controls v8 | CIS-5 — Account Management | Restricting who can submit at jobs depends on account and privilege governance. |
| Recommendation — Limit at usage to approved accounts and remove unnecessary local execution rights. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Detecting suspicious at usage requires auditable job creation and execution records. |
| Recommendation — Generate audit records for at submission and execution events. | ||
Practitioner Guidance
What to verify: Confirm whether at is needed on each host class, who is allowed to submit jobs, and whether the control files match that policy. If the utility is retained, verify that every permitted submitter has a clear operational reason and that the spool is being reviewed or alerted on.
Decision rule: If a job was submitted by an account that should not normally schedule work, treat it as a security event first and an administration event second. Escalate faster when the job appears near privilege changes, new logins, or other persistence indicators, because timing is often the clue that makes the event actionable.
Practitioner takeaway: The real control is not just disabling at or tightening permissions, it is making deferred execution observable enough that an unexpected job cannot quietly become persistence.