How to Hunt for Hidden Scheduled Tasks on Windows Servers

Scheduled tasks are one of the most common ways attackers keep access to Windows systems, and most SOCs already alert on new ones. A nation state technique first described by Microsoft in 2022 goes a step further: it deletes a single registry value so the task vanishes from Task Scheduler and schtasks /query while it keeps running. This guide is for threat hunters in government and the wider public sector who need to find these hidden tasks on servers that rarely reboot, without breaking change control.

Understand how a task is hidden

When Windows registers a scheduled task, it writes the task in three places. Knowing all three is what makes this hunt possible, because the attacker usually only removes one piece.

The SD value is the task's security descriptor, which controls who can see and run it. Microsoft reported that the Tarrask malware, used by the actor then tracked as HAFNIUM and now named Silk Typhoon, created a task called WinUpdate and then deleted its SD value. With SD gone, the task disappeared from Task Scheduler and schtasks /query but still ran on its triggers.

Deleting SD fails with Access Denied even from an elevated prompt. It must run as SYSTEM, which in that case the malware achieved by stealing a token from lsass.exe. MITRE ATT&CK records this under T1053.005 and links it to T1564 Hide Artifacts, and also notes that attackers may hide tasks by altering other metadata such as the Index value.

Check your telemetry before you hunt

A hunt with blind spots produces false confidence. Before you query anything, confirm which of these sources you actually collect for your target servers, and record the gaps in your hunt plan.

Source	What it gives you	Default state
Defender for Endpoint DeviceRegistryEvents	Registry value deletes and changes, with the initiating process and account	On when onboarded
Sysmon Event ID 12 and 13	Registry object create and delete (12) and value set (13)	Depends on your Sysmon config including TaskCache paths
Security Event ID 4657	Registry value modified or deleted	Only with object access auditing and a SACL on the key
Security Event ID 4698 to 4702	Task created, deleted, enabled, disabled and updated	Needs Audit Other Object Access Events
TaskScheduler Operational log	106 registered, 140 updated, 141 deleted, 200 action started, 201 action completed	Often disabled, must be enabled

Hunt for SD value deletion

The strongest single signal is a delete of a value named SD under the TaskCache Tree key. Legitimate software almost never does this, so even one hit deserves investigation.

Defender for Endpoint

DeviceRegistryEvents
| where Timestamp > ago(30d)
| where ActionType == "RegistryValueDeleted"
| where RegistryKey has @"\Schedule\TaskCache\Tree\"
| where RegistryValueName == "SD"
| extend TaskName = tostring(split(RegistryKey, @"\TaskCache\Tree\")[1])
| project Timestamp, DeviceName, TaskName, RegistryKey,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          InitiatingProcessAccountName, InitiatingProcessAccountSid
| order by Timestamp desc

Splunk with Sysmon

index=sysmon EventCode=12 EventType=DeleteValue
TargetObject="*\\Schedule\\TaskCache\\Tree\\*\\SD"
| table _time host Image User TargetObject
| sort - _time

Sigma rule for wider coverage

title: Scheduled Task Hidden by SD Value Deletion
status: experimental
description: Detects deletion of the SD value of a scheduled task, which hides it from Task Scheduler and schtasks.
references:
    - https://attack.mitre.org/techniques/T1053/005/
tags:
    - attack.persistence
    - attack.defense-evasion
    - attack.t1053.005
    - attack.t1564
logsource:
    product: windows
    category: registry_delete
detection:
    selection:
        EventType: DeleteValue
        TargetObject|contains: '\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\'
        TargetObject|endswith: '\SD'
    condition: selection
falsepositives:
    - Unknown
level: high

Extend the same hunt to look for changes to the Index value under the Tree key by any process other than the Task Scheduler service. Expect some noise here, so baseline it per server role before turning it into a detection.

Sweep servers for tasks with no SD value

Telemetry only covers the period you have retained. A task hidden two years ago on a server that never reboots will not appear in 30 days of registry events. A read only sweep of the registry closes that gap.

The script below lists every task key under Tree that has an Id value but no SD value. It reads the registry and writes nothing. Run it elevated, through your approved remote tooling such as Defender for Endpoint Live Response or your server management platform, under the change or hunt authorisation your department requires.

$tree = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree'
Get-ChildItem -Path $tree -Recurse -ErrorAction SilentlyContinue |
    Where-Object {
        $names = $_.GetValueNames()
        ($names -contains 'Id') -and ($names -notcontains 'SD')
    } |
    ForEach-Object {
        [PSCustomObject]@{
            Host    = $env:COMPUTERNAME
            TaskKey = $_.Name
            TaskId  = $_.GetValue('Id')
        }
    }

For each result, use the TaskId to open the matching key under TaskCache\Tasks and read the Actions value, then compare it with the XML file of the same name in C:\Windows\System32\Tasks. Keys that the script cannot read are worth recording too, as they may point to tampered permissions.

Find tasks that run but cannot be seen

A hidden task still has to execute. Programs launched by a task usually start under the svchost.exe instance that hosts the Schedule service. Hunting rare children of that process catches hidden tasks even when the registry artefacts are gone.

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "svchost.exe"
| where InitiatingProcessCommandLine has "Schedule"
| where not(FolderPath startswith @"C:\Windows\")
      and not(FolderPath startswith @"C:\Program Files")
| summarize Devices = dcount(DeviceName), Runs = count(),
            FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            SampleCmd = any(ProcessCommandLine)
    by FileName, FolderPath, SHA256
| where Devices <= 2
| order by Runs desc

Then join what runs with what is visible. For any suspicious binary, check whether a TaskScheduler Operational Event ID 200 on that host names a task that no longer appears in Task Scheduler. A task that keeps producing 200 and 201 events but is missing from schtasks /query is exactly what this hunt is looking for.

Microsoft's own guidance also stresses outbound traffic. Hidden tasks in the Tarrask case were used to restore command and control connections, so review regular outbound connections from Tier 0 and Tier 1 servers to destinations they have never contacted before.

Triage findings and report them

Treat each finding as a possible nation state foothold. Collect evidence before you change anything, and follow your department's incident process for containment.

• Record the hunt hypothesis, scope, data sources and retention period used.
• List servers you could not sweep or that lacked registry telemetry.
• Map findings to T1053.005 and T1564 in the hunt report.
• Raise change requests for missing logging: TaskScheduler Operational, 4698 auditing, Sysmon TaskCache coverage.
• Turn the SD deletion query into a scheduled detection through your rule approval process.
• Reference the hunt as evidence for Cyber Assessment Framework objective C, principles C1 Security Monitoring and C2 Proactive Security Event Discovery.

Key takeaways

---

Hidden scheduled tasks reward patience more than clever tooling. Run the registry sweep on your most critical servers first, close the logging gaps through change control, and keep the SD deletion rule live so the next attempt is caught on the day it happens rather than months later.

Written by Freya, Senior SOC Analyst, Government