Scheduled Task/Job (T1053): How to detect and respond to task-based persistence

What is the Scheduled Task/Job?

Every enterprise environment runs hundreds of scheduled tasks, software updates, backup jobs, monitoring scripts, housekeeping routines. Attackers exploit this ubiquity: T1053 describes how adversaries create or modify scheduled tasks to execute malicious payloads automatically. The task runs on a timer or at boot, the payload re-establishes command and control, and the attacker maintains access without any further interaction.

This technique is one of the most common persistence methods observed in real-world intrusions. According to the Mandiant M-Trends 2026 report, scheduled tasks appear in over 40% of Windows-based compromises. The reason is simplicity: creating a scheduled task requires only standard user privileges (or admin for SYSTEM-context tasks), the mechanism survives reboots, and the task looks identical to thousands of legitimate tasks already running in the environment.

Part of the Persistence (TA0003) tactic in the MITRE ATT&CK® framework.

Key facts about T1053

How the attack works: Attack scenario

Stage 1: Initial execution context

The attacker already has code execution, typically via Execution (TA0002) techniques like PowerShell or a dropped binary. From this execution context, they create a scheduled task to ensure their payload survives beyond the current session. A group like APT29 typically runs the task creation command from a SYSTEM-level process to ensure the task runs with maximum privileges.

Stage 2: Task creation

The attacker uses schtasks.exe, the Windows Task Scheduler COM API, or a tool like SharPersist to register a new task. The task is configured to run at boot, at logon, or on a recurring schedule. The payload can be a binary path, a PowerShell command, or even an encoded script stored in the Registry.

What this looks like in logs:

The attacker names the task to mimic legitimate Windows tasks (SystemMaintenance) and places the binary in a public folder. Without behavioral context, this looks like a routine system task.

Stage 3: Persistent execution

On the next reboot or at the scheduled time, the Task Scheduler service executes the payload. The attacker's implant reconnects to command and control, and the compromised system is back under adversary control, even if the original access vector has been patched.

Real-world attacks using T1053

How to detect and investigate T1053 with Log360

Log360's detection engine monitors scheduled task creation and modification in real time, applying behavioral context that separates attacker activity from legitimate administration.

Detecting offensive tooling

The highest-confidence detection is tool-specific. The SharPersist Detection rule (Critical, Windows) fires when the SharPersist persistence framework is used to create scheduled tasks. SharPersist is a purpose-built offensive tool that automates persistence installation across multiple mechanisms. When this rule triggers, an attacker is actively installing persistence using a known red-team/adversary toolkit. The Critical severity reflects that this is not a false-positive-prone behavioral signal; it is a direct tool fingerprint.

Detecting behavioral anomalies in task creation

Most real-world scheduled task persistence comes from general-purpose tools, not SharPersist. For these cases, Log360 applies behavioral context. The Suspicious Scheduled Tasks created during non-working hours rule (Critical, Windows) flags task creation outside business hours. Legitimate administrators rarely create tasks at 3 AM, but attackers operating from different time zones frequently do. The Schtasks Creation Or Modification With SYSTEM Privileges rule (Trouble, Windows) monitors for tasks configured to run as SYSTEM, which gives the persistence mechanism the highest possible privilege level.

Payload path analysis provides additional detection depth. The Suspicious Schtasks Execution AppData Folder rule (Trouble, Windows) and the Suspicious Scheduled Task Creation Involving Temp Folder rule (Trouble, Windows) both flag tasks that execute payloads from user-writable directories. Legitimate scheduled tasks almost always run binaries from C:\Windows\ or C:\Program Files\; a task running from AppData or Temp is a strong persistence indicator.

Detecting advanced persistence patterns

Sophisticated attackers store payloads in the Registry rather than on disk to avoid file-based detection. The Scheduled Task Executing Payload from Registry rule (Trouble, Windows) detects this fileless pattern, and the Scheduled Task Executing Encoded Payload from Registry rule (Trouble, Windows) adds an additional layer by catching encoded (Base64) payloads pulled from Registry values, a technique that combines fileless persistence with obfuscation.

For domain-wide persistence, the Persistence and Execution at Scale via GPO Scheduled Task rule (Trouble, AD) alerts when scheduled tasks are deployed through Group Policy Objects. This is a high-impact technique: a single GPO modification can deploy a persistent scheduled task to every domain-joined host simultaneously, giving the attacker persistence across the entire environment in one action.

PowerShell-based task creation is covered by the Powershell Create Scheduled Task rule (Trouble, Windows), which catches task creation through the New-ScheduledTask and Register-ScheduledTask cmdlets, the script-friendly alternative to schtasks.exe that appears frequently in automated attack chains.

Investigation workflow in Log360

1. Verify the creating account: Open the alert and check the Subject field in Event ID 4698. Is this a known administrator? Was the account recently compromised? Cross-reference with UEBA risk scores for the account.
2. Examine the task payload: Read the Task Content XML in the event. What binary or command does the task execute? Decode any Base64 arguments. Legitimate tasks reference signed binaries in system directories; malicious tasks reference user-writable paths or encoded commands.
3. Trace the creation process: Identify the parent process that called schtasks.exe or the COM API. If the parent is PowerShell, cmd.exe, or an unusual process, trace backward through the process chain to find the initial execution context.
4. Check for upstream indicators: Search the same host and account for Initial Access and Execution alerts within the preceding time window. Persistence follows execution, and finding the execution event reveals the attack origin.
5. Assess scope: Search for the same task name or payload path across all monitored hosts. If the task was deployed via GPO, check all domain-joined systems.

Behavioral detection with UEBA

Log360's UEBA module adds behavioral context beyond rule-based detection. It baselines normal scheduled task creation patterns per user and per host, flagging anomalies even when the task itself passes rule-based checks. A user who has never created a scheduled task suddenly registering one at 2 AM receives an elevated risk score, even if the task path and privileges appear legitimate.

How to remediate and prevent T1053 attacks with Log360

Immediate containment

1. Delete the malicious task: Use schtasks /Delete /TN "TaskName" /F to remove the task. Verify deletion by querying the Task Scheduler: schtasks /Query /TN "TaskName".
2. Kill the payload process: If the task has already executed, terminate the payload process before deleting the task, otherwise the running process may recreate it.
3. Isolate the host: Move the compromised system to a quarantine VLAN while investigation continues.

Root cause remediation

• Trace the attack origin: The scheduled task is a persistence mechanism, not the initial compromise. Investigate backward through the process chain and alert timeline to find the initial access vector.
• Rotate credentials: Reset passwords and revoke tokens for accounts used to create the task and any accounts with active sessions on the compromised host.
• Check for additional persistence: Attackers rarely use a single persistence mechanism. Search for new services (T1543), Registry Run Keys (T1547), and WMI subscriptions (T1546) created in the same time window.

Long-term hardening

• Restrict task creation privileges: Limit scheduled task creation to specific administrative groups using Group Policy. Standard users should not need to create tasks in most enterprise environments.
• Audit task inventory: Export all scheduled tasks weekly and diff against the approved baseline. New tasks that do not match change tickets are investigation targets.
• Monitor critical Event IDs: Ensure Event IDs 4698, 4699, 4700, 4701, 4702 are collected and forwarded to Log360, per NIST Cybersecurity Framework monitoring guidance.
• GPO task management: Restrict who can modify Group Policy Objects that contain scheduled tasks. Use AD delegation carefully and audit GPO changes in real time.

Log360 automated response configuration

Navigate to Log360's Alert Profiles for each T1053 rule and configure these automated responses via the SOAR framework:

• Disable the creating account: When a Critical-severity task creation alert fires (SharPersist Detection, non-working hours task creation), automatically disable the account that created the task.
• Create incident ticket: Auto-create a ServiceDesk Plus ticket with task name, creator, payload, and host context.
• Email/SMS alert: Notify the SOC on-call analyst and the system owner immediately.

Need to explore ManageEngine Log360? Schedule a personalized demo

FAQ