Windows records scheduled task activity in two separate event logs.
The Security log holds event IDs 4698-4702, covering task creation, deletion, turning on, turning off, and updates, with the full task definition XML attached.
The Microsoft-Windows-TaskScheduler/Operational log holds event IDs 106, 140, and 141 for registration changes, plus 100, 200, and 201 for execution.
Windows doesn’t switch on either source by default: Microsoft’s own Tarrask analysis states that "neither of these are audited by default and must be explicitly turned on by an administrator."
In this post, you’ll learn which event IDs matter, how to turn them on, how to collect them with NXLog Agent, and which patterns separate routine automation from task abuse.
Why scheduled tasks deserve dedicated auditing
Task Scheduler gives attackers the same things it gives administrators: reliable code execution, persistence across reboots, and a crowd of legitimate tasks to hide among. MITRE ATT&CK tracks the abuse as Scheduled Task (T1053.005) under the Execution, Persistence, and Privilege Escalation tactics, and notes that remote task creation also serves lateral movement, because a task can run as SYSTEM on a machine the attacker just reached.
A real campaign shows how this plays out.
In April 2022, Microsoft’s Detection and Response Team documented Tarrask, a HAFNIUM tool that created a scheduled task named WinUpdate to re-establish dropped command-and-control connections, then hid the task from schtasks /query and the Task Scheduler console by deleting a single registry value.
That evasion trick shapes what your logging has to catch, and we return to it below.
Which event IDs record scheduled task activity?
Two channels record task activity, and each answers a question the other can’t. Turn on both.
Security log: event IDs 4698-4702
When you turn on the Audit Other Object Access Events subcategory, the Security log records five task lifecycle events:
| Event ID | Meaning |
|---|---|
A scheduled task was created |
|
A scheduled task was deleted |
|
A scheduled task was enabled |
|
A scheduled task was disabled |
|
A scheduled task was updated |
Event 4698 is the anchor of task auditing because of its TaskContent field, which holds the complete task definition as XML: the command it runs, its arguments, triggers, and the account and run level it executes under.
Microsoft’s monitoring guidance for 4698 recommends watching all task creation events and paying particular attention to tasks registered directly in the library root (a TaskName like \Updater), because manually created and malicious tasks often land there.
Event 4702 adds a TaskContentNew field, so you can diff a modified task against its previous definition.
On Windows 10 version 1903 and later, 4698 also carries ClientProcessId, ParentProcessId, RpcCallClientLocality, and FQDN.
Those four turn a bare "a task was created" record into something you can attribute: which process created the task, and whether the request arrived locally or over RPC.
Task Scheduler Operational log: registration and execution events
The Microsoft-Windows-TaskScheduler/Operational channel records both management and run-time activity.
The management events:
| Event ID | Task category |
|---|---|
Task registered |
|
Task registration updated |
|
Task registration deleted |
|
Task disabled |
And the execution events that tell you whether a task ran:
| Event ID | Task category |
|---|---|
Task started / Task start failed |
|
Task completed / Task terminated |
|
Created task process |
|
Action started / Action completed |
|
Action failed / Action failed to start |
Microsoft’s archived Task Monitoring and Control reference lists the full set. Keep one limitation in mind: event 106 records the task name and the registering user, but not the task definition. Only 4698 carries the XML.
Which channel do you need?
Both, because they answer different questions. Event 4698 tells you what a task does and who created it. The Operational events tell you whether it ran, when, and what process it spawned. A dormant persistence task and one firing on every boot look identical in the Security log, and events 200, 201, and 129 are what make the difference visible. If you can only turn on one today, start with Security auditing for the task XML, then add the Operational channel.
How to turn on scheduled task auditing
Neither channel produces events until you switch it on.
Security log (4698-4702)
Turn on the audit subcategory locally:
> auditpol /set /subcategory:"Other Object Access Events" /success:enable /failure:enableFor fleet-wide rollout, configure it through Group Policy under Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access > Audit Other Object Access Events. Verify the current state with:
> auditpol /get /subcategory:"Other Object Access Events"The subcategory also covers COM+ catalog changes and indirect object access, and Microsoft rates its event volume as low, so turning it on fleet-wide is a small price for the task XML you get back.
Operational channel
Turn it on from an elevated prompt:
> wevtutil sl Microsoft-Windows-TaskScheduler/Operational /e:trueThis is the command-line equivalent of clicking Enable All Tasks History in the Task Scheduler console, as shown in our Task Scheduler integration guide. Confirm the channel state and check its maximum size with:
> wevtutil gl Microsoft-Windows-TaskScheduler/OperationalNote that Microsoft-Windows-TaskScheduler/Maintenance exists by default, but it carries only maintenance information about the Task Scheduler engine, not the task activity you want.
Execution events accumulate fast on busy servers, so review the channel’s size and retention before you rely on it for forensics. Better still, ship the events off the host as they arrive.
Collecting the events with NXLog Agent
NXLog Agent reads both channels through the Event Log for Windows input module. The configuration below extends the single-channel example in our Task Scheduler integration guide: it subscribes to the Security task events and the Operational management and execution events in one input, then converts each record to JSON with the JSON extension.
<Extension json>
Module xm_json
</Extension>
<Input task_audit>
Module im_msvistalog
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Security">
*[System[(EventID=4698 or EventID=4699 or EventID=4700
or EventID=4701 or EventID=4702)]]
</Select>
<Select Path="Microsoft-Windows-TaskScheduler/Operational">
*[System[(EventID=106 or EventID=129 or EventID=140
or EventID=141 or EventID=142 or EventID=200 or EventID=201)]]
</Select>
</Query>
</QueryList>
</QueryXML>
Exec to_json();
</Input>The Event Log for Windows input module parses the EventData section into named fields, so a 4698 record arrives ready for filtering, with no separate XML parsing step:
{
"EventTime": "2026-08-20T09:14:02.113220+02:00",
"Hostname": "WS-042.example.com",
"Channel": "Security",
"EventID": 4698,
"SubjectUserName": "jdoe",
"TaskName": "\\Updater",
"TaskContent": "<?xml version=\"1.0\"?><Task ...><Exec><Command>powershell.exe</Command><Arguments>-EncodedCommand JABjAGwA...</Arguments></Exec></Task>"
}From here, route the input to whichever NXLog Agent output module your SIEM speaks. Or manage the whole pipeline from NXLog Platform: push this configuration to every Windows agent in your fleet, monitor agent health, and route events wherever your detection logic lives. See the NXLog Platform documentation for setup instructions.
Filtering at the agent keeps the noisiest execution events from ever reaching your SIEM. For example, drop action start/complete events for Microsoft’s own task folders while keeping every management event:
<Exec>
if ($EventID == 200 or $EventID == 201) and $TaskName =~ /^\\Microsoft\\/
drop();
</Exec>What task abuse looks like in the logs
These events only become useful once you know which patterns to look for. The five patterns below account for most real-world task abuse.
1. Suspicious task creation
Inspect the TaskContent field of every 4698 event.
Red flags include encoded PowerShell (-EncodedCommand), proxy-execution binaries (mshta, rundll32, regsvr32), executables under \Temp\ or \AppData\, a SYSTEM principal with a HighestAvailable run level, and tasks registered in the library root, the location Microsoft’s 4698 guidance singles out.
Microsoft calls out one more pattern that deserves its own rule: a task whose XML contains <LogonType>Password</LogonType>.
That setting stores the account’s password in Credential Manager in cleartext, where anyone with administrative privileges can extract it.
Alert on it whether or not the task looks malicious, because the credential exposure is the problem.
You can tag candidates as they pass through the agent:
<Exec>
if $EventID == 4698 and
$TaskContent =~ /(-enc|mshta|rundll32|regsvr32|\\AppData\\|\\Temp\\)/i
$TaskSuspect = TRUE;
if $EventID == 4698 and $TaskContent =~ /<LogonType>Password<\/LogonType>/
$TaskStoresPassword = TRUE;
</Exec>Treat the first rule as a hunting filter, not a verdict. Plenty of software installers do odd things.
2. Create, run, delete
An attacker who wants execution rather than persistence registers a task, triggers it, and removes it minutes later.
That sequence shows up in the logs as creation (4698 or 106), then execution (200/201), then deletion (4699 or 141), all sharing the same TaskName within a short time frame.
The deletion is the tell, because legitimate software rarely cleans up that fast.
Correlate on TaskName in your SIEM and alert when the full lifecycle fits inside a short time frame.
3. Tampering with an existing task
Instead of creating a new task, an attacker can repoint a trusted one.
Watch for an update event (4702 or 140), then diff the TaskContentNew XML against your baseline: a changed <Command> or new <Arguments> inside a task that has existed for months deserves a look.
4. Hidden tasks: the Tarrask technique
Registering a task writes keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\, one under Tree\<TaskName> and one under Tasks\{GUID}.
Microsoft’s Tarrask analysis showed that deleting the SD (security descriptor) value under TaskCache\Tree\<TaskName> makes the task disappear from schtasks /query and the Task Scheduler console while it keeps running on its triggers.
The deletion has to happen as SYSTEM, which Tarrask achieved by stealing a token from the lsass.exe process.
Event logs record the task’s creation (if auditing was on at the time) but not the hiding step.
To close that gap, audit the registry itself: Sysmon registry events (ID 12 for object create/delete, ID 13 for value set) on the TaskCache path, collected through our Sysmon integration, or Security event 4657 with a SACL on the key.
Watch writes to SD, not only deletions.
Microsoft’s own remediation guidance is to enumerate the TaskCache\Tree key and "identify any scheduled tasks without SD value."
Binary Defense’s ARC Labs (2024) then demonstrated that assigning a valid SDDL value that denies read access hides a task just as effectively, while leaving an SD value in place.
A detection that only looks for a missing SD walks straight past it.
5. Remote task creation
Auditing is host-local: a task created remotely over RPC or with schtasks /s <target> generates its 4698 event on the target machine, and MITRE notes that attackers use remote scheduling for lateral movement, often to run code as SYSTEM.
On Windows 10 version 1903 and later, the event answers the question itself.
The RpcCallClientLocality field distinguishes a local registration from a remote one, so you can alert on remote task creation directly instead of inferring it.
Pair it with ParentProcessId to see which process made the call.
Where that field is unavailable, fall back to correlation: match the 4698 event against a 4624 event network logon (logon type 3) from the same account moments earlier. Either way, collect from every endpoint, not just servers and domain controllers.
Keep the signal, drop the noise
Every Windows host runs dozens of legitimate scheduled tasks, and execution events multiply the volume. Three habits keep the pipeline useful. Baseline the tasks that belong on each system role, then alert on deltas rather than raw counts. Filter routine Microsoft-folder execution events at the agent, as shown above, so only management events and non-baseline executions reach the SIEM. And keep the management events (4698-4702, 106, 140-142) unfiltered: they are low-volume and carry the forensic weight.
Two channels, one pipeline
Scheduled task auditing comes down to three moves: turn on both event sources, because Windows ships with both off; collect event ID 4698 for content and the Operational events for execution; and hunt the five patterns above, with registry telemetry covering what the event logs can’t see. NXLog Agent handles the collection with one configuration block, and NXLog Platform rolls it out to every Windows host you own. Want to test it against your own event volume? Start free with NXLog Platform.
FAQ
- Which event ID shows that a scheduled task was created?
-
Event ID 4698 in the Security log, which includes the full task definition XML, and event ID 106 in the
Microsoft-Windows-TaskScheduler/Operationallog, which records the task name and the registering account. Both require you to turn on auditing first. - Is event ID 4698 turned on by default?
-
No. It only appears when you turn on the Audit Other Object Access Events subcategory under Advanced Audit Policy Configuration. Check your current state with
auditpol /get /subcategory:"Other Object Access Events". - What is the difference between event 106 and event 4698?
-
Both fire when a task is registered. Event 106 gives you the task name and the user; event 4698 adds the complete task XML (action, arguments, triggers, and the principal it runs as), which makes it far more useful for detection.
- Why does a task keep running but not appear in schtasks /query?
-
An attacker likely removed or rewrote its security descriptor in the registry. That is the hiding technique Microsoft documented in the Tarrask report. Inspect
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\for task keys with a missing or unusual SD value. - How do I collect Task Scheduler event logs centrally?
-
NXLog Agent collects both channels with the Event Log for Windows input module and forwards them in the format your SIEM expects. NXLog Platform manages the agent configuration across your Windows fleet from one place.
