How to defend against scheduled task abuse

What the attacker does

A scheduled task runs a program at a set time, at startup, at logon or on an event, under any account the creator names, including SYSTEM. An attacker who has run code once creates a task so the code runs again after a reboot, or uses a task to run as SYSTEM or on another machine. The task can be created with schtasks.exe, with the ScheduledTasks PowerShell module, or by writing the task XML directly into C:\Windows\System32\Tasks.

What it looks like in the logs

A process creation event (Sysmon Event ID 1, or Windows Security Event ID 4688) for schtasks.exe. With /Create, the /TR switch holds the command the task will run, /SC the schedule and /RU the account. This is one of the tasks in the recordings:

A task created on another machine carries /S <hostname>. The same action is also recorded, when the logs are enabled, as Security Event ID 4698 and as Task Scheduler Operational Event ID 106.

Detect

Measured on the challenge data: the rule caught 3 of 3 attack events and matched 0 of 2,438 normal events.

title: Scheduled task created to run a script interpreter or a user-path binary
id: 22d5efc0-ed55-43a6-9d3a-7d7f514e09c5
status: test
description: >
  Detects a task created with schtasks.exe whose run command starts a script interpreter or a binary
  from a user-writable folder. Software usually registers a task that runs its own signed program, so
  these are worth an alert. Installed software that creates tasks from an XML file (/XML) does not match.
references:
  - https://attack.mitre.org/techniques/T1053/005/
  - https://howdefend.com/defend/scheduled-task-persistence/
author: Bartu Kılıç
date: 2026-10-20
tags:
  - attack.persistence
  - attack.execution
  - attack.t1053.005
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\schtasks.exe'
    CommandLine|contains|all:
      - '/create'
      - '/tr'
  run_suspicious:
    CommandLine|contains:
      - 'powershell'
      - 'pwsh'
      - 'cmd.exe'
      - 'mshta'
      - 'wscript'
      - 'cscript'
      - 'rundll32'
      - 'regsvr32'
      - '\users\'
      - '\appdata\'
      - '\programdata\'
      - '\temp\'
      - '\public\'
  condition: selection and run_suspicious
falsepositives:
  - An installer that registers a task running a script or a program from ProgramData (review the task command)
level: medium

What the rule misses

• A task that runs a signed binary. If the attacker's payload is a dropped executable with a plain path, the command line holds no interpreter and no user-folder marker. Match the known-good tasks on a baseline instead, or alert on the account (/RU system from an interactive session).
• Tasks created without schtasks.exe. The PowerShell module and a direct write into the Tasks folder leave no schtasks.exe process. Event ID 4698 and the Operational log catch those because they record the registration itself.
• Missing logging. The Task Scheduler Operational log is off by default, and 4698 needs the Other Object Access Events audit subcategory. Without them, only the process creation remains.

Prevent

• There is no clean block. Scheduled tasks are used by Windows and by most installed software, so the control is logging and review rather than prevention.
• Review against a baseline. Compare the task list across machines; a task that only one machine has, or one that runs from a user folder, stands out.
• Limit who can create them. A standard user can create tasks that run as themselves; running as SYSTEM or on another machine needs administrator rights. Fewer local administrators means fewer accounts that can hide a task as part of Windows.

Practice

Write the rule yourself on the same data, with every target labelled.

Sources

• MITRE ATT&CK: T1053.005 Scheduled Task
• Microsoft Learn: Audit Other Object Access Events (Event 4698)
• OTRF Security-Datasets (attack recordings used on this page)