Log Dejargonizer

Windows Security Log · Event 4698

Event 4698: A scheduled task was created

A new scheduled task was registered. Tasks run on their own, survive reboots, and can run as SYSTEM — which is why creating one is among the most common ways to keep access to a machine. The event includes the task's full definition.

Also written as Event ID 4698A scheduled task was created4698 scheduled task persistence

What it means for you

On a personal computer

A program set something to run automatically on a schedule. Normal right after installing software. Worth checking if you have not installed anything.

For an analyst

The Task Content field is the whole event — it is the task XML, so you get the command, the arguments, the trigger, and the account it runs as without pivoting anywhere. Watch for tasks running from user-writable directories, tasks that run a shell, triggers tied to logon or boot, and RunLevel HighestAvailable on a task created by a non-administrator.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A scheduled task was created.

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

Task Information:
  Task Name: \Microsoft\Windows\UpdateOrchestrator\Refresh
  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>
      <Arguments>-w hidden</Arguments>
    </Exec>
  </Actions>
</Task>

The fields that decide it

Everything else in the log line is context.

TaskName
The task's path and name. Names imitating Microsoft's own tasks are a common disguise.
TaskContent
The full task definition as XML. Read this rather than anything else.
  • A Command pointing at a temp or user profile directoryTasks do not normally run things from these locations.
  • A Command that is cmd.exe, powershell.exe, or mshta.exeA task that exists only to run a shell command.
  • Arguments containing an encoded or base64 blobAlmost never legitimate.
  • <LogonTrigger> or <BootTrigger>Runs at every sign-in or boot. The point of persistence.
  • <UserId>S-1-5-18</UserId>Runs as SYSTEM, with full privilege.
  • <RunLevel>HighestAvailable</RunLevel>Runs elevated.
SubjectUserName
Who created it.
SubjectLogonId
The session that created it. Join to the 4624 for the source address.

Ordinary reasons this happens

Most of the time it is one of these.

  • Software installation, which frequently registers update and maintenance tasks.
  • Windows itself creating maintenance tasks.
  • Management and deployment tooling scheduling work.
  • Backup software registering its schedule.
  • Administrators scheduling legitimate scripts.

When it is not ordinary

Persistence through a scheduled task.

What gives it awayA task running a binary or script from a temp or user directory, triggered at logon or boot.

ATT&CK T1053.005

Remote execution across the network.

What gives it awayA task created on a remote machine, usually visible alongside atsvc named pipe access in Event 5145.

ATT&CK T1053.005

Privilege escalation.

What gives it awayA task created by a standard user that runs as SYSTEM or with HighestAvailable.

ATT&CK T1053.005

A task disguised as a Windows component.

What gives it awayA task name closely imitating a Microsoft one but with a command that does not match where the real component lives.

ATT&CK T1036.005

What to do next

  1. Read the Task Content XML. The command, the trigger, and the account are all there.
  2. Check where the command runs from. Program Files and System32 are normal; temp and profile directories are not.
  3. Check the trigger. Logon and boot triggers are what make a task persistence.
  4. Check the account it runs as, against who created it. A standard user creating a SYSTEM task needs explaining.
  5. Check whether a software installation was happening at that time.
  6. Compare the task name against the tasks on a known-good machine of the same build.
  7. Correlate with 5145 atsvc access to see whether it was created remotely.

Queries to run

kql Tasks running from user-writable paths or invoking a shell. Short list, high value. 
SecurityEvent | where EventID == 4698 | where RenderedDescription has_any ('\\Temp\\','\\AppData\\','\\Users\\Public\\','cmd.exe','powershell.exe','mshta.exe','-enc ') | project TimeGenerated, Computer, SubjectUserName, RenderedDescription
kql Tasks that appear on only one or two machines. Your own software will be everywhere. 
SecurityEvent | where EventID == 4698 | extend Task = extract(@'<Command>(.+?)</Command>', 1, RenderedDescription) | summarize hosts = dcount(Computer), first = min(TimeGenerated) by Task | where hosts <= 2 | order by first desc
powershell Current state rather than the change. Finds tasks created before you started collecting. 
Get-ScheduledTask | Where-Object { $_.Actions.Execute -notlike 'C:\Windows\*' -and $_.Actions.Execute -notlike 'C:\Program Files*' } | Select-Object TaskName, TaskPath, @{n='Runs';e={$_.Actions.Execute}}, @{n='User';e={$_.Principal.UserId}}
sigma Starting point. Exclude your own deployment tooling by name rather than broadening the terms. 
detection:
  selection:
    EventID: 4698
    TaskContent|contains:
      - '\\AppData\\'
      - '\\Temp\\'
      - 'powershell'
      - '-enc '
  condition: selection

Common questions

Why do attackers use scheduled tasks?

Because a task starts on its own, survives reboots, needs nobody signed in, and can run as SYSTEM. That combination makes it durable access with no running process to notice in the meantime. It is one of the most consistently used persistence techniques there is.

What should I look at first in Event 4698?

The Task Content field. It contains the full XML, so the command, the arguments, the trigger, and the account it runs under are all in the one event. A command running from a temp or user profile directory, or a shell with encoded arguments, tells you almost everything you need.

How do I list suspicious scheduled tasks on a machine?

`Get-ScheduledTask` in PowerShell, filtering out actions under C:\Windows and C:\Program Files. What remains is a short list, and anything running from a user profile or temp directory deserves a proper look. That catches tasks created before you started collecting Event 4698.

Do I need to enable auditing for Event 4698?

Yes — it needs the Audit Other Object Access Events subcategory, which is off by default. Turn it on with `auditpol /set /subcategory:"Other Object Access Events" /success:enable`. The volume is low and the detection value is high, so this is one of the easier auditing decisions.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026