ETW-Manipulation erkennen: wenn die Telemetrie verstummt

Der vorige Beitrag zur AMSI-Umgehung hat gezeigt, wie Angreifer die Skript-Prüfung ausschalten. ETW setzt eine Ebene tiefer an: Es ist die Infrastruktur, über die der Kernel, zahllose Windows-Komponenten und moderne Endpoint-Sensoren ihre Ereignisse melden. Besonders wichtig ist der Threat-Intelligence-Provider ETW-TI, aus dem viele EDR-Lösungen ihre verhaltensbasierte Erkennung speisen. Fällt ETW aus, verstummt nicht nur ein Log, sondern eine ganze Klasse von Sensoren gleichzeitig. Der Beitrag bleibt auf der Verteidigerseite und bleibt konzeptionell.

Was der Angreifer tut

ETW lässt sich auf mehreren Ebenen stören. Auf der Ebene des Prinzips, nicht als Anleitung, sind das vor allem drei:

• EtwEventWrite im Prozess patchen. Die leiseste Variante überschreibt im eigenen Prozess die Funktion, die Ereignisse an ETW übergibt, sodass sie sofort und ohne Meldung zurückkehrt. Der Sensor bekommt dann schlicht nichts mehr zu sehen.
• Provider in der Registry abschalten. Unter den Autologger-Schlüsseln lässt sich ein Provider dauerhaft deaktivieren, indem sein Wert Enabled auf 0 gesetzt wird. Nach dem nächsten Neustart liefert diese Quelle nichts mehr - ein beliebtes Ziel ist der ETW-TI-Provider.
• Sitzungen per Bordmittel stoppen. Mit logman, wevtutil oder den passenden PowerShell-Cmdlets lässt sich eine laufende Trace-Sitzung anhalten oder umkonfigurieren - ganz ohne eigenen Schadcode, nur mit Windows-eigenen Werkzeugen.

Allen gemein ist das Ziel: Die Telemetrie soll ausfallen, bevor die eigentliche Aktivität läuft. Weil ETW so zentral ist, trifft das viele Sensoren auf einmal - was den Angriff mächtig macht, aber auch an einer gut überwachbaren Stelle ansetzt.

Welche Logquellen die Technik zeigt

• PowerShell Script Block Logging. Event-ID 4104 zeigt die Funktionsnamen eines ETW-Patches im entschlüsselten Skript. Die Grundlage legt PowerShell für Verteidiger.
• Registry-Telemetrie. Sysmon Event 13 zeigt das Setzen des Werts Enabled auf 0 unter den Autologger-Schlüsseln - das klarste Signal für ein dauerhaftes Abschalten.
• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen Aufrufe von logman oder wevtutil mit verräterischen Parametern sowie die ETW-Cmdlets in der Kommandozeile.
• Der Ausfall selbst. Ein plötzliches Verstummen einer sonst regen Quelle ist ein eigenes Signal. Dafür muss das erwartete Volumen je Quelle bekannt sein - siehe Sysmon einrichten für die Endpunkt-Seite.

Das Muster im Log

Am eindeutigsten ist der Registry-Eingriff: Ein Enabled-Wert, der unter einem Autologger-Provider auf 0 fällt, hat außerhalb geplanter Wartung kaum einen Grund - besonders beim ETW-TI-Provider. Die Patch-Funktionsnamen im Script Block sind ähnlich verräterisch, weil sie in Verwaltungsskripten nicht vorkommen. Die Bordmittel logman und wevtutil sind legitime Werkzeuge, deshalb zählt hier der Kontext: wer sie wann und gegen welche Sitzung einsetzt. In Summe gilt dieselbe Logik wie bei der Log-Löschung - der Griff nach der Telemetrie ist oft das letzte laute Ereignis, bevor es still wird, und gehört deshalb eng an eine Reaktion gekoppelt.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste nutzt die Patch-Funktionsnamen, die zweite den Registry-Eingriff, die dritte die Bordmittel. Die zweite ist die aussagekräftigste, weil ein abgeschalteter Provider kaum je legitim ist.

1. ETW-Patch-Muster im Script Block (T1685). Funktionsnamen eines In-Process-Patches. Die Regel steht auf level: high.

title: ETW-Patch-Muster im PowerShell Script Block
id: 4a1e8c92-6b73-4f0d-9a2c-1d5e7b3a84f6
status: experimental
description: |
  Erkennt Hinweise auf das Aushebeln von Event Tracing for Windows (ETW) aus
  PowerShell heraus. Angreifer ueberschreiben im eigenen Prozess die Funktion
  EtwEventWrite, damit Telemetrie gar nicht erst geschrieben wird. Die dafuer
  genutzten Funktionsnamen tauchen in regulaeren Verwaltungsskripten praktisch nie auf.
references:
  - https://attack.mitre.org/techniques/T1685/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685
logsource:
  product: windows
  category: ps_script
detection:
  selection:
    ScriptBlockText|contains:
      - 'EtwEventWrite'
      - 'EtwpEventWrite'
      - 'NtTraceEvent'
      - 'EtwNotificationRegister'
  condition: selection
falsepositives:
  - Sicherheitsforschung und Awareness-Demos auf dafuer vorgesehenen Testsystemen
level: high

2. ETW-Autologger-Provider deaktiviert (T1685). Der Wert Enabled auf 0 unter einem Autologger-Schlüssel. Ebenfalls level: high.

title: ETW-Autologger-Provider deaktiviert
id: 9d2f71a4-3c08-4e6b-8f15-6a4c2b9d70e1
status: experimental
description: |
  Erkennt das Abschalten eines ETW-Providers in einer Autologger-Sitzung. Wird der
  Wert Enabled eines Providers auf 0 gesetzt, liefert diese Telemetriequelle nach dem
  naechsten Neustart nichts mehr - ein beliebter Weg, um den ETW-TI-Provider oder die
  Sicherheitsprotokollierung dauerhaft blind zu schalten.
references:
  - https://attack.mitre.org/techniques/T1685/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685
logsource:
  product: windows
  category: registry_set
detection:
  selection:
    TargetObject|contains: '\Control\WMI\Autologger\'
    TargetObject|endswith: '\Enabled'
    Details: 'DWORD (0x00000000)'
  condition: selection
falsepositives:
  - Geplante Umbauten an der Telemetrie durch die Administration; nach Host und Zeitfenster ausnehmen
level: high

3. ETW-Sitzung per Bordmittel gestoppt (T1685). logman, wevtutil oder die ETW-Cmdlets in der Kommandozeile. level: medium, weil es legitime Wartung gibt.

title: ETW-Sitzung per Bordmittel gestoppt oder veraendert
id: 1b7c3e56-8a49-4d2f-b013-5e9a6c4d82b7
status: experimental
description: |
  Erkennt das Stoppen oder Umkonfigurieren von ETW-Sitzungen ueber Bordmittel. Mit
  logman, wevtutil oder den PowerShell-Cmdlets fuer ETW-Trace-Provider laesst sich eine
  laufende Protokollierung gezielt abschalten. Legitim meist nur bei Wartung, daher als
  mittel eingestuft und auf Baselining angewiesen.
references:
  - https://attack.mitre.org/techniques/T1685/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685
logsource:
  product: windows
  category: process_creation
detection:
  selection_logman:
    Image|endswith: '\logman.exe'
    CommandLine|contains:
      - ' stop '
      - ' update '
  selection_wevtutil:
    Image|endswith: '\wevtutil.exe'
    CommandLine|contains: '/e:false'
  selection_ps:
    CommandLine|contains:
      - 'Set-EtwTraceProvider'
      - 'Remove-EtwTraceProvider'
      - 'Disable-EtwTraceProvider'
  condition: selection_logman or selection_wevtutil or selection_ps
falsepositives:
  - Wartung und Diagnose durch die Administration; bekannte Jobs und Konten als Baseline ausnehmen
level: medium

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

• Telemetrie zentral sichern. Ereignisse zeitnah wegschreiben und zentral sammeln, damit ein lokaler ETW-Ausfall nicht gleich eine Lücke in der Auswertung bedeutet. Das Prinzip gleicht dem der Event-Log-Löschung.
• Autologger-Schlüssel überwachen. Schreibzugriffe auf die Autologger-Provider auf Administratoren beschränken und jede Änderung an Enabled alarmieren.
• EDR mit Selbstschutz. Eine Lösung wählen, die Manipulation an ihren eigenen ETW-Quellen erkennt und meldet - mehr dazu bei der EDR-Umgehung.
• PowerShell einschnüren. Script Block Logging erzwingen und den Constrained Language Mode einsetzen, wo es geht, damit In-Process-Patches auffallen. Details in PowerShell für Verteidiger.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon und eingeschaltetem Script Block Logging:

• Für Regel 1 ein harmloses Skript ausführen, das einen der Funktionsnamen enthält, ohne tatsächlich zu patchen. Event 4104 muss den Inhalt zeigen.
• Für Regel 2 im Testsystem unter einem Autologger-Provider den Wert Enabled auf 0 setzen. Sysmon Event 13 muss den Zugriff mit dem DWORD-Wert protokollieren.
• Für Regel 3 logman mit stop oder wevtutil gegen eine Testsitzung aufrufen. Event 4688 und Sysmon Event 1 müssen die Kommandozeile zeigen. Breiter wird der Test mit den passenden Fällen aus Atomic Red Team.

Fehlalarme und Tuning

• Legitime Telemetrie-Umbauten. Administratoren konfigurieren ETW-Sitzungen bei Wartung durchaus um. Für Regel 2 und 3 die bekannten Fenster, Konten und Jobs als Baseline ausnehmen.
• Diagnosewerkzeuge. logman und wevtutil laufen auch im normalen Betrieb. Priorisiere Aufrufe, die auf sicherheitsrelevante Sitzungen zielen.
• Sicherheitsforschung. Die Funktionsnamen aus Regel 1 tauchen in Schulungs- und Demo-Material auf. Übungssysteme dokumentieren und filtern.
• Korrelation schlägt Einzelregel. Ein ETW-Eingriff kommt selten allein. Wer ihn mit nachfolgender, plötzlich unprotokollierter Aktivität verknüpft, trennt Wartung und echten Angriff zuverlässiger.

Fazit

ETW zu manipulieren ist für Angreifer der Hebel, um gleich mehrere Sensoren auf einmal blind zu schalten - gerade die verhaltensbasierte EDR-Erkennung hängt an dieser Quelle. Aber jeder der drei Wege berührt eine gut beobachtbare Stelle: die Patch-Funktionen im Script Block, der Enabled-Wert in der Registry und die Bordmittel in der Kommandozeile. Die wirksamste Härtung sichert die Telemetrie zentral, überwacht die Autologger-Schlüssel und setzt auf ein EDR mit Selbstschutz. Als Nächstes folgt das Abschalten der Sicherheits- und Audit-Protokollierung, das den Defense-Impairment-Teil der Welle abrundet. Verwandt sind die AMSI-Umgehung und die Event-Log-Löschung. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Defense Impairment.