Task Scheduler Event ID 140: Task updated
- Event ID
- 140
- Channel
- Microsoft-Windows-TaskScheduler/Operational
- Provider
- Microsoft-Windows-TaskScheduler
- Log file
- Microsoft-Windows-TaskScheduler%4Operational.evtx
- Category
- Scheduled tasks
- Default logging
- Needs configuration
What event 140 means
Event 140 is written when an already-registered task is changed and saved again: new action, new trigger, new settings or a new run-as account. The record holds the task path in TaskName and the account that made the change in UserName.
As with 106, the event does not say what changed. Compare the current task definition (C:\Windows\System32\Tasks\<TaskName>, the TaskCache registry keys) with a known-good copy, or use Security 4702, which logs the new task XML when object access auditing is enabled.
Updates are common during software and Windows updates, so volume alone is not suspicious. The interesting cases are changes to tasks that normally never change, made by an interactive or remote user account rather than SYSTEM or an installer.
When it is logged
The Microsoft-Windows-TaskScheduler/Operational channel must be enabled — "Enable All Tasks History" in the Task Scheduler console, or wevtutil sl Microsoft-Windows-TaskScheduler/Operational /e:true.
The default state of this channel is not consistent across Windows versions, editions and builds: on some installs it is already recording, on others task history is off and the log stays empty until someone enables it. Check whether the log holds any records before treating a missing event as evidence. On busy hosts the log rolls over quickly.
Key fields
| Field | What it tells you |
|---|---|
| TaskName | Full path of the modified task in the task library, e.g. \Microsoft\Windows\...\TaskName. |
| UserName | Account that saved the change (DOMAIN\user or NT AUTHORITY\SYSTEM). |
Common benign sources
- Application updaters rewriting their own tasks with new versions or schedules.
- Windows servicing refreshing built-in tasks after cumulative or feature updates.
- Administrators editing triggers or credentials of an existing task (for example after a password change).
What attackers do that produces it
- Hijacking an existing, trusted-looking task by replacing its action with a payload, so no new task (106) appears.
- Changing the run-as account of a task to
SYSTEMor a privileged account to gain elevated execution. - Re-enabling or retargeting a disabled vendor task to run attacker code.
Investigation tips
- Flag 140 events where UserName is a regular user or remote admin account instead of
SYSTEMor an installer. - Diff the current task XML against a baseline or another host with the same software.
- Check the next runs of the task (100, 129, 200) for the image path it now launches.
- Correlate with Security 4702 for the new task content if object access auditing is on.
MITRE ATT&CK techniques
| Technique | Tactics |
|---|---|
| T1053.005 Scheduled Task/Job: Scheduled Task | Execution, Persistence, Privilege Escalation |
MITRE ATT&CK v19.2. Technique and tactic names are MITRE's.
Sigma rules for this event
No bundled SigmaHQ rule targets this event ID specifically. Rules on related events may still cover the activity.
Run these rules on your logs
Drop a .evtx file into the viewer: all 2,395 bundled SigmaHQ rules run locally in your browser. Nothing is uploaded.