Detect scheduled task registered with a suspicious action

Siemphony@siemphonyhighT1053.005unverifiedPlaybook · Persistence established

Matches Windows Security scheduled-job registration (4698) and modification (4702) where the task definition itself carries an encoded, download-oriented or living-off-the-land action, so the payload is inspectable at registration time rather than after svchost.exe launches it — MITRE's CommandLineEntropyThreshold knob applied to the registration event. The two event ids carry the task XML under different names: 4698 has `TaskContent` and 4702 has `TaskNewContent`, so each event id gets its own selection. ANDing one field name against both event ids, as the previous version did, silently killed the modification half. Two caveats a SOC needs before deploying: 4698 and 4702 live in the `Audit Other Object Access Events` subcategory, which is off by default and is not enabled by the Microsoft or CIS baselines, so this rule returns nothing at all until audit policy is changed; and the terms match the whole task XML, including RegistrationInfo, so a task whose author, description or URI merely mentions one of them matches without its action being suspicious. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0441, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

1title: Detect scheduled task registered with a suspicious action2id: e1a2d627-d92d-4858-9448-64c9192bbfa63status: experimental4description: |5  Matches Windows Security scheduled-job registration (4698) and modification6  (4702) where the task definition itself carries an encoded, download-oriented7  or living-off-the-land action, so the payload is inspectable at registration8  time rather than after svchost.exe launches it — MITRE's9  CommandLineEntropyThreshold knob applied to the registration event. The two10  event ids carry the task XML under different names: 4698 has `TaskContent` and11  4702 has `TaskNewContent`, so each event id gets its own selection. ANDing one12  field name against both event ids, as the previous version did, silently13  killed the modification half. Two caveats a SOC needs before deploying: 469814  and 4702 live in the `Audit Other Object Access Events` subcategory, which is15  off by default and is not enabled by the Microsoft or CIS baselines, so this16  rule returns nothing at all until audit policy is changed; and the terms match17  the whole task XML, including RegistrationInfo, so a task whose author,18  description or URI merely mentions one of them matches without its action19  being suspicious.20  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0441, not hand-written and not tested by its author. Any lab result is on this rule's own page.21references:22  - https://attack.mitre.org/techniques/T1053/00523  - https://attack.mitre.org/detectionstrategies/DET044124author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)25date: 2026-08-1626tags:27  - attack.execution28  - attack.persistence29  - attack.privilege-escalation30  - attack.t1053.00531logsource:32  product: windows33  service: security34detection:35  selection_created:36    EventID: 469837  selection_updated:38    EventID: 470239  content_created:40    - TaskContent|contains:41        - 'FromBase64String'42        - 'Invoke-Expression'43        - 'Invoke-WebRequest'44        - 'DownloadString'45        - 'DownloadFile'46        - 'mshta'47        - 'regsvr32'48        - 'certutil'49        - '\AppData\Local\Temp\'50        - '\AppData\Roaming\'51        - '\Users\Public\'52        - '\Windows\Temp\'53        - '\PerfLogs\'54    - TaskContent|re: '-e(c|n|nc|ncodedcommand)?[ :=]'55  content_updated:56    - TaskNewContent|contains:57        - 'FromBase64String'58        - 'Invoke-Expression'59        - 'Invoke-WebRequest'60        - 'DownloadString'61        - 'DownloadFile'62        - 'mshta'63        - 'regsvr32'64        - 'certutil'65        - '\AppData\Local\Temp\'66        - '\AppData\Roaming\'67        - '\Users\Public\'68        - '\Windows\Temp\'69        - '\PerfLogs\'70    - TaskNewContent|re: '-e(c|n|nc|ncodedcommand)?[ :=]'71  condition: (selection_created and content_created) or (selection_updated and content_updated)72falsepositives:73  - "Group Policy Preferences Scheduled Task items. The client-side extension re-applies them on every Group Policy refresh (90 minutes plus jitter) and at every boot and logon, writing a fresh 4698 each time on every host in scope, and GPP tasks routinely stage an installer or script under `\\Windows\\Temp\\` or `\\Users\\Public\\`. On a domain with a handful of GPP task items this alone can outproduce the rest of the rule. MITRE's TaskNamePattern knob is where the recurring names belong."74  - "Software deployment and patching platforms that register short-lived tasks pointing at a staged installer under `\\Windows\\Temp\\`, `\\Users\\Public\\` or a user profile. These fire under SYSTEM at predictable maintenance times, which is what MITRE's UserContext knob is for."75  - "In-house administrative PowerShell that passes an encoded command to survive quoting problems in the task XML. Encoding is a convenience there, not evasion, so allow-list by the registering account and the task path rather than dropping the encoded-command pattern, which is the rule's best term."76  - "Any edit to an existing task re-logs the complete new definition in 4702, so changing a trigger on a known-good task that happens to contain a matched string re-alerts every time it is touched, with nothing new having been added to the action."77level: high

Sentinel · KQL

Run this as a search.

SecurityEvent| where ((EventID == 4698 and ((TaskContent contains "FromBase64String" or TaskContent contains "Invoke-Expression" or TaskContent contains "Invoke-WebRequest" or TaskContent contains "DownloadString" or TaskContent contains "DownloadFile" or TaskContent contains "mshta" or TaskContent contains "regsvr32" or TaskContent contains "certutil" or TaskContent contains "\\AppData\\Local\\Temp\\" or TaskContent contains "\\AppData\\Roaming\\" or TaskContent contains "\\Users\\Public\\" or TaskContent contains "\\Windows\\Temp\\" or TaskContent contains "\\PerfLogs\\") or TaskContent matches regex "(?i)-e(c|n|nc|ncodedcommand)?[ :=]")) or (EventID == 4702 and ((TaskNewContent contains "FromBase64String" or TaskNewContent contains "Invoke-Expression" or TaskNewContent contains "Invoke-WebRequest" or TaskNewContent contains "DownloadString" or TaskNewContent contains "DownloadFile" or TaskNewContent contains "mshta" or TaskNewContent contains "regsvr32" or TaskNewContent contains "certutil" or TaskNewContent contains "\\AppData\\Local\\Temp\\" or TaskNewContent contains "\\AppData\\Roaming\\" or TaskNewContent contains "\\Users\\Public\\" or TaskNewContent contains "\\Windows\\Temp\\" or TaskNewContent contains "\\PerfLogs\\") or TaskNewContent matches regex "(?i)-e(c|n|nc|ncodedcommand)?[ :=]")))

Splunk · SPL

Run this as a search.

index=* | where ((EventID=4698 AND ((match(TaskContent, "(?i)FromBase64String") OR match(TaskContent, "(?i)Invoke-Expression") OR match(TaskContent, "(?i)Invoke-WebRequest") OR match(TaskContent, "(?i)DownloadString") OR match(TaskContent, "(?i)DownloadFile") OR match(TaskContent, "(?i)mshta") OR match(TaskContent, "(?i)regsvr32") OR match(TaskContent, "(?i)certutil") OR match(TaskContent, "(?i)\\\\AppData\\\\Local\\\\Temp\\\\") OR match(TaskContent, "(?i)\\\\AppData\\\\Roaming\\\\") OR match(TaskContent, "(?i)\\\\Users\\\\Public\\\\") OR match(TaskContent, "(?i)\\\\Windows\\\\Temp\\\\") OR match(TaskContent, "(?i)\\\\PerfLogs\\\\")) OR match(TaskContent, "-e(c|n|nc|ncodedcommand)?[ :=]"))) OR (EventID=4702 AND ((match(TaskNewContent, "(?i)FromBase64String") OR match(TaskNewContent, "(?i)Invoke-Expression") OR match(TaskNewContent, "(?i)Invoke-WebRequest") OR match(TaskNewContent, "(?i)DownloadString") OR match(TaskNewContent, "(?i)DownloadFile") OR match(TaskNewContent, "(?i)mshta") OR match(TaskNewContent, "(?i)regsvr32") OR match(TaskNewContent, "(?i)certutil") OR match(TaskNewContent, "(?i)\\\\AppData\\\\Local\\\\Temp\\\\") OR match(TaskNewContent, "(?i)\\\\AppData\\\\Roaming\\\\") OR match(TaskNewContent, "(?i)\\\\Users\\\\Public\\\\") OR match(TaskNewContent, "(?i)\\\\Windows\\\\Temp\\\\") OR match(TaskNewContent, "(?i)\\\\PerfLogs\\\\")) OR match(TaskNewContent, "-e(c|n|nc|ncodedcommand)?[ :=]"))))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4698$</field>    <field name="TaskContent" type="pcre2">(?i)((FromBase64String|Invoke-Expression|Invoke-WebRequest|DownloadString|DownloadFile|mshta|regsvr32|certutil|\\AppData\\Local\\Temp\\|\\AppData\\Roaming\\|\\Users\\Public\\|\\Windows\\Temp\\|\\PerfLogs\\)|-e(c|n|nc|ncodedcommand)?[ :=])</field>    <description>Detect scheduled task registered with a suspicious action (1/2)</description>    <mitre>      <id>T1053.005</id>    </mitre>  </rule>   <rule id="100001" level="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4702$</field>    <field name="TaskNewContent" type="pcre2">(?i)((FromBase64String|Invoke-Expression|Invoke-WebRequest|DownloadString|DownloadFile|mshta|regsvr32|certutil|\\AppData\\Local\\Temp\\|\\AppData\\Roaming\\|\\Users\\Public\\|\\Windows\\Temp\\|\\PerfLogs\\)|-e(c|n|nc|ncodedcommand)?[ :=])</field>    <description>Detect scheduled task registered with a suspicious action (2/2)</description>    <mitre>      <id>T1053.005</id>    </mitre>  </rule></group>

Elastic · ES|QL

Run this as a search.

Elastic cannot express this construct. ES|QL RLIKE uses Lucene regexp syntax, which has no case-insensitive flag, and Sigma regexes are case-insensitive. Use |contains/|startswith/|endswith, or write the ES|QL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: security / windows
Level: high
Category: persistence_scheduled_task
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: e1a2d627-d92d-4858-9448-64c9192bbfa6

ATT&CKT1053.005

T1053.005Scheduled Task

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Evidence

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Noise checkdid not run

The Sigma source did not build into an evaluable rule, so the check did not run. this rule uses a regular expression, which is not evaluated here — an untrusted pattern can be made to run for a very long time

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1053.005, evaluated against their — events.

Using it

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

UserContext (MITRE's knob): carve out the SYSTEM-invoked deployment agents
TaskNamePattern (MITRE's knob): allow-list the recurring known task names
Split 4702 into a separate, lower-severity rule if modification churn dominates
Add \ProgramData\ cautiously — a common staging directory, and a legitimate

Declared by the author

Group Policy Preferences Scheduled Task items. The client-side extension re-applies them on every Group Policy refresh (90 minutes plus jitter) and at every boot and logon, writing a fresh 4698 each time on every host in scope, and GPP tasks routinely stage an installer or script under \Windows\Temp\ or \Users\Public\. On a domain with a handful of GPP task items this alone can outproduce the rest of the rule. MITRE's TaskNamePattern knob is where the recurring names belong.
Software deployment and patching platforms that register short-lived tasks pointing at a staged installer under \Windows\Temp\, \Users\Public\ or a user profile. These fire under SYSTEM at predictable maintenance times, which is what MITRE's UserContext knob is for.
In-house administrative PowerShell that passes an encoded command to survive quoting problems in the task XML. Encoding is a convenience there, not evasion, so allow-list by the registering account and the task path rather than dropping the encoded-command pattern, which is the rule's best term.
Any edit to an existing task re-logs the complete new definition in 4702, so changing a trigger on a known-good task that happens to contain a matched string re-alerts every time it is touched, with nothing new having been added to the action.

Lessonpersistence scheduled task

persistence scheduled taskAI draft — unreviewed

01 · What this rule detects

A scheduled task being registered (4698) or modified (4702) where the task definition itself contains an encoded, download-oriented, living-off-the-land or world-writable-path action. The key move is when it inspects. MITRE's analytic AN1221 describes task creation "followed by execution from svchost.exe or taskeng.exe" — a chain across two events. This rule declines to wait for the execution half, because at registration time the Security channel hands you the entire task XML in TaskContent. The payload is readable before it ever runs.

02 · Telemetry you need

The Windows Security channel with the Other Object Access Events audit
TaskContent preserved intact. It is the whole task XML and it is long;
Nothing else. That is the point — no Sysmon, no correlation.

03 · How the logic works

Two conditions, AND-ed:

Why EventID is written out. The log source is product: windows, service: security — the raw channel, not a Sigma taxonomy category. Nothing filters the event type for you, so without it the rule would evaluate TaskContent against every Security event in the channel. MITRE's brief says so directly: the log source note reads "Security EventID 4698 — match EventID in detection". Why 4698 and 4702 and not their neighbours. The analytic mentions deletion too, and 4699 exists for it — but a deletion carries no task definition, so it cannot satisfy the second condition and would only widen the first. 4700/4701 (enabled/disabled) likewise carry no action string. These two are the only event IDs that ship a new task body. Why the registration event rather than `schtasks.exe` command lines. Task creation via schtasks /XML, PowerShell Register-ScheduledTask, the WMI PS_ScheduledTask class or the COM API leaves nothing useful on a command line. 4698 catches all of them, because the Task Scheduler service logs the resulting definition regardless of who asked. The four term families. Encoding (-enc carries a trailing space so it does not match -encoding; -EncodedCommand covers the long form); in-memory execution and retrieval; three LOLBins; three directories any unprivileged user can write to. Together they are MITRE's CommandLineEntropyThreshold knob approximated by literals — Sigma cannot compute entropy, so the author enumerated the constructs high-entropy payloads arrive in. Two caveats before you triage. mshta, regsvr32 and certutil are bare substrings, so a task whose <Description> merely mentions one of them matches. And contains is case-insensitive in Sigma's model, but the renders are not uniform — the Elastic LIKE and Wazuh pcre2 forms in translations.json carry no case-insensitivity flag, so -ENC may slip past them. Verify that in your backend rather than assuming YAML semantics survive translation.

04 · Common false positives

Software deployment and patching platforms registering short-lived tasks that
In-house administrative PowerShell using -EncodedCommand to dodge quoting
4702 re-fires whenever a task is touched. Editing a trigger in the Task

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from MITRE ATT&CK DET0441 and never executed against a log line. The high level reflects that an AND of a registration event and an obfuscation indicator is a tighter join than either half alone; it is not a measured false-positive rate, because there is no measurement.
tier_2: confirm the audit subcategory is on, run the rule over historical 4698/4702 volume, and turn your actual deployment tooling into named exclusions.
tier_3: restores MITRE's chain — registration correlated with the subsequent svchost.exe/taskeng.exe execution inside a TimeWindow, which is correlation logic Sigma cannot carry.

Related detections1 nearby

Detect COM registration utility running a user-writable assembly

Ranked by how alike the detection logic reads, computed offline. Proximity is not evidence — each of these carries its own verification state on its own page.

Share this rule

/u/siemphony/e1a2d627-d92d-4858-9448-64c9192bbfa6

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

1 thread

@hana-kobayashi
30 Aug 2026
Rolled this out to three tenants and got zero hits on all three, which felt like a clean estate until we read the description properly: 4698 and 4702 live in Audit Other Object Access Events, off by default and not enabled by the Microsoft or CIS baselines, and none of the three had it on. The rule was not quiet, it was blind, and nothing on the dashboard distinguishes the two. After the audit-policy change, two tenants produce events and the third's forwarder truncates the task XML, so the terms have nothing to match on. Fire a benign registration through the whole pipe before you count this as coverage.
- @priya-raman
  30 Aug 2026
  Validated the registration leg on the range: a task carrying a FromBase64String action fires 4698 exactly as written. The field-name split is real, too — our first local port matched TaskContent on both event ids, and the 4702 modification leg was silently dead, which is precisely the bug the description says an earlier version of this rule had. One trap from the terms matching the whole task XML: RegistrationInfo counts, so a task whose author or description merely mentions certutil matches with a perfectly innocent action. We hit it with our own inventory job, whose description read "replaces certutil download job".

Detect scheduled task registered with a suspicious action

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Wazuh · XML rule

Elastic · ES|QL

Community

Verdicts from engineers who deployed it

1 thread