ACSC Logo
© GEMXIT
GEMXIT Logo
Friday Cyber Briefing • Microsoft Defender XDR • Scheduled Tasks • Persistence

The Scheduled Task Was Created At 2:41AM

Persistence does not always arrive as ransomware.

It does not always arrive as a suspicious executable sitting on the desktop.

Sometimes it arrives as something Windows administrators use every day: a Scheduled Task.

At 2:41AM, a new task appeared. It looked ordinary. It used a legitimate Windows feature. It did not scream incident.

But every reboot gave the attacker another chance to come back.

Discuss Microsoft security Back to briefings
Agent Foskett Microsoft Defender XDR Scheduled Task persistence investigation
Scheduled Task Persistence

A PowerShell process ran. A payload was downloaded. Then a Scheduled Task was created. Individually, each event looked explainable. Together, they told the persistence story.

Investigate schtasks.exe
Review TaskCache registry evidence
Build the endpoint timeline

The clue at 2:41AM

The alert did not say persistence. The endpoint did not look obviously compromised. The clue was buried in normal-looking Windows administration activity.
02:38 — PowerShell executed A PowerShell command appeared shortly after normal user activity had ended. The command line needed context, not assumptions.
02:40 — External connection Network telemetry showed the device reaching out shortly after the script activity. That made the process more interesting.
02:41 — Scheduled Task created The task gave the attacker persistence. It was not noisy. It was not dramatic. It was just scheduled to run again.

Why attackers use Scheduled Tasks

Scheduled Tasks are useful for administrators, software installers and maintenance jobs. That is exactly why attackers like them.
They look legitimate Windows creates and runs scheduled tasks constantly. The presence of a task alone is not enough to prove compromise.
They survive reboots A task can run at startup, logon, idle time or on a timer. That makes it useful for persistence after the first compromise.
They can launch almost anything PowerShell, CMD, scripts, LOLBins and dropped binaries can all be launched by Scheduled Tasks if the task is configured that way.

Find schtasks.exe executions

Start with the obvious command-line utility. The command line often shows whether the task was created, deleted, queried or modified.
find-schtasks-execution.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "schtasks.exe"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName,
          InitiatingProcessCommandLine, FileName, ProcessCommandLine
| order by Timestamp desc

Hunt for suspicious task creation commands

Task creation becomes more interesting when the command contains PowerShell, CMD, encoded commands, temporary paths or user-writable locations.
suspicious-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
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName =~ "schtasks.exe"
| where ProcessCommandLine has_any ("/create", "/change", "/sc", "/tn", "/tr")
| where ProcessCommandLine has_any ("powershell", "cmd.exe", "wscript", "cscript", "mshta", "AppData", "Temp", "ProgramData")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Review Scheduled Task registry evidence

Scheduled Task evidence can also appear in the TaskCache registry path. This is useful when process telemetry alone does not explain the task.
scheduled-task-registry-evidence.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
DeviceRegistryEvents
| where Timestamp > ago(14d)
| where RegistryKey has @"Schedule\TaskCache"
| project Timestamp, DeviceName, ActionType, RegistryKey,
          RegistryValueName, RegistryValueData,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Build the persistence timeline

The strongest finding is not one event. It is the sequence: script execution, network activity, file creation, registry changes and scheduled task creation.
scheduled-task-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
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
let InvestigationDevice = "DEVICE-NAME-HERE";
let StartTime = ago(2d);
union isfuzzy=true
(
    DeviceProcessEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | where FileName in~ ("powershell.exe", "cmd.exe", "schtasks.exe")
    | project Timestamp, DeviceName, EvidenceType="Process", ActionType,
              Detail=ProcessCommandLine
),
(
    DeviceNetworkEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="Network", ActionType,
              Detail=strcat(RemoteUrl, " ", RemoteIP, ":", RemotePort)
),
(
    DeviceFileEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="File", ActionType,
              Detail=strcat(FolderPath, "\", FileName)
),
(
    DeviceRegistryEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | where RegistryKey has @"Schedule\TaskCache"
    | project Timestamp, DeviceName, EvidenceType="Registry", ActionType,
              Detail=strcat(RegistryKey, " ", RegistryValueData)
)
| order by Timestamp asc

Look for Defender scheduled task events

Some environments surface task-related activity in DeviceEvents. Availability can vary, but it is worth checking when investigating persistence.
deviceevents-scheduled-task-check.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
DeviceEvents
| where Timestamp > ago(14d)
| where ActionType has_any ("ScheduledTask", "Task")
| project Timestamp, DeviceName, ActionType, AdditionalFields,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

What made this task suspicious?

A Scheduled Task is not automatically malicious. The surrounding evidence determines whether it belongs to IT operations or an attacker.
The parent process was wrong Task creation following unusual PowerShell, script hosts or browser-spawned processes deserves closer review.
The timing was wrong A task created at 2:41AM by a user account that does not normally administer devices is a timeline clue.
The action was wrong Tasks launching encoded commands, remote downloads, scripts from Temp or binaries from user-writable paths need investigation.

Investigation pivots

Once the task is found, do not stop at the task name. Follow what created it, what it launched and what happened next.
Pivot to the creator Identify the account, parent process and initiating command line that created or modified the task.
Pivot to execution Find later process activity launched by the task. Persistence only matters if it successfully runs something.
Pivot to related evidence Correlate process, file, registry and network telemetry to understand the full compromise path.

Related Agent Foskett investigations

Scheduled Task persistence connects naturally to PowerShell, process trees, child processes, LOLBins and endpoint timeline reconstruction.
The Browser Spawned PowerShellFollow browser activity into script execution and suspicious command lines.
The Child Process Shouldn't Have ExistedInvestigate process relationships that reveal hidden attacker behaviour.
The Process Tree Told The Real StoryUse endpoint process relationships to reconstruct what really happened.
The PowerShell Command Was Base64 EncodedDecode suspicious PowerShell and understand what the attacker tried to hide.
The CertUtil Command Downloaded Something At 2:17AMInvestigate LOLBin activity and suspicious downloads from endpoint telemetry.
Microsoft Defender KQL Threat Hunting Complete GuideUse KQL across Defender XDR to hunt identity, endpoint, email and cloud activity.
Persistence rarely announces itself.
Build the timeline, follow the parent process and check what the task was designed to run.
Visit the Academy

Final thought

The Scheduled Task was not the whole attack. It was the mechanism that helped the attacker return. The logs already knew.
Persistence hides in normality Attackers often choose features that administrators already use because normal behaviour creates excellent cover.
The timeline told the story PowerShell, network activity, registry changes and Scheduled Task creation made sense only when viewed together.
The Logs Already Knew. The evidence is rarely missing. The challenge is recognising how every event fits together.
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 Was Created At 2:41AM

This Agent Foskett Friday Cyber Briefing explains how attackers use Windows Scheduled Tasks for persistence and how analysts can investigate scheduled task creation in Microsoft Defender XDR.

Microsoft Defender XDR Scheduled Task Investigation

Security analysts can use KQL across DeviceProcessEvents, DeviceRegistryEvents, DeviceEvents, DeviceFileEvents and DeviceNetworkEvents to investigate schtasks.exe, TaskCache registry activity, suspicious PowerShell and endpoint persistence timelines.

GEMXIT KQL Threat Hunting And Endpoint Persistence

GEMXIT helps organisations understand Microsoft Defender XDR, Microsoft Sentinel, Entra ID, endpoint telemetry, KQL threat hunting, Windows persistence, incident response and practical cyber security investigations.