Windows Event ID 4700 — Scheduled Task Enabled

MITRE ATT&CK

Why It Matters

Enabling a disabled task is a stealthier persistence technique than creating a new one. Attackers create or modify a task while it is disabled — bypassing execution monitoring — and then enable it in a separate step when ready to execute. This splits the suspicious activity into two lower-signal events: one modification (4702) and one enable (4700), neither of which looks alarming in isolation. The pattern disable (4701) → modify (4702) → enable (4700) is particularly common in post-exploitation frameworks that need to update a task's payload without triggering immediate execution or EDR alerts on task creation. Additionally, attackers disabling then re-enabling security-related tasks (backup agents, AV scheduled scans, monitoring heartbeats) to create maintenance windows for malicious activity generate 4700 as the cover-your-tracks step.

Key Fields

Investigation Tips

1. 1.Enable following modify is the core pattern: search for a 4702 (task modified) event for the same Task Name in the hours before this 4700. If the modification changed the task's <Actions> XML and this enable makes it active, you're looking at a two-step payload activation — the modification was the weaponization, the enable is the arming.
2. 2.Disable-modify-enable sequence: look back for a 4701 (task disabled) event for the same Task Name before the 4702 modification. This three-event sequence — disable, modify payload, re-enable — is used by frameworks to update running tasks without triggering task-creation detections. All three events should be attributed to the same account within a compressed time window.
3. 3.Built-in task enables from unexpected accounts: legitimate enables of Windows built-in tasks (any path under \Microsoft\Windows\) come from SYSTEM or Windows Update during patching. An interactive user account or service account enabling one of these tasks is unusual and warrants investigation of the task's current XML content.
4. 4.Security task re-enable: if a security tool, backup agent, or monitoring heartbeat task was previously disabled (4701) and then re-enabled (4700) by the same non-SYSTEM account, this is the 'hide your tracks, then restore to avoid alerting on sustained silence' pattern. The window between disable and re-enable is when the attacker operated.
5. 5.Correlate with execution: after 4700, the task will fire at its next trigger time. Check Event ID 4688 (process creation) for what the task spawned — the TaskScheduler/Operational log (Event 201 — Task completed action) gives you the exact execution timestamp and exit code.

Detection Logic (KQL)

Microsoft Sentinel (KQL) — detect the disable→modify→enable sequence indicating payload swap, and unexpected task enables from non-system accounts.

// Disable → modify → enable sequence within 1 hour (payload swap pattern)
let disables = SecurityEvent
| where EventID == 4701
| project DisabledTime = TimeGenerated, TaskName, Computer, Account = SubjectAccount;
let modifies = SecurityEvent
| where EventID == 4702
| project ModifiedTime = TimeGenerated, TaskName, Computer;
let enables = SecurityEvent
| where EventID == 4700
| project EnabledTime = TimeGenerated, TaskName, Computer, Enabler = SubjectAccount;
enables
| join kind=inner modifies on TaskName, Computer
| join kind=inner disables on TaskName, Computer
| where DisabledTime < ModifiedTime and ModifiedTime < EnabledTime
| where EnabledTime - DisabledTime < 1h
| project Computer, TaskName, Account, DisabledTime, ModifiedTime, EnabledTime
| sort by DisabledTime desc

// Built-in Windows task enabled by non-SYSTEM account
SecurityEvent
| where EventID == 4700
| where TaskName has_any ("\\Microsoft\\Windows\\", "\\Microsoft\\Edge\\")
| where SubjectAccount !endswith "$"
| where SubjectAccount !in ("SYSTEM", "NT AUTHORITY\\SYSTEM")
| project TimeGenerated, SubjectAccount, TaskName, Computer

Related Event IDs