ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Defender XDR • Scheduled Tasks • Persistence • KQL

The Scheduled Task Looked Legitimate — Until We Checked Who Created It

The task name looked normal.
The folder looked like Windows.
The task was configured to run as SYSTEM.

At first glance, there was nothing dramatic about it.

Then Agent Foskett asked one question that changed the case:

Who actually created the task?

Discuss Microsoft securityBack to investigations
Agent Foskett investigating who created a suspicious Windows scheduled task using Microsoft Defender XDR
Execution Identity Is Not Creator Identity

A scheduled task can be configured to run as SYSTEM while being created by a completely different user or process. If you only inspect who the task runs as, you can miss the account that put it there.

✓ Find the task creation event
✓ Identify the account and process that created it
✓ Correlate the creator with logon and remote-session evidence

Nothing about the task looked immediately malicious

The task appeared under a Windows-looking path and carried a name that could easily disappear into a long Task Scheduler list: MaintenanceCheck. It was configured to run as SYSTEM and launch a maintenance script from C:\ProgramData\UpdateCache\maintenance.ps1. The name was not proof. The path was not proof. Even SYSTEM was not proof.
Normal-looking nameAttackers do not have to call a task EvilPersistence. Blending in is usually more useful.
Privileged run contextRunning as SYSTEM tells you how the task executes, not necessarily who created it.
Plausible actionA PowerShell maintenance script can be legitimate administration or attacker persistence. Context decides.

The dangerous assumption was hidden in the word "SYSTEM"

An analyst looking only at the task configuration might record that the task ran as SYSTEM and move on. Agent Foskett separated two different identities: the account the task is configured to run as and the account that created or changed the task. Those are not the same question.
Investigation principle: execution identity is not creator identity. Follow the creation telemetry before deciding who was responsible for the task.

Start with scheduled-task activity in DeviceEvents

Microsoft Defender XDR DeviceEvents includes miscellaneous endpoint events and exposes initiating-process account, file and command-line fields. Use the in-portal schema reference to confirm the scheduled-task ActionType values available in your tenant, then pivot into the account and process responsible for the event.
01-review-scheduled-task-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType has "ScheduledTask"
    or InitiatingProcessCommandLine has_any
        ("schtasks", "Register-ScheduledTask", "New-ScheduledTask")
| project Timestamp, DeviceName, ActionType,
          InitiatingProcessAccountDomain,
          InitiatingProcessAccountName,
          InitiatingProcessAccountSid,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          AdditionalFields
| order by Timestamp desc
Do not overclaim: ActionType availability can vary with sensor telemetry and schema support. If a scheduled-task event is not present, hunt for the creation commands and surrounding process activity instead.

The creator was not SYSTEM

The task was configured to execute as SYSTEM. But the creation telemetry pointed somewhere else. A temporary support account called helpdesk-temp had launched schtasks.exe with a command that created the task and instructed it to run under SYSTEM.
01:11A remote logon for helpdesk-temp appears on WKSTN-214.
01:13PowerShell starts in the same account context.
01:14schtasks.exe creates MaintenanceCheck and configures it to run as SYSTEM.
01:20The task executes the maintenance script.
LaterThe task looks like SYSTEM activity unless the creation timeline is preserved.

Find the process that actually created it

DeviceProcessEvents provides process creation records together with account, parent-process, command-line and remote-session context. This is where the apparently ordinary task started to look very different.
02-find-task-creator-process.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "schtasks.exe"
    or ProcessCommandLine has_any
        ("Register-ScheduledTask", "New-ScheduledTask")
| project Timestamp, DeviceName,
          AccountDomain, AccountName, AccountSid,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountName,
          InitiatingProcessRemoteSessionDeviceName,
          InitiatingProcessRemoteSessionIP
| order by Timestamp desc
What matters: the query is not trying to declare every use of schtasks.exe or Register-ScheduledTask malicious. Administrators and software legitimately use them. The goal is to establish who used them, from which process chain, at what time, and whether that behaviour fits the environment.

The command line supplied the missing context

The relevant process showed a command similar to:
schtasks.exe /create /tn "MaintenanceCheck" /tr "powershell.exe -NoProfile -File C:\ProgramData\UpdateCache\maintenance.ps1" /sc onlogon /ru SYSTEM /f
The /ru SYSTEM argument explained why the task later appeared to run as SYSTEM. It did not explain who created it. The account columns on the process event did.

Then check how the creator account reached the device

Once the creator account is known, pivot into DeviceLogonEvents. A scheduled-task creation performed by a normal administrator during an approved maintenance window is one story. The same command following an unexpected remote logon is another.
03-review-creator-logons.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let Creator = "helpdesk-temp";
let TargetDevice = "WKSTN-214";
DeviceLogonEvents
| where Timestamp > ago(30d)
| where DeviceName =~ TargetDevice
| where AccountName =~ Creator
| project Timestamp, DeviceName, ActionType,
          LogonType, AccountDomain, AccountName,
          RemoteDeviceName, RemoteIP,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc
Important: an unexpected remote IP or temporary support account still does not prove compromise. Validate the address, support tooling, change ticket, administrator activity and normal working pattern before assigning intent.

The task name was camouflage, not evidence

Task nameMaintenanceCheck sounded harmless. Names are attacker-controlled metadata.
Run accountSYSTEM explained the later execution context, not the creator.
Creation accounthelpdesk-temp was the pivot that connected the task to the suspicious access timeline.

What the evidence can and cannot prove

SupportedThe account and process shown in Defender telemetry created or changed the scheduled task at the recorded time.
Needs correlationWhether the account was being used by its legitimate owner, an approved tool or an attacker.
Do not assumeA Windows-looking task name, SYSTEM execution or use of schtasks.exe is not malicious by itself.

The investigation question changed

The first question was, “What does this scheduled task run?” That was useful, but incomplete. The better investigation asked: Who created it? What process created it? How did that account reach the device? And what happened immediately before and after?
Agent Foskett rule: do not stop at the object. Investigate the actor and the process that produced it.

Related investigations

Continue following persistence and endpoint evidence.
The Scheduled Task Was Created At 2:41AMFollow the timing of a new scheduled task that quietly restored attacker persistence.The Scheduled Task Was The PersistenceInvestigate recurring malicious execution that survives cleanup and returns through Task Scheduler.The Defender Exclusion Was Added 12 Minutes Before the Malware RanInvestigate the control change that happened before the endpoint threat appeared.
The task can lie about what it looks like.
The creation timeline is harder to argue with.
Continue the Investigation

Final thought

The scheduled task looked legitimate because almost everything visible in Task Scheduler was designed to look legitimate. The name blended in. The run account was SYSTEM. The action looked like maintenance. But the Defender timeline preserved the account and process that created it. Once Agent Foskett followed the creator instead of the label, the task stopped looking ordinary. The Logs Already Knew! 🔎
Looks legitimate?Names and folders are clues, not verdicts.
Runs as SYSTEM?Ask who configured it to run that way.
Need attribution?Correlate creator account, process chain and logon evidence.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Scheduled Task Looked Legitimate — Until We Checked Who Created It

This Agent Foskett investigation examines Windows scheduled task creation using Microsoft Defender XDR, DeviceEvents, DeviceProcessEvents and DeviceLogonEvents to identify the account and process that created a task.

Scheduled Task Creator Investigation With Microsoft Defender XDR And KQL

Learn how to separate the account a scheduled task runs as from the user or process that created it, then correlate task creation, process ancestry, command lines and remote logon evidence.

Investigating Scheduled Task Persistence

A legitimate-looking task name or SYSTEM run context does not prove legitimacy. Build the timeline, identify the creator and validate the account activity before deciding whether the task is administrative or malicious.