Event ID 4700Audit SuccessSecurityT1053.005

Windows Event ID 4700 — Scheduled Task Enabled

Logged when a previously disabled scheduled task is enabled — via schtasks.exe /change /enable, PowerShell Enable-ScheduledTask, or the Task Scheduler COM API.

MITRE ATT&CK

Technique

T1053.005 · Scheduled Task

Tactic

Execution

View on attack.mitre.org →

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

Task NameThe enabled task's name — if this matches a task that was recently modified (4702) or a built-in security/monitoring task that was previously disabled (4701), investigate immediately; unexpected enables of \Microsoft\Windows\ tasks by non-SYSTEM accounts are high-priority
Subject Account NameWho enabled the task — SYSTEM or a known deployment account is normal for legitimate re-enablement after patching. A standard user or unexpected privileged account enabling tasks outside a maintenance window is suspicious, especially if the same account modified the task in a preceding 4702 event
Subject Logon IDCorrelate with Event 4624 to determine how the account was authenticated when enabling the task — a Type 3 (network) logon indicates the enable was performed remotely, consistent with remote lateral movement preparation

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

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

Go deeper: the full Scheduled Task Abuse — Persistence and Lateral Execution guide

Explore the related technique, investigation steps, and evidence to consider alongside this event.

Read the Scheduled Task Abuse — Persistence and Lateral Execution guide →

See Event ID 4700 in your logs

Copy the event details as XML and inspect them in your browser. No file upload or hosted analysis is needed.

Decode an event →
← All detection guides·Decode an event →