Detecting Scheduled Task Persistence: Event 4698 and Task Scheduler Logs

Scheduled tasks are a favourite persistence and privilege-escalation mechanism: they survive reboots, can run as SYSTEM, and can fire on a timer, at logon or on an event. Windows logs creation in two places, Security Event 4698 (which carries the full task XML) and the Task Scheduler Operational log. The gap most teams have is not detection logic but auditing: neither source is fully on by default.

Signals at a Glance

Event 4698 and the Task XML

Enable Audit Other Object Access Events so that Event 4698 is written, and enable the Task Scheduler Operational log, which is disabled by default. The 4698 event carries the whole task definition in the TaskContent field, so you can inspect the action, the principal and the trigger without ever touching the host. This Splunk search extracts the command and flags the usual suspects:

index=wineventlog source="WinEventLog:Security" EventCode=4698
| rex field=TaskContent "(?s)<Command>(?<task_cmd>[^<]+)</Command>(\s*<Arguments>(?<task_args>[^<]*)</Arguments>)?"
| eval act=lower(task_cmd . " " . coalesce(task_args, ""))
| where match(act, "(powershell|cmd\.exe|mshta|wscript|cscript|rundll32|regsvr32|certutil|bitsadmin)")
    OR match(act, "(\\\\appdata\\\\|\\\\temp\\\\|\\\\programdata\\\\|\\\\users\\\\public\\\\)")
| table _time host SubjectUserName TaskName task_cmd task_args
| sort - _time
`comment("tune/validate: field names such as TaskContent vary by TA version; baseline vendor updater tasks first")`

Most of the real signal is in who created the task and what it launches. A task created by a service account from a workstation, or one that runs a user-profile binary as SYSTEM, deserves immediate triage.

Hidden Tasks and Fleet Sweeps

Some actors make a task invisible to schtasks /query and the Task Scheduler UI by deleting the Security Descriptor (SD) value under the task’s TaskCache\Tree key. The task still runs, but standard enumeration misses it. Sweep for task entries that have an Id but no SD, and list task actions that point outside the usual install paths:

# PowerShell fleet-hunt: tasks missing an SD value, and tasks with unusual action paths
$tree = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree'
Get-ChildItem $tree -Recurse -ErrorAction SilentlyContinue |
  Where-Object { $_.GetValueNames() -contains 'Id' -and $_.GetValueNames() -notcontains 'SD' } |
  Select-Object Name

Get-ScheduledTask | ForEach-Object {
  foreach ($a in $_.Actions) {
    if ($a.Execute -and $a.Execute -notmatch '^(C:\\Windows\\|C:\\Program Files)') {
      [pscustomobject]@{ Task = $_.TaskPath + $_.TaskName; User = $_.Principal.UserId
                         Execute = $a.Execute; Args = $a.Arguments }
    }
  }
}
# tune/validate: run against a clean reference host first and exclude known vendor tasks.

• Alert on registry deletions of the SD value under TaskCache\Tree using Sysmon Event ID 12 or 13; legitimate software essentially never does this.
• Correlate 4698 with a preceding network logon (4624 type 3) from another host to catch remotely created tasks.
• Watch Task Scheduler Operational events 200 and 129 (action started, process created) for tasks that launch unsigned binaries.
• Include tasks that run once and delete themselves: a 4698 followed within minutes by a 4699 is a common execution pattern, not only persistence.