The at utility schedules a command to run at a specified time and date. MITRE tracks its abuse as T1053.002, a sub-technique of Scheduled Task/Job, under Execution, Persistence and Privilege Escalation. It exists on Windows, Linux and macOS.
On Windows, at has been deprecated in favor of schtasks. MITRE notes that using it still requires the Task Scheduler service to be running and the user to be a member of the local Administrators group. Because it is old, it is easy to forget to monitor.
How attackers use it
MITRE describes several uses. Adversaries can run programs at startup or on a schedule for persistence, run tasks on a remote system as part of lateral movement, or run a process under a chosen account such as SYSTEM. On Windows they can also schedule through the WMI Win32_ScheduledJob class instead of calling at directly.
On Linux, MITRE adds two more. A task can spawn an interactive shell or run system commands to break out of a restricted environment, and if the at binary is allowed to run as superuser through sudo, it can serve privilege escalation.
Access on Linux and macOS is governed by two files. Users in at.allow may use it. If that file is absent, at.deny is checked, and anyone not listed is allowed. If neither exists, which MITRE says is often the baseline, only the superuser can use at.
How to detect it
MITRE's analytics, by platform:
- Windows: task creation through at.exe or the Win32_ScheduledJob class, followed by anomalous processes launched by svchost.exe or taskeng.exe.
- Linux: use of the at command followed by job execution and modification of job files under /var/spool/cron/atjobs.
- macOS: user or root invocation of at, followed by job execution and activity in /usr/lib/cron/at.
MITRE also points to a Windows registry key created when a task is made on the destination host, under Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\At1. On Linux and macOS, at activity can be audited locally or through centrally collected syslog or auditd events.
How to reduce the risk
- Limit who can create tasks, especially on remote systems. Only authorized administrators should be able to.
- On Linux, manage access with at.allow and at.deny.
- Where possible, configure scheduled tasks to run as the authenticated account instead of SYSTEM. MITRE points to the Group Policy setting named Domain Controller: Allow server operators to schedule tasks, set to disabled.
- Restrict the Increase scheduling priority right to the Administrators group.
- Audit for permission weaknesses in scheduled tasks that could allow privilege escalation.
Check your own environment
- Linux shell:
atqlists pending at jobs for the current user. - Linux shell:
ls -l /etc/at.allow /etc/at.denyshows whether either file exists and who owns it. - Windows Command Prompt:
atwith no arguments lists legacy at jobs on older systems.
Quick check
On Linux, who can use at if neither at.allow nor at.deny exists?
Only the superuser, according to MITRE.
Sources
- MITRE ATT&CK: Scheduled Task/Job: At (T1053.002)
