Unusual Scheduled Task Update

ELASTIC detection rule by Elastic · Elastic License v2

Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts.

[metadata]
creation_date = "2022/08/29"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts.
"""
false_positives = ["Legitimate scheduled tasks may be created during installation of new software."]
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Unusual Scheduled Task Update"
note = """ ## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Unusual Scheduled Task Update

Scheduled tasks in Windows environments automate routine tasks, but adversaries can exploit them for persistence by modifying tasks to execute malicious code. The detection rule identifies first-time task modifications by non-system users, flagging potential unauthorized changes. By excluding known system accounts, it focuses on suspicious user activity, aiding in early threat detection.

### Possible investigation steps

- Review the event logs for event code 4702 to identify the specific scheduled task that was modified and the user account responsible for the change.
- Investigate the user account involved in the modification to determine if it is a legitimate user or potentially compromised. Check for any recent unusual activity associated with this account.
- Examine the details of the modified scheduled task, including the command or script it is set to execute, to assess if it is potentially malicious or unauthorized.
- Cross-reference the scheduled task's modification time with other security events or logs to identify any correlated suspicious activities or anomalies.
- Check the history of the scheduled task to determine if this is the first modification or if there have been previous changes that might indicate a pattern of unauthorized access.

### False positive analysis

- Scheduled task modifications by IT administrators performing routine maintenance can trigger alerts. To manage this, create exceptions for known administrator accounts that regularly update tasks.
- Software updates or installations by trusted applications may modify scheduled tasks. Identify these applications and exclude their associated user accounts or processes from the rule.
- Automated scripts or management tools that modify tasks as part of their normal operation can be mistaken for suspicious activity. Document these tools and exclude their activity from detection.
- Temporary user accounts used for specific projects or tasks might modify scheduled tasks. If these accounts are verified and trusted, consider excluding them from the rule during their active period.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized scheduled task modifications or potential lateral movement by the adversary.
- Terminate any suspicious processes associated with the modified scheduled task to halt any ongoing malicious activity.
- Review the modified scheduled task details, including the command or script being executed, and remove or disable any malicious components identified.
- Reset the credentials of the user account involved in the modification to prevent further unauthorized access, and investigate for any signs of credential compromise.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
- Implement additional monitoring and alerting for scheduled task modifications across the environment to enhance detection of similar threats in the future.
"""

setup = """## Setup

Audit Other Object Access Events must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-other-object-access-events
"""

references = ["https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698"]
risk_score = 21
rule_id = "a02cb68e-7c93-48d1-93b2-2c39023308eb"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.category: "iam" and host.os.type:"windows" and event.code: "4702" and
  not winlog.event_data.SubjectUserSid : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20") and
  not user.name : *$
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.005"
name = "Scheduled Task"
reference = "https://attack.mitre.org/techniques/T1053/005/"



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[rule.new_terms]
field = "new_terms_fields"
value = ["winlog.event_data.TaskName"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

3f3154e4-5ec1-4ce5-b4ed-aabea7bbe93e

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion