Log Dejargonizer

Windows Security Log · Event 4702

Event 4702: A scheduled task was updated

An existing scheduled task was modified. It is far noisier than task creation, because Windows updates its own maintenance tasks constantly — and that noise is exactly what makes hijacking an existing task quieter than creating a new one.

Also written as Event ID 4702A scheduled task was updated4702 task modified

What it means for you

On a personal computer

A scheduled job on this PC was changed. Windows adjusts its own maintenance schedules regularly, so this is usually nothing.

For an analyst

The volume difference from 4698 matters. Windows Update, defragmentation, and telemetry tasks rewrite themselves on a cycle, and those updates dominate. Baseline them by task path — most live under \Microsoft\Windows\ — and what remains is small. The detection is a task whose name you recognise but whose Command no longer points where it used to, which no amount of name-based auditing will catch.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A scheduled task was updated.

Subject:
  Security ID:    CORP\jbrooks
  Account Name:   jbrooks
  Account Domain: CORP
  Logon ID:       0x3E9A11

Task Information:
  Task Name: \Microsoft\Windows\Defrag\ScheduledDefrag
  Task Content: <?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2">
  <Triggers><LogonTrigger><Enabled>true</Enabled></LogonTrigger></Triggers>
  <Principals><Principal id="Author"><UserId>S-1-5-18</UserId><RunLevel>HighestAvailable</RunLevel></Principal></Principals>
  <Actions>
    <Exec>
      <Command>C:\Users\jbrooks\AppData\Local\Temp\wh.exe</Command>
    </Exec>
  </Actions>
</Task>

The fields that decide it

Everything else in the log line is context.

TaskName
The task's path and name. Tasks under \Microsoft\Windows\ are usually Windows updating itself.
TaskContent
The new task definition as XML. Compare the Command against what the task is supposed to run.
  • A Command that no longer matches the task's stated purposeThe hijack pattern. A familiar name now running something else.
  • A Command in a temp or user profile directoryTasks do not normally run things from there.
  • A newly added <LogonTrigger> or <BootTrigger>A task that did not previously run at startup now does.
  • <UserId>S-1-5-18</UserId> addedThe task now runs as SYSTEM when it previously did not.
SubjectUserName
Who made the change. SYSTEM is normal for Windows maintaining its own tasks.
SubjectLogonId
The session responsible. Join to the 4624 for the source address.

Ordinary reasons this happens

Most of the time it is one of these.

  • Windows updating its own maintenance tasks, which is the overwhelming majority.
  • Software updates rewriting their updater task.
  • Management tooling adjusting schedules across the estate.
  • An administrator changing when a job runs.
  • Group Policy reapplying a task definition at refresh.

When it is not ordinary

Hijacking a legitimate task instead of creating one.

What gives it awayA recognised task name whose Command now points at a user-writable directory or a shell. Auditing by task name alone will never catch this.

ATT&CK T1053.005

Adding a trigger to an existing task.

What gives it awayA task that previously ran on a schedule now also carrying a logon or boot trigger.

ATT&CK T1053.005

Escalating an existing task's privileges.

What gives it awayA task modified to run as SYSTEM or with HighestAvailable when it previously did not.

ATT&CK T1053.005

Reverting a task after use.

What gives it awayAn update returning a task to its original definition shortly after the payload ran, which removes the evidence while leaving the task in place.

ATT&CK T1070

What to do next

  1. Filter out tasks under \Microsoft\Windows\ updated by SYSTEM first — that is most of the volume.
  2. For what remains, read the Command in the new definition and ask whether it matches the task's name and purpose.
  3. Compare against the same task on a known-good machine of the same build. A diff is far more informative than the event alone.
  4. Check whether triggers were added, particularly logon or boot.
  5. Check whether the account the task runs as changed.
  6. If a 4698 exists for the same task, compare the original definition against this one.

Queries to run

kql Task updates by a real account that point somewhere unusual. Short list once Windows' own maintenance is excluded. 
SecurityEvent | where EventID == 4702 | where SubjectUserName != 'SYSTEM' | where RenderedDescription has_any ('\\Temp\\','\\AppData\\','powershell','cmd.exe','-enc ') | project TimeGenerated, Computer, SubjectUserName, RenderedDescription
kql The tasks generating the noise, so you know what to exclude rather than guessing. 
SecurityEvent | where EventID == 4702 | extend Task = extract(@'Task Name:\s*(\S+)', 1, RenderedDescription) | where Task startswith '\\Microsoft\\Windows\\' | summarize count() by Task | order by count_ desc | take 20
powershell Tasks whose definitions changed recently, including any modified before you began collecting this event. 
Get-ScheduledTask | Where-Object { $_.Date -and ([datetime]$_.Date) -gt (Get-Date).AddDays(-30) } | Select-Object TaskName, TaskPath, Date, @{n='Runs';e={$_.Actions.Execute}}

Common questions

Why do I see so many Event 4702 entries?

Because Windows rewrites its own scheduled tasks routinely — update, defragmentation, and telemetry tasks all update their definitions on a cycle, and each rewrite logs one. Filter to updates made by accounts other than SYSTEM, and to tasks outside \Microsoft\Windows\, and the volume drops to something you can actually read.

Why is modifying a task stealthier than creating one?

Because the name stays familiar. A new task called something unusual stands out in a task list; an existing Windows maintenance task that now runs a different command does not. Anyone auditing by task name walks straight past it, which is why comparing the Command against a known-good machine matters more than reviewing names.

How do I compare a task against what it should be?

Pull the same task from a machine of the same build with `Export-ScheduledTask -TaskName <name>` and diff the XML. The Command, the triggers, and the Principal are the three parts worth checking. Task definitions are stable across identical builds, so a difference is meaningful.

Read next

Vendor documentation

Last reviewed 28 August 2026