B01 Löschung von Ereignisprotokollen

Einleitung

Die Überwachung der Integrität von Ereignisprotokollen gehört zu den grundlegendsten Bausteinen einer wirksamen Angriffserkennung. Der Use-Case B01 – Löschung von Ereignisprotokollen behandelt die detektive Maßnahme, das Entfernen protokollierter Daten frühzeitig zu erkennen. Da Ereignisprotokolle eine zentrale Quelle für forensische Analysen, Incident-Response-Prozesse und die Nachvollziehbarkeit von Benutzer- oder Systemaktivitäten darstellen, führt ihre Manipulation unweigerlich zu einer deutlichen Reduzierung der Transparenz innerhalb der IT-Landschaft. Angreifer löschen Logs häufig, um Spuren zu verwischen, Privilegienausweitungen zu verbergen oder Schadaktivitäten unentdeckt zu lassen.

Der Use-Case sieht daher vor, dass jede Löschung eines Ereignisprotokolls überwacht und bewertet wird. Technisch geschieht dies über das Ereignisformat LOG01, welches protokolliert, wenn Logdateien auf einem System entfernt wurden. Neben der reinen Detektion wird auch das ausführende Benutzerkonto sowie das betroffene System berücksichtigt. In vielen Fällen existieren legitimierte Prozesse — etwa reguläre Housekeeping-Jobs oder Backup-Rotationen — deren Aktivitäten in Negativlisten hinterlegt werden, damit keine unnötigen Fehlalarme ausgelöst werden. Gleichzeitig kann über Positivlisten sichergestellt werden, dass bestimmte besonders sensible Benutzerkonten grundsätzlich eine Alarmierung auslösen, selbst wenn sie in automatisierten Abläufen vorkommen.

Die Dringlichkeit dieses Use-Cases ist hoch einzustufen: Wird ein Löschvorgang erkannt, besteht die Möglichkeit, dass weitere sicherheitsrelevante Ereignisse bereits entfernt wurden. Der empfohlene Reaktionstyp ist daher eine unmittelbare Warnmeldung mit anschließender forensischer Prüfung. Idealerweise werden Ereignisprotokolle bereits vor der Löschung auf einen sicheren, manipulationsgeschützten Server übertragen, sodass trotz einer Löschung auf dem Ursprungssystem eine Rekonstruktion der Vorgänge möglich bleibt.

Die Auswertung nach Use-Case B01 bildet eine unverzichtbare Grundlage für nahezu alle weiteren Use-Cases im Katalog. Ohne funktionierende Logquellen – oder im Falle manipulierter bzw. gelöschter Logs – ist eine zuverlässige Erkennung von Angriffsmustern praktisch unmöglich. Durch die Implementierung dieses Use-Cases wird daher ein fundamentales Minimum an Detektionsfähigkeit geschaffen, das sowohl für kleine als auch für große Organisationen essenziell ist.

Implementierung

Die Möglichkeiten zur Implementierung sind vielfältig und hängen stark von der Umgebung ab, false-positives sind immer möglich, eingeständig zu prüfen und entsprechend auszuschließen.

Mitre

Mit den MITRE Framework lässt sich zu Beginn ein einfacher Filter erzeugen:

Search String

Im Modul Threat Hunting lässt sich ebenfalls ein komplexerer Search String erstellen, wie immer muss für jede Umgebung nachgearbeitet werden:

(
    (
        (
            data.win.system.eventID:(1102 OR 104)
            OR rule.description:(*log* AND (*cleared* OR *deleted*))
            OR message:(*log* AND (*cleared* OR *deleted*))
            OR rule.mitre.technique:("Indicator Removal" OR "Indicator Remove on Host")
        )
        AND NOT (data.win.system.providerName:("Microsoft-Windows-TerminalServices-ClientActiveXCore") OR data.win.system.providerName:("Microsoft-Windows-TaskScheduler"))
    )
    OR
    (
        rule.mitre.id:("T1070" OR "T1070.001" OR "T1070.004")  
        AND NOT (rule.groups:("syscheck_entry_deleted OR syscheck_registry"))
    )
)
AND
(
    data.srcuser:*
    OR data.dstuser:* 
    OR data.win.eventdata.user:*
    OR data.win.eventdata.userName:*
    OR data.win.eventdata.subjectUserName:*
    OR data.win.logFileCleared.subjectUserName:*
    OR data.win.eventdata.targetUserName:*
)
AND
(
    host.name:*
    OR agent.name:*
    OR agent.ip:*
)

FIM / auditd

Über das Modul File Integrity Monitoring aber auch auditd lassen sich ebenfalls Manipulationen an Logdateien erkennen. Ein detaillierte Beschreibung hierzu ist in Arbeit …