Audit-Logging abschalten erkennen: wenn gar nichts mehr entsteht

Dieser Beitrag schließt den Defense-Impairment-Teil der Welle ab. Nach der AMSI-Umgehung und der ETW-Manipulation geht es nun um die direkteste Form, der Abwehr die Sicht zu nehmen: die Sicherheits- und Audit-Protokollierung ganz abzuschalten. Das ist die Kehrseite der Event-Log-Löschung. Statt nachträglich Spuren zu verwischen, sorgt der Angreifer dafür, dass gar keine Spuren entstehen. Weil nichts gelöscht wird, fehlt auch die verräterische Lücke - die Erkennung muss deshalb am Akt des Abschaltens ansetzen. Der Beitrag bleibt auf der Verteidigerseite und bleibt konzeptionell.

Was der Angreifer tut

Die Protokollierung lässt sich auf mehreren Ebenen stilllegen. Auf der Ebene des Prinzips, nicht als Anleitung, sind das vor allem drei:

• Audit-Richtlinie abschalten. Mit auditpol wird die Protokollierung für ganze Kategorien oder alle Unterkategorien auf disable gesetzt. Danach entstehen die betroffenen Sicherheitsereignisse gar nicht erst - ganz ohne einen einzigen Löschvorgang.
• Den EventLog-Dienst stoppen. Steht der Dienst still, schreibt Windows nichts mehr in die Protokolle. Der Dienst ist gegen simples Beenden geschützt, deshalb führt der Weg über sc, net, PowerShell oder den Startwert in der Registry.
• Einen Kanal gezielt deaktivieren. Über den Wert Enabled eines Kanals unter WINEVT\Channels lässt sich ein einzelnes Protokoll - etwa das Sicherheits- oder das PowerShell-Operational-Log - abschalten, ohne den ganzen Dienst anzufassen. Das ist besonders leise.

Allen gemein ist: Es wird nichts gelöscht, sondern die Quelle versiegt. Der entscheidende Hebel für die Verteidigung ist, dass das Abschalten selbst noch einmal protokolliert wird - es ist das letzte Ereignis, bevor es dunkel wird.

Welche Logquellen die Technik zeigt

• Die Audit-Richtlinie selbst. Event-ID 4719 meldet jede Änderung an der Systemaudit-Richtlinie - das direkte Signal, wenn auditpol Kategorien abschaltet. Dieses Ereignis entsteht noch, bevor die Protokollierung aussetzt.
• Prozess-Telemetrie. Event 4688 zeigt die Aufrufe von auditpol, sc, net oder der Service-Cmdlets samt Kommandozeile - auch dann, wenn 4719 durch die Reihenfolge verpasst würde.
• Registry-Telemetrie. Sysmon Event 13 zeigt das Setzen des Werts Enabled auf 0 unter WINEVT\Channels sowie Änderungen am Startwert des EventLog-Dienstes.
• Der Ausfall selbst. Ein Host, der plötzlich keine Sicherheitsereignisse mehr liefert, 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

Das klarste native Signal ist Event 4719: Eine Audit-Kategorie, die auf "keine Überwachung" umspringt, hat außerhalb geplanter Umbauten kaum einen Grund. Ergänzt wird es durch die Kommandozeilen von auditpol, sc und net sowie durch den Enabled-Wert eines Kanals, der in der Registry auf 0 fällt. Entscheidend ist der Zeitpunkt: Diese Ereignisse stehen ganz am Ende der Spur, unmittelbar bevor der Angreifer im Dunkeln weiterarbeitet. Genau wie bei der Log-Löschung gilt deshalb - der Griff nach der Protokollierung gehört eng an eine sofortige Reaktion gekoppelt, sonst ist er das letzte, was man sieht.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und über alle Backends sauber übersetzbar. Die erste nutzt auditpol, die zweite den EventLog-Dienst, die dritte den Registry-Kanal. Zusammen decken sie die drei Wege ab, auf denen die Protokollierung versiegt.

1. Audit-Richtlinie per auditpol abgeschaltet (T1685.001). auditpol mit disable, clear oder remove. Die Regel steht auf level: high.

title: Audit-Richtlinie per auditpol abgeschaltet
id: 7e3a1c58-4b92-4d6f-a107-2c9e5b8d41f3
status: experimental
description: |
  Erkennt das Abschalten der Windows-Audit-Richtlinie ueber auditpol. Mit einem
  einzigen Aufruf laesst sich die Protokollierung fuer ganze Kategorien oder alle
  Unterkategorien auf disable setzen - danach entstehen die sicherheitsrelevanten
  Ereignisse gar nicht erst. Legitim ist das fast nur bei geplanten Umbauten.
references:
  - https://attack.mitre.org/techniques/T1685/001/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685.001
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\auditpol.exe'
    CommandLine|contains:
      - '/success:disable'
      - '/failure:disable'
  selection_clear:
    Image|endswith: '\auditpol.exe'
    CommandLine|contains:
      - '/clear'
      - '/remove'
  condition: selection or selection_clear
falsepositives:
  - Geplante Umstellung der Audit-Richtlinie durch die Administration; Fenster und Konten als Baseline ausnehmen
level: high

2. EventLog-Dienst gestoppt oder deaktiviert (T1685.001). sc, net oder die Service-Cmdlets gegen den Dienst EventLog. Ebenfalls level: high.

title: EventLog-Dienst per Bordmittel gestoppt oder deaktiviert
id: 2d6b94e1-7f30-4a85-9c12-6e4a1b3d70c8
status: experimental
description: |
  Erkennt den Versuch, den Windows-Dienst EventLog anzuhalten oder dauerhaft zu
  deaktivieren. Steht der Dienst still, schreibt Windows keine Ereignisse mehr in die
  Protokolle. Der Dienst ist bewusst gegen ein simples Beenden geschuetzt, daher
  greifen Angreifer zu sc, net oder PowerShell.
references:
  - https://attack.mitre.org/techniques/T1685/001/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685.001
logsource:
  product: windows
  category: process_creation
detection:
  img_tools:
    Image|endswith:
      - '\sc.exe'
      - '\net.exe'
      - '\net1.exe'
  cmd_action:
    CommandLine|contains:
      - 'stop'
      - 'config'
      - 'disabled'
  cmd_ps:
    CommandLine|contains:
      - 'Stop-Service'
      - 'Set-Service'
  cmd_eventlog:
    CommandLine|contains: 'eventlog'
  condition: (img_tools and cmd_action and cmd_eventlog) or (cmd_ps and cmd_eventlog)
falsepositives:
  - Wartungsarbeiten am Protokolldienst durch die Administration; bekannte Faelle ausnehmen
level: high

3. Protokollkanal in der Registry deaktiviert (T1685.001). Der Wert Enabled auf 0 unter WINEVT\Channels. Ebenfalls level: high.

title: Windows-Protokollkanal in der Registry deaktiviert
id: 5c81f7a0-3e49-4b2d-8f06-1a7c6b4e92d5
status: experimental
description: |
  Erkennt das Abschalten eines einzelnen Windows-Protokollkanals ueber die Registry.
  Wird der Wert Enabled eines Kanals unter WINEVT\Channels auf 0 gesetzt, protokolliert
  dieser Kanal nichts mehr - ein gezielter, leiser Weg, um etwa das Sicherheits- oder
  PowerShell-Operational-Log blind zu schalten, ohne den ganzen Dienst zu stoppen.
references:
  - https://attack.mitre.org/techniques/T1685/001/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685.001
logsource:
  product: windows
  category: registry_set
detection:
  selection:
    TargetObject|contains: '\WINEVT\Channels\'
    TargetObject|endswith: '\Enabled'
    Details: 'DWORD (0x00000000)'
  condition: selection
falsepositives:
  - Bewusste Deaktivierung eines sehr lauten Kanals durch die Administration; nach Kanal und Host ausnehmen
level: high

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

• Protokolle sofort wegschreiben. Ereignisse per Weiterleitung zeitnah zentral sammeln, damit ein lokales Abschalten die bereits übertragenen Daten nicht mehr erreicht - dasselbe Prinzip wie gegen die Event-Log-Löschung.
• Audit-Richtlinie per GPO erzwingen. Die erweiterte Audit-Richtlinie zentral vorgeben, sodass ein lokales auditpol-Kommando beim nächsten Richtlinienabgleich wieder überschrieben wird.
• Rechte einschränken. Das Ändern der Audit-Richtlinie und das Steuern des EventLog-Dienstes auf wenige Administratoren begrenzen und jede solche Aktion alarmieren.
• Kanal-Schlüssel überwachen. Schreibzugriffe auf WINEVT\Channels und den Startwert des EventLog-Dienstes als eigene, scharfe Regel führen.

Der Test

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

• Für Regel 1 auditpol mit einer harmlosen Unterkategorie auf disable setzen. Event 4719 und Event 4688 müssen den Vorgang zeigen; danach die Richtlinie wieder aktivieren.
• Für Regel 2 im Testsystem den EventLog-Dienst über sc oder Stop-Service anhalten. Event 4688 muss die Kommandozeile zeigen.
• Für Regel 3 unter WINEVT\Channels für einen unkritischen Kanal den Wert Enabled auf 0 setzen. Sysmon Event 13 muss den Zugriff protokollieren. Breiter wird der Test mit den passenden Fällen aus Atomic Red Team.

Fehlalarme und Tuning

• Geplante Richtlinien-Umbauten. Administratoren stellen Audit-Einstellungen legitim um. Für Regel 1 die bekannten Fenster und Konten als Baseline ausnehmen.
• Dienst-Wartung. Der EventLog-Dienst wird selten, aber doch bei Wartung angefasst. Treffer mit dem Wartungskalender abgleichen.
• Laute Kanäle. Gelegentlich wird ein sehr gesprächiger Kanal bewusst deaktiviert. Für Regel 3 nach Kanal und Host ausnehmen, statt die Regel zu entschärfen.
• Korrelation schlägt Einzelregel. Ein Abschalten der Protokollierung kommt selten allein. Wer es mit vorangehender Rechteausweitung oder nachfolgender, plötzlich unprotokollierter Aktivität verknüpft, trennt Wartung und echten Angriff zuverlässiger.

Fazit

Die Protokollierung abzuschalten ist die leiseste Art, blind zu machen: Es fehlt keine Zeile, es entsteht nur keine mehr. Der Hebel für die Verteidigung ist, dass das Abschalten selbst ein letztes Ereignis erzeugt - Event 4719 für die Audit-Richtlinie, die Kommandozeilen von auditpol und sc, der Enabled-Wert in der Registry. Die wirksamste Härtung schreibt Protokolle sofort zentral weg, erzwingt die Audit-Richtlinie per GPO und beschränkt die Rechte am EventLog-Dienst. Damit ist der Defense-Impairment-Teil der Welle abgeschlossen. Verwandt sind die Event-Log-Löschung, die ETW-Manipulation und der offizielle Weg, Defender abzuschalten. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Defense Impairment.