Bösartige geplante Aufgaben erkennen: Persistenz-Triage
Checkliste für bösartige geplante Aufgaben: beschreibbare Pfade, kodiertes PowerShell, LOLBins, SYSTEM, Zufallsnamen, versteckte Tasks, XML/Registry-Abweichungen.
Kurz gesagt. Bewerten Sie jede Aufgabe anhand weniger Fragen: Wo liegt der Befehl (für Benutzer beschreibbarer Pfad?), was ist er (PowerShell -EncodedCommand, rundll32, mshta, certutil...), wer führt ihn aus (SYSTEM, höchste Privilegien, bei einer Nicht-Microsoft-Aufgabe?), versteckt sie sich (Hidden, kein SD, Zufallsname, Stammordner), ist sie neu (Registrierung nahe am Vorfall) und stimmen die Kopien überein (XML gegen TaskCache, Hash). Das sind Hinweise für die Triage, keine Urteile. Belegen Sie Befunde, bevor Sie „bösartig“ schreiben.
Dieser Artikel gehört zur Untersuchungsserie und setzt voraus, dass Sie XML und TaskCache gemeinsam ausgewertet haben, wie im Leitfaden zur Forensik geplanter Aufgaben beschrieben. Geplante Aufgaben zählen in Incident-Response-Berichten durchgängig zu den am häufigsten beobachteten Persistenztechniken, etwa im Threat Detection Report von Red Canary, und MITRE führt sie als T1053.005.
Schritt 0: die Baseline aussortieren
Eine Standardinstallation von Windows bringt weit über hundert Aufgaben mit, fast alle unter \Microsoft\Windows\, viele versteckt, viele als SYSTEM. Jeder der folgenden Indikatoren schlägt bei einigen davon an. Bevor Sie nach Bösartigem suchen:
- Nach Pfad und Autor sortieren. Microsoft-Aufgaben liegen unter
\Microsoft\Windows\und haben meist Microsoft als Autor oder einen Ressourcen-String wie$(@%SystemRoot%\system32\...). - Prüfen, ob ihre Aktionen noch dorthin zeigen, wohin sie sollen: auf Binärdateien unter
%windir%\system32\...oder eineComHandler-CLSID. Wer eine bestehende Microsoft-Aufgabe verändert, behält Pfad und Autor bei und tauscht nur die Aktion aus. - Mit einem sauberen Rechner desselben Builds vergleichen, wenn möglich. Eine Aufgabe, die nicht in der Baseline vorkommt, lesen Sie zuerst.
Die Indikatoren
| Indikator | Warum relevant | Häufige False Positives |
|---|---|---|
| Befehl in einem für Benutzer beschreibbaren Pfad | Angreifer legen Payloads dort ab, wo sie schreiben dürfen | Benutzerbezogene Updater (Teams, OneDrive, Browser) |
| Kodiertes PowerShell | Verschleiert den eigentlichen Befehl | Verwaltungswerkzeuge, manche Herstellerskripte |
| LOLBin oder Skript-Host als Befehl | Signierte Binärdateien reichen die Payload durch | Admin-Skripte mit cscript, wscript |
SYSTEM oder HighestAvailable bei einer Nicht-Microsoft-Aufgabe | Persistenz mit maximalen Rechten | Sicherheitsagenten, Backup-Software, Hilfsprogramme von Treibern |
| Versteckte Nicht-Microsoft-Aufgabe | In der Konsole schlechter sichtbar | Manche Herstelleraufgaben sind versteckt |
| Tree-Eintrag ohne SD | Verstecken nach Tarrask-Art | Kaum verbreitet |
| Aufgabe nur in der Registry oder nur auf dem Datenträger | Aufräumen oder Manipulation | Dirty Hive, unvollständige Deinstallation |
| Hash-Abweichung | XML oder Registry nach der Registrierung bearbeitet | Selten; manuelle Änderungen durch Admins |
| Zufällig wirkender Name, Stammordner | Generierte oder nachlässige Benennung | Herstelleraufgaben mit GUID als Name |
| Kürzliche Registrierung | Nahe am Zeitfenster des Vorfalls | Patchday, Softwareinstallationen |
Netzwerkpfad (\\server\share) | Payload liegt auf einem entfernten System | Anmeldeskripte in verwalteten Umgebungen |
Aktion aus einer alten .job-Datei | Alte Werkzeuge auf einem modernen Betriebssystem | Sehr alte Anwendungen |
Für Benutzer beschreibbare Pfade
Sehen Sie sich den Command und Dateipfade in den Arguments an: C:\Users\Public\, C:\ProgramData\, C:\Users\<user>\AppData\ (Local, Roaming, Temp), C:\Windows\Temp\, C:\Perflogs\ und das Stammverzeichnis eines Laufwerks. C:\ProgramData\Intel\m64.exe wirkt wie ein Herstellerpfad, liegt aber in einem Ordner, in dem standardmäßig jeder Benutzer Dateien anlegen kann. Lösen Sie Umgebungsvariablen auf, bevor Sie urteilen: %LOCALAPPDATA% in einer SYSTEM-Aufgabe verweist auf das Systemprofil.
Kodiertes PowerShell
powershell.exe -EncodedCommand <base64> (oder Abkürzungen wie -enc, -e) erwartet einen Base64-String aus UTF-16LE-Text. Dekodieren Sie ihn, bevor Sie ihn lesen; wie das geht, erklärt der Glossareintrag kodiertes PowerShell. Beispiel: VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAHMAeQBuAHQAaABlAHQAaQBjACAAcwBhAG0AcABsAGUAJwA= ergibt dekodiert Write-Output 'synthetic sample'. Achten Sie auch auf -WindowStyle Hidden, -NoProfile, -ExecutionPolicy Bypass und -NonInteractive: In bösartigen Aufgaben tauchen sie oft gemeinsam auf, in legitimer Automatisierung aber ebenso. Der Scheduled Tasks Parser dekodiert kodierte Befehle für die Anzeige, sodass Sie das Skript lesen und nicht das Base64.
LOLBins und Skript-Hosts
Signierte Windows-Binärdateien, die anderen Code ausführen oder nachladen können (LOLBins): rundll32.exe, regsvr32.exe, mshta.exe, wscript.exe, cscript.exe, certutil.exe, bitsadmin.exe, msiexec.exe, cmd.exe /c und powershell.exe selbst. Das LOLBAS-Projekt dokumentiert, was jede davon kann. Eine Aufgabe mit einem dieser Befehle ist für sich genommen nicht verdächtig; entscheidend sind die Argumente. rundll32.exe C:\Users\Public\x.dll,Start ist es; rundll32.exe mit einer DLL aus System32 und Microsoft als Autor meist nicht.
Prinzipal und Privilegien
Lesen Sie UserId/GroupId, LogonType und RunLevel im XML (oder den Prinzipal aus dem Header des TaskCache-Werts Triggers, wenn das XML fehlt). S-1-5-18 (SYSTEM) mit HighestAvailable bei einer Aufgabe, deren Autor ein lokaler Benutzer ist, ist die klassische Kombination: Jemand mit Administratorrechten hat dafür gesorgt, dass etwas beim Systemstart als SYSTEM läuft. LogonType Password bedeutet, dass für die Aufgabe Anmeldedaten gespeichert wurden; Microsoft empfiehlt, darauf zu alarmieren (Hinweise zu Ereignis 4698). S4U läuft ohne gespeichertes Passwort, aber auch ohne Anmeldedaten für das Netzwerk.
Verstecken
<Hidden>true</Hidden>bei einer Nicht-Microsoft-Aufgabe.- Ein
Tree-Schlüssel ohneSDoder mit einem SD, der das Lesen verweigert: siehe Tarrask und versteckte geplante Aufgaben. - Namen, die Microsoft nachahmen (
\Microsoft\Windows\UpdateOrchestrator\...mit einer Nicht-Microsoft-Aktion), oder Zufallsstrings (\a8Xq2LmZ). - Aufgaben im Stammverzeichnis der Bibliothek: Microsofts eigene Hinweise zu 4698 nennen es ausdrücklich als Ort, an dem manuell angelegte und bösartige Aufgaben häufig landen.
Konsistenz zwischen den Kopien
Diese Prüfung lassen die meisten Triage-Skripte aus, und genau hier spielt die Offline-Auswertung ihre Stärke aus:
- TaskCache ohne XML: Die Datei wurde gelöscht, die Aufgabe aber nicht abgemeldet. Dekodieren Sie das
Actions-Blob. - XML ohne TaskCache: abgelegt, aber nie registriert, oder die Registry wurde bereinigt; prüfen Sie zuerst den Zustand des Hives.
- Hash-Abweichung: Der
Hashpasst nicht mehr zum XML. Eine der Kopien wurde am Dienst vorbei bearbeitet. - Abweichende Aktion: Das XML nennt einen Befehl, das
Actions-Blob einen anderen.
Zeitpunkte
Vergleichen Sie die Registrierung (Date mit dem richtigen UTC-Offset, Erstellungszeit in DynamicInfo) mit dem Zeitfenster des Vorfalls und sehen Sie sich letzte Ausführung und letztes Ergebnis in DynamicInfo an. Eine Aufgabe, die zwanzig Minuten nach einer verdächtigen Anmeldung registriert wurde und zuletzt erfolgreich lief, ist interessanter als eine vom Installationstag. Denken Sie daran, dass Datumsangaben im XML meist Ortszeiten ohne Zeitzone sind: siehe Aufbau des Task-XML.
Erst belegen, dann urteilen
Eine markierte Aufgabe ist eine Hypothese. Folgende Spuren bestätigen oder widerlegen sie:
- Lief sie? Letzte Ausführung und Ergebnis in
DynamicInfo; TaskScheduler/Operational 200 und 201; Prefetch für den Befehl; Amcache für den Hash der Binärdatei und ihre erste Ausführung. - Wer hat sie angelegt? Security 4698 (mit dem XML) und TaskScheduler/Operational 106, sofern protokolliert. Der EVTX-Parser und sein Artikel zu Persistenz über geplante Aufgaben und Ereignis 4698 decken diese Seite ab.
- Was ist die Binärdatei? Hashen Sie sie, prüfen Sie die Signatur und sehen Sie sich die Zeitstempel in
$MFTund im USN-Journal rund um den Registrierungszeitpunkt an. - Gibt es sie auf anderen Rechnern? Dieselbe Aufgabe auf fünfzig Arbeitsplätzen ist Softwareverteilung; auf einem einzigen ist sie interessant.
Formulieren Sie Befunde als Beobachtungen: „Aufgabe \Microsoft\Windows\UPnP\UPnPHostConfigSync führt powershell.exe mit einem kodierten Befehl, der zu ... dekodiert, als SYSTEM aus, registriert am 2026-09-14 um 10:12:40 UTC, letzte erfolgreiche Ausführung 10:42:41 UTC“. Das Wort „bösartig“ sollte erst die Bestätigung durch weitere Spuren tragen.
Ein fiktives Beispiel von Anfang bis Ende mit mehreren dieser Indikatoren finden Sie unter geplante Aufgaben im Browser analysieren.
FAQ
Was macht eine geplante Aufgabe verdächtig?
Befehle in für Benutzer beschreibbaren Ordnern, kodiertes PowerShell, Skript-Hosts und LOLBins, Nicht-Microsoft-Aufgaben, die als SYSTEM oder mit höchsten Privilegien laufen, versteckte Nicht-Microsoft-Aufgaben, zufällig wirkende Namen, Netzwerkpfade, eine kürzlich erfolgte Registrierung und jede Abweichung zwischen der XML-Datei und dem TaskCache-Eintrag in der Registry.
Sind diese Indikatoren ein Beweis für bösartige Aktivität?
Nein. Für jeden gibt es legitime Erklärungen: Hersteller-Updater in ProgramData, IT-Skripte mit -EncodedCommand, Agenten, die als SYSTEM laufen. Die Indikatoren legen die Reihenfolge der Prüfung fest. Ein Befund muss durch Ausführungsspuren, Ereignisprotokolle oder die Binärdatei selbst gestützt werden.
Wie reduziere ich das Rauschen durch Microsoft-Aufgaben?
Sortieren Sie nach Autor und Pfad, stellen Sie Aufgaben unter \Microsoft\Windows\ mit Microsoft als Autor zurück, nachdem Sie geprüft haben, dass ihre Aktionen auf Binärdateien in System32 zeigen, und vergleichen Sie den Rest mit einer Baseline von einem sauberen Rechner desselben Builds.