How can security teams detect at (Linux)?

What “at” Looks Like on Linux When You’re Hunting for It

The useful signal is not just that at ran, but that it created a deferred execution path. Security teams should treat queue activity, job file creation, and command execution at odd hours as the core detection points. A single at job is not suspicious by itself; the context around who created it, what it runs, and whether the host should ever use scheduled deferred jobs is what turns it into an alertable event.

On Linux, review the job payload for scripts, network fetches, shell wrappers, or commands that stage later activity. That is why Persistence Techniques Guide is relevant here, because deferred execution is often used as a simple persistence mechanism rather than an isolated admin task. The strongest detections combine process creation telemetry with job metadata, so you can tell whether the command was routine maintenance or part of an access path that should not exist.

In practice, the detection question is whether the job content and timing fit the system’s normal administration pattern. On a hardened Linux server, Linux Server Hardening Guide is the right companion reference because it frames at alongside broader host controls such as logging, privilege limitation, and hardening baselines. If the platform was never meant to rely on at, then even a legitimate job may still be a policy violation worth investigating.

The operational challenge is that deferred execution can look like normal sysadmin work until you correlate it with the initiating account, the working directory, the command line, and the downstream process tree. Unexpected users, unusual schedules, or jobs that invoke downloaders, interpreters, or cleanup steps deserve more scrutiny than a simple one-off command. Where the host is embedded or tightly constrained, Embedded Device Security Guide is useful because it reinforces the idea that many systems should not have ad hoc job scheduling at all, making any use of at more suspicious by default.

Risk and Threat Considerations

at becomes risky when it is available to users or services that should not be able to stage delayed execution. An attacker who has low-friction shell access can use it to defer execution, blend in with administrative activity, or create persistence that fires later when monitoring is weaker.

Failure mechanism: The control fails when job submission is not restricted, queue activity is not monitored, or job contents are not reviewed for staged downloads, shells, or post-exploitation behaviour. That lets a normal scheduling feature become a persistence and execution primitive.

Impact: The result can be delayed command execution, hidden persistence, and a weaker timeline for incident response because the malicious action is separated from the original compromise. It can also widen blast radius if the job runs with elevated context or on systems that should never rely on at.

Practitioner Guidance

What to verify: Confirm which users can submit jobs, which hosts legitimately use at, and whether queue records are retained long enough to reconstruct who created each job. If the environment has no approved use case, treat any job creation as a policy exception until proven otherwise.

Decision rule: If the job runs from an unexpected account, launches a script or downloader, or lands on a system that should not use deferred scheduling, prioritize containment and review of the job payload before deciding whether the activity is benign. If the command is legitimate but unauthorized, treat it as a governance failure, not just a tuning issue.

Common mistake: Teams often alert only on process execution and miss the job creation event that explains why the command appeared later. The better detection pattern is queue creation plus payload inspection plus downstream process correlation, because each view closes a different part of the attacker’s path.

Practitioner takeaway: The highest-value signal is not “at exists,” but “an unexpected identity used at to create deferred execution on a host where that behavior should be rare or forbidden.”

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?