XML geplanter Aufgaben erklärt, Element für Element
Task-XML lesen wie ein Forensiker: RegistrationInfo, Triggers, Principals, Settings und Actions sowie die Ortszeiten ohne Zeitzone in Date und StartBoundary.
Kurz gesagt. Ein Task-XML hat fünf Abschnitte, auf die es ankommt: RegistrationInfo (wer und wann, laut eigener Angabe), Triggers (wann die Aufgabe auslöst), Principals (welches Konto, welche Rechte), Settings (versteckt, aktiviert, Limits) und Actions (was ausgeführt wird). Zwei Fallen: Date und StartBoundary sind meist Ortszeit ohne Offset, und Author ist Freitext. Lesen Sie die Datei als Sammlung von Behauptungen und prüfen Sie diese gegen TaskCache und die Ereignisprotokolle.
Das Format dokumentiert Microsoft im Task Scheduler Schema, mit dem Namespace http://schemas.microsoft.com/windows/2004/02/mit/task. Dieser Artikel liest es aus der Sicht eines Ermittlers. Wo die Dateien liegen, steht in Speicherorte und Sicherung geplanter Aufgaben.
Ein minimales Beispiel
Eine mit schtasks auf einem Arbeitsplatzrechner registrierte Aufgabe sieht typischerweise so aus. Das Beispiel ist ein gekürzter Auszug aus dem fiktiven Beispielsystem FIN-WKS-07, das auf dieser Website durchgängig verwendet wird und auf UTC+02:00 eingestellt ist:
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2026-09-14T12:09:58.4413872</Date>
<Author>FIN-WKS-07\svc_backup</Author>
<Description>Intel graphics telemetry</Description>
<URI>\IntelGfxTelemetry</URI>
</RegistrationInfo>
<Triggers>
<BootTrigger><Enabled>true</Enabled></BootTrigger>
<TimeTrigger>
<Repetition><Interval>PT1H</Interval></Repetition>
<StartBoundary>2026-09-14T12:15:00</StartBoundary>
<Enabled>true</Enabled>
</TimeTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>S-1-5-18</UserId>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<Hidden>true</Hidden>
<Enabled>true</Enabled>
</Settings>
<Actions Context="Author">
<Exec>
<Command>C:\ProgramData\Intel\m64.exe</Command>
<Arguments>-svc</Arguments>
</Exec>
</Actions>
</Task>
Die Datei auf dem Datenträger ist meist UTF-16LE mit Byte Order Mark, auch wenn die XML-Deklaration manchmal als UTF-8 herumkopiert wird. Ein Parser, der UTF-8 annimmt, zeigt Zeichensalat; schon das ist ein Grund, ein Werkzeug zu verwenden, das für dieses Format gebaut ist.
RegistrationInfo: die behaupteten Metadaten
| Element | Was es aussagt | Wie weit man ihm trauen kann |
|---|---|---|
URI | Aufgabenpfad in der Bibliothek, z. B. \Microsoft\Windows\Defrag\ScheduledDefrag | Sollte zum Dateipfad und zum Tree-Schlüssel in TaskCache passen; eine Abweichung ist festzuhalten |
Author | Wer die Aufgabe registriert hat | Freitext. Konsole und schtasks schreiben DOMAIN\user; Installer tragen oft einen Herstellernamen ein; manche Microsoft-Aufgaben verwenden einen Ressourcenverweis wie $(@%SystemRoot%\system32\...) |
Date | Registrierungsdatum | Meist Ortszeit, ohne Offset (siehe unten) |
Description | Beschreibung für Menschen | Freitext; Angreifer kopieren Formulierungen von Microsoft |
SecurityDescriptor | Optionale SDDL für die Aufgabe | Im XML selten; maßgeblich ist der Wert SD in TaskCache |
Source, Version, Documentation | Optional | Gelegentlich hilfreich, um einen Hersteller zuzuordnen |
Praxisnotizen wie Psmths' Windows forensic artifacts weisen darauf hin, dass der Author einer remote angelegten Aufgabe das auslösende Konto verraten kann. Nichts hindert jedoch einen XML-Import daran, einen gefälschten Autor mitzubringen. Vergleichen Sie mit dem SubjectUserName von Ereignis 4698 oder 106, sofern vorhanden.
Triggers: wann die Aufgabe auslöst
Das Schema erlaubt bis zu 48 Trigger pro Aufgabe: BootTrigger, LogonTrigger, RegistrationTrigger, IdleTrigger, TimeTrigger, CalendarTrigger, EventTrigger und SessionStateChangeTrigger. Alle teilen sich Enabled, StartBoundary, EndBoundary, Repetition und ExecutionTimeLimit.
Lesart für die Ermittlung:
- Boot- und Logon-Trigger sind klassische Persistenz. Ein
LogonTriggerohneUserIdlöst für jeden Benutzer aus. - RegistrationTrigger löst einmal bei der Registrierung der Aufgabe aus: ein verbreiteter Weg, etwas sofort auszuführen und dabei wie ein geplanter Job auszusehen.
- TimeTrigger mit kurzem
Repetition-Intervall (zum BeispielPT5M) ist ein Beacon-ähnliches Muster. - EventTrigger trägt eine XPath-Abfrage in
Subscription; damit kann eine Aufgabe bei einer bestimmten Ereignis-ID auslösen, was leicht übersehen wird. - SessionStateChangeTrigger (
SessionUnlock,RemoteConnect) ist seltener und einen zweiten Blick wert.
Principals: welches Konto, welche Rechte
| Element | Werte | Bedeutung |
|---|---|---|
UserId | Kontoname oder SID (S-1-5-18 ist SYSTEM, S-1-5-19 LOCAL SERVICE, S-1-5-20 NETWORK SERVICE) | Der Sicherheitskontext |
GroupId | Gruppenname oder SID | Läuft für Mitglieder einer Gruppe, z. B. S-1-5-32-545 (Users) |
LogonType | InteractiveToken, Password, S4U, InteractiveTokenOrPassword | Wie das Konto angemeldet wird; siehe S4U |
RunLevel | LeastPrivilege, HighestAvailable | Ob ein Administratortoken verwendet wird; siehe Ausführungsebene |
Eine nicht von Microsoft stammende Aufgabe, die als S-1-5-18 mit HighestAvailable läuft, ist die Kombination, die Sie zuerst ansehen sollten. LogonType Password bedeutet, dass Anmeldedaten gespeichert wurden, damit die Aufgabe auch ohne angemeldeten Benutzer laufen kann; Microsofts Empfehlungen zu Ereignis 4698 raten, darauf zu alarmieren, weil ein Administrator das gespeicherte Kennwort wiederherstellen kann.
Settings: die Schalter, die verstecken oder drosseln
Zuerst lesen sollten Sie Hidden, Enabled, ExecutionTimeLimit (PT0S bedeutet kein Limit), MultipleInstancesPolicy, StartWhenAvailable, DisallowStartIfOnBatteries, WakeToRun, RunOnlyIfNetworkAvailable und DeleteExpiredTaskAfter.
Hidden=true versteckt die Aufgabe nur in der Konsole, solange "Show Hidden Tasks" nicht angehakt ist. Vor schtasks, der API oder der Registry verbirgt es sie nicht. Die wirksameren Verstecktechniken spielen sich in der Registry ab, siehe Tarrask und versteckte geplante Aufgaben. DeleteExpiredTaskAfter zusammen mit einem EndBoundary lässt eine Aufgabe sich selbst löschen: Dass sie später fehlt, beweist nicht, dass es sie nie gab.
Actions: was ausgeführt wird
| Aktion | Inhalt | Hinweise |
|---|---|---|
Exec | Command, Arguments, WorkingDirectory | Die überwiegende Mehrheit der Aufgaben |
ComHandler | ClassId (CLSID), optional Data | Führt ein COM-Objekt aus, typischerweise eine DLL, die in taskhostw.exe geladen wird; siehe COM-Handler-Aktion |
SendEmail | Server, To, Subject... | Von Microsoft abgekündigt; auf aktuellen Systemen selten |
ShowMessage | Title, Body | Abgekündigt; selten |
Das Element Actions hat ein Attribut Context, das den Principal benennt. Bis zu 32 Aktionen sind erlaubt, und sie laufen nacheinander ab. Lesen Sie also alle: Einer harmlosen ersten Aktion kann eine bösartige zweite folgen.
Bei ComHandler lösen Sie die CLSID im SOFTWARE-Hive auf (Classes\CLSID\{...}\InprocServer32), um die DLL zu finden. Eine CLSID zu kapern, die eine legitime Aufgabe bereits verwendet, ist eine unauffälligere Form der Persistenz als eine neue Aufgabe anzulegen.
Zeit: Ortszeiten ohne Zeitzone
Das Schema typisiert Date, StartBoundary und EndBoundary als xs:dateTime. Die Skript-API dokumentiert das Format YYYY-MM-DDTHH:MM:SS(+-)HH:MM mit Offset (Trigger.StartBoundary). In der Praxis speichern Aufgaben, die in der Konsole oder mit schtasks angelegt wurden, keinen Offset, und die Zeit ist die Ortszeit des Rechners beim Speichern der Aufgabe. Manche Aufgaben speichern ein Z oder einen expliziten Offset; die meisten nicht.
Das wird relevant, sobald Sie mit UTC-Quellen vergleichen. In Microsofts Beispiel zu 4698 ist das TimeCreated des Ereignisses 2015-09-23T02:03:06Z und das Date im XML 2015-09-22T19:03:06.9258653: derselbe Zeitpunkt, sieben Stunden auseinander.
Wege, den Offset zu ermitteln:
- TaskCache:
DynamicInfoenthält für dieselbe Aufgabe eine Erstellungs-FILETIME in UTC; die Differenz zuDateist der Offset, gerundet auf die nächste Viertelstunde. Siehe TaskCache-Forensik in der Registry. - SYSTEM-Hive:
TimeZoneInformationliefert die eingestellte Zeitzone; denken Sie daran, dass die Sommerzeit zum Datum des Ereignisses gilt, nicht zum Datum der Sicherung. - Ereignis 4698:
TimeCreatedin UTC gegenüber dem eingebettetenDate.
Der Scheduled Tasks Parser erledigt den ersten Weg automatisch: Er vergleicht die Registrierungsdaten im XML mit den TaskCache-FILETIMEs, schlägt einen Offset vor und lässt Sie ihn überschreiben.
StartBoundary hat eine zusätzliche Tücke: Der Wert gibt an, ab wann der Trigger aktiv wird. Das kann in der Vergangenheit liegen (Aufgaben, die "jetzt" angelegt werden, erhalten oft die Minute ihrer Erstellung) oder weit in der Zukunft. Es ist keine Ausführungszeit. Ausführungszeiten stammen aus DynamicInfo in TaskCache und aus den Ereignissen 200/201.
FAQ
In welcher Zeitzone steht das Date im XML einer geplanten Aufgabe?
Meist in keiner. Das Schema erlaubt einen Offset, doch Aufgaben, die in der Konsole oder mit schtasks angelegt wurden, speichern in der Regel die Ortszeit ohne jeden Offset. Leiten Sie den Offset aus einer UTC-Quelle ab, etwa aus TaskCache-FILETIMEs oder dem TimeCreated von Ereignis 4698, bevor Sie mit anderen Spuren vergleichen.
Beweist das Feld Author, wer die Aufgabe angelegt hat?
Nein. Author ist Freitext, geschrieben von dem, was die Aufgabe registriert hat. Die Konsole und schtasks tragen das anlegende Konto ein, ein Skript oder ein importiertes XML kann dort aber alles hineinschreiben. Behandeln Sie den Wert als Behauptung, die gegen die Ereignisprotokolle zu prüfen ist.
Was bedeutet Hidden=true?
Die Aufgabe wird in der Aufgabenplanungskonsole nicht angezeigt, solange der Benutzer Show Hidden Tasks nicht aktiviert. schtasks und die API listen sie weiterhin auf. Viele Microsoft-Aufgaben sind versteckt, relevant ist das Merkmal daher vor allem bei Aufgaben, die nicht von Microsoft stammen.