Was ist Forensic Readiness?

Forensic Readiness bezeichnet den Zustand eines Unternehmens, Digitale Forensik effizient durchführen zu können. Jeder Incident stellt für alle Beteiligten eine Stresssituation dar. Durch einen hohen Reifegrad in der Forensic Readiness kann die Analysezeit von Incidents verkürzt und die Qualität der Aussagen über den Incident erhöht werden.

Wie bei der Behandlung von Incidents sind auch bei der Vorbereitung viele verschiedene Stakeholder und Sichtweisen involviert. Daher kann Forensic Readiness in mehrere Säulen und Phasen unterteilt werden, wie in der folgenden Abbildung dargestellt.

Im Rahmen dieses Artikels werden nur die Voraussetzungen auf Windows-Clients betrachtet, die den Analyseprozess effizienter gestalten. Neben diesen technischen Voraussetzungen gibt es auch Anforderungen an z.B. das Personal und an die eingesetzten Prozesse. Diese Themen werden in zukünftigen Artikeln näher beschrieben. Darüber hinaus werden die technischen Anforderungen an andere Betriebssysteme und z.B. Cloud-Dienste ebenfalls in zukünftigen Artikeln beschrieben.

Zusammengefasst bedeutet dies, dass die Forensic Readiness grundsätzlich 2 Ziele verfolgt:

• Die Kosten der digitalen Forensik zu reduzieren.
• Die Möglichkeiten verbessern und die Wahrscheinlichkeiten zu erhöhen, relevante Artefakte in die Analyse einzubeziehen, um die Aussagekraft der digitalen Forensik zu erhöhen

Wie diese Grafik zeigt, kann Forensic Readiness aus verschiedenen Blickwinkeln betrachtet werden. Im Rahmen dieses Artikels konzentrieren wir uns ausschließlich auf das Thema Technologie und konkret auf die Datengrundlage.

Wozu brauche ich sie?

Konkret hat der Grad der Forensic Readiness Ihres Unternehmens folgende Auswirkungen:

• Wenn Sie eine Cyber Risiko Versicherung haben, sind Sie in der Regel in der Pflicht, alle notwendigen Beweise bereitzustellen, damit externe Forensiker den Fall rekonstruieren können, um einen Report an die Versicherung zu erstellen. Auf der Grundlage dieses Berichts entscheidet die Versicherung über die Zahlung und die Höhe der Zahlung. Es liegt daher in Ihrem Interesse, alle erforderlichen Daten zur Verfügung zu stellen und eine lückenlose Rekonstruktion des Falles zu ermöglichen, um Ihrer Mitwirkungspflicht nachzukommen.

• Wenn Sie von einem Schadensfall betroffen sind, kann es sein, dass Sie im Rahmen der Incident Response Ihre IT-Systeme herunterfahren oder sogar die Produktion einstellen müssen. Um die Ausfallzeit so gering wie möglich zu halten, muss die Analyse schnell und effizient durchgeführt werden können. Dies ist nur möglich, wenn Sie über einen gewissen Reifegrad in Ihrer Forensic Readiness verfügen. Darüber hinaus benötigen häufig Partner/Lieferanten des betroffenen Unternehmens genaue Informationen über die Auswirkung des Incidents, um zu entscheiden, ob z.B. VPN-Tunnel wieder freigeschaltet werden müssen, um das Daily-Business weiterführen zu können.

• Darüber hinaus können Sie von Compliance-Anforderungen betroffen sein, die eine forensische Analyse erfordern. Beispielsweise definiert der Digital Operational Resilience Act (DORA) eine Meldepflicht für schwerwiegende Vorfälle. Zur Klassifizierung des Vorfalls ist häufig eine detailierte forensische Analyse erforderlich, die nur mit der geforderten Forensic Readiness erreicht werden kann. Ähnliches gilt für die NIS-2 Verordnung, die weiterhin noch einen Abschlussbericht fordert.

Forensic Readiness im Windows-Umfeld

Da Windows-Systeme den größten Teil der Betriebssysteme im Unternehmesnkontext ausmachen, ist hier eine Priorisierung notwendig. Windows-Systeme bieten viele Möglichkeiten, die Quantität und Qualität der forensischen Artefakte zu verbessern. Die folgende Checkliste dient dazu, die Generierung dieser Artefakte zu aktivieren bzw. deren Qualität zu verbessern. Dabei werden zunächst nur Windows-Clients betrachtet, da Server teilweise andere Anforderungen haben und häufig auch anwendungsspezifische Log-Dateien betrachtet werden müssen.

Eventlogs

Windows-Eventslogs bilden die Grundlage jeder forensischen Untersuchung. Die Eventlogs enthalten viele relevante Informationen über Ereignisse, die auf dem System stattfinden. Die Ergebnisprotokolle sind dabei in mehrere Dateien (sog. Channels) unterteilt, die unterschiedliche Ereignisse protokollieren. Obwohl standardmäßig viele Ereignisse protokolliert werden, fehlen einige wichtige Ereignisse.

Process Creation

Windows protokolliert standardmäßig nicht die Erstellung neuer Prozesse. Da Prozesse einer der wichtigsten Aspekte einer forensischen Untersuchung sind, sollte dieser Eintrag dringend aktiviert werden. Zusätzlich sollte die Protokollierung der kompletten Kommandozeile aktiviert werden. Dies erhöht den Informationsgehalt drastisch, da in vielen Fällen der bloße Start eines Prozesses nur eine sehr geringe Aussagekraft hat, wenn nicht bekannt ist, mit welchen Parametern er gestartet wurde. Dies ist insbesondere bei sogenannten LOLBas-Programmen relevant, die immer wieder gerne von Angreifern eingesetzt werden. Die Logs werden vom Security Channel unter der Event-ID 4688 protokolliert.

Ausgehende Netzwerkverbindungen

Angreifer müssen mit anderen internen Systemen kommunizieren, um sich zu verbreiten, oder mit ihren eigenen Systemen, um Tools nachzuladen und Befehle zu erhalten. Aus diesem Grund sind die Protokolle der Netzwerkverbindungen auch für die forensische Analyse unerlässlich. Die Logs werden vom Security Channel unter der Event-ID 5156 protkolliert. Das Event beinhalter auch den Prozessnamen und die Prozess ID des Prozesses, der die Verbindung initiert hat und kann daher mit der Event ID 4688 korelliert werden

Ausführung von PowerShell

PowerShell ist ein mächtiges Werkzeug für Administratoren, aber auch für Angreifer, wie beispielsweise in einem Threat Report von Red Canary aus dem jahr 2023 zu sehen ist (https://redcanary.com/threat-detection-report/techniques/).. Aufgrund der großen Funktionalität von PowerShell verwenden auch Angreifer gerne dieses Werkzeug. Standardmäßig ist das PowerShell-Logging nicht sehr aussagekräftig, aber Microsoft bietet mehrere Möglichkeiten, dies zu verbessern. Konkret kann PowerShell an 4 Stellen protokolliert werden, den PowerShell Logs, dem Script Block Logging, dem Transcription Logging und dem Module Logging. Jeder dieser Logs hat seine Vor und Nachteile, es wird jedoch empfohlen alle zu aktivieren.

Defender Logs

Jeder Windows Client wird mit einer abgespeckten Version von Microsoft Defender ausgeliefert. Wenn im Unternehmen kein dediziertes Antiviren- oder EDR-Tool im Einsatz ist, so sollte der Microsoft Defender aktiviert bleiben. Sobald der Defender eine Bedrohung erkennt, wird ein Alarm im Defender Log generiert. Auch wenn die Detekionen hier eher rudimentär sind, so werden doch häufig relevante Events aufgezeichnet, dies geschieht im dedizieren “Defender Operational” Channel, der in jedem Incident analysiert wird. Sollte ein anderes Sicherheitstool verwendet werden, so muss sichergestellt werden, das das Tool Events protokolliert und dies möglichst in einem verwertbaren Format.

Eine Alternative ist die Verwendung von Sysmon. Sysmon ist Teil der Sysinternals-Suite und bietet viele hilfreiche Events, die zur Analyse verwendet und potentiell an ein SIEM weitergeleitet werden können. Sysmon bietet weit mehr Möglichkeiten als klassische Eventlogs, so können z.B. auch Änderungen in der Registry protokolliert werden. ysmon verwendet eine Konfigurationsdatei, um zu bestimmen, was geloggt werden soll. Sollte man sich nicht ganz sicher sein, was benötigt wird, werden folgende Konfigurationen als Ausgangspunkt empfohlen https://github.com/olafhartong/sysmon-modular und https://github.com/Neo23x0/sysmon-config

Neben der Aktivierung der verschiedenen Logs sollte jedoch auch auf die Loggröße geachtet werden. Jedes Logfile hat eine maximale Loggröße. Ist diese erreicht, werden ältere Einträge gelöscht, um Platz für neue Einträge zu schaffen. Die Standardgröße der Logs ist zu klein, so dass bereits kleine Verzögerungen bei der Beweissicherung dazu führen können, dass relevante Informationen nicht mehr vorhanden sind. Die Größe sollte daher erhöht werden. Grundsätzlich sollte angestrebt werden, dass die Logs mindestens 2 bis 4 Wochen auf dem Terminal verbleiben, bevor sie rotiert werden. Die daraus resultierende Größe der Logs hängt vom Unternehmen ab, es wird empfohlen, die Größe auf mindestens 2 GB zu setzen.

Weitere Artefakte

Neben den beschriebenen Eventlogs gibt es noch weitere interessante Artefakte, den Program Compability Assistant (PCA) und den Background Activity Monitor (BAM). Beide Artefakte zeichnen die Ausführung von Prozessen auf und sind daher für jede forensische Analyse sehr relevant. Beide Artefakte sind standardmäßig aktiviert, wenn das Windows-System über die erforderliche Version verfügt. Dies ist für BAM Windows 10 Update 1709 und für PCA Windows 11 22H2. Es wird daher empfohlen, alle Clients auf der aktuellsten Version des Betriebssystems zu halten. Obwohl Informationen über die Ausführung von Prozessen bereits durch die Event-ID 4688 abgedeckt werden, ist es ratsam, diese Informationen an mehreren Stellen zu haben, da Angreifer gerne Eventlogs löschen, um ihre Spuren zu verwischen.

An dieser Stelle kann die Frage aufkommen, ob solche Informationen nicht bereits z.B. in einem SIEM oder EDR vorhanden sind und warum redundante Informationen auf den Endpoints vorhanden sein müssen. Darauf gibt es mehrere Antworten:

• Die Daten im SIEM/EDR können unvollständig sein. Bei einem SIEM z.B. ist immer zu bedenken, dass eine größere Datenmenge auch mehr Kosten verursacht. EDRs arbeiten mit eigener Telemetrie, die ebenfalls nicht vollständig ist. (siehe folgende Übersicht https://github.com/tsale/EDR-Telemetry).

• Angreifer können z.B. EDRs “blind” machen oder die Datenübertragung zu SIEMs stoppen. Auch wenn solche Techniken nicht von jedem Angreifer eingesetzt werden und auch nicht trivial sind, da sich z.B. EDRs dagegen schützen können, so kann ein Ausfall der Telemetrie entscheidende Informationen verschleiern.

• Für eine forensische Analyse ist es hilfreich, wenn sich alle Daten an einem Ort befinden, nämlich im System selbst. Andernfalls muss die forensische Analyse Daten aus mehreren Quellen korrelieren, was einen zusätzlichen Aufwand bedeutet.

Fazit

Forensic Readiness ermöglicht es, tiefgehende forensische Analysen durchzuführen und genau zu verstehen, was passiert ist. Die Erstellung der notwendigen Datenquellen ist in vielen Fällen ein einmaliger Aufwand, der sich im Falle eines Incidents bezahlt macht.

Während dieser Artikel einen Einblick in die technische Forensic Readiness von Windows-Clients gibt, werden in den nächsten Artikeln weitere Betriebssysteme und Cloud-Anbieter näher beschrieben.

Forensic Readiness ist ein entscheidender Faktor, um Ihr Unternehmen auf potenzielle Vorfälle vorzubereiten und die Effizienz und Aussagekraft der digitalen Forensik zu erhöhen. Eine frühzeitige und umfassende Vorbereitung kann nicht nur Kosten senken, sondern auch sicherstellen, dass wichtige Beweise schnell und vollständig zur Verfügung stehen. Wenn Sie Unterstützung bei der Umsetzung von Forensic Readiness in Ihrem Unternehmen benötigen oder Fragen haben, stehen wir Ihnen gerne zur Verfügung. Zögern Sie nicht, uns zu kontaktieren – wir sind jederzeit für Sie da!