Abwehr: Windows-Aufgabenplanung als Einfallstor für Angriffe

Windows[English]Angreifer verwenden als Technik die Windows-Aufgabenplanung und erstellen dort Tasks (geplante Aufgaben), um sich auf dem Rechner eines Opfers einzunisten. Das Forschungsteam von Qualys hat eine Reihe von Möglichkeiten untersucht, wie Angreifer solche geplanten Aufgaben verstecken können. Dieser Beitrag beschreibt drei neue Techniken zum Verbergen und Löschen geplanter Aufgaben in einer Microsoft Windows-Umgebung. Das ist keine theoretische Arbeit "im luftleeren Raum", denn die Technik wurde von der mutmaßlich chinesischen Angreifer (APT) Hafnium eingesetzt.


Anzeige

Angreifer missbrauchen die Aufgabenplanung (Taskplaner) in Microsoft Windows-Umgebungen, um die erstmalige oder wiederholte Ausführung von bösartigem Code beim Systemstart oder zu einem geplanten Zeitpunkt zu ermöglichen. Das MITRE ATT&CK-Framework führt dies sogar als eine der beliebtesten Techniken von Angreifern an, da die Möglichkeit zur Planung von Programmen oder Skripten ein gängiger Dienst in verschiedenen Betriebssystemen ist.

Hafnium nutzt diese Technik

Vor kurzem veröffentlichten Sicherheitsforscher von Microsoft einen Artikel, der beschreibt, wie die Hacker der staatlich geförderten chinesischen Gruppe Hafnium geplante Aufgaben verbergen, indem sie den Security Descriptor (SD)-Wert im Registrierungspfad von Windows löschen:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\TASK_NAME

Nachdem Microsoft diese Angriffstechnik öffentlich bekanntgegeben hatte, stellte sich das Qualys-Forschungsteam die Frage, ob es noch andere Möglichkeiten zum Verbergen geplanter Aufgaben gibt, und beschloss, dies näher zu untersuchen.

Geplante Aufgabe ausblenden

In diesem Blog-Beitrag werden die Ergebnisse erläutert. Die wichtigste Erkenntnis der Analyse ist, dass der Index-Wert im Windows-Registrierungspfad

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\TASK_NAME

auch dazu missbraucht werden kann, eine geplante Aufgabe auszublenden und zu löschen.

Nachfolgend wird kurz die Technik beschrieben, die Hafnium und andere Akteure zum Verbergen einer geplanten Aufgabe verwenden. Danach wird detailliert auf neue Techniken eingegangen, die genutzt werden können, um eine geplante Aufgabe in Microsoft-Umgebungen zu verbergen.

So verstecken Angreifer geplante Aufgaben

Dem Microsoft-Beitrag zufolge werden bei der Erstellung jeder geplanten Aufgabe die folgenden beiden Registrierungsunterschlüssel erzeugt, einer im Tree-Pfad und der andere im Tasks-Pfad.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\TASK_NAME 
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID} 

Der erste Unterschlüssel TASK_NAME, der im Tree-Pfad erzeugt wird, entspricht dem Namen der geplanten Aufgabe. Die darin erzeugten Werte (d. h. Id, Index und SD) enthalten Metadaten für die Aufgabenregistrierung im System.


Anzeige

Der zweite Unterschlüssel {GUID}, der im Tasks-Pfad erzeugt wird, entspricht dem Id-Wert im Tree-Unterschlüssel. Die darin erzeugten Werte (d. h. Aktionen, Pfad, Trigger usw.) enthalten die grundlegenden Parameter, die zur Ausführung der Aufgabe erforderlich sind.

Im Fall von Hafnium erstellten die Angreifer eine geplante Aufgabe namens WinUpdate, um unterbrochene Verbindungen zu ihrer Command & Control-Infrastruktur wiederherzustellen. Infolgedessen wurden Unterschlüssel im Tree-Pfad und im Tasks-Pfad erzeugt. Anschließend verschafften sich die Angreifer SYSTEM-Rechte (durch Token-Diebstahl) und löschten den SD-Wert im Tree-Unterschlüssel.

Durch das Entfernen des SD-Werts „verschwand" die Aufgabe aus dem Aufgabenplaner und aus der Ausgabe des Befehls schtasks /query, was dazu führte, dass die geplante Aufgabe mit keiner der herkömmlichen Identifizierungsmöglichkeiten mehr zu finden war.

Die Untersuchung durch die Qualsys-Sicherheitsforscher ergab nun, dass das Ändern oder Löschen des Indexwerts im Tree-Unterschlüssel ebenfalls dazu führt, dass geplante Aufgaben verborgen werden. Im Folgenden werden erläutern die Sicherheitsforscher ihre Erkenntnisse, doch zunächst eine kurze Beschreibung der Untersuchungsbedingungen.

Der Untersuchungsaufbau des Qualys-Forschungsteams

Die Sicherheitsforscher führten ihre Untersuchungen unter Windows 10 Pro (v10.0.19043), Windows 10 Enterprise (v10.0.19044) und Windows 2016 Server durch. Auf jedem Rechner wurden zunächst die beiden folgenden Schritte ausgeführt:

  • Konfigurieren der Objektüberwachung in den erweiterten Überwachungseinstellungen der lokalen Sicherheitsrichtlinie, damit im Windows-Sicherheitsereignisprotokoll Einträge für die Erstellung (4698), Löschung (4699) und Aktualisierung (4702) geplanter Aufgaben angezeigt werden.
  • Erstellung einer geplanten Aufgabe namens ImpTask, die nach der Benutzeranmeldung ausgeführt wird.

schtasks /create /tn ImpTask /tr cmd.exe /sc onlogon /rl highest

Sobald der Befehl schtasks /create ausgeführt wird, werden die drei folgenden Unterschlüssel für die neu erstellte Aufgabe ImpTask erzeugt (s. Abb. 1).

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\ImpTask 
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID} 
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Logon\{GUID}

Der Indexwert im ImpTask-Unterschlüssel wird auf 0x2 gesetzt (s. Abb. 1), da der Unterschlüssel {GUID} für diese Aufgabe im Anmeldepfad erstellt wird (weil die Aufgabe so geplant ist, dass sie nach der Benutzeranmeldung ausgeführt wird).


Abb. 1. Drei Registrierungsschlüssel zu der geplanten Aufgabe ImpTask.

Neue Methoden zum Verbergen einer geplanten Aufgabe

Die Sicherheitsforscher stellten fest, dass bei der Erstellung einer geplanten Aufgabe zusätzlich zum Tree- und Tasks-Unterschlüssel noch ein weiterer Unterschlüssel erzeugt wird. Dieser dritte Unterschlüssel wird in Abhängigkeit davon erzeugt, wann die geplante Aufgabe ausgeführt werden soll:

  • Beim Starten, angegeben durch den Parameter /sc onstart parameter in schtasks /create
  • Während der Benutzeranmeldung, angegeben durch den Parameter /sc onlogon in schtasks /create
  • Zu einem anderen Zeitpunkt als beim Hochfahren oder Anmelden (z. B. /sc daily /st 09:00)

Der dritte Unterschlüssel wird unter einem der folgenden Pfade erzeugt:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Boot\{GUID} 
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Logon\{GUID} 
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Plain\{GUID}

Der Name des dritten Unterschlüssels {GUID} stimmt mit dem Id-Wert im Tree-Unterschlüssel überein. Außerdem beobachteten wir, dass der Indexwert im Tree-Unterschlüssel ebenfalls mit diesem dritten Unterschlüssel für die geplante Aufgabe verknüpft ist. Wie die Sicherheitsforscher feststellten, ist der Indexwert entweder auf 0x1 oder 0x2 oder 0x3 gesetzt. Im Einzelnen gilt:

  • Alle Aufgaben, die im Pfad HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\ Boot registriert werden, haben einen Indexwert von 0x1
  • Alle Aufgaben, die im Pfad HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Logon registriert werden, haben einen Indexwert von 0x2
  • Alle Aufgaben, die im Pfad HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\(Plain or Maintenance) registriert werden, haben einen Indexwert von 0x3

Das Qualys-Forschungsteam schrieb ein Python-Skript und führte es auf verschiedenen Windows-Rechnern aus, um dieses Verhalten zu bestätigen. Da jede geplante Aufgabe entweder Teil von Boot oder Logon oder Plain or Maintenance ist, scheint es nur drei mögliche Werte für Index zu geben: 0x1, 0x2 oder 0x3.

Bei den Nachforschungen fanden die Sicherheitsforscher keine Online-Dokumentation, die den Zweck des Indexwerts im Zusammenhang mit der geplanten Aufgabe beschreibt. Jedoch gelang es den Forscher, den Indexwert zu manipulieren, um die folgenden Ergebnisse zu erzielen:

  • Eine bestimmte geplante Aufgabe verbergen: Die Forscher stellten fest, dass die Aufgabe vor dem Aufgabenplaner und der Ausgabe des Befehls schtasks /query verborgen wird, wenn der Indexwert im Tree-Unterschlüssel auf 0x0 gesetzt wird. Trotzdem wird die Aufgabe weiterhin zum geplanten Zeitpunkt ausgeführt, auch bei einem Neustart des Systems. So ergibt sich ein Verhalten, das genau dem entspricht, was die Hafnium-Angreifer durch Löschen des SD-Werts erreichten. Zudem stellten die Forscher fest, dass die Aufgabe gelöscht wird, wenn sie diese sie zu ändern versuchen, nachdem ihr Indexwert mit dem Befehl schtasks /change auf 0x0 gesetzt worden war. Im Windows-Sicherheitsereignisprotokoll erscheint jedoch kein Ereignis mit der ID 4699 für das Löschen einer geplanten Aufgabe.
  • Alle geplanten Aufgaben verbergen: Weiterhin stellten wir fest, dass das Löschen des Indexwerts dazu führt, dass der Aufgabenplaner und schtasks /query die Fehlermeldung „Es ist ein interner Fehler aufgetreten" ausgeben, woraufhin alle geplanten Aufgaben effektiv verborgen werden. Die vorhandenen Aufgaben werden jedoch weiter ausgeführt, und es können auch neue Aufgaben erstellt werden.

Wenn der Index auf einen anderen Wert gesetzt wird (0x4, 0xffff usw.), wird die geplante Aufgabe nicht versteckt, und die Aufgabe wird weiter planmäßig ausgeführt. Sehen wir uns nun die beiden Ergebnisse einer Manipulation des Indexwerts näher an.

Eine geplante Aufgabe verbergen

In diesem ersten Szenario erstellen die Sicherheitsforscher eine weitere geplante Aufgabe namens ModifyIndexTask, die mit SYSTEM-Rechten einmal ausgeführt wird – und zwar nach der Erstellung von ImpTask –, und setzen ihren Indexwert auf 0x0. Der Befehl lautet wie folgt:

schtasks /create /tn ModifyIndexTask /tr "reg.exe add  \"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\ImpTask\" /v Index /d 0x0 /t REG_DWORD /f" /ru "NT AUTHORITY\SYSTEM" /rl highest /sc once /st <time later than creation time of ImpTask>


Abb. 2. Der Indexwert von ImpTask wird auf 0x0 geändert.

Sobald die Aufgabe ModifyIndexTask ausgeführt wird, setzt sie den Indexwert von ImpTask auf 0 (Abb. 2). Infolgedessen verschwindet ImpTask sowohl aus dem Aufgabenplaner (Abb. 3) als auch aus der Ausgabe des Befehls schtasks /query (Abb. 4).

ImpTask wird jedoch weiter ausgeführt, auch nach einem System-Neustart (Abb. 5). Obwohl ImpTask in der Ausgabe von schtasks /query nicht erscheint, zeigt Abb. 5, dass es möglich ist, den Status der Aufgabe mit dem Befehl schtasks /query abzurufen, indem der Name der Aufgabe mit dem Parameter /tn angegeben wird.


Abb. 3.  ImpTask verschwindet aus dem Aufgabenplaner, sobald der Indexwert auf 0x0 geändert wird.


Abb. 4.  ImpTask verschwindet aus der Ausgabe von schtasks /query, sobald der Indexwert auf 0x0 geändert wird.


Abb. 5. ImpTask wird weiter ausgeführt, auch nachdem der Indexwert auf 0x0 gesetzt wurde

Das Qualys Forschungsteam konnte dieses Problem auf jedem Windows 10-Rechner reproduzieren, mit dem experimentiert wurde – die Tests erfolgten auf insgesamt fünf Geräten.

Eine weitere interessante Beobachtung war folgende: Wenn wir versuchen, den Programmnamen in ImpTask (mit dem Indexwert 0x0) mit dem Befehl schtasks /change /tr zu ändern, wird die Aufgabe gelöscht, wie in Abb. 6 gezeigt. Dies wird ausgeführt, ohne dass im Windows-Sicherheitsereignisprotokoll die Ereignis-ID 4699 (Eine geplante Aufgabe wurde gelöscht) oder die Ereignis-ID 4702 (Eine geplante Aufgabe wurde aktualisiert) angezeigt wird. Dagegen wird die Ereignis-ID 4699 angezeigt, wenn wir den Befehl schtasks /delete verwenden, um ImpTask zu löschen.


Abb. 6. Wenn ImpTask mit schtasks /change /tr gelöscht wird, hinterlässt dies im Windows Sicherheitsprotokoll keine Spuren.

Alle geplanten Aufgaben verbergen

In diesem zweiten Szenario erstellen die Sicherheitsforscher eine weitere geplante Aufgabe, die mit SYSTEM-Rechten ausgeführt wird und den Indexwert im ImpTask-Unterschlüssel löscht. Der Befehl dazu lautet:

schtasks /create /tn ModifyIndexTask /tr "reg.exe delete \"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\ImpTask\" /v Index /f" /ru "NT AUTHORITY\SYSTEM" /rl highest /sc once /st <time later than creation time of ImpTask>

Sobald der Indexwert im ImpTask-Unterschlüssel gelöscht wird (Abb. 7), verschwinden alle geplanten Aufgaben aus dem Aufgabenplaner (Abb. 8) und der Ausgabe des Befehls schtasks /query (Abb. 9). Stattdessen erhalten wir die Fehlermeldung „Ein interner Fehler ist aufgetreten". Auch die Angabe des Aufgabennamens ImpTask mit dem Parameter /tn funktioniert nicht.


Abb. 7. Indexwert aus dem ImpTask-Unterschlüssel gelöscht.


Abb. 8. Nach dem Löschen des Indexwerts verschwinden alle geplanten Aufgaben aus dem Aufgabenplaner, und es wird eine Fehlermeldung angezeigt.
Abb. 9. Den Namen der Aufgabe mit dem Befehl schtasks /query /tn anzugeben, funktioniert ebenfalls nicht.

Obwohl die geplanten Aufgaben nicht angezeigt werden, werden sie zum geplanten Zeitpunkt ausgeführt. Auch nach einem Neustart des Systems können die geplanten Aufgaben nicht angezeigt werden. Wenn ImpTask mit dem Befehl schtasks /change geändert wird, wird der Indexwert erneut generiert, und danach wird der Befehl schtasks /query dann erfolgreich ausgeführt (Abb. 10).


Abb. 10. Die Änderung von ImpTask mit dem Befehl schtasks /change führt dazu, dass der Indexwert erneut generiert wird, woraufhin der Befehl schtasks /query erfolgreich ausgeführt wird.

Nachdem die Forscher den Indexwert gelöscht hatten, versuchten sie, ImpTask mit schtasks /delete zu löschen. Interessanterweise schlug dieses Kommando fehl, und es wurde eine Fehlermeldung ausgegeben. Als wir anschließend versuchten, ImpTask mit dem Befehl schtasks /change zu ändern, wurde der Indexwert im ImpTask-Unterschlüssel wiederhergestellt. Alle Aufgaben erschienen nun wieder im Aufgabenplaner, und die Ausführung von schtasks /query war ebenfalls erfolgreich. Beachten Sie, dass der Indexwert nur wiederhergestellt wird, wenn schtasks /delete vor schtasks /change ausgeführt wird. Wenn wir schtasks /change ausführten, ohne vorher schtasks /delete ausgeführt zu haben, wurde der Indexwert nicht wiederhergestellt, und wir erhielten beim Ausführen von schtasks /query weiterhin eine Fehlermeldung.

Zusammenfassung

Eine Untersuchung durch das Qualys-Forschungsteam hat ergeben, dass neben dem SD-Wert auch der Indexwert im Tree-Unterschlüssel einer geplanten Aufgabe eine wichtige Rolle spielt und beide von Angreifern missbraucht werden können. In diesem Blog haben wir drei neue Techniken beschrieben, um geplante Aufgaben zu verstecken und zu löschen:

  • Eine geplante Aufgabe vor dem Aufgabenplaner und der Ausgabe des Befehls schtasks /query verbergen, indem ihr Indexwert auf 0x0 gesetzt wird
  • Eine geplante Aufgabe löschen, indem man zunächst ihren Indexwert auf 0x0 setzt und dann den Befehl schtasks /change /tr verwendet, wodurch die Aufgabe effektiv gelöscht wird, ohne dass dies eine Spur im Windows Sicherheitsereignisprotokoll hinterlässt.
  • Alle geplanten Aufgaben vor dem Aufgabenplaner und der Ausgabe des Befehls schtasks /query verbergen, indem man den Indexwert einer beliebigen geplanten Aufgabe löscht

Jede dieser neuen Techniken kann eingesetzt werden, um eine geplante Aufgabe in Microsoft-Umgebungen zu verbergen. Deshalb ist es wichtig, Änderungen an den Index- und SD-Werten geplanter Aufgaben zu überwachen. Solche Änderungen könnten darauf hinweisen, dass ein Angreifer versucht, bösartigen Code auszuführen – entweder beim Systemstart oder zu einem geplanten Zeitpunkt –, um Persistenz zu erlangen.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

17 Antworten zu Abwehr: Windows-Aufgabenplanung als Einfallstor für Angriffe

  1. Luzifer sagt:

    wenn ich das richtig verstanden habe sind das Techniken die genutzt werden um eine Lücke/Malware/Code zu installieren die einem den ZUGRIFF weiterhin garantiert, nachdem man bereits eingedrungen ist! Also eben genau nicht das Einfallstor.

    Also Techniken die nicht neu sind, sondern übliches Vorgehen (nun eben nur über die Aufgabenplannung). Schließlich ist es Ziel eines Angreifers möglichst lange unendeckt und auch ein Backupzugang zu haben falls man doch auffliegt

    Um aber da rauf zu kommen muss er erstmal aufs System kommen!

    • Günter Born sagt:

      Zum letzten Satz: Hafnium & Co. haben gezeigt, wie sie auf's System kommen. Die obigen Techniken verstecken die betreffenden Tasks, so dass eine oberflächliche forensische Analyse nichts findet.

    • Stephan sagt:

      Ja, wieder ein Super riesen Ausführlicher Beitrag über eine ganz ganz gemeine Sicherheitslücke, die….. ja, die eigentlich keine ist.

      Der Angreifer muss dazu sowieso schon am System sein, kann dort den Registrierungs Editor verwenden und Aufgaben Hinzufügen.
      Absolut Gefährliche sicherheitslücke.

      Ach ne, moment, der Gemeine Angreifer hat sowieso schon zugriff auf das System.
      Warum den umweg über die Aufgaben planung gehen.

      Leider wieder ein Riesen Faß geöffnet, eine Sicherheitslücke beschrieben, die gar keine ist.

  2. Markus Köln sagt:

    Vielen Dank!

    • Fritz sagt:

      Geplante Tasks waren auch schon früher zu XP-Zeiten der Weg, wenn man mal eine Shell mit Rechten von SYSTEM statt Administrator brauche.

  3. Chris sagt:

    Und was ist mit dem physischen Dateien unter "C:\Windows\System32\Tasks" die für jede Aufgabe angelegt werden?

    Sind die auch verborgen oder kann man einfach durch Überwachung des Ordners ungewünschte neue Tasks identifizieren?

    • McAndrew777 sagt:

      Bevor ich "C:\Windows\System32\Tasks" überwache kann ich auch direkt die o.g. REG-Verzeichnisse überwachen. Dazu müssten nur unter TASKS alle GUIDs und Action/Path mit einem gespeicherten soll verglichen werden.

      Intern verwendet die Aufgabenplanung meines Wissens die REG-Einträge. "C:\Windows\System32\Tasks" dient meines Wissens der Kompaitbilität für Thirdparty-Applikationen.

  4. Gui sagt:

    Ein (noch) nicht kompromittiertes System, Anmeldung als gemeiner Nutzer: Wie kann da was in den Registry-Pfad HKLM schreiben?

  5. js sagt:

    Bei allem Respekt für die gute Analyse und Aufbereitung dieser vermutlich sonst undokumentierten Speichermethoden für Tasks möchte ich etwas hinzufügen um den leicht überhöhten Alarm-Charakter der Nachricht rauszunehmen:

    1.) Hatte ich schonmal im großen Stil mit dieser Registry-Struktur zu tun, als eine große Anzahl von Windows-Servern mit Inplace-Upgrades über mehrere Versionssände von 2008 nach 2019 hochgezogen wurde. Dabei konnte es vorkommen, dass vorher manuell erstellte Tasks nicht sauber migriert wurden und so lange Fehler erzeugten, bis man in dem besagten Baum die zugehörigen Einträge löschte. Soll heißen, es schadet nicht, die Stelle zu kennen.

    2.) Sitze ich hier an einem ebenfalls upgegradeten Windows10 und sehe SEHR VIELE Index=0 Einträge, die gerne mal jemand stichprobenartig mit einer frischen 10-Installation vergleichen könnte. Es scheint mir so zu sein, dass die Index=0 Versteckmechanik bewusst und gewollt impementiert ist und darum bei mir kein besonderer Gruselfaktor bei dem Thema aufkommt. Übrigens werden die Index=0 Einträge von Sysinternals Autoruns angezeigt wie sich das gehört und das ist wesentlich, denn meiner Einschätzung nach geht keiner mit der MMC forensisch gucken.

    3) Wie schon von anderen gesagt: Wenn ein Angreifer dort schreiben kann (und verstecken kann), ist der Kompromittierungsdrops bei dem System doch sowieso längst gelutscht.

    Hier meine Index=0 Liste in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache. Vielleicht ist das bei Frischinstallationen ja ähnlich:
    \Tree\Microsoft\OneCore\DirectX\DirectXDatabaseUpdater
    \Tree\Microsoft\Windows\Application Experience\AitAgent
    \Tree\Microsoft\Windows\Customer Experience Improvement Program\KernelCeipTask
    \Tree\Microsoft\Windows\Customer Experience Improvement Program\OptinNotification
    \Tree\Microsoft\Windows\Live\Roaming\MaintenanceTask
    \Tree\Microsoft\Windows\Live\Roaming\SynchronizeWithStorage
    \Tree\Microsoft\Windows\MemoryDiagnostic\CorruptionDetector
    \Tree\Microsoft\Windows\MemoryDiagnostic\DecompressionFailureDetector
    \Tree\Microsoft\Windows\MemoryDiagnostic\MemUsageTask
    \Tree\Microsoft\Windows\NetworkAccessProtection\NAPStatus UI
    \Tree\Microsoft\Windows\PLA\System\ConvertLogEntries
    \Tree\Microsoft\Windows\RAC\RACAgent
    \Tree\Microsoft\Windows\SettingSync\BackupTask
    \Tree\Microsoft\Windows\Shell\CrawlStartPages
    \Tree\Microsoft\Windows\Shell\FamilySafetyRefresh
    \Tree\Microsoft\Windows\TaskScheduler\Idle Maintenance
    \Tree\Microsoft\Windows\TaskScheduler\Maintenance Configurator
    \Tree\Microsoft\Windows\TaskScheduler\Manual Maintenance
    \Tree\Microsoft\Windows\TaskScheduler\Regular Maintenance
    \Tree\Microsoft\Windows\Windows Activation Technologies\ValidationTask
    \Tree\Microsoft\Windows\Windows Activation Technologies\ValidationTaskDeadline
    \Tree\Microsoft\Windows\Windows Subsystem For Linux\AptPackageIndexUpdate
    \Tree\Microsoft\Windows\WindowsBackup\ConfigNotification
    \Tree\Microsoft\Windows\WindowsUpdate\Automatic App Update
    \Tree\Microsoft\Windows\WindowsUpdate\Scheduled Start
    \Tree\Microsoft\Windows\WindowsUpdate\sihboot
    \Tree\Microsoft\Windows\WS\Badge Update
    \Tree\Microsoft\Windows\WS\License Validation
    \Tree\Microsoft\Windows\WS\Sync Licenses
    \Tree\Microsoft\Windows\WS\WSRefreshBannedAppsListTask
    \Tree\Microsoft\Windows\WS\WSTask
    \Tree\PostponeDeviceSetupToast_[SID]

    PS: Oh, ich habe vergessen: Die Überschrift "Windows-Aufgabenplanung als Einfallstor für Angriffe" passt nicht gut zum Artikelinhalt, weil die Aufgabenplanung in dem Kontext kein Einfallstor ist. Das würde passen, wenn ein regulärer User ohne Adminrechte über Tricks Tasks mit erhöhten Privilegien pflanzen könnte.

    • McAlex777 sagt:

      Wie könnte man solch versteckte Tasks Steuern und/oder deaktivieren?
      z.B.:

      Das setzen des Index-Werts von KernelCeipTask von 0 auf 2 oder 3 führt in der Aufgabenplanung zu einer Fehlermeldung.

      Ich kann nicht erkennen welcher RegKey einen Scheduled Task Enabled/Disabled.

      • McAlex777 sagt:

        Um das weiter zu konkretisieren:
        1.
        Wenn ich einen eigenen Scheduled Task anlege, kann ich den wie im Artikel beschrieben über den IndexWert verstecken, und wieder Anzeigen lassen – der Task wird in jedemfall ausgeführt.

        2.
        Wenn ich gleiches Verfahren für "KernelCeipTask" anwende erhalte ich in der Aufgabenplanung den folgenden Fehler:
        "Die ausgewählte Aufgabe "KernelCeipTask" ist nicht mehr vorhanden…."

        Die Meldung bleibt auch wenn ich die ID-Schlüssel aus Tree jeweils in den Verzeichnis "Boot, Logon, Maintenance, Plain" anlege, und einen bestehende Config in "C:\Windows\System32\Tasks" nach KernelCeipTask kopiere.

        Damit könnte ich zum jetzigen Zeitpunkt den Task ganz löschen, aber nicht einsehen oder deaktivieren.

        • McAlex777 sagt:

          Nachtrag:

          Der ID-Eintrag ist unter Tasks nicht definiert. Das gilt auch für weitere Microsoft Scheduled Tasks, welche mit Index=0 definiert sind.

          Ein hoch auf proparitäre Software.

    • McAlex777 sagt:

      >> Übrigens werden die Index=0 Einträge von Sysinternals Autoruns angezeigt wie sich das gehört und das ist wesentlich, denn meiner Einschätzung nach geht keiner mit der MMC forensisch gucken.

      Bei mir wird mein manuell auf Index=0 gesetzter Task nicht mehr via AutoRuns angezeigt, aber ausgeführt.

      • js sagt:

        Oh. Ich hatte nur eine Stickprobe gemacht. Fachpersonal ist heutzutage sooo schwer zu finden :)

        • McAlex777 sagt:

          Trotzdem Danke für den aufschlussreichen Beitrag…

          Einmal mehr beginnt man hinter schick gestrichene Fassaden zu schauen.

          Ich bin bei Dir das das kein Angriffswerkzeug ist – aber ein interessantes Verschleierungswerkzeug. Ich würd mich nicht wundern wenn laufende Processe ähnlich über undokumentierte "Features" verschleiert werden könnten.

  6. Anonymous sagt:

    Wirklich? Das fällt denen jetzt erst auf? Seit zig Jahren kann man wunderbar Tasks im Scheduler unsichtbar verstecken; ein Hoch auf die Benutzerverwaltung.

    Praktiziere ich auch, um Möchtegern-Turnschuh-Admins von unangebrachten Modifikationen abzuhalten.

Schreibe einen Kommentar zu McAlex777 Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.