Enquêter sur une tâche planifiée Windows : configuration, historique et exécution
Reliez une tâche planifiée Windows à sa création, ses modifications et son exécution, en distinguant les faits des hypothèses pendant l’investigation SOC.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Une tâche planifiée déclenche une alerte sur un poste Windows. Son nom évoque une maintenance habituelle, mais son action mérite une vérification. Avant de conclure, votre SOC doit distinguer trois objets : la configuration actuellement présente, les changements passés et les exécutions réellement observées.
Une tâche enregistrée ne prouve pas que son programme a été lancé. Une configuration rassurante aujourd’hui peut aussi différer de celle utilisée pendant l’incident. Voici une méthode pour construire un dossier vérifiable, indépendamment du SIEM ou de l’outil de collecte utilisé.
Préserver la configuration observée
Le fait documenté : Microsoft propose schtasks /query pour consulter les tâches. L’option /xml, associée au chemin complet de la tâche avec /tn, permet d’obtenir sa définition XML. Cette consultation décrit l’état accessible au moment de la collecte. Source : Microsoft, schtasks query
Notre recommandation : conserver cette définition avant toute modification, avec le nom complet de la tâche, le poste, l’heure de collecte, le compte utilisé et la méthode employée. Limitez la collecte au périmètre autorisé et protégez les exports, qui peuvent contenir des arguments ou des chemins sensibles.
Travaillez ensuite sur une copie. Si une mesure de confinement urgente empêche cette collecte préalable, documentez l’ordre des actions et les informations devenues indisponibles. Une suppression peut effacer une pièce utile et perturber un traitement légitime ; elle doit relever d’une décision de réponse explicite.
Lire ce que la tâche est censée faire
Examinez la définition avec une grille courte. Le champ contenant un nom d’auteur est un indice à confronter aux événements disponibles ; il ne suffit pas à attribuer l’action à une personne.
| Élément à examiner | Question d’investigation |
|---|---|
| Action | Quel programme ou mécanisme est appelé ? Avec quels arguments ? |
| Emplacement | Où se trouve le fichier concerné ? Qui peut le modifier ? |
| Déclencheur | Quelle condition provoque l’exécution : horaire, connexion ou événement ? |
| Identité d’exécution | Sous quel compte et avec quel niveau de droits la tâche doit-elle fonctionner ? |
| Paramètres | Les conditions de lancement ou les relances expliquent-elles l’activité observée ? |
| Justification | Quel changement approuvé ou quel service attendu correspond à cette définition ? |
Notre recommandation : vérifier la cible réelle de l’action, pas uniquement le nom affiché. Si un interpréteur appelle un script, conservez aussi le chemin, les arguments et le fichier accessible. Le contenu actuel du fichier peut avoir changé depuis une exécution passée : notez cette limite.
Reconstituer la création et les modifications
Microsoft documente l’événement de sécurité 4698 pour la création d’une tâche. Il contient notamment son nom, sa définition XML et le compte ayant demandé l’opération. La documentation décrit aussi un identifiant de connexion utilisable pour un rapprochement avec d’autres événements. Source : Microsoft, événement 4698
L’événement 4702 concerne une modification et fournit une nouvelle définition de la tâche. Les champs effectivement disponibles doivent être vérifiés sur les versions Windows présentes dans votre environnement. Source : Microsoft, événement 4702
Notre recommandation : chercher ces événements sur la machine concernée, puis comparer les définitions successives avec l’export actuel. Documentez l’ordre des changements : remplacement du programme appelé, nouveaux arguments, modification du compte ou du déclencheur. Reliez chaque observation à sa source et à son horodatage.
Le compte qui enregistre une tâche et celui qui doit l’exécuter peuvent différer. Conservez ces identités séparément. Un compte d’administration ou de déploiement légitime demande lui aussi une vérification du changement attendu.
Si les événements manquent, contrôlez l’audit, la collecte et la rétention avant de conclure. Leur absence dans votre outil ne démontre pas qu’aucune création ou modification n’a eu lieu.
Corroborer l’exécution et ses effets
La définition indique une intention de lancement. Recherchez une observation d’exécution dans les données disponibles : historique du planificateur, processus du terminal ou télémétrie de votre outil de protection. Vérifiez le poste, l’heure, le compte, le programme et les arguments conservés.
Microsoft documente l’événement 4688 pour la création d’un processus. La présence de sa ligne de commande dépend d’une stratégie de journalisation spécifique. Un champ vide ne permet donc pas d’inventer les arguments manquants. Source : Microsoft, événement 4688
Notre recommandation : rapprocher les identifiants de processus dans leur contexte temporel, car ils peuvent être réutilisés. Cherchez ensuite les effets utiles à l’hypothèse : fichier créé, connexion réseau ou autre activité du programme. Une proximité horaire seule reste un rapprochement à corroborer.
Écrivez la conclusion au niveau établi : tâche présente, modification observée, exécution corroborée ou effets confirmés. Si le lien entre tâche et processus reste incertain, indiquez la pièce nécessaire pour le renforcer.
Utiliser les outils de revue sans perdre le contexte
Autoruns permet d’examiner des emplacements de lancement automatique, notamment les tâches planifiées. Microsoft documente la vérification des signatures et des options de consultation ou d’envoi à VirusTotal. Source : Microsoft Sysinternals, Autoruns
Notre recommandation : préserver une vue complète avant d’appliquer des filtres. Une signature valide ne remplace pas l’analyse du rôle du programme, de ses arguments et de son contexte. Les éventuels envois vers un service externe doivent respecter les règles de partage de votre organisation.
Pour préparer votre SOC, testez ce parcours dans un environnement autorisé avec une tâche bénigne connue. Faites vérifier par un second analyste la distinction entre définition actuelle, historique et exécution. Le résultat attendu est une fiche reproductible : sources consultées, correspondances établies, limites restantes et décision humaine justifiée.