Detecting Malicious Scheduled Tasks for Persistence (T1053.005)

Scheduled Tasks are one of the most frequently abused persistence mechanisms on Windows — and one of the hardest to detect reliably. Adversaries use them to survive reboots, maintain persistence after initial access, and execute payloads under the context of SYSTEM or privileged user accounts. MITRE catalogues this as T1053.005 under the Persistence and Privilege Escalation tactics.

What makes scheduled task abuse so effective is that it blends with a noisy baseline. Hundreds of legitimate scheduled tasks run on every Windows endpoint. Attackers exploit that noise, naming their tasks to resemble built-in Microsoft components and placing payloads in directories that see regular activity.

How Attackers Create Malicious Scheduled Tasks

The three primary creation mechanisms each leave distinct artifacts:

1. schtasks.exe (command-line)

The classic approach — run directly from a shell or via a parent process:

schtasks /create /tn "MicrosoftEdgeUpdateTaskMachineCore" /tr "C:\ProgramData\update.exe" /sc onlogon /ru SYSTEM /f

The /f flag suppresses the confirmation prompt, making this suitable for scripted deployment. Attackers frequently impersonate real task names to reduce analyst suspicion.

2. COM object via PowerShell

Attackers who want to avoid schtasks.exe process creation (which is easily detected) use the Task Scheduler COM interface directly:

$action = New-ScheduledTaskAction -Execute "C:\Windows\Temp\payload.exe"
$trigger = New-ScheduledTaskTrigger -AtLogon
$settings = New-ScheduledTaskSettingsSet -Hidden
Register-ScheduledTask -TaskName "WindowsDefenderHealthUpdate" -Action $action -Trigger $trigger -Settings $settings -RunLevel Highest -Force

This avoids spawning schtasks.exe but still writes to the registry and task XML files.

3. Direct XML/registry manipulation

Advanced actors write task definitions directly to C:\Windows\System32\Tasks\ or C:\Windows\SysWOW64\Tasks\, bypassing high-level APIs entirely. This is rarer but seen in post-exploitation frameworks like Cobalt Strike’s schtaskc module.

Key Detection Data Sources

Reliable scheduled task detection requires at least two data sources:

Windows Security Event 4698 is the most reliable single signal. It logs the full task XML definition, including the command to be executed, triggers, and the account context. Audit Object Access must be enabled for scheduled task objects.

Sigma Rules

Rule 1: Scheduled Task Created with SYSTEM Privilege and Non-Standard Executable

title: Suspicious Scheduled Task Created with SYSTEM Run Level
id: 7a3b9e2f-1c4d-4e5f-8a6b-2d3c4e5f6a7b
status: experimental
description: >
  Detects scheduled task creation via schtasks.exe or Task Scheduler COM
  targeting SYSTEM privileges with executables outside expected system paths.
author: SOC Analyst Hub
date: 2026/06/04
references:
  - https://attack.mitre.org/techniques/T1053/005/
logsource:
  product: windows
  service: security
  definition: 'Requires Windows Security Event 4698 with task XML in the event data'
detection:
  selection_event:
    EventID: 4698
  selection_suspicious_path:
    TaskContent|contains:
      - '\AppData\'
      - '\ProgramData\'
      - '\Temp\'
      - '\Users\Public\'
  selection_system:
    TaskContent|contains: 'HighestAvailable'
  condition: selection_event and (selection_suspicious_path or selection_system)
falsepositives:
  - Legitimate software installers creating tasks in ProgramData
  - Some endpoint agents run tasks at highest privilege
level: high
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1053.005

Rule 2: schtasks.exe with Encoded Command

title: Scheduled Task Creation with Base64 Encoded Command
id: 2c8f4a7e-3b5d-4c6e-9f1a-8d7e6f5a4b3c
status: stable
description: Detects schtasks.exe invoked with an encoded PowerShell command — a common LOLBin chaining technique used to obscure payload execution.
author: SOC Analyst Hub
date: 2026/06/04
references:
  - https://attack.mitre.org/techniques/T1053/005/
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\schtasks.exe'
    CommandLine|contains:
      - '-EncodedCommand'
      - '-enc '
      - 'hidden'
      - 'bypass'
  condition: selection
falsepositives:
  - Some legitimate software management tools
level: high
tags:
  - attack.persistence
  - attack.defense_evasion
  - attack.t1053.005
  - attack.t1059.001

KQL Queries for Microsoft Sentinel

Detect task creation from non-standard paths (Security Events)

SecurityEvent
| where EventID == 4698
| extend TaskXML = extract(@"<Task>(.*?)</Task>", 0, EventData)
| extend CommandPath = extract(@"<Command>(.*?)</Command>", 1, TaskXML)
| where CommandPath matches regex @"(?i)(\\AppData\\|\\Temp\\|\\ProgramData\\|\\Users\\Public\\|%TEMP%|%APPDATA%)"
| project TimeGenerated, Account, Computer, CommandPath, TaskXML
| sort by TimeGenerated desc

Detect schtasks.exe spawned by unusual parents

DeviceProcessEvents
| where FileName =~ "schtasks.exe"
| where InitiatingProcessFileName !in~ (
    "services.exe", "msiexec.exe", "taskhostw.exe",
    "svchost.exe", "explorer.exe", "cmd.exe", "powershell.exe"
)
| project Timestamp, DeviceName, InitiatingProcessFileName,
          InitiatingProcessCommandLine, ProcessCommandLine, AccountName
| sort by Timestamp desc

Correlate task creation with subsequent execution

let NewTasks = SecurityEvent
    | where EventID == 4698
    | extend TaskName = extract(@"TaskName: (.*?)\\n", 1, EventData)
    | project TaskCreateTime = TimeGenerated, Computer, TaskName, Account;
let TaskRuns = SecurityEvent
    | where EventID == 4688
    | where ParentProcessName has "taskeng" or ParentProcessName has "svchost"
    | project TaskRunTime = TimeGenerated, Computer, ProcessName = NewProcessName;
NewTasks
| join kind=inner TaskRuns on Computer
| where TaskRunTime between (TaskCreateTime .. (TaskCreateTime + 1h))
| project TaskCreateTime, TaskRunTime, Computer, TaskName, Account, ProcessName

High-Fidelity Hunting Patterns

When hunting in an environment with high baseline noise, focus on these high-fidelity indicators:

1. Task XML with <Hidden>true</Hidden>
Legitimate software rarely needs to hide scheduled tasks. Event 4698 includes the full XML — search for this attribute explicitly.

2. Action pointing to mshta.exe, wscript.exe, or cscript.exe
These LOLBins are commonly chained via scheduled tasks for fileless persistence.

3. Trigger set to AtSystemStart or AtLogon with SYSTEM run level
Startup triggers are over-represented in malicious tasks. Cross-reference with newly created accounts or recently modified tasks.

4. Task name matching known Microsoft task names but different binary path
Query C:\Windows\System32\Tasks\ and compare the <Command> field against a baseline of known-good task definitions. Any mismatch is highly suspicious.

Remediation and Hardening

• Enable Windows Security Audit Policy for Audit Other Object Access Events to capture Events 4698–4702.
• Deploy Sysmon with file-create monitoring on C:\Windows\System32\Tasks\ (Event ID 11) to catch direct XML writes.
• Use AppLocker or WDAC to restrict which binaries can be executed by Task Scheduler, particularly from user-writable paths.
• Review all tasks running as SYSTEM created within the past 30 days: Get-ScheduledTask | Where-Object { $_.Principal.RunLevel -eq 'Highest' } | Select TaskName, TaskPath, @{n='Execute';e={$_.Actions.Execute}}

Scheduled task persistence is both common and detectable — the challenge is signal-to-noise. A layered approach combining Event 4698 enrichment, process creation correlation, and regular task baseline reviews significantly reduces dwell time for this technique.