Eventlogs, die im IT-Notfall besser aktiviert sind

In der IT-Forensik stellen Eventlogs und die enthaltenen Zeitstempel eine nahezu unabdingbare Informationsquelle dar. Doch viele Eventlogs (dt. Ereignisprotokolle) sind nicht standardmäßig aktiviert. Wir zeigen im Folgenden auf, welche Logs bei der forensischen Analyse von besonderer Bedeutung sind und wie durch die Aktivierung dieser auch gleichzeitig die Forensic Readiness gesteigert wird.

Forensic Readiness – gewappnet für den Notfall

Wie der Name bereits sagt, geht es um präventive Maßnahmen für eine spätere IT-forensische Untersuchung. Wurde ein Unternehmen Opfer eines Cyberangriffs, ist es zwingend notwendig diesen forensisch aufzuarbeiten. Hier gilt es nicht nur den Tathergang nachzuvollziehen, um ggf. rechtliche Schritte einleiten zu können. Denn schon bei der Planung des Wiederaufbaus ist es entscheidend zu wissen, welche Sicherheitslücken ausgenutzt wurden, um die Wahrscheinlichkeit von wiederholten Angriffen zu verringern. Zudem sollte im Zuge dessen der Umgang mit dem nächsten Angriff und ggf. das Verhalten im Notfall betrachtet werden – Stichwort „Lessons learned“ (dt. Lektion gelernt).

Doch um stichhaltige Beweise zu sichern und Maßnahmen für die Zukunft empfehlen zu können, müssen Systeme entsprechend vorbereitet sein. Dies kann u.a. die Sicherstellung einer ausführlichen Protokollierung oder deren Ausweitung sein. Empfehlungen für die Größe von gespeicherten Protokolldateien variieren abhängig vom Log und der IT-Umgebung.

In vielen Fällen empfiehlt sich jedoch zu prüfen, ob auch die Aktivierung von weniger gängigen Protokollen lohnt. Denn oftmals sind wichtige Logs nicht standardmäßig aktiviert.

Wichtige Windows Eventlogs

Im Folgenden stellen wir eine Auswahl von Windows Eventlogs vor, auf die sich IT-Forensiker im IT-Notfall verlassen:

Security Log

Im Security Log werden eine Vielzahl von verschiedenen Ereignissen protokolliert. Aus forensischer Sicht sind vor allem die protokollierten Benutzeranmeldungen ein wichtiges Indiz dafür, wie sich Angreifer durch das Netzwerk bewegen. Auf der einen Seite stellt das Protokoll mit einer großen Menge an Ereignissen eine wichtige Informationsquelle für eine Untersuchung dar. Auf der anderen Seite führt die hohe Anzahl an Ereignissen oft zu einem überfüllten Protokoll. Dann werden alte und möglicherweise relevante Daten mit neuen Einträgen überschrieben. Einer von vielen Gründen, um die Standardgröße dieser Protokolldatei zu erhöhen.

Ein weiterer Grund ist die Möglichkeit die Überwachung der Kommandozeile auszuweiten. Mit der Einführung von Server 2012R2 hatte Microsoft eine neue Richtline eingeführt, um die Protokollierung von Prozess Erstellungen zu dokumentieren. Diese ist standardmäßig deaktiviert, da hierbei eine Vielzahl an Ereignissen festgehalten wird. Im Gegenzug lassen sich jedoch weitreichende Schlüsse über schadhafte Prozesse ziehen.

Dies kann bei der Ermittlung zum entscheidenden Durchbruch führen und eine andernfalls unsichtbar gebliebene Backdoor aufdecken, was ein weiterer Grund für die Erweiterung von Speicherkapazitäten für Protokolldateien sowie die Aktivierung von weniger gängigen Eventlogs wäre.

System Log

Ähnlich verhält es sich mit dem System Log. Hier lassen sich im Besonderen schadhafte Programme oder Prozesse feststellen. Die Event-ID 7045 beispielsweise zeigt die Installation eines neuen Dienstes. Dienste sowie auch geplante Aufgaben werden vermehrt von Angreifern verwendet, um auch nach dem Neustart eines Systems einen Zugang aufrecht zu erhalten. Im Folgenden zeigen wir, wie die Aktivierung von nicht standardmäßig eingeschalteten Protokollen die Problematik von zu schnell vollgelaufenen Protokollen gemindert werden kann.

Task Scheduler / Operational Log

Ein Beispiel für ein Ereignis, welches im Securitylog mit der Event-ID 4698 gelistet wird, jedoch auch in einem separaten Protokoll aufgeführt werden würde, ist die Erstellung einer geplanten Aufgabe. Im Microsoft Windows Task Scheduler / Operational Log wird jedes Ereignis im Zusammenhang mit geplanten Aufgaben protokolliert. Aus forensischer Sicht sind diese Ereignisse von enormer Bedeutung, da sie aufzeigen können, auf welchen Systemen die Angreifer Persistenz erlangt haben.

Jedoch ist dieses Protokoll bei neueren Versionen von Windows (Windows 10 & 11) nicht standardmäßig aktiviert. Aus den bereits genannten Gründen empfehlen wir jedoch die Aktivierung dieses Protokolls. Dies kann u.a, über Gruppenrichtlinien geregelt werden.

PowerShell / Operational Log

Während PowerShell ein vielseitiges Werkzeug zur Verwaltung einer IT-Infrastruktur darstellt, wird es aus eben denselben Gründen immer häufiger von Angreifern verwendet. Das Microsoft Windows PowerShell / Operational Log stellt somit für IT-Forensiker eine ebenso wichtige Informationsquelle dar. Um der Menge an protokollierten Ereignissen über ein Jahr hinweg gerecht zu werden, empfiehlt FireEye die Größe der Protokolldatei auf mindestens 1GB zu setzen.

Zudem sollte beachtet werden, dass auch Module wie Skriptblockprotokollierung, und automatische Transkription aktiviert werden. Dies lässt sich ebenfalls über Gruppenrichtlinien festlegen (Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows Komponenten > Windows PowerShell)

Neben dem PowerShell-Protokoll zeigen auch die Eventlogs des Remote-Desktop-Protokolls die Bewegungen von Angreifern auf. Auch hier sind verschiedene Konfigurationen möglich.

Voraussetzungen schaffen, um Schäden zu minimieren

Das Konfigurieren der einzelnen Protokolle und die Bereitstellung der nötigen Ressourcen bedürfen einigen Aufwands. Gleichzeitig sollte das in der DSGVO festgelegte Prinzip der Datenminimierung nicht übergangen werden. Entsprechende Maßnahmen sollten immer im Einzelnen mit dem Datenschutzbeauftragten abgestimmt werden.

Um jedoch im Notfall einem Angriff nicht hilflos ausgeliefert zu sein, bedarf es einer Vielzahl von Vorbereitungen. Das es früher oder später zu einem IT-Sicherheitsvorfall kommt, kann nie ausgeschlossen werden. Die Zeit, die zuvor investiert wurde, um die richtigen Voraussetzungen zu schaffen, wird den möglichen Schaden reduzieren und die Wiederaufnahme des Betriebs beschleunigen.