A Sigma rule for scheduled task detection is the portable way to catch one of the most reliable persistence techniques on Windows: an attacker registering a scheduled task to re-run their payload after reboot. Windows already records the evidence as Event ID 4698, and in my post on detecting malicious scheduled tasks I worked through that event by hand. This post takes the same logic and writes it as Sigma, so the detection converts to KQL, SPL, or whatever SIEM I happen to be standing in front of.

Key Takeaways

• Scheduled-task persistence (MITRE ATT&CK T1053.005) shows up in two places: Security Event ID 4698 and the creation of schtasks.exe as a process.
• A Sigma rule for scheduled task detection lets you author the logic once and convert it to your SIEM, instead of hand-writing the same query per platform.
• Event ID 4698 only fires if the "Audit Other Object Access Events" subcategory is enabled — without it the log is silent and the rule finds nothing.
• The high-signal fields are the task's action and trigger: a task that launches PowerShell, runs from a temp path, or fires at logon is far more interesting than a vendor updater.
• Pairing a 4698 rule with a schtasks.exe process-creation rule covers both the API path and the command-line path that loaders use.

Environment

• sigma-cli 1.0+ with a backend installed (I used kusto for Microsoft Sentinel; Splunk and Elastic backends work the same way).
• Windows endpoints with "Audit Other Object Access Events" auditing enabled so Event ID 4698 is actually generated.
• Sysmon or Security 4688 process auditing with command-line capture for the process-creation rule.
• A SIEM workspace to validate the converted query — I tested against a Sentinel trial tenant before promoting anything to an analytics rule.

The Problem

Scheduled tasks are the persistence mechanism I see most often because they are legitimate. Every Windows host runs dozens of them, vendors install more, and administrators script them deliberately. A task that runs powershell.exe -enc <blob> every time a user logs on looks, at the event level, almost identical to a benign maintenance job. The detection problem is not "did a task get created" — it is "did a task get created that no sane administrator would write".

The raw 4698 event carries the answer, but it carries it as an XML task definition stuffed into a single field, which is awkward to query consistently across SIEMs. Each platform parses and names that field differently. Writing the detection in Sigma lets me describe the suspicious shape — a task action that invokes a script host with an encoded command, or executes from a user-writable directory — and let the converter deal with the per-platform field naming. The technique reference is MITRE ATT&CK T1053.005.

The Solution — Writing a Sigma Rule for Scheduled Task Detection

Step 1 — Confirm the event is actually being logged

Before writing a rule against Event ID 4698, confirm the host generates it. The subcategory is off by default in many baselines:

# Check whether the relevant audit subcategory is on
auditpol /get /subcategory:"Other Object Access Events"

# Enable success auditing for it (test this in a controlled GPO first)
auditpol /set /subcategory:"Other Object Access Events" /success:enable

If this is off, the cleanest fix is a Group Policy advanced audit setting pushed fleet-wide rather than a local auditpol call. The essential Windows Event IDs reference lists the other task events worth collecting alongside 4698: 4699 (deleted), 4700/4701 (enabled/disabled), and 4702 (updated).

Step 2 — Match the suspicious task definition in Event ID 4698

Event ID 4698 records the full task XML. Sigma can match substrings of that content, so the rule keys on the action — what the task actually runs — rather than the task name, which an attacker controls:

title: Suspicious Scheduled Task Registered via Event ID 4698
id: 2d4b7c91-8e3f-4a6d-b0c2-5f8a1e9d3c47
status: experimental
description: Detects creation of a scheduled task whose action launches a script host or runs from a user-writable path
references:
  - https://attack.mitre.org/techniques/T1053/005/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.persistence
  - attack.t1053.005
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4698
  suspicious_action:
    TaskContent|contains:
      - 'powershell'
      - 'pwsh'
      - 'cmd.exe /c'
      - 'mshta'
      - 'rundll32'
      - '-enc'
      - '-EncodedCommand'
      - '\AppData\'
      - '\Temp\'
      - '\Users\Public\'
  condition: selection and suspicious_action
falsepositives:
  - Software deployment and patching tools that register tasks running from temp paths
level: high

The selection pins the event; suspicious_action is an OR-list of indicators that rarely appear in a legitimate task action. Because the keys live in separate named blocks combined with and in the condition, the rule fires only when a 4698 event also contains one of the staging indicators.

Step 3 — Catch the command-line path with a process-creation rule

Not every environment audits 4698, and some attackers build tasks through schtasks.exe directly. A second rule on process creation covers that path and depends only on command-line logging, which most fleets already have for Sysmon or Security 4688:

title: Scheduled Task Creation via schtasks.exe with Staging Indicators
id: 7a1f5e0c-2b9d-4c83-a6e1-0d4b8f2c6e95
status: experimental
description: Detects schtasks.exe creating a task that runs a script host or an encoded command
references:
  - https://attack.mitre.org/techniques/T1053/005/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.persistence
  - attack.t1053.005
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\schtasks.exe'
    CommandLine|contains: '/create'
  selection_payload:
    CommandLine|contains:
      - 'powershell'
      - 'pwsh'
      - '-enc'
      - 'mshta'
      - 'rundll32'
      - '\AppData\'
      - '\Temp\'
  condition: all of selection_*
falsepositives:
  - Legitimate administrative provisioning scripts that register tasks
level: medium

all of selection_* requires both blocks — it must be schtasks.exe /create and carry a staging indicator. That keeps the rule off the routine /query and /change calls that fill the log with noise.

Step 4 — Convert and validate against your SIEM

With both rules written, convert them the same way as any Sigma rule. The process-creation rule maps cleanly onto Defender XDR's DeviceProcessEvents table:

sigma convert -t kusto -p sysmon scheduled_task_schtasks.yml

The emitted KQL is the query I would otherwise have written by hand, close to the correlation logic in my SIEM correlation rules walkthrough:

DeviceProcessEvents
| where FileName =~ "schtasks.exe"
| where ProcessCommandLine contains "/create"
| where ProcessCommandLine has_any ("powershell", "pwsh", "-enc", "mshta", "rundll32", "\\AppData\\", "\\Temp\\")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName

Run the converted query against a known-good baseline first. Software deployment tools are the usual false-positive source here; once you see which ones register tasks from temp paths, add a filter block for their signed parent process and reconvert.

Step 5 — Tune the false positives you will actually get

The two reliable noise sources are patch-management agents and OEM updaters. Rather than weaken the indicator list, carve them out by their known parent or account:

  filter_known_good:
    ParentImage|endswith:
      - '\ccmexec.exe'        # SCCM client
      - '\TiWorker.exe'       # Windows servicing
  condition: all of selection_* and not filter_known_good

Documenting each exclusion in the falsepositives field matters as much as writing it. The next person to review the rule needs to know the exclusion was a deliberate tradeoff, not an oversight.

Frequently Asked Questions

Why does my Sigma rule for Event ID 4698 never fire?

Almost always because the "Audit Other Object Access Events" subcategory is disabled. Confirm with auditpol /get /subcategory:"Other Object Access Events". Without success auditing enabled, Windows never writes 4698, so the rule has nothing to match.

Should I detect on 4698 or on schtasks.exe process creation?

Both, ideally. 4698 catches tasks registered through the API or other tools, while the process-creation rule catches command-line creation and works even where 4698 auditing is off. Running both gives redundant coverage for a technique attackers rely on heavily.

Does this catch tasks created by PowerShell instead of schtasks.exe?

The 4698 rule does, because it keys on the registered task definition regardless of what created it. The process-creation rule is specific to schtasks.exe; to cover the Register-ScheduledTask cmdlet, add a parallel selection for powershell.exe with that cmdlet in the command line.

How do I reduce false positives from legitimate software?

Add a filter block keyed on the signed parent process of your patch-management and OEM updater tools, combined with and not in the condition. Avoid trimming the indicator list itself, which weakens detection of the malicious case.

What encryption or obfuscation will this miss?

A task whose action points at a renamed LOLBin or a benign-looking script file that pulls the real payload at runtime will not match these string indicators. Layer this with script-block logging and behavioural detection rather than treating the task rule as complete coverage.

Conclusion

Scheduled-task persistence is common precisely because it hides among legitimate activity, so the detection has to lean on the task's action rather than its existence. Writing that logic as Sigma gives me two portable rules — one on Event ID 4698, one on schtasks.exe — that convert into whatever SIEM I am running and survive a platform change.

Neither rule is complete on its own. The 4698 rule needs an audit subcategory most baselines leave off, and the process-creation rule only sees the command-line path. Run both, exclude your real false positives by parent process, and document why. That combination does the unglamorous triage work of separating the maintenance job from the loader, which is the whole point.

Related Posts

• Windows Security: Detecting Malicious Scheduled Tasks — the raw-log detail behind the Sigma rules in this post.
• Sysmon Configuration for Windows Security Monitoring — the process-creation log source the schtasks.exe rule depends on.
• From Logs to Threats: SIEM Correlation Rules for Real Attacks — how to correlate task-creation alerts once these rules are firing.

Authoritative reference: MITRE ATT&CK T1053.005 — Scheduled Task and the SigmaHQ rule repository.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.