Windows Event ID 4702 — Scheduled Task Modified

MITRE ATT&CK

Why It Matters

Task hijacking is stealthier than new task creation (Event 4698) because the task name is already trusted — attackers leave the name intact and only change what the task executes. Windows ships with hundreds of built-in tasks (Windows Defender, Windows Update, MicrosoftEdgeUpdate, OneDriveRemediation) that run as SYSTEM on a schedule; modifying one of these turns a trusted OS mechanism into a persistent payload launcher. 4702 is also less monitored than 4698 — many detection stacks alert on task creation but miss modification. Post-exploitation frameworks (Cobalt Strike, Metasploit, Empire) routinely use task modification for durable persistence after establishing an initial foothold.

Key Fields

Investigation Tips

1. 1.XML diff is the core investigation: open Task New Content and focus on the <Actions><Exec> block. Any new <Command> or <Arguments> entry not matching the task's historical baseline is the modification. Compare against a known-good snapshot from SCCM, Intune, or a previously captured 4702 event.
2. 2.Built-in task hijacking: any 4702 for a task under \Microsoft\Windows\, \Microsoft\Edge\, or \Microsoft\Office\ where Subject Account Name is not SYSTEM or a known deployment account is a critical incident. Legitimate Windows task updates come from Windows Update or SYSTEM — never from a user account or interactive session.
3. 3.Encoded payload detection: search the Task New Content XML for -EncodedCommand, -enc, -w hidden, FromBase64String, or any http:// / https:// URL inside <Arguments>. These strings in task XML are unambiguous malicious modification indicators.
4. 4.Persistence upgrade via triggers: if the <Triggers> section now includes <LogonTrigger> or <BootTrigger> that wasn't there before, the attacker has ensured their payload executes on every user logon or system boot — treat this as a high-confidence persistence IOC.
5. 5.Correlate with 4688: look for schtasks.exe, PowerShell, or cmd.exe executing immediately before the 4702 timestamp on the same host. This shows the attack chain — what process made the modification and what command it ran.
6. 6.Audit policy verification: 4702 requires 'Audit Other Object Access Events' in Advanced Audit Policy Configuration → Object Access to be enabled. Without it, task modifications are completely invisible. Verify this is deployed via GPO on endpoints and servers — gaps in coverage are attacker opportunities.
7. 7.Mass modification pattern: multiple 4702 events across different task names from a single account within seconds indicates a script or framework (Cobalt Strike's schtasks module, Impacket's atexec) performing batch task hijacking. Corroborate with network logon events on the target hosts.

Detection Logic

// Task modifications with encoded or suspicious command content
SecurityEvent
| where EventID == 4702
| where TaskContent has_any (
    "-EncodedCommand", "-enc ", "FromBase64String",
    "http://", "https://", "\\AppData\\", "\\Temp\\",
    "-w hidden", "-WindowStyle Hidden")
| project TimeGenerated, SubjectAccount, TaskName, TaskContent, Computer
| sort by TimeGenerated desc

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

Related Event IDs

Frequently Asked Questions

Is Event ID 4702 always suspicious?

No — Windows Update, Group Policy, and legitimate management tools modify tasks regularly. What makes 4702 suspicious is who modified it (Subject Account Name — non-SYSTEM or non-deployment account is a red flag), which task was modified (any \Microsoft\Windows\ task modified by a user account is high priority), and what changed in the XML Actions block.

How do attackers use Event ID 4702 for persistence?

Task hijacking: attackers modify an existing trusted task's XML Actions block to execute their payload while leaving the task name unchanged. The task name stays legitimate (e.g., \Microsoft\Windows\Defrag\ScheduledDefrag) while the Command now points to a malicious binary. This bypasses detections focused on new task creation (4698) since the task already existed and looks trusted by name.

What's the difference between Event ID 4698 and 4702?

4698 fires when a new scheduled task is created; 4702 fires when an existing task is modified. Many detection stacks alert on 4698 but miss 4702 — attackers know this and prefer hijacking existing tasks over creating new ones. A 4698 followed immediately by 4702 on the same task name is the create-then-modify pattern: set up a task, immediately change its payload before execution triggers.

What should I look for in Event ID 4702 Task XML?

Focus on the Task New Content XML Actions block. Look for: new <Command> paths in AppData, Temp, or unusual directories; <Arguments> containing encoded PowerShell, base64, or download URLs; <UserId> set to SYSTEM with a non-standard Command; and <Author> that doesn't match a known deployment account. Compare against a known-good baseline from SCCM, Intune, or a previous 4698 creation event.