ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Endpoint Security • Persistence • Microsoft Defender XDR

The Scheduled Task Was The Persistence

The malware was gone.

The file had been deleted. The suspicious PowerShell window had closed. Nothing new appeared in the alerts queue, and the endpoint looked quiet again.

Then the same command ran the next morning at 8:00AM.

Agent Foskett was not looking for the original script anymore. He was looking for the thing that kept bringing it back.

Discuss endpoint security Back to briefings
Agent Foskett Microsoft Defender XDR scheduled task persistence investigation
Briefing summary

Persistence is how an attacker survives cleanup, reboot and user logoff. A scheduled task can relaunch a script, binary or command long after the original activity has disappeared from view.

Suspicious Task Created
PowerShell Relaunched
Persistence Confirmed
Timeline Rebuilt

The scheduled task was not noise

Scheduled tasks are useful for administration. That is exactly why attackers like them.
It survived cleanup Deleting the obvious file did not remove the mechanism that relaunched the activity later.
It looked administrative Task Scheduler is a normal Windows feature, which can make malicious tasks blend into real operations.
It controlled the return The important question was not only what ran, but what made it run again.

What Defender XDR can show

A persistence investigation usually crosses process, device, file and registry evidence.
DeviceEvents Review scheduled task creation, updates and suspicious task-related activity.
DeviceProcessEvents Follow schtasks.exe, PowerShell, cmd.exe and any process launched by the task.
DeviceFileEvents and DeviceRegistryEvents Correlate task creation with script writes, payload drops and registry persistence.

Find scheduled task creation

Start with task creation and update events, then pivot into the command line and account context.
find-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
  14. 14
  15. 15
  16. 16
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType has_any ("ScheduledTaskCreated", "ScheduledTaskUpdated")
    or InitiatingProcessCommandLine has_any ("schtasks", "Schedule.Service")
| project
    Timestamp,
    DeviceName,
    ActionType,
    InitiatingProcessAccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    AdditionalFields
| order by Timestamp desc

The command line told the story

The task name may look harmless. The action behind it is what matters.
Hidden PowerShell Tasks that launch PowerShell with hidden windows, encoded commands or download functions deserve immediate review.
User profile paths Commands pointing into AppData, Temp, ProgramData or Startup paths may indicate attacker-controlled content.
Odd schedules A task created shortly after suspicious execution, then scheduled at logon or daily, is a persistence clue.

Review suspicious scheduled task command lines

Look for task creation commands that reference script interpreters, user-writable paths or download behaviour.
review-suspicious-task-command-lines.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
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("schtasks.exe", "powershell.exe", "pwsh.exe", "cmd.exe")
| where ProcessCommandLine has_any (
    "schtasks",
    "powershell",
    "pwsh",
    "-enc",
    "-EncodedCommand",
    "DownloadString",
    "Invoke-WebRequest",
    "AppData",
    "Temp",
    "ProgramData"
)
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    FileName,
    ProcessCommandLine
| order by Timestamp desc

Persistence often follows execution

The task is rarely the first event. It is usually created after an initial script, download or process chain.
Initial access A browser, email client or user action may start the first process in the chain.
Payload staging The attacker may write a script or binary into a user-writable folder before creating the task.
Scheduled return The task gives the attacker a reliable way to relaunch after reboot, logon or cleanup.

Look for files written before the task

Identify scripts, binaries and shortcuts created shortly before scheduled task persistence appears.
look-for-files-written-before-task.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
  18. 18
DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType in~ ("FileCreated", "FileModified", "FileRenamed")
| where FolderPath has_any ("\AppData\", "\Temp\", "\ProgramData\", "\Startup\")
| where FileName has_any (".ps1", ".vbs", ".js", ".bat", ".cmd", ".exe", ".dll", ".lnk")
| project
    Timestamp,
    DeviceName,
    ActionType,
    FolderPath,
    FileName,
    SHA256,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

Check what the task launched

A scheduled task can be the parent of the next suspicious process. Follow what ran after the task triggered.
check-task-launched-processes.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 InitiatingProcessFileName in~ ("taskeng.exe", "taskhostw.exe", "svchost.exe", "schtasks.exe")
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe")
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine
| order by Timestamp desc

What investigators should ask

A scheduled task investigation should explain creation, purpose, trigger and impact.
Who created it? Review the account, parent process and command line that created or modified the task.
What does it launch? Extract the action from the task and inspect the script, binary, arguments and destination path.
When does it run? Daily, logon, startup and repeated triggers can reveal how the attacker planned to remain present.

Build the persistence timeline

Join task, process, file and registry activity into one endpoint timeline.
build-the-persistence-timeline.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
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
let InvestigationDevice = "DEVICE-NAME-HERE";
let StartTime = ago(1d);
union isfuzzy=true
(
    DeviceEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="DeviceEvent", ActionType, Detail=tostring(AdditionalFields), InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceProcessEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="Process", ActionType, Detail=ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceFileEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="File", ActionType, Detail=FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceRegistryEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="Registry", ActionType, Detail=strcat(RegistryKey, " ", RegistryValueName, " ", RegistryValueData), InitiatingProcessFileName, InitiatingProcessCommandLine
)
| order by Timestamp asc

The task made the compromise durable

Persistence turns a one-time execution into a recurring problem.
No alert does not mean no persistence A scheduled task can sit quietly until the next trigger occurs.
Cleanup must include autoruns Removing the visible payload is not enough if the relaunch mechanism remains.
The timeline proves intent Task creation after suspicious execution shows the attacker planned to come back.

Related investigations

Continue the investigation through AppData execution, process trees, PowerShell, LOLBins and timeline reconstruction.
The Script Ran From AppDataInvestigate suspicious scripts executing from user-writable AppData locations.
The Child Process Shouldn't Have ExistedFollow unexpected parent-child process relationships after initial execution.
The Timeline Told The StoryUse timeline reconstruction to explain the order of Defender XDR evidence.
The PowerShell Command Was Base64 EncodedDecode suspicious PowerShell activity and understand attacker obfuscation.
The Process Tree Told The Real StoryUse process lineage to separate normal activity from attacker behaviour.
The Device Was Talking To Something It Shouldn'tPivot from endpoint execution into suspicious outbound connections.
Need help investigating endpoint persistence?
GEMXIT helps organisations understand Microsoft Defender XDR evidence, endpoint telemetry, KQL hunting and practical incident response.
Contact GEMXIT

Final thought

The scheduled task was not the loudest event. It was the event that explained why the attack came back.
At GEMXIT We help organisations investigate Microsoft Defender XDR, endpoint security, persistence, process execution and practical threat hunting. If you want to understand how this applies to your environment, see our Microsoft Security services.
Agent Foskett mindset Do not stop when the first suspicious file is removed. Find what launches it, what keeps it alive and what brings it back.
Develop IT. Protect IT. The task looked small. The persistence story was not. GEMXIT PTY LTD | GEMXIT UK LTD

The Scheduled Task Was The Persistence

This Agent Foskett investigation explains how scheduled task persistence can relaunch suspicious PowerShell, scripts or binaries after cleanup, reboot or user logon.

Microsoft Defender XDR Scheduled Task Investigation

DeviceEvents, DeviceProcessEvents, DeviceFileEvents and DeviceRegistryEvents can help defenders reconstruct scheduled task creation, task-triggered process execution, suspicious file writes and endpoint persistence.

KQL Hunting For Scheduled Task Persistence

Defenders can use KQL to hunt for schtasks.exe, Schedule.Service, PowerShell persistence, AppData payloads, taskhostw.exe, taskeng.exe and attacker behaviour in Microsoft Defender XDR.

ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026