Tarrask: versteckte geplante Aufgaben erkennen

Kurz gesagt. Im April 2022 beschrieb Microsoft Tarrask, ein Werkzeug von HAFNIUM, das geplante Aufgaben versteckte, indem es den Wert SD unter TaskCache\Tree\<task> löschte. Die Aufgabe verschwand aus schtasks und der Konsole, blieb aber in der Registry und auf dem Datenträger erhalten. Spätere Varianten nutzen eine Sicherheitsbeschreibung, die den Lesezugriff verweigert, oder manipulieren Index. Offline sind alle drei sichtbar: Listen Sie Tree-Schlüssel ohne SD auf, dekodieren Sie die vorhandenen SDs, prüfen Sie Index und vergleichen Sie mit dem XML-Ordner. Verwenden Sie einen Hive, dessen Transaktionsprotokolle eingespielt wurden.

Dieser Artikel gehört zur Serie über die Untersuchung geplanter Aufgaben. Die zugrunde liegenden Registry-Strukturen erklärt TaskCache-Forensik in der Registry.

Was Microsoft berichtet hat

In Tarrask malware uses scheduled tasks for defense evasion (12. April 2022) beschrieb Microsofts Threat-Intelligence-Team ein Werkzeug von HAFNIUM (heute als Silk Typhoon geführt), das geplante Aufgaben zur Persistenz anlegte und anschließend den Wert SD aus dem Tree-Schlüssel der Aufgabe entfernte. Die Kernpunkte des Berichts:

• Der Wert SD enthält die Sicherheitsbeschreibung der Aufgabe. Ohne ihn zeigen Werkzeuge, die Aufgaben über den Dienst auflisten, darunter schtasks /query und die Aufgabenplanungskonsole, die Aufgabe nicht an.
• Das Löschen erforderte SYSTEM; eine Administrator-Eingabeaufforderung mit erhöhten Rechten erhielt "Zugriff verweigert". Das Werkzeug verschaffte sich SYSTEM-Rechte, indem es ein Token von lsass.exe stahl.
• Die Werte der Aufgabe unter Tree und Tasks sowie ihre XML-Datei in C:\Windows\System32\Tasks blieben erhalten.
• Das Verstecken hielt die Aufgabe nicht auf: Sie lief weiter nach ihren Triggern. Microsoft ergänzt, dass die Aufgabe selbst nach dem Löschen der Schlüssel Tree und Tasks und der XML-Datei bis zum nächsten Neustart oder bis zum Ende des hostenden svchost.exe-Prozesses weiterlaufen würde; erst das Behalten der Registry-Daten, abzüglich SD, sichert die Persistenz über Neustarts hinweg.
• Microsofts Empfehlung zur Erkennung: TaskCache\Tree nach Aufgaben ohne Wert SD durchsuchen und die Protokollierung für den Kanal TaskScheduler/Operational sowie das Security-Ereignis 4698 aktivieren.

MITRE ATT&CK nahm die Technik in T1053.005 auf und nennt sowohl das Löschen der SD als auch das Ändern des Werts Index als Wege, eine Aufgabe zu verstecken.

Varianten, die Sie ebenfalls prüfen sollten

Sicherheitsbeschreibung mit Leseverbot. 2024 zeigte Binary Defense, dass eine gültige SD, deren ACL allen Konten den Lesezugriff verweigert, eine Aufgabe vor denselben Werkzeugen versteckt. Der Wert SD existiert und lässt sich sauber parsen, eine Regel für "fehlende SD" übersieht ihn also. Sie müssen die Beschreibung dekodieren und die ACEs lesen.

Manipulation von Index. Das DWORD Index im Tree-Schlüssel ordnet die Aufgabe einer Kategorie zu (1 Boot, 2 Logon, 3 Plain, 4 Maintenance, laut cyber.wtf). MITRE nennt das Setzen eines unerwarteten Werts als Versteckmethode. Öffentlich sind hierzu weniger Details bekannt als zum Löschen der SD, behandeln Sie auffällige Werte daher als Spur.

Anlegen nur über die Registry. Binary Defense stellte außerdem fest, dass das direkte Schreiben einer Aufgabe in den TaskCache, ohne SD, sowohl Security 4698 als auch TaskScheduler/Operational 106 umging. Unter Windows 10 war eine solche Aufgabe sofort nutzbar; unter Windows 11 lief sie erst nach einem Neustart des Dienstes oder des Hosts. Das Fehlen von Erstellungsereignissen belegt also nicht, dass keine Aufgabe angelegt wurde.

Erkennung offline

Alles Nötige steckt im SOFTWARE-Hive und im Ordner Tasks:

1. Tree-Aufgabenschlüssel ohne SD auflisten. Ein Aufgabenschlüssel hat einen Wert Id; Ordner haben weder Id noch Index. Jeder Aufgabenschlüssel ohne SD ist ein Befund: Legitime Aufgaben haben einen.
2. Jede SD zu SDDL dekodieren und nach Deny-ACEs (D:(D;...)) oder einer DACL suchen, die Administratoren oder SYSTEM nichts gewährt. Vergleichen Sie mit den Beschreibungen benachbarter Microsoft-Aufgaben.
3. Index prüfen gegen den Kategorieschlüssel (Boot, Logon, Plain, Maintenance), unter dem die GUID der Aufgabe auftaucht.
4. Mit der XML-Datei abgleichen. Eine versteckte Aufgabe hat meist noch ihre XML. Lesen Sie Aktionen und Principal wie bei jeder anderen Aufgabe.
5. DynamicInfo lesen in Tasks\{GUID}: Die Zeiten der letzten Ausführung und der letzten erfolgreichen Ausführung zeigen, ob die versteckte Aufgabe gelaufen ist.
6. Die Last-Write-Zeit des Tree-Schlüssels ansehen. Das Löschen von SD verändert den Schlüssel. Eine Last-Write-Zeit nach der Registrierung der Aufgabe passt dazu, dass die SD nachträglich entfernt wurde. Für sich allein ist das kein Beweis: Jede Änderung an Id, Index oder SD aktualisiert sie.

Die Falle des inkonsistenten Hives

Ein aus einem laufenden System kopierter Hive enthält möglicherweise nicht die jüngsten Änderungen, die noch in SOFTWARE.LOG1/.LOG2 stehen können. Bei versteckten Aufgaben wirkt das in beide Richtungen: Ein kürzliches Löschen der SD fehlt womöglich in der Primärdatei (Sie übersehen das Verstecken), oder eine wenige Minuten vor der Sicherung registrierte Aufgabe fehlt vollständig. Sichern Sie die Protokolle, spielen Sie sie mit einem Werkzeug ein, das Transaktionsprotokolle versteht, und ziehen Sie erst dann Schlüsse. Der Scheduled Tasks Parser erkennt inkonsistente Hives und warnt, spielt die Protokolle aber nicht selbst ein. Details zur Sicherung stehen in Speicherorte und Sicherung geplanter Aufgaben.

Erkennung am Live-System

Am laufenden System entspricht dem eine Registry-Abfrage als SYSTEM oder Administrator auf HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree, die Schlüssel mit Id und ohne SD auflistet. Velociraptor bringt genau dafür ein Artefakt mit, Windows.Registry.TaskCache.HiddenTasks, das auch die passende XML einsammelt. Für das Löschen selbst gibt es eine Sigma-Regel, sofern Registry-Auditing verfügbar ist (Spiegel auf detection.fyi).

Für die laufende Überwachung gelten Microsofts Empfehlungen weiterhin: Protokollierung von TaskScheduler/Operational aktiv, Security 4698 auditiert und Alarmierung bei Registry-Löschungen von SD unter TaskCache\Tree. Binary Defense ergänzt einen nützlichen Ansatz für das Threat Hunting: Aufgaben, die im TaskCache vorhanden sind, aber kein passendes Erstellungsereignis (106 oder 4698) haben, obwohl diese Protokolle ansonsten vollständig sind.

Einen Treffer bewerten

Ein Tree-Eintrag ohne SD ist ein starkes Signal; einen verbreiteten legitimen Grund dafür gibt es nicht. Formulieren Sie den Befund trotzdem als Beobachtung: "Der Tree-Schlüssel für \Microsoft\Windows\UPnP\UPnPHostConfigSync hat keinen Wert SD; die Aufgabe wird daher von schtasks und der Aufgabenplanungskonsole nicht aufgelistet." Klären Sie anschließend:

• Was sie ausführt: XML-Aktionen oder den dekodierten Actions-Blob, falls die XML fehlt.
• Unter welchem Konto: Principal in der XML oder im Triggers-Header.
• Seit wann: Erstellungszeit aus DynamicInfo, XML-Feld Date (mit dem richtigen UTC-Offset), Last-Write-Zeit des Schlüssels.
• Ob sie gelaufen ist: letzte Ausführung und Ergebnis aus DynamicInfo, TaskScheduler/Operational 200/201, Ausführungsspuren wie Prefetch.
• Wie SYSTEM-Rechte erlangt wurden: Das Löschen setzt sie voraus, suchen Sie also in den Ereignisprotokollen nach dem Schritt der Rechteausweitung oder des Zugriffs auf Anmeldedaten.

Ein durchgespieltes, fiktives Beispiel mit einer Aufgabe im Tarrask-Stil finden Sie in geplante Aufgaben im Browser analysieren.

FAQ

Wie hat Tarrask geplante Aufgaben versteckt?

Es löschte den Wert SD (Sicherheitsbeschreibung) im Schlüssel der Aufgabe unter TaskCache\Tree im SOFTWARE-Hive. Ohne ihn zeigen schtasks /query und die Aufgabenplanungskonsole die Aufgabe nicht mehr an, während ihre Registry-Daten und ihre XML-Datei erhalten bleiben. Laut Microsoft musste das Löschen als SYSTEM erfolgen.

Läuft eine versteckte Aufgabe weiter?

Ja. In Microsofts Bericht zu Tarrask lief die versteckte Aufgabe weiter nach ihren Triggern, und Microsoft merkt an, dass selbst eine Aufgabe, deren Registry-Schlüssel und XML vollständig gelöscht wurden, bis zum nächsten Neustart oder bis zum Ende ihres svchost.exe-Hosts weiterläuft. Spätere Untersuchungen von Binary Defense ergaben, dass sich das Verhalten bei direkt in die Registry geschriebenen Aufgaben zwischen Windows 10 und 11 unterscheidet. Prüfen Sie die letzte Ausführungszeit in DynamicInfo im TaskCache und die Ereignisprotokolle, statt etwas vorauszusetzen.

Wie finde ich versteckte geplante Aufgaben offline?

Werten Sie den SOFTWARE-Hive aus und listen Sie jeden Aufgabenschlüssel unter TaskCache\Tree auf, der keinen Wert SD hat, eine SD, die den Lesezugriff verweigert, oder einen ungewöhnlichen Index. Vergleichen Sie die Liste mit den XML-Dateien in System32\Tasks und stellen Sie sicher, dass die Transaktionsprotokolle des Hives eingespielt wurden.