Tarrask et tâches planifiées cachées : les détecter

En bref. En avril 2022, Microsoft a décrit Tarrask, un outil de HAFNIUM qui cachait des tâches planifiées en supprimant la valeur SD sous TaskCache\Tree\<tâche>. La tâche disparaissait de schtasks et de la console, mais restait dans le registre et sur le disque. Les variantes apparues depuis utilisent un descripteur qui refuse l'accès en lecture ou manipulent Index. Hors ligne, les trois sont visibles : listez les clés Tree sans SD, décodez les SD présents, vérifiez Index et comparez avec le dossier des XML. Travaillez sur une ruche dont les journaux de transactions ont été rejoués.

Cet article fait partie de la série sur les investigations de tâches planifiées. Les structures de registre sur lesquelles il s'appuie sont expliquées dans analyse forensique du registre TaskCache.

Ce que Microsoft a rapporté

Dans Tarrask malware uses scheduled tasks for defense evasion (12 avril 2022), l'équipe de threat intelligence de Microsoft a décrit un outil de HAFNIUM (désormais suivi sous le nom de Silk Typhoon) qui créait des tâches planifiées pour assurer sa persistance, puis supprimait la valeur SD de la clé Tree de la tâche. Points clés de l'analyse :

• La valeur SD contient le descripteur de sécurité de la tâche. Sans elle, les outils qui énumèrent les tâches via le service, dont schtasks /query et la console du Planificateur de tâches, n'affichent pas la tâche.
• La suppression nécessitait SYSTEM ; une invite administrateur élevée obtenait « access denied ». L'outil obtenait SYSTEM en volant un jeton à lsass.exe.
• Les valeurs Tree et Tasks de la tâche, ainsi que son fichier XML dans C:\Windows\System32\Tasks, restaient en place.
• Cacher la tâche ne l'arrêtait pas : elle continuait de s'exécuter selon ses déclencheurs. Microsoft ajoute que même la suppression des clés Tree et Tasks et du fichier XML laisserait la tâche tourner jusqu'au prochain redémarrage ou jusqu'à la fin du processus svchost.exe hôte ; c'est la conservation des données de registre, moins le SD, qui assure la persistance à travers les redémarrages.
• Recommandation de détection de Microsoft : énumérer TaskCache\Tree à la recherche de tâches sans valeur SD, et activer la journalisation du canal TaskScheduler/Operational et de l'événement Security 4698.

MITRE ATT&CK a ajouté la technique à T1053.005, en citant à la fois la suppression du SD et la modification de la valeur Index comme moyens de cacher une tâche.

Les variantes à vérifier aussi

Descripteur refusant la lecture. En 2024, Binary Defense a montré qu'un SD valide dont l'ACL refuse la lecture à tous les comptes cache une tâche aux mêmes outils. La valeur SD existe et se décode proprement : une règle « SD manquant » passe donc à côté. Il faut décoder le descripteur et lire les ACE.

Manipulation d'Index. Le DWORD Index de la clé Tree range la tâche dans une catégorie (1 Boot, 2 Logon, 3 Plain, 4 Maintenance, selon cyber.wtf). MITRE cite le fait de lui donner une valeur inattendue comme méthode de dissimulation. Les détails publics sont plus minces que pour la suppression du SD : traitez les valeurs étranges comme une piste.

Création uniquement dans le registre. Binary Defense a également constaté qu'écrire une tâche directement dans TaskCache, sans SD, évitait à la fois l'événement Security 4698 et l'événement TaskScheduler/Operational 106. Sous Windows 10, une telle tâche était utilisable immédiatement ; sous Windows 11, elle ne s'exécutait qu'après un redémarrage du service ou de l'hôte. L'absence d'événements de création ne prouve donc pas l'absence de tâche.

Détection hors ligne

Tout ce qu'il faut se trouve dans la ruche SOFTWARE et le dossier Tasks :

1. Lister les clés de tâche Tree sans SD. Une clé de tâche est une clé qui possède une valeur Id ; les dossiers n'ont ni Id ni Index. Toute clé de tâche sans SD est un constat : les tâches légitimes en ont une.
2. Décoder chaque SD en SDDL et rechercher des ACE de refus (D:(D;...)) ou une DACL qui n'accorde rien aux Administrateurs ni à SYSTEM. Comparer avec les descripteurs des tâches Microsoft voisines.
3. Vérifier Index par rapport à la clé de catégorie (Boot, Logon, Plain, Maintenance) sous laquelle figure le GUID de la tâche.
4. Associer au fichier XML. Une tâche cachée a généralement toujours son XML. Lisez ses actions et son principal comme pour n'importe quelle autre tâche.
5. Lire DynamicInfo dans Tasks\{GUID} : les heures de dernière exécution et de dernière exécution réussie indiquent si la tâche cachée s'est exécutée.
6. Regarder la date de dernière écriture de la clé Tree. La suppression de SD modifie la clé. Une date de dernière écriture postérieure à l'enregistrement de la tâche est cohérente avec un SD supprimé ultérieurement. Ce n'est pas une preuve à elle seule : toute modification de Id, Index ou SD la met à jour.

Le piège de la ruche « dirty »

Une ruche copiée depuis un système en fonctionnement peut ne pas contenir les dernières modifications, qui peuvent encore se trouver dans SOFTWARE.LOG1/.LOG2. Pour les tâches cachées, cela joue dans les deux sens : une suppression récente du SD peut être absente du fichier principal (vous manquez la dissimulation), ou une tâche enregistrée quelques minutes avant la collecte peut manquer entièrement. Collectez les journaux, rejouez-les avec un outil qui les prend en charge, et seulement ensuite concluez. Le Scheduled Tasks Parser détecte les ruches « dirty » et émet un avertissement ; il ne rejoue pas lui-même les journaux. Les détails d'acquisition se trouvent dans emplacements et acquisition des tâches planifiées.

Détection à chaud

Sur un système en fonctionnement, l'équivalent est une requête de registre, en tant que SYSTEM ou administrateur, sur HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree, listant les clés qui ont un Id mais pas de SD. Velociraptor fournit un artefact dédié à exactement cela, Windows.Registry.TaskCache.HiddenTasks, qui récupère aussi le XML correspondant. Sigma propose une règle pour la suppression elle-même lorsque l'audit du registre est disponible (miroir detection.fyi).

Pour la surveillance continue, les recommandations de Microsoft restent valables : journalisation TaskScheduler/Operational activée, audit de Security 4698, et alerte sur les suppressions de SD sous TaskCache\Tree dans le registre. Binary Defense ajoute un angle de chasse utile : les tâches présentes dans TaskCache sans événement de création correspondant (106 ou 4698) alors que ces journaux sont par ailleurs complets.

Interpréter une détection

Une entrée Tree sans SD est un signal fort ; il n'existe pas de raison légitime courante à cela. Rédigez néanmoins le constat tel que vous l'avez observé : « la clé Tree de \Microsoft\Windows\UPnP\UPnPHostConfigSync n'a pas de valeur SD ; la tâche n'est donc pas listée par schtasks ni par la console du Planificateur de tâches ». Établissez ensuite :

• Ce qu'elle exécute : les actions du XML, ou le blob Actions décodé si le XML a disparu.
• Sous quel compte : le principal dans le XML ou dans l'en-tête de Triggers.
• Depuis quand : la création dans DynamicInfo, la Date du XML (avec le bon décalage UTC), la date de dernière écriture de la clé.
• Si elle s'est exécutée : la dernière exécution et le résultat dans DynamicInfo, les événements TaskScheduler/Operational 200/201, les artefacts d'exécution comme Prefetch.
• Comment SYSTEM a été obtenu : la suppression l'exige, cherchez donc l'étape d'élévation de privilèges ou d'accès aux identifiants dans les journaux d'événements.

Un exemple complet et fictif avec une tâche de type Tarrask figure dans comment analyser les tâches planifiées dans votre navigateur.

FAQ

Comment Tarrask cachait-il les tâches planifiées ?

Il supprimait la valeur SD (descripteur de sécurité) de la clé de la tâche sous TaskCache\Tree dans la ruche SOFTWARE. Sans elle, schtasks /query et la console du Planificateur de tâches n'affichent plus la tâche, qui conserve pourtant ses données de registre et son fichier XML. Microsoft a indiqué que la suppression devait être effectuée en tant que SYSTEM.

Une tâche cachée s'exécute-t-elle toujours ?

Oui. Dans l'analyse de Tarrask publiée par Microsoft, la tâche cachée continuait de s'exécuter selon ses déclencheurs, et Microsoft précise que même une tâche dont les clés de registre et le XML ont tous été supprimés continue de s'exécuter jusqu'au prochain redémarrage ou jusqu'à la fin de son hôte svchost.exe. Des recherches ultérieures de Binary Defense ont montré que le comportement diffère entre Windows 10 et 11 pour les tâches écrites directement dans le registre. Vérifiez l'heure de dernière exécution dans DynamicInfo de TaskCache et les journaux d'événements plutôt que de supposer.

Comment trouver des tâches planifiées cachées hors ligne ?

Analysez la ruche SOFTWARE et listez chaque clé de tâche TaskCache\Tree qui n'a pas de valeur SD, dont le SD refuse l'accès en lecture, ou dont l'Index est inhabituel. Comparez cette liste avec les fichiers XML de System32\Tasks, et assurez-vous que les journaux de transactions de la ruche ont été rejoués.