Geplante Aufgaben im Browser analysieren: Fallbeispiel

Kurz gesagt. Sichern Sie System32\Tasks, SysWOW64\Tasks, C:\Windows\Tasks und den SOFTWARE-Hive (mit .LOG1/.LOG2), ziehen Sie die Dateien oder das Triage-ZIP in den Scheduled Tasks Parser, lesen Sie die Warnungen, bestätigen Sie den abgeleiteten UTC-Offset und arbeiten Sie dann die Befunde ab: zuerst Aufgaben nur in der Registry, fehlendes SD, Hash-Abweichungen, danach Pfade, kodierte Befehle, LOLBins und Privilegien. Exportieren Sie als CSV, JSON oder Timeline-CSV. Nichts verlässt den Browser. Der fiktive Fall unten, identisch mit dem eingebauten Beispiel, zeigt jeden Schritt.

Dies ist das Praxisbegleitstück zum Leitfaden zur Forensik geplanter Aufgaben. Die Sicherung behandelt Speicherorte geplanter Aufgaben und Sicherung.

Was das Werkzeug kann und was nicht

Der Parser ist in Rust geschrieben, nach WebAssembly kompiliert und läuft in einem Web Worker in Ihrem Browser. Dateien werden lokal gelesen und nie hochgeladen. Er:

• liest Task-XML (UTF-16LE, Schema 1.2 und neuer): RegistrationInfo, alle Trigger-Typen, Prinzipale, Einstellungen und die Aktionen Exec/ComHandler/SendEmail/ShowMessage;
• liest alte .job-Dateien: festen und variablen Abschnitt, Trigger, letzte Ausführungszeit wie gespeichert (lokale SYSTEMTIME);
• liest den TaskCache aus dem SOFTWARE-Hive: Tree (Id, Index, SD dekodiert als SDDL, Zeitpunkte des letzten Schreibzugriffs auf die Schlüssel) und Tasks\{GUID} (Path, URI, Author, Date, Hash, Schema, DynamicInfo, dekodierte Actions, Header von Triggers und Prinzipal);
• korreliert XML und TaskCache über den Pfad, berechnet den Hash neu und markiert Aufgaben, die nur in der Registry, nur auf dem Datenträger oder ohne SD existieren;
• warnt, wenn der Hive dirty ist. Er spielt keine Transaktionsprotokolle ein, carvt keine gelöschten Schlüssel und wertet keine Ereignisprotokolle aus.

Befunde sind Heuristiken, die Ihre Prüfung ordnen, keine Urteile.

Der fiktive Fall

Alles Folgende ist für Schulungszwecke erfunden: Host, Konto, Adressen und Dateien existieren nicht, und die Befehle sind harmlose Platzhalter. Es ist genau das Beispiel, das Sie auf der Startseite über Try a sample laden, sodass Sie mitlesen und mitklicken können.

Ein Arbeitsplatz in der Finanzabteilung, FIN-WKS-07, eingestellt auf die Zeitzone UTC+02:00. Am 2026-09-14 schlägt ein Alarm wegen ungewöhnlichen ausgehenden Datenverkehrs an. Andere Artefakte zeigen ein Konto, das niemand kennt: svc_backup. Die Frage für diesen Schritt: Hat der Eindringling geplante Aufgaben hinterlassen, und was hat er zwischen 10:00 und 10:55 UTC getan?

Schritt 1: Task-Ordner und SOFTWARE-Hive sichern

Die Sicherung folgt der KAPE-Struktur, wie sie dieser Aufruf erzeugt:

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

Das resultierende ZIP enthält C/Windows/System32/Tasks (19 XML-Dateien), C/Windows/Tasks (eine .job-Datei) und C/Windows/System32/config/SOFTWARE. Eine Velociraptor-Sammlung Windows.Triage.Targets mit denselben Targets funktioniert genauso. Hashen Sie das Archiv, bevor Sie beginnen.

Schritt 2: Dateien im Browser laden

Öffnen Sie das Werkzeug und ziehen Sie das ZIP hinein. Sie können auch einzelne Dateien oder einen Ordner ablegen. Der Parser durchläuft das Archiv (KAPE-Struktur oder Velociraptor-Struktur mit prozentkodierten Pfaden und Einträgen mit Backslash im Namen), wählt die Task-Dateien und den SOFTWARE-Hive aus und ignoriert den Rest. Das dauert ein bis zwei Sekunden.

Die Übersichtsleiste zeigt für das Beispiel: 21 Aufgaben (19 XML, 1 .job, 16 damit zusammengeführte TaskCache-Einträge), 8 markiert, 1 versteckt (kein SD), 1 nur in der Registry, 1 nur als XML, 5 kürzlich registriert.

Schritt 3: Warnungen lesen

Bevor Sie irgendetwas über eine „fehlende“ Aufgabe schließen, lesen Sie die Warnungen des Parsers:

Der Hive im Beispiel ist sauber: keine Dirty-Hive-Warnung, daher lassen sich die Befunde „nur in der Registry“ und „nur als XML“ beim Wort nehmen. Bei einer Live-Sicherung sehen Sie die Warnung häufig; spielen Sie dann die Protokolle ein, bevor Sie Abwesenheiten trauen.

Schritt 4: Zeitzone prüfen

Die XML-Werte Date und StartBoundary sind meist Ortszeit ohne Offset (warum). Der Parser vergleicht das XML-Date jeder Aufgabe mit der UTC-Erstellungs-FILETIME in DynamicInfo derselben Aufgabe und zählt die gefundenen Offsets. Für das Beispiel meldet er UTC+02:00 ×4, UTC+01:00 ×1 und wendet +02:00 an. Zwei der Vergleiche:

Der Ausreißer ist kein Fehler: Der Edge-Updater wurde im März unter Winterzeit (MEZ, UTC+01:00) registriert, die Aufgaben vom September unter Sommerzeit (MESZ, UTC+02:00). Deshalb kann ein einziger Offset, auf einen ganzen Rechner angewendet, für ältere Aufgaben falsch sein. In diesem Fall wurden alle relevanten Aufgaben am 2026-09-14 registriert, +02:00 ist also richtig. Ab jetzt wird jede Zeit in UTC angezeigt.

Schritt 5: Befunde sichten

Sortieren Sie nach Schweregrad. Von den 21 Aufgaben sind 13 gewöhnliche Aufgaben von Microsoft, Office, Edge und der Feed-Synchronisierung ohne Befund. Zwei weitere sind markiert, aber harmlos; es lohnt sich, sie zur Kalibrierung zuerst zu lesen:

• \GoogleUpdateTaskMachineUA: Erhöhte Rechte, nicht Microsoft. Sie läuft als SYSTEM und hat keinen Autor. So registriert sich der Updater von Google.
• \OneDrive Standalone Update Task-S-1-5-21-…-1104: Für Benutzer beschreibbarer Pfad. Ihr Befehl liegt unter %localappdata%, wo der benutzerbezogene OneDrive-Updater zu Hause ist.

Befunde sind Hinweise, keine Urteile. Entscheidend sind die folgenden sechs Aufgaben.

\Microsoft\Windows\UPnP\UPnPHostConfigSync: versteckt, kein SD

• Als Autor ist Microsoft Corporation angegeben, und die Aufgabe liegt unter \Microsoft\Windows\, um nicht aufzufallen.
• Registriert um 10:12:40 UTC (XML-Date 2026-09-14T12:12:40.0918251 Ortszeit).
• Prinzipal: SYSTEM, HighestAvailable. Trigger: LogonTrigger und ein TimeTrigger ab 12:12:40 Ortszeit, Wiederholung alle 30 Minuten (PT30M).
• Aktion: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -EncodedCommand VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAHMAeQBuAHQAaABlAHQAaQBjACAAcwBhAG0AcABsAGUAJwA=, vom Parser dekodiert als Write-Output 'synthetic sample' (ein Platzhalter für ein echtes Skript).
• TaskCache: Der Tree-Schlüssel hat Id und Index = 2, aber keinen Wert SD. Sein letzter Schreibzugriff liegt bei 10:13:05 UTC, 25 Sekunden nach der Registrierung.
• DynamicInfo: letzte Ausführung 10:42:40 UTC, letzte erfolgreiche Ausführung 10:42:41 UTC.

Befunde: Versteckt: kein SD im TaskCache (kritisch), Kodiertes PowerShell (hoch), Kürzlich registriert. Das ist das Tarrask-Muster: Auf dem laufenden System würde schtasks /query die Aufgabe nicht auflisten. Der Schreibzugriff auf den Schlüssel 25 Sekunden nach der Registrierung passt dazu, dass das SD um 10:13 entfernt wurde, was zugleich bedeutet, dass der Eindringling zu diesem Zeitpunkt SYSTEM-Rechte hatte.

\IntelGfxTelemetry: Hidden-Einstellung, SYSTEM, beschreibbarer Pfad

• Autor FIN-WKS-07\svc_backup, Beschreibung „Intel graphics telemetry“, Stammordner.
• Registriert um 10:09:58 UTC. Prinzipal: S-1-5-18, HighestAvailable. <Hidden>true</Hidden>.
• Trigger: BootTrigger und ein TimeTrigger ab 12:15:00 Ortszeit (10:15 UTC), stündlich.
• Aktion: C:\ProgramData\Intel\m64.exe -svc.
• DynamicInfo: letzte Ausführung 10:15:00 UTC, letztes Ergebnis 0x00041301 (SCHED_S_TASK_RUNNING: Das Programm lief zum Zeitpunkt der Sicherung noch).

Befunde: Für Benutzer beschreibbarer Pfad, Erhöhte Rechte, nicht Microsoft, Hidden-Einstellung, Kürzlich registriert. Anders als die UPnP-Aufgabe behält sie ihr SD: Sie ist nur in der Standardansicht der Konsole verborgen, nicht vor schtasks.

\a8Xq2LmZ: Definition nach der Registrierung geändert

• Zufällig wirkender Name im Stammordner, registriert um 10:21:30 UTC von svc_backup, ausgeführt als svc_backup (InteractiveToken, LeastPrivilege) bei dessen Anmeldung.
• TaskCache-Actions: C:\Windows\System32\rundll32.exe C:\Users\svc_backup\Downloads\tools\helper.dll,Init.
• XML auf dem Datenträger: derselbe Befehl mit helper.dll,Start. Der Hash im TaskCache passt nicht mehr zur Datei.
• DynamicInfo: letzte Ausführung 10:24:02 UTC.

Befunde: XML nach der Registrierung geändert und Registry-Aktion weicht vom XML ab (hoch), LOLBin, Für Benutzer beschreibbarer Pfad, Zufällig wirkender Name, Kürzlich registriert. Jemand hat die XML-Datei direkt bearbeitet, statt die Aufgabe neu zu registrieren, daher hält der Dienst noch die registrierte Fassung. Lesen Sie beide: Die Registry sagt, was registriert wurde, die Datei, wie es danach aussehen sollte.

\Microsoft\Windows\Maintenance\CleanupTemp: nie registriert

• Nur eine XML-Datei: überhaupt kein TaskCache-Eintrag.
• Als Autor ist Microsoft Corporation angegeben; Date 12:31:05 Ortszeit (10:31:05 UTC mit dem Offset +02:00); Hidden=true; Prinzipal svc_backup; TimeTrigger um 12:35 Ortszeit.
• Aktion: C:\Windows\System32\mshta.exe C:\Users\svc_backup\Downloads\tools\cleanup.hta.

Befunde: Nicht registriert (mittel), LOLBin, Für Benutzer beschreibbarer Pfad, Kürzlich registriert. Eine in den Tasks-Ordner gelegte Datei ist erst dann eine Aufgabe, wenn der Dienst sie registriert. Da der Hive sauber ist, hat das Fehlen im TaskCache Aussagekraft: Diese Aufgabe wurde vorbereitet, nach dieser Beweislage aber nie eingeplant.

\SyncBackup: nur in der Registry

• Keine XML-Datei auf dem Datenträger; der TaskCache enthält noch Tree und Tasks\{GUID}.
• TaskCache-Date 2026-09-14T12:44:10.2059113 (Ortszeit); DynamicInfo erstellt 10:44:10 UTC, letzte Ausführung 10:47:12 UTC, letzte erfolgreiche Ausführung 10:53:51 UTC, Ergebnis 0.
• Dekodierte Actions: C:\Users\Public\rclone.exe copy C:\Users\Public\data E:\exfil.
• Header von Triggers: Startgrenze 2026-09-14T12:47:00 Ortszeit, Prinzipal-SID endet auf -1119 (svc_backup).

Befunde: XML-Datei fehlt (hoch), Für Benutzer beschreibbarer Pfad, Kürzlich registriert. Die Datei wurde gelöscht, die Aufgabe aber nie abgemeldet, sodass sie auf dem laufenden System weiterhin in schtasks erscheinen würde. Die Registry ist die einzige erhaltene Definition, und sie verweist auf ein Kopierwerkzeug, das nach E:\exfil schreibt, ein Laufwerk, das es zu identifizieren gilt.

\Cleanup: eine alte .job-Datei

• Datei: C:\Windows\Tasks\Cleanup.job, Autor FIN-WKS-07\svc_backup.
• Befehl: cmd.exe /c del /q C:\Users\svc_backup\Desktop\creds.txt.
• Trigger: einmalig, 12:52 Ortszeit. Letzte Ausführung: 2026-09-14 12:52:30 Ortszeit (10:52:30 UTC), Status 0x00041305 (SCHED_S_TASK_NOT_SCHEDULED: keine weiteren Ausführungen geplant).

Befunde: Alte .job-Datei, Für Benutzer beschreibbarer Pfad. Eine .job-Datei auf einem modernen System ist schon für sich ungewöhnlich; diese löscht am Ende der Sitzung eine Datei vom Desktop des Kontos, was nach Aufräumen aussieht.

Schritt 6: Zeitraum eingrenzen und exportieren

Öffnen Sie \SyncBackup und zentrieren Sie den Zeitraum mit plus oder minus 1 Stunde darauf. Das Werkzeug zentriert auf den ersten Zeitpunkt der Aufgabe, ihre Registrierung um 10:44:10 UTC, das Fenster reicht also von 09:44:10 bis 11:44:10 UTC. Der Dichtestreifen zeigt die Häufung zwischen 10:09 und 10:54; die dreizehn Baseline-Aufgaben fallen weg. Sie können auch Von 2026-09-14 10:00:00 und Bis 10:55:00 UTC sekundengenau eingeben.

Exportieren Sie die gefilterte Ansicht als CSV, JSON oder als Timeline-CSV, deren Spalten message, datetime und timestamp_desc sich direkt in Timesketch importieren lassen. Der rekonstruierte Ablauf, alle Zeiten in UTC:

Nächste Schritte außerhalb dieses Werkzeugs: die Ausführung von m64.exe, rclone.exe und rundll32.exe mit Prefetch und Amcache bestätigen, in den Ereignisprotokollen nach 4698/106 und 200/201 suchen, das Volume E: identifizieren, helper.dll und cleanup.hta sicherstellen und herausfinden, wie svc_backup an SYSTEM-Rechte kam. Die Indikator-Checkliste hinter diesen Befunden steht in bösartige geplante Aufgaben erkennen.