Analyse forensique des tâches planifiées : guide complet

En bref. Une tâche planifiée Windows laisse jusqu'à quatre types de traces : une définition XML dans C:\Windows\System32\Tasks, une copie dans le registre au sein de la ruche SOFTWARE sous TaskCache, parfois un fichier .job hérité dans C:\Windows\Tasks, et des événements dans les journaux (Security 4698 à 4702, TaskScheduler/Operational 106, 140, 141, 200, 201). Collectez-les toutes, rapprochez le XML du registre par chemin de tâche, comparez-les, et traitez chaque attribut suspect comme une piste à vérifier plutôt que comme un verdict.

Les tâches planifiées comptent parmi les mécanismes de persistance les plus courants sous Windows. MITRE ATT&CK les répertorie sous T1053.005 Scheduled Task, pour la persistance, l'exécution et l'élévation de privilèges. C'est aussi l'un des endroits les plus bruyants d'un système sain : une installation neuve de Windows 11 enregistre largement plus d'une centaine de tâches Microsoft. Le travail de l'enquêteur consiste à repérer la poignée de tâches qui n'ont rien à faire là, et à les dater.

Ce guide est le point d'entrée de la série. Chaque section renvoie vers un article plus détaillé.

Les quatre sources de traces

Le schéma XML est documenté par Microsoft dans la référence Task Scheduler Schema. La structure du registre et le format .job ne sont que partiellement documentés : le format .job est spécifié dans MS-TSCH, tandis que les valeurs binaires de TaskCache sont surtout connues grâce à la rétro-ingénierie communautaire, notamment l'analyse TaskCache de cyber.wtf et le winreg-kb de libyal.

L'emplacement de chaque fichier selon la version de Windows, et la façon de le collecter sans perdre de données, sont traités dans où sont stockées les tâches planifiées et comment les acquérir.

Pourquoi le registre compte autant que le XML

Beaucoup de checklists s'arrêtent au dossier XML. Ce n'est pas suffisant. Le service Planificateur de tâches conserve sa propre copie de chaque tâche enregistrée dans la clé TaskCache de la ruche SOFTWARE, répartie en deux :

• Tree\<task path> contient une clé par tâche, portant le nom de la tâche, avec les valeurs Id (le GUID de la tâche), Index et SD, le descripteur de sécurité qui détermine qui peut voir et modifier la tâche.
• Tasks\{GUID} contient les données de la tâche : Path, URI, Author, Date, Hash, Actions, Triggers et DynamicInfo, une valeur binaire qui porte la création de la tâche, sa dernière exécution et son dernier résultat.

Trois conséquences pour l'enquête :

1. Supprimer le fichier XML ne désenregistre pas la tâche. L'entrée de registre, et souvent la tâche elle-même, subsistent. Une tâche présente uniquement dans TaskCache mérite qu'on s'y attarde.
2. Supprimer la valeur SD masque la tâche à schtasks /query et à la console du Planificateur de tâches. C'est la technique décrite par Microsoft pour le malware Tarrask en avril 2022. Voir Tarrask et les tâches planifiées cachées.
3. Le registre détient des métadonnées d'exécution absentes du XML. DynamicInfo enregistre la date de création et de dernière exécution de la tâche, ainsi que le dernier code de résultat, ce que le XML ne fait jamais.

Le temps, et le piège du XML

Le Date de RegistrationInfo et le StartBoundary des déclencheurs sont des valeurs XML dateTime. L'API de Microsoft accepte un décalage UTC (YYYY-MM-DDTHH:MM:SS(+-)HH:MM, voir Trigger.StartBoundary), mais les tâches créées via la console ou schtasks n'enregistrent généralement aucun décalage : la valeur est exprimée dans l'heure locale de la machine. L'exemple d'événement 4698 fourni par Microsoft l'illustre : l'événement est journalisé à 2015-09-23T02:03:06Z alors que le XML de la tâche qu'il embarque indique <Date>2015-09-22T19:03:06.9258653</Date>, soit sept heures plus tôt, sur une machine située dans un fuseau UTC-7.

Les horodatages de TaskCache (DynamicInfo, heures de dernière écriture des clés) sont des FILETIME en UTC. Comparer les deux pour une même tâche est le moyen le plus simple d'en déduire le décalage de la machine. Plus de détails dans l'anatomie du XML d'une tâche et dans l'entrée de glossaire StartBoundary.

Journaux d'événements : utiles quand ils existent

Les événements Security exigent la sous-catégorie Audit Other Object Access Events, qui n'est pas activée par défaut sur la plupart des postes de travail. Le canal Operational est celui que pilote l'option "Enable All Tasks History" de la console du Planificateur de tâches ; sur de nombreux systèmes, il est désactivé ou n'a qu'une faible rétention. Considérez l'absence d'événements comme « non enregistré », pas comme « ne s'est pas produit ». Des chercheurs ont également montré que des tâches écrites directement dans le registre peuvent échapper totalement à 4698 comme à 106 (Binary Defense). Si vous disposez des journaux, analysez-les avec l'EVTX parser et alignez-les sur les données des tâches.

Ce qu'il faut rechercher

Une liste courte, détaillée dans comment détecter les tâches planifiées malveillantes :

• Des commandes situées dans des dossiers accessibles en écriture à l'utilisateur : C:\Users\Public, C:\ProgramData, %TEMP%, AppData.
• Du PowerShell encodé (-EncodedCommand) et des hôtes de scripts ou LOLBins comme rundll32, regsvr32, mshta, certutil.
• Des tâches non Microsoft qui s'exécutent en tant que SYSTEM ou avec HighestAvailable.
• Des tâches à la racine de la bibliothèque ou aux noms d'apparence aléatoire, un motif que les recommandations de supervision de Microsoft elles-mêmes signalent.
• Des tâches cachées (<Hidden>true</Hidden>) d'un auteur non Microsoft, et des entrées TaskCache sans valeur SD.
• Des incohérences : XML présent mais aucune entrée de registre, entrée de registre sans XML, ou Hash qui ne correspond pas au XML sur disque.
• Des dates d'enregistrement récentes, proches de la fenêtre de l'incident.

Chaque point a ses explications anodines. Les programmes de mise à jour des éditeurs résident dans ProgramData ; les scripts de l'IT utilisent -EncodedCommand. Ces indicateurs restreignent la recherche ; c'est votre corroboration qui tranche.

Une méthode qui tient la route

1. Acquérir C:\Windows\System32\Tasks (récursivement), C:\Windows\SysWOW64\Tasks, C:\Windows\Tasks, la ruche SOFTWARE avec ses journaux de transactions .LOG1/.LOG2, ainsi que les journaux Security et TaskScheduler/Operational. Les cibles KAPE ScheduledTasks et RegistryHivesSystem couvrent les fichiers et les ruches (KapeFiles).
2. Analyser ensemble le XML, les .job et TaskCache, puis rapprocher chaque fichier XML de son entrée TaskCache par chemin de tâche.
3. Contrôler l'intégrité : tâches présentes uniquement dans le registre, uniquement sur disque, SD manquant, hash incohérents, et vérifier si la ruche était « dirty » au moment de la copie.
4. Normaliser le temps : déduire ou fixer le décalage UTC pour les heures XML sans fuseau ; conserver les FILETIME du registre en UTC.
5. Trier à l'aide de la liste d'attributs suspects ci-dessus, puis corroborer avec des traces d'exécution de processus (Prefetch, Amcache) et les journaux d'événements.

Le Scheduled Tasks Parser réalise les étapes 2 à 4 dans le navigateur : déposez les dossiers, la ruche ou une archive ZIP KAPE/Velociraptor, et il rapproche le XML de TaskCache, vérifie les hash, signale les tâches cachées et celles présentes uniquement dans le registre, puis exporte en CSV ou JSON. Rien n'est envoyé sur un serveur. La démarche pas à pas se trouve dans comment analyser les tâches planifiées dans votre navigateur.

FAQ

Où Windows stocke-t-il les tâches planifiées ?

À trois endroits : une définition XML par tâche sous C:\Windows\System32\Tasks, une copie dans le registre sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache et, pour les tâches héritées uniquement, des fichiers .job binaires dans C:\Windows\Tasks.

Qui fait foi : le fichier XML ou le registre ?

Depuis Windows 8, le service Planificateur de tâches travaille à partir des données TaskCache du registre ; les fichiers XML sont maintenus en cohérence avec elles. Une tâche peut subsister dans le registre après la suppression de son fichier XML : collectez et comparez donc toujours les deux.

Quels event IDs enregistrent la création d'une tâche planifiée ?

Côté Security, 4698 (création, avec le XML complet de la tâche), 4699 (suppression), 4700 (activation), 4701 (désactivation) et 4702 (mise à jour), qui exigent la stratégie Audit Other Object Access Events ; côté TaskScheduler/Operational, 106 (enregistrement), 140 (mise à jour), 141 (suppression), 200 (action démarrée) et 201 (action terminée).

Pour aller plus loin

• Microsoft Learn, Task Scheduler Schema.
• Microsoft, [MS-TSCH]: Task Scheduler Service Remoting Protocol.
• Microsoft Threat Intelligence, Tarrask malware uses scheduled tasks for defense evasion (avril 2022).
• cyber.wtf, Windows Registry Analysis: Tasks (2022).
• MITRE ATT&CK, T1053.005 Scheduled Task.