Geplante Aufgaben erkennen: Ausführung über den Windows-Taskplaner

Mit diesem Beitrag beginnt der Execution-Teil der Welle: die Techniken, mit denen Angreifer ihren Code tatsächlich zur Ausführung bringen. Den Anfang macht die geplante Aufgabe. Sie ist ein Grenzgänger zwischen drei Taktiken - sie führt aus, bleibt bestehen und kann Rechte ausweiten -, aber ihr Kern ist die Ausführung. Weil der Windows-Taskplaner ein legitimes, viel genutztes Verwaltungswerkzeug ist, geht Missbrauch leicht in der Masse unter. Die Kunst liegt darin, die wenigen verräterischen Merkmale herauszufiltern. Der Beitrag bleibt auf der Verteidigerseite und bleibt konzeptionell.

Was der Angreifer tut

Der Missbrauch geplanter Aufgaben läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Schritten ab:

• Eine Aufgabe anlegen. Über schtasks, PowerShell oder direkt die COM-Schnittstelle des Taskplaners wird eine neue Aufgabe erzeugt - lokal oder aus der Ferne auf einem anderen Host.
• Die Aktion verstecken. Als Aktion dient oft eine Kommandozeile, PowerShell mit codiertem Befehl oder ein LOLBin wie mshta - der eigentliche Schadcode steckt im Aufgaben-Inhalt.
• Den Trigger wählen. Ein Zeitplan, der Systemstart oder eine Anmeldung als Auslöser macht aus der Aufgabe zugleich Persistenz.
• Rechte mitnehmen. Läuft die Aufgabe als SYSTEM oder als anderes Konto, dient sie auch der Rechteausweitung - ein Grund, warum sie so beliebt ist.

Für die Erkennung ist entscheidend: Das Anlegen der Aufgabe ist ein klar protokolliertes Ereignis - sowohl über die Kommandozeile als auch nativ -, und die Aktion verrät die Absicht.

Welche Logquellen die Technik zeigt

• Native Aufgaben-Protokollierung. Event-ID 4698 meldet jede neu angelegte Aufgabe samt Name und Inhalt - auch die, die nicht über schtasks, sondern über COM erzeugt werden.
• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen den schtasks-Aufruf samt Kommandozeile - inklusive des Schalters für die Fernanlage und der eingebetteten Aktion.
• Die ausgeführte Aktion. Startet die Aufgabe später eine PowerShell oder ein LOLBin, greifen die PowerShell-Protokollierung und die LOLBins-Erkennung.
• Endpunkt-Telemetrie. Für die saubere Erfassung von Prozessen und Aufgaben siehe Sysmon einrichten.

Das Muster im Log

Das stärkste Signal ist die Kombination aus Anlass und Inhalt. Eine Aufgabe, die aus der Ferne auf einem anderen Host angelegt wird, ist ein typischer Fernausführungs-Weg - die legitime Variante kommt fast nur von Verwaltungsquellen. Noch deutlicher ist eine Aufgabe, deren Aktion eine PowerShell mit codiertem Befehl oder ein LOLBin ist: Dafür gibt es kaum einen harmlosen Grund. Das native Event 4698 fängt beide Wege ab und ergänzt die, die schtasks umgehen. Für sich genommen ist das Anlegen einer Aufgabe Alltag; erst der Blick auf Herkunft, Konto und Aktion trennt Verwaltung von Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste nutzt die Fernanlage, die zweite die verdächtige Aktion, die dritte die native Registrierung. Die zweite ist die aussagekräftigste, weil eine Aufgabe mit Shell- oder LOLBin-Aktion selten legitim ist.

1. Geplante Aufgabe aus der Ferne (T1053.005). schtasks /create mit dem Schalter für einen entfernten Host. Die Regel steht auf level: high.

title: Geplante Aufgabe aus der Ferne per schtasks angelegt
id: 7c2e9b41-5a38-4d16-b0f9-3e6a1c4d85b2
status: experimental
description: |
  Erkennt das Anlegen einer geplanten Aufgabe auf einem entfernten Host ueber schtasks
  mit dem Schalter /s. Eine Aufgabe, die aus der Ferne auf einem anderen System erzeugt
  wird, ist ein klassischer Weg zur Fernausfuehrung - eine Alternative zu PsExec. Legitime
  Fernwartung nutzt das ebenfalls, daher auf Baselining der Quellen angewiesen.
references:
  - https://attack.mitre.org/techniques/T1053/005/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1053.005
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\schtasks.exe'
  sel_create:
    CommandLine|contains: '/create'
  sel_remote:
    CommandLine|contains: '/s '
  condition: sel_img and sel_create and sel_remote
falsepositives:
  - Fernwartung durch Administrationskonten; bekannte Verwaltungsquellen als Baseline ausnehmen
level: high

2. Aufgabe mit Shell- oder LOLBin-Aktion (T1053.005). Eine Aktion, die PowerShell, cmd oder ein LOLBin startet. Ebenfalls level: high.

title: Geplante Aufgabe mit Shell- oder LOLBin-Aktion
id: 2a8d6c13-7f49-4e05-9b21-5c3a7b2d61e4
status: experimental
description: |
  Erkennt das Anlegen einer geplanten Aufgabe, deren Aktion eine Kommandozeile, PowerShell
  oder ein LOLBin startet. Angreifer verpacken ihre Ausfuehrung so in eine Aufgabe, oft mit
  codiertem Befehl. Eine Aufgabe, die powershell -enc, mshta oder rundll32 aufruft, ist
  selten legitim und ein starkes Signal.
references:
  - https://attack.mitre.org/techniques/T1053/005/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1053.005
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\schtasks.exe'
  sel_create:
    CommandLine|contains: '/create'
  sel_action:
    CommandLine|contains:
      - 'powershell'
      - 'cmd /c'
      - 'cmd.exe'
      - 'mshta'
      - 'rundll32'
      - 'regsvr32'
      - 'wscript'
      - 'cscript'
      - '-enc'
      - '-EncodedCommand'
  condition: sel_img and sel_create and sel_action
falsepositives:
  - Softwareinstaller, die Aufgaben mit Skriptaktionen anlegen; bekannte Faelle ausnehmen
level: high

3. Registrierung einer Aufgabe (T1053.005). Das native Event 4698, das auch COM-basierte Anlage erfasst. level: medium und auf Baselining angewiesen.

title: Registrierung einer geplanten Aufgabe (Event 4698)
id: 9e1c4b70-3a28-4d35-8f02-6b5a2c7e93d8
status: experimental
description: |
  Erkennt die native Protokollierung einer neu angelegten geplanten Aufgabe ueber Event
  4698. Dieser Weg fasst auch die Aufgaben, die nicht ueber schtasks, sondern direkt ueber
  die COM-Schnittstelle des Taskplaners erzeugt werden. Das Ereignis enthaelt Name und
  Inhalt der Aufgabe und ist die zuverlaessigste Basis fuer Baselining und Hunting.
references:
  - https://attack.mitre.org/techniques/T1053/005/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1053.005
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4698
  condition: selection
falsepositives:
  - Legitime Aufgaben durch Software und Administration; nach Taskname und Konto als Baseline ausnehmen
level: medium

Härtung: der Angriff, der ins Leere läuft

• Aufgaben-Erstellung protokollieren. Die Überwachung für die Objekterstellung geplanter Aufgaben aktivieren, damit Event 4698 überhaupt entsteht.
• Rechte einschränken. Das Anlegen von Aufgaben - besonders solcher, die als SYSTEM laufen - auf wenige Konten begrenzen und die Fernanlage per Firewall eindämmen.
• Aufgaben inventarisieren. Einen Soll-Bestand der geplanten Aufgaben pflegen, damit jede neue Aufgabe auffällt - das ist die halbe Erkennung.
• Verhaltensregeln scharf schalten. Die Regel auf Shell- und LOLBin-Aktionen aktiv überwachen, weil sie die wenigsten Fehlalarme erzeugt.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon und eingeschalteter Aufgaben-Überwachung:

• Für Regel 3 eine harmlose Aufgabe lokal anlegen. Event 4698 und Event 4688 müssen sie zeigen.
• Für Regel 2 eine Testaufgabe anlegen, deren Aktion eine PowerShell mit einem unschädlichen Befehl ist. Die Regel muss auf die Aktion anschlagen.
• Für Regel 1 vom Testhost aus eine Aufgabe auf einem zweiten System per /s anlegen. Der schtasks-Aufruf mit dem Fernschalter muss erscheinen. Breiter wird der Test mit den Fällen zu T1053 aus Atomic Red Team.

Fehlalarme und Tuning

• Software und Updater. Installer und Updater legen laufend Aufgaben an. Für Regel 3 die bekannten Tasknamen und Pfade als Baseline ausnehmen.
• Fernwartung. Administratoren legen Aufgaben auch aus der Ferne an. Für Regel 1 die Verwaltungsquellen und -konten filtern, nicht die Regel entschärfen.
• Legitime Skriptaufgaben. Einzelne Verwaltungsaufgaben rufen PowerShell auf. Für Regel 2 die bekannten, signierten Skriptpfade ausnehmen und auf codierte Befehle priorisieren.
• Korrelation schlägt Einzelregel. Wer die Anlage mit der späteren Ausführung der Aufgabe verknüpft, trennt Verwaltung und echten Angriff zuverlässiger als jede Einzelregel.

Fazit

Die geplante Aufgabe ist so nützlich für die Verwaltung wie für den Angreifer - Ausführung, Persistenz und Rechteausweitung in einem Werkzeug. Die verlässlichen Signale sind die Fernanlage, die Shell- oder LOLBin-Aktion und das native Event 4698, das auch den COM-Weg erfasst. Die wirksamste Härtung schaltet die Aufgaben-Überwachung ein, begrenzt die Erstellungsrechte und pflegt einen Soll-Bestand. Als Nächstes folgt WMI als zweiter großer Ausführungsweg. Verwandt sind die Admin-Shares, ein alternativer Ausführungspfad, und die Impacket-Werkzeuge, deren atexec genau auf geplanten Aufgaben beruht. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Execution.