Analyser vos tâches planifiées dans le navigateur (exemple)

En bref. Collectez System32\Tasks, SysWOW64\Tasks, C:\Windows\Tasks et la ruche SOFTWARE (avec ses .LOG1/.LOG2), déposez-les, ou le ZIP de triage, dans le Scheduled Tasks Parser, lisez les avertissements, confirmez le décalage UTC déduit, puis traitez les constats dans l'ordre : tâches présentes uniquement dans le registre, SD manquant, hash discordants d'abord, puis chemins, commandes encodées, LOLBins et privilèges. Exportez en CSV, en JSON ou en CSV de chronologie. Rien ne quitte le navigateur. Le cas fictif ci-dessous, qui correspond à l'exemple intégré, illustre chaque étape.

Cet article est le pendant pratique du guide d'analyse forensique des tâches planifiées. L'acquisition est traitée dans emplacements et acquisition des tâches planifiées.

Ce que fait l'outil, et ce qu'il ne fait pas

Le parser est écrit en Rust compilé en WebAssembly et s'exécute dans un Web Worker de votre navigateur. Les fichiers sont lus localement et ne sont jamais envoyés. Il :

• lit le XML des tâches (UTF-16LE, schéma 1.2 et suivants) : RegistrationInfo, tous les types de déclencheurs, les principaux, les paramètres et les actions Exec/ComHandler/SendEmail/ShowMessage ;
• lit les fichiers .job hérités : sections fixe et variable, déclencheurs, heure de dernière exécution telle qu'elle est stockée (SYSTEMTIME local) ;
• lit TaskCache dans la ruche SOFTWARE : Tree (Id, Index, SD décodé en SDDL, heures de dernière écriture des clés) et Tasks\{GUID} (Path, URI, Author, Date, Hash, Schema, DynamicInfo, Actions décodé, en-tête Triggers et principal) ;
• corrèle le XML avec TaskCache par chemin, recalcule le hash et signale les tâches présentes uniquement dans le registre, uniquement sur le disque, ou sans SD ;
• avertit quand la ruche est « dirty ». Il ne rejoue pas les journaux de transactions, ne récupère pas les clés supprimées par carving et n'analyse pas les journaux d'événements.

Les constats sont des heuristiques pour ordonner votre examen, pas des verdicts.

Le cas fictif

Tout ce qui suit est inventé à des fins de formation : l'hôte, le compte, les adresses et les fichiers n'existent pas, et les commandes sont des substituts inoffensifs. C'est exactement l'exemple que vous obtenez avec Try a sample sur la page d'accueil : vous pouvez donc suivre en parallèle.

Un poste de travail du service financier, FIN-WKS-07, configuré sur un fuseau UTC+02:00. Le 2026-09-14, une alerte se déclenche sur un trafic sortant inhabituel. D'autres artefacts montrent un compte que personne ne reconnaît, svc_backup. La question à ce stade : l'intrus a-t-il laissé des tâches planifiées derrière lui, et qu'ont-elles fait entre 10:00 et 10:55 UTC ?

Étape 1 : Collecter les dossiers de tâches et la ruche SOFTWARE

La collecte suit l'arborescence KAPE, telle que produite par :

kape.exe --tsource C: --tdest C:\triage\kape --target ScheduledTasks,RegistryHivesSystem

Le ZIP obtenu contient C/Windows/System32/Tasks (19 fichiers XML), C/Windows/Tasks (un fichier .job) et C/Windows/System32/config/SOFTWARE. Une collecte Velociraptor Windows.Triage.Targets avec les mêmes targets fonctionne de la même manière. Calculez le hash de l'archive avant de commencer.

Étape 2 : Charger les fichiers dans le navigateur

Ouvrez l'outil et déposez le ZIP. Vous pouvez aussi déposer des fichiers isolés ou un dossier. Le parser parcourt l'archive (arborescence KAPE, ou arborescence Velociraptor avec chemins encodés en pourcentage et noms d'entrées avec barres obliques inverses), sélectionne les fichiers de tâches et la ruche SOFTWARE, et ignore le reste. Cela prend une ou deux secondes.

La barre de synthèse de l'exemple affiche : 21 tâches (19 XML, 1 .job, 16 entrées TaskCache fusionnées avec elles), 8 signalées, 1 cachée (sans SD), 1 uniquement dans le registre, 1 uniquement en XML, 5 enregistrées récemment.

Étape 3 : Lire les avertissements

Avant toute conclusion sur une tâche « manquante », lisez les avertissements du parser :

La ruche de l'exemple est propre : aucun avertissement de ruche « dirty », si bien que les constats « uniquement dans le registre » et « uniquement en XML » peuvent être pris au pied de la lettre. Sur une collecte à chaud, vous verrez souvent cet avertissement ; rejouez les journaux avant de vous fier aux absences.

Étape 4 : Vérifier le fuseau horaire

Les valeurs Date et StartBoundary du XML sont généralement en heure locale sans décalage (pourquoi). Le parser compare la Date XML de chaque tâche avec le FILETIME UTC de création dans DynamicInfo pour la même tâche, et compte les décalages obtenus. Pour l'exemple, il indique UTC+02:00 ×4, UTC+01:00 ×1 et applique +02:00. Deux de ces comparaisons :

La valeur isolée n'est pas une erreur : le programme de mise à jour d'Edge a été enregistré en mars, à l'heure d'hiver (CET, UTC+01:00), et les tâches de septembre à l'heure d'été (CEST, UTC+02:00). C'est pourquoi un décalage unique appliqué à toute une machine peut être faux pour les tâches plus anciennes. Dans ce cas, toutes les tâches intéressantes ont été enregistrées le 2026-09-14 : +02:00 est donc correct. À partir de là, toutes les heures sont affichées en UTC.

Étape 5 : Trier les constats

Triez par gravité. Sur les 21 tâches, 13 sont des tâches ordinaires de Microsoft, d'Office, d'Edge et de synchronisation de flux, sans aucun constat. Deux autres sont signalées mais bénignes, et il vaut la peine de les lire en premier pour vous étalonner :

• \GoogleUpdateTaskMachineUA : Privilèges élevés, pas Microsoft. Elle s'exécute en SYSTEM et n'a pas d'auteur. C'est ainsi que le programme de mise à jour de Google s'enregistre.
• \OneDrive Standalone Update Task-S-1-5-21-…-1104 : Chemin inscriptible par l'utilisateur. Sa commande se trouve sous %localappdata%, là où réside le programme de mise à jour OneDrive par utilisateur.

Les constats sont des pistes, pas des verdicts. Les six tâches ci-dessous sont celles qui comptent.

\Microsoft\Windows\UPnP\UPnPHostConfigSync : cachée, sans SD

• L'auteur se présente comme Microsoft Corporation, et la tâche se trouve sous \Microsoft\Windows\ pour se fondre dans le décor.
• Enregistrée à 10:12:40 UTC (Date XML 2026-09-14T12:12:40.0918251 en heure locale).
• Principal : SYSTEM, HighestAvailable. Déclencheurs : LogonTrigger et un TimeTrigger à partir de 12:12:40 en heure locale, répété toutes les 30 minutes (PT30M).
• Action : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -EncodedCommand VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAHMAeQBuAHQAaABlAHQAaQBjACAAcwBhAG0AcABsAGUAJwA=, décodée par le parser en Write-Output 'synthetic sample' (un substitut d'un vrai script).
• TaskCache : la clé Tree possède Id et Index = 2 mais pas de valeur SD. Son heure de dernière écriture est 10:13:05 UTC, 25 secondes après l'enregistrement.
• DynamicInfo : dernière exécution à 10:42:40 UTC, dernière exécution réussie à 10:42:41 UTC.

Constats : Cachée : pas de SD dans TaskCache (critique), PowerShell encodé (élevé), Enregistrée récemment. C'est le schéma Tarrask : sur l'hôte en fonctionnement, schtasks /query ne la listerait pas. L'écriture de la clé 25 secondes après l'enregistrement est cohérente avec une suppression du SD à 10:13, ce qui signifie aussi que l'intrus disposait des droits SYSTEM à ce moment-là.

\IntelGfxTelemetry : paramètre Hidden, SYSTEM, chemin inscriptible par l'utilisateur

• Auteur FIN-WKS-07\svc_backup, description « Intel graphics telemetry », dossier racine.
• Enregistrée à 10:09:58 UTC. Principal : S-1-5-18, HighestAvailable. <Hidden>true</Hidden>.
• Déclencheurs : BootTrigger et un TimeTrigger à partir de 12:15:00 en heure locale (10:15 UTC), toutes les heures.
• Action : C:\ProgramData\Intel\m64.exe -svc.
• DynamicInfo : dernière exécution à 10:15:00 UTC, dernier résultat 0x00041301 (SCHED_S_TASK_RUNNING : le programme tournait encore au moment de la collecte).

Constats : Chemin inscriptible par l'utilisateur, Privilèges élevés, pas Microsoft, Paramètre Hidden, Enregistrée récemment. Contrairement à la tâche UPnP, elle conserve son SD : elle n'est cachée que de la vue par défaut de la console, pas de schtasks.

\a8Xq2LmZ : la définition a changé après l'enregistrement

• Nom d'apparence aléatoire à la racine, enregistrée à 10:21:30 UTC par svc_backup, exécutée sous svc_backup (InteractiveToken, LeastPrivilege) à l'ouverture de session de cet utilisateur.
• Actions dans TaskCache : C:\Windows\System32\rundll32.exe C:\Users\svc_backup\Downloads\tools\helper.dll,Init.
• XML sur le disque : la même commande avec helper.dll,Start. Le Hash de TaskCache ne correspond plus au fichier.
• DynamicInfo : dernière exécution à 10:24:02 UTC.

Constats : XML modifié après l'enregistrement et Action du registre différente du XML (élevé), LOLBin, Chemin inscriptible par l'utilisateur, Nom d'apparence aléatoire, Enregistrée récemment. Quelqu'un a modifié directement le fichier XML au lieu de réenregistrer la tâche : le service conserve donc la version enregistrée. Lisez les deux : le registre dit ce qui a été enregistré, le fichier dit à quoi quelqu'un a voulu qu'elle ressemble ensuite.

\Microsoft\Windows\Maintenance\CleanupTemp : jamais enregistrée

• Fichier XML uniquement : aucune entrée TaskCache.
• L'auteur se présente comme Microsoft Corporation ; Date 12:31:05 en heure locale (10:31:05 UTC avec le décalage +02:00) ; Hidden=true ; principal svc_backup ; TimeTrigger à 12:35 en heure locale.
• Action : C:\Windows\System32\mshta.exe C:\Users\svc_backup\Downloads\tools\cleanup.hta.

Constats : Non enregistrée (moyen), LOLBin, Chemin inscriptible par l'utilisateur, Enregistrée récemment. Un fichier déposé dans le dossier Tasks n'est pas une tâche tant que le service ne l'a pas enregistré. Comme la ruche est propre, l'absence dans TaskCache a du sens : cette tâche a été préparée mais, au vu de ces éléments, jamais planifiée.

\SyncBackup : uniquement dans le registre

• Aucun fichier XML sur le disque ; TaskCache contient toujours Tree et Tasks\{GUID}.
• Date dans TaskCache 2026-09-14T12:44:10.2059113 (heure locale) ; DynamicInfo : création à 10:44:10 UTC, dernière exécution à 10:47:12 UTC, dernière exécution réussie à 10:53:51 UTC, résultat 0.
• Actions décodé : C:\Users\Public\rclone.exe copy C:\Users\Public\data E:\exfil.
• En-tête Triggers : start boundary 2026-09-14T12:47:00 en heure locale, SID du principal se terminant par -1119 (svc_backup).

Constats : Fichier XML manquant (élevé), Chemin inscriptible par l'utilisateur, Enregistrée récemment. Le fichier a été supprimé mais la tâche n'a jamais été désenregistrée : elle apparaîtrait donc toujours dans schtasks sur l'hôte en fonctionnement. Le registre est la seule définition qui subsiste, et il pointe vers un outil de copie qui écrit vers E:\exfil, un lecteur qu'il faut identifier.

\Cleanup : un .job hérité

• Fichier : C:\Windows\Tasks\Cleanup.job, auteur FIN-WKS-07\svc_backup.
• Commande : cmd.exe /c del /q C:\Users\svc_backup\Desktop\creds.txt.
• Déclencheur : unique, à 12:52 en heure locale. Dernière exécution : 2026-09-14 12:52:30 en heure locale (10:52:30 UTC), état 0x00041305 (SCHED_S_TASK_NOT_SCHEDULED : aucune autre exécution prévue).

Constats : .job hérité, Chemin inscriptible par l'utilisateur. Un fichier .job sur un système moderne est inhabituel en soi ; celui-ci supprime un fichier du bureau du compte en fin de session, ce qui ressemble à du nettoyage.

Étape 6 : Restreindre la plage temporelle et exporter

Ouvrez \SyncBackup et centrez la plage temporelle sur cette tâche, à plus ou moins 1 heure. L'outil se centre sur la première heure de la tâche, son enregistrement à 10:44:10 UTC : la fenêtre va donc de 09:44:10 à 11:44:10 UTC. La bande de densité montre la rafale d'activité entre 10:09 et 10:54 ; les treize tâches de référence disparaissent. Vous pouvez aussi saisir From 2026-09-14 10:00:00 et To 10:55:00 UTC, à la seconde près.

Exportez la vue filtrée en CSV, en JSON ou en CSV Timeline, dont les colonnes message, datetime et timestamp_desc s'importent directement dans Timesketch. La séquence reconstituée, entièrement en UTC :

Étapes suivantes, en dehors de cet outil : confirmer l'exécution de m64.exe, rclone.exe et rundll32.exe avec Prefetch et Amcache, rechercher les événements 4698/106 et 200/201 dans les journaux d'événements, identifier le volume E:, récupérer helper.dll et cleanup.hta, et déterminer comment svc_backup a obtenu les droits SYSTEM. La checklist d'indicateurs à l'origine de ces constats se trouve dans comment détecter les tâches planifiées malveillantes.