Forensik geplanter Aufgaben in Windows: Der Leitfaden

Kurz gesagt. Eine geplante Aufgabe unter Windows hinterlässt bis zu vier Arten von Spuren: eine XML-Definition in C:\Windows\System32\Tasks, eine Registry-Kopie im SOFTWARE-Hive unter TaskCache, manchmal eine alte .job-Datei in C:\Windows\Tasks und Einträge in Ereignisprotokollen (Security 4698 bis 4702, TaskScheduler/Operational 106, 140, 141, 200, 201). Sichern Sie alles, ordnen Sie XML und Registry über den Aufgabenpfad einander zu, vergleichen Sie beide und behandeln Sie jedes verdächtige Attribut als Spur, die zu prüfen ist, nicht als Urteil.

Geplante Aufgaben gehören zu den häufigsten Persistenzmechanismen unter Windows. MITRE ATT&CK führt sie als T1053.005 Scheduled Task, eingesetzt für Persistenz, Ausführung und Rechteausweitung. Gleichzeitig sind sie schon auf einem sauberen System eine der lautesten Stellen: Eine frische Windows-11-Installation registriert deutlich mehr als hundert Microsoft-Aufgaben. Die Aufgabe des Ermittlers besteht darin, die wenigen zu finden, die nicht dorthin gehören, und sie zeitlich einzuordnen.

Dieser Leitfaden ist der Einstieg in die Serie. Jeder Abschnitt verweist auf einen vertiefenden Artikel.

Die vier Spurenquellen

Das XML-Schema dokumentiert Microsoft in der Referenz Task Scheduler Schema. Registry-Layout und .job-Format sind nur teilweise dokumentiert: Das .job-Format ist in MS-TSCH spezifiziert, die Binärwerte in TaskCache kennt man dagegen vor allem aus Reverse Engineering der Community, insbesondere aus der TaskCache-Analyse von cyber.wtf und aus libyals winreg-kb.

Wo die einzelnen Dateien unter jeder Windows-Version liegen und wie Sie sie ohne Datenverlust sichern, beschreibt wo geplante Aufgaben gespeichert sind und wie Sie sie sichern.

Warum die Registry so wichtig ist wie das XML

Viele Checklisten hören beim XML-Ordner auf. Das reicht nicht. Der Aufgabenplanungsdienst führt eine eigene Kopie jeder registrierten Aufgabe im Schlüssel TaskCache des SOFTWARE-Hives, aufgeteilt in zwei Bereiche:

• Tree\<task path> enthält pro Aufgabe einen Schlüssel, benannt wie die Aufgabe, mit einem Wert Id (die GUID der Aufgabe), einem Index und einem Wert SD, dem Sicherheitsdeskriptor, der festlegt, wer die Aufgabe sehen und ändern darf.
• Tasks\{GUID} enthält die Aufgabendaten: Path, URI, Author, Date, Hash, Actions, Triggers und DynamicInfo, einen Binärwert mit Erstellungszeit, letzter Ausführung und letztem Ergebnis der Aufgabe.

Daraus folgen drei Konsequenzen für eine Untersuchung:

1. Das Löschen der XML-Datei hebt die Registrierung nicht auf. Der Registry-Eintrag und oft auch die Aufgabe selbst bleiben bestehen. Eine Aufgabe, die nur in TaskCache existiert, verdient einen genauen Blick.
2. Das Entfernen des Werts SD versteckt die Aufgabe vor schtasks /query und der Aufgabenplanungskonsole. Genau diese Technik hat Microsoft im April 2022 für die Malware Tarrask beschrieben. Siehe Tarrask und versteckte geplante Aufgaben.
3. Die Registry enthält Ausführungsmetadaten, die im XML fehlen. DynamicInfo hält fest, wann die Aufgabe angelegt wurde und zuletzt lief, sowie den letzten Ergebniscode. Das XML tut das nie.

Zeit und die Falle im XML

Das Date in RegistrationInfo und die StartBoundary der Trigger sind XML-Werte vom Typ dateTime. Die API von Microsoft akzeptiert einen UTC-Offset (YYYY-MM-DDTHH:MM:SS(+-)HH:MM, siehe Trigger.StartBoundary), doch Aufgaben, die über die Konsole oder schtasks angelegt wurden, speichern meist überhaupt keinen Offset: Der Wert steht in der lokalen Zeit des Rechners. Microsofts eigenes Beispiel zu Ereignis 4698 zeigt das: Das Ereignis wird um 2015-09-23T02:03:06Z protokolliert, während das eingebettete Task-XML <Date>2015-09-22T19:03:06.9258653</Date> angibt, sieben Stunden früher, auf einem Rechner in einer Zeitzone UTC-7.

TaskCache-Zeitstempel (DynamicInfo, Zeitpunkte des letzten Schreibzugriffs auf Schlüssel) sind FILETIMEs in UTC. Beide Werte für dieselbe Aufgabe zu vergleichen ist der einfachste Weg, den Offset des Rechners abzuleiten. Mehr dazu in Aufbau des Task-XML und im Glossareintrag StartBoundary.

Ereignisprotokolle: nützlich, wenn es sie gibt

Die Security-Ereignisse setzen die Unterkategorie Audit Other Object Access Events voraus, die auf den meisten Arbeitsplatzrechnern standardmäßig nicht aktiviert ist. Der Operational-Kanal ist der, den der Schalter "Enable All Tasks History" in der Aufgabenplanungskonsole steuert; auf vielen Systemen ist er aus oder hat nur eine kurze Vorhaltezeit. Werten Sie fehlende Ereignisse als "nicht protokolliert", nicht als "nicht passiert". Forscher haben außerdem gezeigt, dass Aufgaben, die direkt in die Registry geschrieben werden, sowohl 4698 als auch 106 vollständig umgehen können (Binary Defense). Wenn Sie die Protokolle haben, werten Sie sie mit dem EVTX Parser aus und legen Sie sie neben die Aufgabendaten.

Worauf Sie achten sollten

Eine kurze Liste, ausführlich behandelt in bösartige geplante Aufgaben erkennen:

• Befehle in für Benutzer beschreibbaren Ordnern: C:\Users\Public, C:\ProgramData, %TEMP%, AppData.
• Kodierte PowerShell (-EncodedCommand) sowie Skript-Hosts oder LOLBins wie rundll32, regsvr32, mshta, certutil.
• Nicht von Microsoft stammende Aufgaben, die als SYSTEM oder mit HighestAvailable laufen.
• Aufgaben im Stammordner der Bibliothek oder mit zufällig wirkenden Namen, ein Muster, auf das Microsofts eigene Überwachungsempfehlungen hinweisen.
• Versteckte Aufgaben (<Hidden>true</Hidden>) eines Autors außerhalb von Microsoft und TaskCache-Einträge ohne SD-Wert.
• Abweichungen: XML vorhanden, aber kein Registry-Eintrag, Registry-Eintrag ohne XML oder ein Hash, der nicht zum XML auf dem Datenträger passt.
• Junge Registrierungsdaten nahe am Zeitfenster des Vorfalls.

Für jeden Punkt gibt es harmlose Erklärungen. Updater von Herstellern liegen in ProgramData, IT-Skripte nutzen -EncodedCommand. Die Merkmale grenzen die Suche ein; entscheiden muss Ihre Gegenprüfung.

Ein belastbarer Ablauf

1. Sichern Sie C:\Windows\System32\Tasks (rekursiv), C:\Windows\SysWOW64\Tasks, C:\Windows\Tasks, den SOFTWARE-Hive mit seinen Transaktionsprotokollen .LOG1/.LOG2 sowie die Protokolle Security und TaskScheduler/Operational. Die KAPE-Targets ScheduledTasks und RegistryHivesSystem decken Dateien und Hives ab (KapeFiles).
2. Parsen Sie XML, .job und TaskCache gemeinsam und ordnen Sie jede XML-Datei über den Aufgabenpfad ihrem TaskCache-Eintrag zu.
3. Prüfen Sie die Integrität: Aufgaben nur in der Registry, nur auf dem Datenträger, fehlender SD, abweichende Hashes und ob der Hive beim Kopieren dirty war.
4. Normalisieren Sie die Zeit: Leiten Sie den UTC-Offset für XML-Zeiten ohne Zeitzone ab oder legen Sie ihn fest; lassen Sie die FILETIMEs der Registry in UTC.
5. Sichten Sie mit der Liste verdächtiger Attribute oben und belegen Sie Befunde anschließend mit Ausführungsspuren (Prefetch, Amcache) und Ereignisprotokollen.

Der Scheduled Tasks Parser erledigt die Schritte 2 bis 4 im Browser: Ziehen Sie die Ordner, den Hive oder ein KAPE- bzw. Velociraptor-ZIP hinein, und er ordnet XML und TaskCache einander zu, prüft Hashes, markiert versteckte und nur in der Registry vorhandene Aufgaben und exportiert CSV oder JSON. Es wird nichts hochgeladen. Die Schritt-für-Schritt-Anleitung steht in geplante Aufgaben im Browser analysieren.

FAQ

Wo speichert Windows geplante Aufgaben?

An drei Stellen: eine XML-Definition pro Aufgabe unter C:\Windows\System32\Tasks, eine Kopie in der Registry unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache und, nur bei Legacy-Aufgaben, binäre .job-Dateien in C:\Windows\Tasks.

Ist die XML-Datei oder die Registry die maßgebliche Quelle?

Ab Windows 8 arbeitet der Aufgabenplanungsdienst mit den TaskCache-Daten aus der Registry; die XML-Dateien werden damit synchron gehalten. Eine Aufgabe kann in der Registry weiterbestehen, nachdem ihre XML-Datei gelöscht wurde. Sichern und vergleichen Sie deshalb immer beides.

Welche Ereignis-IDs protokollieren das Anlegen geplanter Aufgaben?

Security 4698 (angelegt, mit dem vollständigen Task-XML), 4699 (gelöscht), 4700 (aktiviert), 4701 (deaktiviert) und 4702 (aktualisiert), die die Richtlinie Audit Other Object Access Events voraussetzen; außerdem TaskScheduler/Operational 106 (registriert), 140 (aktualisiert), 141 (gelöscht), 200 (Aktion gestartet) und 201 (Aktion abgeschlossen).

Weiterführende Literatur

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