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

The Scheduled Task Looked Legitimate — Until We Checked What It Launched

The scheduled task had an ordinary name.

It ran at a predictable time.
It did not contain the word malware.
Nothing about the task name alone demanded an incident.

Then Agent Foskett stopped looking at the name and followed the execution chain.

The task launched a trusted Windows utility. That utility launched PowerShell. PowerShell reached into a user-writable directory.

The scheduled task was not the conclusion.

It was the beginning of the timeline.

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating a suspicious scheduled task and process chain in Microsoft Defender XDR
Don't Trust The Task Name

Scheduled tasks are normal Windows functionality. The investigation changes when the task's execution chain, creator, target or timing no longer fits the environment.

✓ Identify the task execution
✓ Follow the child processes
✓ Reconstruct persistence context

The task name looked harmless

The first clue was not a dramatic malware alert. It was a scheduled execution that deserved context.

The task name looked like something an administrator or application could plausibly create. That made it tempting to dismiss.

But names are labels. They are not evidence.

Agent Foskett asked three questions instead:

Who created it? What did it launch? What happened next?
NameA legitimate-looking name can still be attached to suspicious behaviour.
ExecutionThe process launched by the task matters more than the label.
ContextCreation time, account, parent process and follow-on activity determine whether it belongs.

Find scheduled-task creation activity

Microsoft Defender XDR telemetry can expose processes commonly used to create or modify scheduled tasks. Agent Foskett started by hunting for schtasks.exe activity and inspecting the command line rather than assuming every use of the utility was malicious.
scheduled-task-creation.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
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName =~ "schtasks.exe"
| project Timestamp,
          DeviceName,
          AccountName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountName
| order by Timestamp desc

The command line changed the investigation

The task creation command revealed what the friendly task name did not. Its action pointed to a trusted Windows component, but that component was only the first step.

Agent Foskett extracted the device, account, task timing and executable path, then pivoted into the endpoint process timeline around the scheduled execution.
Investigation principle: A trusted executable can still participate in an untrusted execution chain.

Follow what the task launched

DeviceProcessEvents allowed Agent Foskett to reconstruct the process relationship. The important evidence was not simply that PowerShell existed on the device. It was the relationship between the scheduled execution, the parent process and the command that followed.
scheduled-execution-chain.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 Device = "WS-024";
let StartTime = datetime(2026-09-28 02:00:00);
DeviceProcessEvents
| where DeviceName =~ Device
| where Timestamp between (StartTime - 5m .. StartTime + 15m)
| project Timestamp,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          SHA256
| order by Timestamp asc

PowerShell was not suspicious by itself

PowerShell is legitimate administration technology. Seeing powershell.exe in telemetry is not enough to call an incident malicious.

What changed the context was how it was launched and what its command line referenced: a script stored under a user-writable path that did not match the expected application or administrative workflow.

Agent Foskett therefore pivoted from the process into the file evidence.
script-file-evidence.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
  17. 17
let Device = "WS-024";
DeviceFileEvents
| where Timestamp > ago(14d)
| where DeviceName =~ Device
| where FolderPath has @"\AppData\"
| where FileName endswith ".ps1"
| project Timestamp,
          DeviceName,
          ActionType,
          FileName,
          FolderPath,
          SHA256,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

When did the persistence appear?

Timing matters. If the task was created shortly after an unusual download, script write or suspicious process execution, those events may form one chain rather than unrelated telemetry.

Agent Foskett widened the window around the task creation and looked for registry activity that could provide additional persistence or configuration context.
persistence-context.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 Device = "WS-024";
DeviceRegistryEvents
| where Timestamp > ago(14d)
| where DeviceName =~ Device
| project Timestamp,
          ActionType,
          RegistryKey,
          RegistryValueName,
          RegistryValueData,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

The timeline told the story

Individually, the events could look ordinary: a file write, a Windows utility, PowerShell, a scheduled task.

Placed in chronological order, they became much harder to dismiss.

A script appeared in a user-writable directory. A process created a scheduled task. At the configured time, the task launched a trusted component. That execution led to PowerShell and the script.

The behaviour was in the relationships between the events.
01:51 — Script writtenA PowerShell script appears under the user's profile.
01:54 — Task createdA legitimate-looking scheduled task is configured.
02:00 — Task runsThe execution chain reaches PowerShell and the user-writable script.

What Agent Foskett checked

CreatorWhich account and initiating process created or modified the task?
ActionWhat executable, script or command did the task actually launch?
Parent-child chainWhat processes appeared immediately after the scheduled execution?
File evidenceWhere did referenced scripts or payloads come from?
TimingDid task creation follow another suspicious event?
Persistence contextWere there other registry, file or process changes supporting persistence?

What the evidence can and cannot prove

Scheduled tasks are everywhere in Windows environments. Operating-system components, software updaters, management agents and administrators create them legitimately.

Likewise, schtasks.exe, PowerShell and user-profile paths are not automatically malicious.

The investigation becomes meaningful when multiple facts align: an unexpected creator, suspicious command line, unusual target, user-writable script, abnormal timing or follow-on behaviour.

Context turns ordinary telemetry into evidence.

The lesson

The task looked legitimate because its name looked legitimate.

Agent Foskett ignored the label and followed what it actually did.

That changed the investigation from a harmless-looking scheduled task into a persistence chain that required explanation.

A scheduled task is not suspicious because it exists. What matters is what created it, what it launches and what happens next.
Investigation principle: Don't investigate the name of the persistence mechanism. Investigate its behaviour.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.The Script Ran From AppDataInvestigate suspicious script execution from user-writable locations with Microsoft Defender XDR.SOC Analyst AcademyBuild practical investigation and triage skills across endpoint, identity, email and cloud security.
The task name looked normal. The execution chain didn't.
Follow what created it. Follow what it launched. Follow what happened next.
Continue the Investigation

Final thought

Attackers do not need to invent new Windows features when legitimate ones already provide reliable execution and persistence.

That is why an analyst cannot judge a scheduled task by its name alone.

Reconstruct the creation. Inspect the action. Follow the process tree. Correlate the file and registry evidence.

Follow the evidence. Build the timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
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 What It Launched

This Agent Foskett investigation examines a legitimate-looking Windows scheduled task by tracing its creator, command, execution chain and persistence context in Microsoft Defender XDR.

Investigating Scheduled Tasks With Microsoft Defender XDR and KQL

Use DeviceProcessEvents, DeviceFileEvents and DeviceRegistryEvents to investigate schtasks.exe activity, PowerShell execution, user-writable scripts and related endpoint evidence.

Scheduled Task Persistence Investigation

A scheduled task is not malicious simply because it exists. Analysts should determine who created it, what it launches, when it runs and what activity follows before reaching a verdict.