Event-Log-Löschung erkennen: Event 1102, wevtutil und der Protokolldienst

Event-Log-Löschung erkennen ist eine der dankbarsten Erkennungen überhaupt, weil sie fast kein Rauschen hat: Ein geleertes Sicherheitsprotokoll gehört nicht zum normalen Betrieb. Angreifer greifen trotzdem dazu, weil Protokolle der direkteste Beweis für ihr Tun sind. Die Ironie dabei: Das Löschen beseitigt die alten Spuren, erzeugt aber eine neue, die deutlicher ist als alles, was gelöscht wurde. Dieser Beitrag aus der Serie "Angriff erkennen" zeigt die Technik aus Verteidigersicht, mit drei Sigma-Regeln, der Härtung und dem Test. Verwandt ist das Blindmachen der Endpunktsicherung, behandelt im Beitrag zu EDR-Umgehung erkennen.

Was der Angreifer tut

Um die Protokollierung auszuhebeln, gibt es drei Wege. Auf der Ebene des Prinzips, nicht als Anleitung:

• Das ganze Protokoll leeren. Mit Bordmitteln wie wevtutil oder den PowerShell-Cmdlets wird ein Ereignisprotokoll komplett geleert, am häufigsten das Sicherheitsprotokoll.
• Die Protokollierung abschalten. Wer den Ereignisprotokolldienst stoppt oder deaktiviert, verhindert, dass überhaupt noch etwas geschrieben wird, ohne ein einzelnes Log zu leeren.
• Gezielt eingreifen. Feiner ist das Verstellen der Protokollgröße oder das Abschalten einzelner Kanäle, sodass belastende Ereignisse überschrieben werden oder gar nicht erst entstehen.

Für die Erkennung ist entscheidend: Jeder dieser Eingriffe ist selbst ein Ereignis. Das Leeren erzeugt einen Eintrag, das Stoppen des Dienstes ebenso, und der Aufruf der Werkzeuge erscheint in der Prozessüberwachung. Das Aufräumen lässt sich nicht aufräumen.

Welche Logquellen die Technik zeigt

• Das geleerte Sicherheitsprotokoll. Event 1102 wird geschrieben, sobald das Sicherheitsprotokoll geleert wird, mit dem Konto, das es getan hat. Das ist die klarste und fehlalarmärmste Quelle.
• Der gestoppte Dienst. Das Herunterfahren des Ereignisprotokolls wird als Event 1100 vermerkt; ein unerwartetes 1100 außerhalb eines Neustarts ist verdächtig.
• Der Werkzeugaufruf. Event 4688 und Sysmon Event 1 zeigen wevtutil, die PowerShell-Cmdlets oder sc mit der Kommandozeile, oft noch bevor das Log geleert ist.
• Die zentrale Kopie. Wo Ereignisse weitergeleitet werden, liegt die Spur längst auf dem Sammelserver, wenn das lokale Log fällt; siehe Windows Event Forwarding.

Das Muster im Log

Das stärkste Signal ist Event 1102 selbst: Es hat kaum einen legitimen Grund außerhalb eines dokumentierten Wartungsfensters und gehört zu den wenigen Ereignissen, auf die sich ein Alarm fast ohne Tuning lohnt. Noch aussagekräftiger ist der Kontext: Wer hat geleert, von welchem Host, und was stand kurz davor im Protokoll. Ein 1102, dem Minuten vorher verdächtige Anmeldungen oder Prozessstarts vorausgingen, ist das Ende einer Kette, nicht ihr Anfang. Verdächtig sind ebenso ein wevtutil cl aus einem Skript-Host und ein gestoppter Protokolldienst ohne zugehörigen Neustart. Weil das Löschen die lokale Spur kappt, zählt hier die zentrale Sammlung doppelt: Sie bewahrt genau das auf, was der Angreifer verschwinden lassen will.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste nutzt das Ereignis des Leerens, die zweite und dritte den Werkzeugaufruf. Regel 1 setzt das Sicherheitsprotokoll voraus, die anderen die Prozessüberwachung mit Kommandozeile.

1. Sicherheitsprotokoll geleert (T1685.005). Event 1102 ist fast immer relevant und steht auf level: high.

title: Windows-Sicherheitsprotokoll geleert
id: 824efd66-8810-4680-a0fe-7e26fcab2658
status: experimental
description: |
  Erkennt das Leeren des Windows-Sicherheitsprotokolls (Event 1102). Angreifer
  loeschen Protokolle, um ihre Spuren zu verwischen. Das Leeren selbst erzeugt
  Event 1102 und ist damit eine der wenigen fast fehlalarmfreien Erkennungen.
references:
  - https://attack.mitre.org/techniques/T1685/005/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685.005
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 1102
  condition: selection
falsepositives:
  - Geplantes Archivieren oder Zuruecksetzen von Protokollen im Wartungsfenster; dokumentieren und korrelieren
level: high

2. Protokoll per wevtutil oder PowerShell geleert (T1685.005). Der aktive Löschbefehl, sichtbar in der Kommandozeile. Ebenfalls level: high.

title: Ereignisprotokoll per wevtutil oder PowerShell geleert
id: b42e4a10-1544-4e1f-84d5-b135d7d24819
status: experimental
description: |
  Erkennt das Leeren von Ereignisprotokollen ueber wevtutil oder die
  PowerShell-Cmdlets Clear-EventLog, Remove-EventLog und Limit-EventLog. Das ist
  der aktive Weg, mit dem ein Angreifer Spuren entfernt, bevor oder nachdem er
  sein Ziel erreicht hat.
references:
  - https://attack.mitre.org/techniques/T1685/005/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685.005
logsource:
  category: process_creation
  product: windows
detection:
  selection_wevtutil:
    Image|endswith: '\wevtutil.exe'
    CommandLine|contains:
      - ' cl '
      - ' clear-log'
  selection_ps:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'Clear-EventLog'
      - 'Remove-EventLog'
      - 'Limit-EventLog'
  condition: selection_wevtutil or selection_ps
falsepositives:
  - Administrative Wartung, die Protokolle gezielt leert; nach Konto und Host ausnehmen
level: high

3. Protokolldienst gestoppt oder deaktiviert (T1685.001). Der Eingriff in genau den Ereignisprotokolldienst ist im Normalbetrieb sehr selten. Die Regel steht auf level: high.

title: Windows-Ereignisprotokolldienst gestoppt oder deaktiviert
id: 9d784581-dd6f-4305-8748-608adbdfcae6
status: experimental
description: |
  Erkennt das Stoppen oder Deaktivieren des Ereignisprotokolldienstes ueber sc
  oder net. Wer den Dienst anhaelt, unterbindet die Protokollierung, ohne ein
  einzelnes Log zu leeren. Der Eingriff in genau diesen Dienst ist im Normalbetrieb
  sehr selten.
references:
  - https://attack.mitre.org/techniques/T1685/001/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_sc:
    Image|endswith: '\sc.exe'
    CommandLine|contains|all:
      - 'eventlog'
    CommandLine|contains:
      - ' stop'
      - 'start= disabled'
      - 'config'
  selection_net:
    Image|endswith:
      - '\net.exe'
      - '\net1.exe'
    CommandLine|contains|all:
      - 'stop'
      - 'eventlog'
  condition: selection_sc or selection_net
falsepositives:
  - Administrative Dienststeuerung in Wartungsfenstern; nach Konto und Host ausnehmen
level: high

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

• Protokolle zentral sammeln. Die wirksamste Gegenmaßnahme: Ereignisse per Windows Event Forwarding oder Agent sofort an einen Sammelserver schicken. Dann läuft jedes lokale Leeren ins Leere, weil die Kopie längst woanders liegt.
• Löschrechte einschränken. Das Leeren des Sicherheitsprotokolls erfordert hohe Rechte. Wer diese Rechte eng hält und das Leeren als Alarm führt, macht das Manöver teuer.
• Protokollgröße und Aufbewahrung sichern. Ausreichend große, nicht überschreibbare Protokolle und eine Mindestaufbewahrung verhindern, dass belastende Ereignisse von selbst verschwinden.
• Manipulationsschutz. Wo verfügbar, schützt die Härtung des Protokolldienstes und der Zugriffsrechte davor, dass der Dienst einfach gestoppt wird.

Der Test

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

• Für Regel 1 das Sicherheitsprotokoll in der Ereignisanzeige leeren. Es muss unmittelbar ein Event 1102 erscheinen.
• Für Regel 2 ein unkritisches Protokoll per wevtutil cl oder Clear-EventLog leeren. Event 4688 muss den Aufruf mit Kommandozeile zeigen.
• Für Regel 3 den Ereignisprotokolldienst testweise stoppen und wieder starten. Event 4688 muss den sc- oder net-Aufruf zeigen, dazu das Event 1100. Vollständiger wird der Test mit den Fällen zu T1070 und T1562 aus Atomic Red Team.

Fehlalarme und Tuning

• Wartungsfenster. Geplantes Archivieren oder Zurücksetzen von Protokollen erzeugt legitime 1102-Ereignisse. Dokumentiere diese Fenster und korreliere die Treffer dagegen, statt die Regel zu entschärfen.
• Backup- und Monitoring-Agenten. Manche greifen auf Protokolle zu oder starten Dienste neu. Erfasse die bekannten Konten und Hosts als Ausnahme.
• Konto und Host gewichten. Ein 1102 von einem Admin-Jumphost im Wartungsfenster wiegt leicht, dasselbe von einem Arbeitsplatz mitten am Tag wiegt schwer. Reichere die Treffer um Konto, Host und Uhrzeit an.
• Priorität. Event 1102 und ein gestoppter Protokolldienst gehören zu den hochprioren Alarmen und verdienen eine sofortige Rückfrage.

Fazit

Das Löschen von Protokollen ist der Versuch, Spuren zu verwischen, und zugleich eine der deutlichsten Spuren überhaupt. Event 1102, der gestoppte Protokolldienst und der Werkzeugaufruf ergeben zusammen ein klares Bild. Die stärkste Antwort ist nicht nur die Regel, sondern die zentrale Sammlung: Wer Ereignisse sofort weiterleitet, nimmt dem Löschen seinen Sinn. Verwandt ist das Blindmachen der Endpunktsicherung unter EDR-Umgehung erkennen. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Defense Impairment.