Attackers use at on Linux to schedule a one-time command for later execution, often to regain access after compromise or delay malware activity. Security teams should review at jobs, restrict who can create them, and monitor for unusual commands, especially when paired with new user accounts or suspicious scripts.
Why At Matters as an Attack Persistence Mechanism
At is a legitimate Linux scheduler for one-time command execution, which makes it useful to attackers who want delayed execution without leaving a constantly running process behind. In practice, that can mean post-compromise persistence, staged payload delivery, or triggering cleanup and credential theft steps after the initial intrusion has settled.
The abuse pattern is straightforward: an attacker with sufficient local access creates a job, sets the execution time, and lets the system run it later under the existing user or service context. That makes at attractive when the goal is to blend in with normal administration activity rather than rely on obvious malware service installers.
Because this is a scheduling mechanism, the signal is often behavioural rather than binary. A suspicious at job may look harmless on its own, but it becomes much more important when it appears after an initial foothold, alongside new accounts, unusual shell history, or scripts dropped into writable locations.
How Attackers Hide Their Tracks with Scheduled One-Time Execution
Attackers often prefer at when they want a simple, low-noise persistence path that does not require a cron entry, systemd timer, or long-running service. A one-time job can be used to re-run a payload after reboot, delay execution until defenders are less active, or chain into another script that establishes a stronger foothold.
That behaviour fits common post-exploitation tradecraft: first compromise, then establish a return path, then reduce operator visibility. The job itself is only part of the story. The more important question is what the scheduled command does, what files or network destinations it touches, and whether it is designed to create a second-stage access route.
Defenders should treat at as part of the broader persistence and execution toolset, not as a standalone anomaly. NHIMG’s Persistence Techniques Guide is useful here because the investigative problem is not just finding the scheduled job, but understanding whether it is one piece of a wider persistence chain.
What to Check When You Find Suspicious at Usage
Start with exposure confirmation: who created the job, under which account, and what command line was scheduled. Review the at queue, the job file contents, shell history, recent login activity, and any script or binary references embedded in the command. If the job references network callbacks, privilege changes, or account creation, treat it as a likely intrusion indicator rather than routine automation.
At scale, the biggest mistake is looking only for direct malware names. The command may simply launch a harmless-looking script, while the script performs the real malicious action later. That is why defenders should correlate at activity with new user accounts, newly modified startup scripts, and unexpected file changes in writable directories.
Use host telemetry to confirm whether the scheduled command actually executed, and whether it spawned child processes, touched secrets, or connected to unusual destinations. If the job already ran, the next step is to assess whether the attacker used it for persistence, privilege expansion, or delayed destruction of evidence.
Risk and Threat Considerations
At is risky because it can convert a single foothold into delayed, repeatable execution that is easy to overlook in short investigations. The main threat is not the scheduler itself, but the attacker’s ability to use trusted system functionality to time malicious actions after initial compromise.
Failure mechanism: An attacker with local execution rights creates or modifies an at job that later runs a payload, often after the initial alert window has passed. The command can re-establish access, launch a second-stage script, or trigger actions that are harder to attribute back to the original compromise.
Impact: Delayed execution extends dwell time, complicates incident timelines, and can preserve attacker access even after the original entry point is removed. If the job is tied to a privileged account or a sensitive script, the blast radius can include credential exposure, lateral movement, or destructive changes.
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 scheduled job mechanism used for delayed execution and persistence. |
| Recommendation — Map suspicious at jobs to T1053 and hunt for follow-on execution or persistence activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Restricting who can create at jobs depends on controlling local account and privilege use. |
| Recommendation — Limit at job creation to authorized admin accounts and review unauthorized scheduler use. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limiting who can schedule commands reduces misuse of at for persistence and delayed execution. |
| AU-6 — Audit Review, Analysis, and Reporting | Investigating at abuse requires review of job creation, execution, and related host events. | |
| SI-4 — System Monitoring | Detecting suspicious at use depends on monitoring unusual scheduled execution behavior. | |
| Recommendation — Apply AC-6 to restrict who can create and run scheduled one-time jobs. Correlate at activity with process, account, and file events to confirm abuse. Monitor for anomalous at job creation and execution on sensitive hosts. | ||
Practitioner Guidance
What to verify: Check which users are allowed to submit at jobs and whether that permission matches operational need. The most useful signal is not volume alone, but whether the job was created outside normal admin workflows or by an account that should not be scheduling execution.
Decision rule: If an at job appears after compromise, assume it may be a persistence or delayed-execution mechanism until you can prove otherwise. Remove the job, inspect the command and its artifacts, then decide whether the host needs broader containment based on what the command was designed to do.
Practitioner takeaway: Treat at as a lightweight execution foothold, not a benign scheduler, because the security question is whether it gives an attacker a trusted way to come back later.