Task Scheduler : poisoning et altération des journaux d'événements

Le Planificateur de tâches Windows (Task Scheduler) journalise la création de chaque tâche, notamment via l'Event Log 4698 ("Task Created"), un signal exploité par de nombreuses équipes de détection pour repérer une persistance suspecte. Ces travaux documentent deux techniques distinctes de Defense Evasion qui s'attaquent directement à la fiabilité de ce journal.

La première technique permet, en créant une tâche à partir d'un fichier XML, d'empoisonner le champ "Author" des métadonnées de la tâche avec une valeur arbitraire, faussant les métadonnées de la tâche et l'Event Log 4698.

La seconde exploite un buffer alloué sans limite dans ce même champ "Author" : la valeur injectée écrase l'intégralité de la description du journal d'événements Windows qui la traite ensuite. L'exploitation peut aussi être déclenchée à distance, en modifiant le champ Author dans le fichier XML envoyé via RPC (notamment via impacket-atexec).

Pourquoi c'est significatif

Un attaquant qui contrôle le contenu du journal d'audit n'a plus besoin de l'effacer pour brouiller une investigation : falsifier une entrée ou saturer un champ jusqu'à écraser les données utiles (commande exécutée, arguments) suffit à rendre le journal inexploitable pour une équipe de réponse à incident, sans déclencher les alertes associées à une suppression de logs.

Divulgation responsable

Ces vulnérabilités ont été documentées dans le cadre d'une recherche en sécurité, à des fins éducatives et de sensibilisation.

Ressource technique complète (dépôt GitHub)

Source : github.com/rubenformation/TaskScheduler-Logs-Tampering.

Description

Two new Defense Evasion techniques have been discovered.

The first vulnerability affects Task metadata and Event Log 4698 ("Task Created"), allowing an attacker to create a task from an XML file and poison the "Author" entry with arbitrary data.

The second vulnerability leverages an unlimited allocated buffer in the "Author" task metadata field, which is later handled by the Windows Event Log, overwriting the entire log description. The exploit can also be triggered remotely by patching the Author entry in the XML file sent over RPC via impacket-atexec.

Requirements

• Batch Logon rights on the task principal for the task to actually run (otherwise the metadata / event log is still poisoned or overwritten, but the task itself won't run).
• The password of the task principal, if the user creating the task is not an admin or doesn't hold SeImpersonate privileges.
• The security policy "Audit Other Object Access Events" enabled.

Commands

Remote

# Replace the original impacket-atexec script with the modified version, and run it with the original arguments.
# To poison the log with a fake Author entry, change the buffer in the XML file to the desired data, e.g. "Microsoft Corporation".
impacket-atexec [[domain/]username[:password]@]<targetName or address> command

Task poisoning (metadata / event log)

# Run this to check whether the INJECTED-DATA author name has been set in the task description.
schtasks /create /tn poc /xml poc-poisoning.xml /ru <username> /rp <password> /f

# Check whether the data was injected by querying the task. If the author name is INJECTED-DATA, the target is vulnerable.
schtasks /query /tn poc /xml | findstr /i author

Task event log overflow

# Run this to check whether the 3500+ byte payload was injected into Event Log 4698.
# If this log type isn't enabled on your machine and you still want to test it, enable it under:
# Local Security Policy -> Advanced Audit Policy Configuration -> System Audit Policies - Local Group Policy Object -> Object Access -> Audit Other Object Access Events -> Success
schtasks /create /tn poc /xml poc-overflow.xml /ru <username> /rp <password> /f

Log check

# Check the task log with the following PowerShell command. If the <RegistrationInfo> tag contains a 3500-byte buffer instead of the executed command and its arguments, the target is vulnerable.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4698} | Where-Object { $_.Message -like '*poc*' } | Select-Object -First 1 | Format-List TimeCreated, Message

Notes

This code is for educational and research purposes only. The author takes no responsibility for any misuse of this code.

Ce qu'il faut retenir

• Un journal d'événements n'est fiable que si ses champs le sont : une métadonnée non validée (comme "Author") est une surface d'attaque à part entière.
• La détection basée uniquement sur la présence d'un log (plutôt que sur son contenu) peut être trompée sans jamais supprimer ni désactiver l'audit.
• Surveiller les créations de tâches planifiées reste utile, mais ne suffit pas si le contenu du journal lui-même peut être manipulé.

Vous voulez évaluer la fiabilité de vos journaux d'audit face à ce type de manipulation ? Parlons-en.