Persistenz erkennen: geplante Aufgaben, Dienste und WMI-Ereignisse

Persistenz erkennen ist die Erkennung, die den Unterschied zwischen einem bereinigten und einem weiterhin kompromittierten Netz ausmacht. Ein Angreifer, der einmal drin war, will nicht beim ersten Neustart oder Passwortwechsel wieder draußen sein, also legt er sich einen oder mehrere Wege zurück. Windows bietet dafür Dutzende Mechanismen; drei davon kommen in der überwiegenden Mehrheit der Vorfälle vor, weil sie zuverlässig, dokumentiert und mit Bordmitteln erreichbar sind: geplante Aufgaben, Dienste und permanente WMI-Ereigniskonsumenten. Dieser Beitrag behandelt alle drei nach demselben Schema, weil die Erkennung bei allen dem gleichen Prinzip folgt: Die Erstellung wird protokolliert, und der Inhalt wird gegen das geprüft, was in der Umgebung normal ist. Er ist länger als die anderen Beiträge der Serie, weil er drei Techniken abdeckt.

Warum diese drei

Persistenz über den Autostart-Ordner oder Run-Schlüssel der Registry ist häufig, aber laut und leicht zu finden; Persistenz über manipulierte Dienste-DLLs oder COM-Hijacking ist leise, aber selten. Die drei hier behandelten Mechanismen liegen in der Mitte: häufig genug, um in fast jedem Vorfall vorzukommen, und leise genug, um ohne gezielte Erkennung durchzurutschen. Geplante Aufgaben starten Code zu einer Zeit oder bei einem Ereignis, Dienste starten ihn beim Systemstart mit hohen Rechten, WMI-Konsumenten starten ihn bei einem beliebigen Systemereignis und überleben sogar manche Bereinigung, weil sie nicht im Dateisystem, sondern im WMI-Repository liegen. Alle drei sind in ATT&CK unter Persistence geführt, und ihre Detection Strategies sagen dasselbe: nicht das Vorhandensein, sondern die Erstellung und der Inhalt sind das Signal.

Geplante Aufgaben (T1053.005)

Was der Angreifer tut: Er legt eine geplante Aufgabe an, die ein Skript oder ein Bordmittel startet, bei Anmeldung, beim Systemstart, in Intervallen oder bei einem Ereignis. Werkzeuge sind schtasks, das PowerShell-Modul ScheduledTasks oder der direkte Aufruf über die Aufgabenplanungs-API; Angreifer geben der Aufgabe gern einen Namen, der wie eine Windows-Aufgabe klingt, und legen sie im Wurzelverzeichnis der Aufgaben ab.

Logquellen: Event 4698 (Aufgabe erstellt) im Security-Log enthält den vollständigen XML-Inhalt der Aufgabe, also Auslöser, auszuführendes Programm und Argumente; 4702 (geändert) und 4699 (gelöscht) ergänzen. Im Kanal Microsoft-Windows-TaskScheduler/Operational zeigt Event 106 die Registrierung und 200/201 die Ausführung. Sysmon 1 zeigt beim Auslösen den gestarteten Prozess mit Elternprozess svchost.exe und dem Task-Namen in der Befehlszeile.

Muster: Verdächtig ist eine Aufgabe, deren auszuführendes Programm ein Skript-Interpreter oder Bordmittel ist (powershell, cmd, mshta, rundll32, regsvr32), deren Argument eine URL, ein Base64-Block oder ein Pfad in einem Benutzer- oder Temp-Verzeichnis enthält, oder die von einem ungewöhnlichen Konto angelegt wurde. Ein weiteres Signal ist der Auslöser bei Anmeldung eines beliebigen Benutzers in Kombination mit einem solchen Payload.

title: Scheduled Task With Suspicious Action Created
id: 3b8e1c9f-2a7d-4e5b-9c1a-6f0d2e3a4b5c
status: test
tags:
  - attack.persistence
  - attack.t1053.005
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4698
  selection_action:
    TaskContent|contains:
      - 'powershell'
      - 'cmd.exe /c'
      - 'mshta'
      - 'rundll32'
      - 'regsvr32'
      - '-enc'
      - 'http://'
      - 'https://'
      - '\Users\'
      - '\Temp\'
  filter_known:
    SubjectUserName|startswith: 'adm-'
  condition: selection and selection_action and not filter_known
falsepositives:
  - Softwareverteilung und Verwaltungsskripte, die Aufgaben anlegen; nach Konto und Taskpfad ausnehmen
level: high

Dienste (T1543.003)

Was der Angreifer tut: Er legt einen neuen Dienst an, der beim Systemstart mit den Rechten des lokalen Systems ein Programm oder eine DLL startet. Dasselbe Muster nutzen PsExec-artige Werkzeuge zur seitlichen Bewegung, nur wird der Dienst dort nach der Ausführung wieder gelöscht; bei der Persistenz bleibt er.

Logquellen: Event 7045 (Dienst installiert) im System-Log mit Dienstname, Pfad und Starttyp; 4697 im Security-Log mit dem auslösenden Konto. Änderungen an bestehenden Diensten zeigt 7040 (Starttyp geändert). Sysmon 1 zeigt beim Start den Prozess mit Elternprozess services.exe.

Muster: Verdächtig ist ein Dienst mit einem zufällig wirkenden Namen, einem Pfad außerhalb von System- und Programmverzeichnissen, einer Befehlszeile mit Skript-Interpreter oder kodiertem Befehl, oder einem Starttyp automatisch für ein Programm, das keine Dienstbinärdatei ist. Ein Dienst, dessen ImagePath direkt auf powershell.exe oder cmd.exe zeigt, ist fast immer bösartig.

title: Suspicious Service Installed For Persistence
id: 7c2f4a1e-9b6d-4d3a-8e5c-1f0b2a3c4d5e
status: test
tags:
  - attack.persistence
  - attack.t1543.003
logsource:
  product: windows
  service: system
detection:
  selection:
    EventID: 7045
  selection_path:
    ImagePath|contains:
      - 'powershell'
      - 'cmd.exe'
      - 'mshta'
      - 'rundll32'
      - 'regsvr32'
      - '-enc'
      - '\Users\'
      - '\Temp\'
      - '\ProgramData\'
  condition: selection and selection_path
falsepositives:
  - Softwareverteilung mit temporären Diensten; Sysinternals PsExec (PSEXESVC) durch Administratoren
level: high

Permanente WMI-Ereigniskonsumenten (T1546.003)

Was der Angreifer tut: Er registriert im WMI-Repository ein Filter-Konsumenten-Paar: Ein Ereignisfilter beschreibt, wann etwas passieren soll, etwa beim Systemstart oder zu einer bestimmten Uhrzeit, ein Ereigniskonsument beschreibt, was dann passiert, meist ein Kommandozeilen- oder Skript-Konsument, der ein Programm startet. Eine Bindung verknüpft beide. Der Reiz für den Angreifer: Das Ganze liegt im WMI-Repository, nicht im Dateisystem, läuft mit Systemrechten und überlebt viele Bereinigungen, weil kaum jemand dort nachsieht.

Logquellen: Der Kanal Microsoft-Windows-WMI-Activity/Operational zeigt mit Event 5861 die Registrierung eines permanenten Konsumenten, mit 5859 die Aktivität. Sysmon deckt die drei Teile direkt ab: Event 19 (WmiEventFilter), 20 (WmiEventConsumer) und 21 (WmiEventConsumerToFilter) protokollieren Filter, Konsument und Bindung mit ihren Details. Das ist die zuverlässigste Quelle, weil sie den auszuführenden Befehl mitliefert.

Muster: Jeder permanente WMI-Konsument verdient einen Blick, weil legitime selten sind; verdächtig ist ein Konsument vom Typ Kommandozeile oder ActiveScript, dessen Befehl ein Bordmittel, ein Skript oder einen kodierten Block enthält, und ein Filter, der an den Systemstart oder einen kurzen Zeittakt gebunden ist.

title: WMI Persistent Event Consumer Created
id: 5e9a3c7b-1d2f-4b8a-9e6c-3f4a2b1c0d9e
status: test
tags:
  - attack.persistence
  - attack.t1546.003
logsource:
  product: windows
  category: wmi_event
detection:
  selection_consumer:
    EventID: 20        # Sysmon WmiEventConsumer
  selection_type:
    Type:
      - 'Command Line'
      - 'Active Script'
  filter_scm:
    Destination|contains: 'C:\Program Files\Monitoring\'
  condition: selection_consumer and selection_type and not filter_scm
falsepositives:
  - Monitoring- und Verwaltungssoftware mit eigenen WMI-Konsumenten; nach Destination ausnehmen
level: high

Alle drei Regeln folgen demselben Prinzip: Sie feuern auf die Erstellung, nicht auf die Existenz, und sie prüfen den Inhalt gegen die üblichen Payload-Merkmale. Die Community-Sammlung hat für jeden der drei Mechanismen feiner abgestufte Regeln; die Filter für die eigene Softwareverteilung und Verwaltung sind das, was in jeder Umgebung angepasst werden muss, wie im Beitrag zu Sigma-Regeln beschrieben.

Der Test

Alle drei lassen sich im Homelab in wenigen Minuten prüfen, und Atomic Red Team hat für T1053.005, T1543.003 und T1546.003 passende Tests. Von Hand: eine geplante Aufgabe mit schtasks anlegen, die powershell mit einem harmlosen Befehl bei Anmeldung startet, erwartet werden 4698 mit dem XML und TaskScheduler 106; einen Dienst mit sc create anlegen, dessen binPath auf cmd.exe zeigt, erwartet werden 7045 und 4697; mit dem PowerShell-WMI-Modul oder mofcomp ein Filter-Konsumenten-Paar registrieren, das bei Systemstart ein Programm startet, erwartet werden Sysmon 19, 20 und 21 und WMI-Activity 5861. Jede der drei Regeln muss einmal treffen. Wichtig ist, im Lab nach dem Test aufzuräumen, weil gerade der WMI-Konsument sonst dauerhaft bleibt; ein Snapshot vor dem Test und ein Rollback danach ist der sichere Weg. Ergebnis und Datum für alle drei Techniken in den Navigator.

Fehlalarme und Tuning

• Softwareverteilung und Verwaltung. Verteilungslösungen legen Aufgaben, Dienste und gelegentlich WMI-Konsumenten an, mit Skript-Payloads, die wie ein Angriff aussehen. Sie kommen über Konto, Pfad und Zeitplan in die Filter; eine Änderung an einem dieser Merkmale ist ein Alarm.
• Windows selbst. Das Betriebssystem legt viele geplante Aufgaben an, aber unter definierten Pfaden wie \Microsoft\Windows\ und ohne Skript-Payloads in Benutzerpfaden. Die Regel auf verdächtige Aktionen trifft sie nicht; wer stattdessen auf jede neue Aufgabe alarmiert, ertrinkt.
• Monitoring mit WMI. Manche Monitoring- und Inventarlösungen nutzen permanente WMI-Konsumenten legitim. Sie sind namentlich zu erfassen, und danach ist jeder weitere Konsument verdächtig, weil neue selten sind.
• PsExec-Dienste. Das Original von Sysinternals legt den Dienst PSEXESVC an; ein eigener Filter mit Quellprüfung nimmt ihn heraus, während zufällig benannte Varianten Treffer bleiben.
• Die Gegenmaßnahme, die die Regeln entlastet. Ein regelmäßiger Bestandsabgleich: Welche geplanten Aufgaben, Dienste und WMI-Konsumenten existieren, und gehören sie dorthin? Werkzeuge wie Autoruns von Sysinternals oder eine Velociraptor-Sammlung listen alle Autostart-Punkte über die ganze Flotte, und die Differenz zum letzten bekannten Stand ist die beste Persistenz-Erkennung, die es gibt, weil sie auch die Mechanismen findet, für die keine Regel geschrieben wurde.

Fazit

Persistenz ist der Teil des Angriffs, den der Verteidiger nach der Bereinigung finden muss, sonst war die Bereinigung umsonst. Geplante Aufgaben, Dienste und WMI-Konsumenten decken die meisten Fälle ab, und die Erkennung folgt bei allen dem gleichen Prinzip: auf die Erstellung feuern, den Inhalt gegen das Normale prüfen, die eigene Verwaltung als Filter pflegen. Wer die drei Regeln im Lab getestet und einen regelmäßigen Autostart-Abgleich eingerichtet hat, findet den Weg zurück, den der Angreifer sich gelegt hat, und schließt ihn, bevor er ihn benutzt. Für ein Blue Team ist das die Erkennung, die im Post-Incident-Review die Frage beantwortet, ob der Angreifer wirklich weg ist.