Detection rules › Splunk

Windows Scheduled Task with Suspicious Name

Author
Steven Dick
Source
upstream

The following analytic detects the creation, modification, or enabling of scheduled tasks with known suspicious or malicious task names. It leverages Windows Security EventCode 4698, 4700, and 4702 to identify when such tasks are registered, modified, or enabled. This activity is significant as it may indicate an attempt to establish persistence or execute malicious commands on a system. If confirmed malicious, this could allow an attacker to maintain access, execute arbitrary code, or escalate privileges, posing a severe threat to the environment.

MITRE ATT&CK coverage

TacticTechniques
ExecutionT1053.005 Scheduled Task/Job: Scheduled Task
PersistenceT1053.005 Scheduled Task/Job: Scheduled Task
Privilege EscalationT1053.005 Scheduled Task/Job: Scheduled Task

Event coverage

ProviderEvent IDTitle
Security-Auditing4698A scheduled task was created.
Security-Auditing4700A scheduled task was enabled.
Security-Auditing4702A scheduled task was updated.

Stages and Predicates

Stage 1: search

search EventCode IN (4698, 4700, 4702)

Stage 2: eval

eval ... using (TaskContentNew)

Stage 3: xmlkv

xmlkv

Stage 4: stats

stats BY Computer, TaskName, Command, Enabled, Hidden, Caller_User_Name, EventCode

Stage 5: lookup

lookup <lookup> TaskName, task_name

Stage 6: where

where isnotnull(tool_type)

Stage 7: eval

eval ... using (Arguments, Author, Caller_User_Name, Command, Computer, TaskName)

Stage 8: search

search

Stage 9: search

search

Stage 10: search

search `macro`

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
EventCodein
  • 4698 corpus 2 (splunk 2)
  • 4700 corpus 2 (splunk 2)
  • 4702 corpus 2 (splunk 2)

Neighbors

Often fire together

Rules that target events appearing in the same incident timelines. They pattern-match on adjacent steps of the same TTP, so an alert from one is often paired with alerts from these. Useful for triage context and for assembling chained-detection rules.

Share event IDs (chain-detection candidates)

Rules that observe the same Windows event-ID pairs as this one. If you're authoring a multi-stage / sequence rule that spans these events, these are the existing detections that already cover one or both endpoints.