Tarrask and Hidden Scheduled Tasks: How to Detect Them

TL;DR. In April 2022 Microsoft described Tarrask, a HAFNIUM tool that hid scheduled tasks by deleting the SD value under TaskCache\Tree\<task>. The task vanished from schtasks and the console but stayed in the registry and on disk. Variants since then use a descriptor that denies read access or tamper with Index. Offline, all three are visible: list Tree keys without SD, decode the SDs you do have, check Index, and compare with the XML folder. Use a hive with its transaction logs replayed.

This article is part of the scheduled task investigation series. The registry structures it relies on are explained in TaskCache registry forensics.

What Microsoft reported

In Tarrask malware uses scheduled tasks for defense evasion (April 12, 2022), Microsoft's threat intelligence team described a HAFNIUM (now tracked as Silk Typhoon) tool that created scheduled tasks to maintain persistence, then removed the SD value from the task's Tree key. Key points from the write-up:

• The SD value holds the task's security descriptor. Without it, tools that enumerate tasks through the service, including schtasks /query and the Task Scheduler console, do not show the task.
• The deletion required SYSTEM; an elevated administrator prompt got "access denied". The tool obtained SYSTEM by stealing a token from lsass.exe.
• The task's Tree and Tasks values and its XML file in C:\Windows\System32\Tasks remained.
• Hiding the task did not stop it: it kept running on its triggers. Microsoft adds that even deleting the Tree and Tasks keys and the XML file would leave the task running until the next reboot or until the hosting svchost.exe process ended; keeping the registry data, minus the SD, is what gives persistence across reboots.
• Microsoft's detection advice: enumerate TaskCache\Tree for tasks with no SD value, and enable logging for the TaskScheduler/Operational channel and Security event 4698.

MITRE ATT&CK added the technique to T1053.005, noting both SD deletion and alteration of the Index value as ways to hide a task.

The variants you should also check

Deny-read descriptor. In 2024 Binary Defense showed that a valid SD whose ACL denies read access to all accounts hides a task from the same tools. The SD value exists and parses cleanly, so a "missing SD" rule misses it. You have to decode the descriptor and read the ACEs.

Index tampering. The Index DWORD in the Tree key places the task in a category (1 Boot, 2 Logon, 3 Plain, 4 Maintenance, per cyber.wtf). MITRE cites setting it to an unexpected value as a hiding method. Public details are thinner than for SD deletion, so treat odd values as a lead.

Registry-only creation. Binary Defense also found that writing a task directly into TaskCache, without an SD, avoided both Security 4698 and TaskScheduler/Operational 106. On Windows 10 such a task was usable immediately; on Windows 11 it did not run until the service or host restarted. Absence of creation events is therefore not evidence of absence.

Detection, offline

Everything needed is in the SOFTWARE hive and the Tasks folder:

1. List Tree task keys without SD. A task key is one with an Id value; folders have neither Id nor Index. Every task key without SD is a finding: legitimate tasks have one.
2. Decode each SD to SDDL and look for deny ACEs (D:(D;...)) or a DACL that grants nothing to Administrators or SYSTEM. Compare with the descriptors of neighbouring Microsoft tasks.
3. Check Index against the category key (Boot, Logon, Plain, Maintenance) where the task GUID appears.
4. Pair with the XML file. A hidden task usually still has its XML. Read its actions and principal as for any other task.
5. Read DynamicInfo in Tasks\{GUID}: the last run and last successful run times tell you whether the hidden task has been executing.
6. Look at the Tree key last-write time. Deleting SD modifies the key. A last-write time later than the task's registration is consistent with the SD being removed afterwards. It is not proof on its own: any change to Id, Index or SD updates it.

The dirty hive trap

A hive copied from a live system may not contain the latest changes, which can still be in SOFTWARE.LOG1/.LOG2. For hidden tasks this cuts both ways: a recent SD deletion may be absent from the primary file (you miss the hiding), or a task registered minutes before collection may be missing entirely. Collect the logs, replay them with a log-aware tool, and only then conclude. The Scheduled Tasks Parser detects dirty hives and warns; it does not replay logs itself. Acquisition details are in scheduled task locations and acquisition.

Detection, live

On a live system, the equivalent is a registry query as SYSTEM or an administrator against HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree, listing keys with an Id and no SD. Velociraptor ships an artifact for exactly this, Windows.Registry.TaskCache.HiddenTasks, which also pulls the matching XML. Sigma has a rule for the deletion itself when registry auditing is available (detection.fyi mirror).

For ongoing monitoring, Microsoft's recommendations still apply: TaskScheduler/Operational logging on, Security 4698 audited, and alerting on registry deletions of SD under TaskCache\Tree. Binary Defense adds a useful hunting angle: tasks present in TaskCache with no matching creation event (106 or 4698) when those logs are otherwise complete.

Interpreting a hit

A Tree entry without SD is a strong signal; there is no common legitimate reason for it. Still, write the finding as what you observed: "the Tree key for \Microsoft\Windows\UPnP\UPnPHostConfigSync has no SD value; the task is therefore not listed by schtasks or the Task Scheduler console". Then establish:

• What it runs: XML actions, or the decoded Actions blob if the XML is gone.
• As whom: principal in XML or in the Triggers header.
• Since when: DynamicInfo created, XML Date (with the right UTC offset), key last-write time.
• Whether it ran: DynamicInfo last run and result, TaskScheduler/Operational 200/201, execution artifacts such as Prefetch.
• How SYSTEM was obtained: the deletion needs it, so look for the privilege escalation or credential access step in event logs.

A worked, fictional example with a Tarrask-style task is in how to analyze scheduled tasks in your browser.

FAQ

How did Tarrask hide scheduled tasks?

It deleted the SD (security descriptor) value of the task's key under TaskCache\Tree in the SOFTWARE hive. Without it, schtasks /query and the Task Scheduler console no longer show the task, while the task keeps its registry data and XML file. Microsoft reported that the deletion had to be done as SYSTEM.

Does a hidden task still run?

Yes. In Microsoft's Tarrask write-up, the hidden task kept running on its triggers, and Microsoft notes that even a task whose registry keys and XML were all deleted keeps running until the next reboot or until its svchost.exe host ends. Later research by Binary Defense found behaviour differs between Windows 10 and 11 for tasks written straight into the registry. Check the TaskCache DynamicInfo last run time and event logs rather than assuming.

How do I find hidden scheduled tasks offline?

Parse the SOFTWARE hive and list every TaskCache\Tree task key that has no SD value, an SD that denies read access, or an unusual Index. Compare the list with the XML files in System32\Tasks, and make sure the hive's transaction logs were replayed.