How can a scheduled task provide persistence?¶
A scheduled task can provide persistence by causing a command, script or program to run at a chosen time or event.
Avoid the dangerous assumption¶
The dangerous assumption is that any unusual scheduled task is malicious.
Scheduled tasks are widely used for updates, backups, maintenance and administration.
Investigators should identify:
- the task name and identifier
- creation time
- creator account or process
- trigger
- command or program launched
- working directory
- privilege level
- execution history
- result
- linked files or network activity.
A task may trigger at startup, user login, a fixed time or another system event.
The presence of the task does not prove it executed.
Execution history, process records and resulting activity are needed.
Likewise, execution does not automatically prove malicious purpose.
An offender may create a task with a legitimate-looking name or use an existing task rather than creating a new one.
Preserve the task definition and associated payload before removal.
Check whether timestamps and history survived. Some systems retain only limited task information.
A scheduled task may explain recurring activity that continues after the original session ends.
It may also launch under a different account or higher privilege than the account that created it.
Scheduled tasks may be imported from another system or created by software installers. Compare the task definition with normal organisational baselines and preserve any remote-management, deployment or script records that explain its origin.
Record whether the task was enabled, disabled or altered during response.
Operational takeaway¶
Preserve the task definition, creator, trigger and execution history, and distinguish task creation from successful malicious use.