Man hätte hoffen können, das Microsoft eindeutige und kohärente Dateiaktivitätsereignisse im Ereignisprotokoll von Windows bereitstellen würde. Das Dateiaktivitätsprotokoll ist aus den üblichen Gründen sehr wichtig – Compliance, Forensik, Überwachung von berechtigten Anwendern und Erkennung von Ransomware und anderen Attacken mit Schadprogrammen, während diese ablaufen. Die Dateiaktivitäten zu protokollieren sollte ganz einfach und leicht sein, oder? Alles, was nötig ist, sind Zeitstempel, Benutzername, Dateiname, Operation (Erstellen, Lesen, Ändern, Umbenennen, Löschen usw.) und ein Ergebnis (Erfolg oder Fehlschlag).
Aber wir reden von Microsoft. Und die machen niemals im Leben etwas schön und einfach.
Der Fall „Löschen“
Beginnen wir mit dem Löschen, dem einfachsten Szenario. Suchen Sie bei Google nach „Windows file delete event„ (Windows Datei löschen Ereignis) und das erste Ergebnis kommt, wie üblich, aus der Windows Event Encyclopedia von Randy Franklin Smith: „4660: An object was deleted“ (4660: Ein Objekt wurde gelöscht).
Für einen Windows-Neuling könnte der Eindruck entstehen, dass unsere Suche beendet sei. Bedauerlicherweise fehlt bei dem Löschereignis eine entscheidende Information: der Dateiname. Warum? Wenn Sie Ransomware entdecken, möchten Sie wissen, welche Dateien verschlüsselt werden. In gleicher Weise wäre zu erwarten, dass bei der Benachrichtigung über den Zugriff eines berechtigten Benutzers auf sensible Dateien auch gemeldet würde, auf genau welche Dateien zugegriffen wurde.
Der schwierige Teil ist zu ermitteln, welcher Dateiname mit einem Ereignis verbunden ist. Selbst die Identifizierung einer simplen Sache wie eines Dateinamens ist nicht einfach, weil die Windows-Ereignisinformationen über mehrere Protokolleinträge verteilt sind. Sie müssten z. B. das Löschereignis 4660 mit dem Ereignis „Objektzugriff“ 4663 korrelieren. In der Praxis erstellen Sie eine Suche nach zueinander passenden 4660- und 4663-Ereignissen und führen dann die Informationen beider Ereignisse zusammen, um einen für den Anwender besser nutzbaren Protokolleintrag abzuleiten.
Lassen Sie uns die Korrelationen besprechen, die zur Überwachung von Dateiaktivitäten mit dem Windows-Ereignisprotokoll erforderlich sind. Die tatsächliche Umsetzung hängt von den Tools ab, mit denen die Ereignisse abgerufen werden: Eine Datenbankabfrage, ein Programm oder eine spezialisierte Korrelations-Engine – also ein für diese Aktivität maßgeschneidertes Programm.
Der Audit-Flow für Dateiaktivitäten bei Windows
Windows protokolliert Dateiaktivitäten nicht so, wie Sie es erwarten würden. Stattdessen protokolliert es granulare Datei-Operationen, die weiter verarbeitet werden müssen. Lassen Sie uns also einen genaueren Blick auf die Protokollierung von Datei-Operationen unter Windows werfen.
Die Grafik unten verdeutlicht, wie Windows jede Datei-Operation mit mehreren Mikro-Operationsprotokollen protokolliert: 
Der Löschvorgang ist insofern einzigartig, dass bei ihm wie oben erwähnt ein viertes Ereignis (4660) aufgezeichnet wird. Der Ablauf wird durch die Ereigniseigenschaft „Handle ID“ identifiziert, die für diesem Ablauf (zumindest bis zum nächsten Neustart) eindeutig zugeordnet ist.
Das Ereignis mit dem größten Informationsgehalt ist 4663, das den Zugriffsversuch auf ein Objekt markiert. Die Bezeichnung ist allerdings irreführend, weil Windows das Ereignis nur dann auslöst, wenn die Operation abgeschlossen ist. Tatsächlich kann es für eine einzige Handle ID mehrere 4663-Ereignisse geben, wobei mehrere kleiner Operationen protokolliert werden, die zusammen die gesamte Aktion ausmachen. Zum Beispiel sind mit dem Umbenennen eines Objekts eine Lese-, eine Lösch- und eine Schreib-Operation verbunden. Außerdem könnte ein 4663-Ereignis mehrere Werte in der Eigenschaft „Accesses“ enthalten, in der die für die Operation ausgeübten Berechtigungen aufgeführt sind. Diese „Accesses“ dienen uns als Leitfaden für die Operationen selbst. Darauf kommen wir später zurück.
Die folgende Tabelle enthält Informationen über jedes Ereignis:
| Ereignis-ID | Name | Beschreibung | Bereitgestellte Daten |
|---|---|---|---|
| 4656 | Ein Handle zu einem Objekt wurde angefordert |
Protokolliert den Beginn jeder Datei-Aktivität, aber garantiert nicht, dass diese erfolgreich war |
Der Name der Datei |
| 4663 | Es wurde versucht, auf ein Objekt zuzugreifen | Protokolliert die spezifischen Mikro-Operationen, die im Rahmen der Aktivität durchgeführt werden |
Was genau getan wurde |
| 4660 | Ein Objekt wurde gelöscht | Protokolliert eine Lösch-Operation | Die einzige Methode, eine Aktivität zu verifizieren, ist tatsächlich das Löschen |
| 4658 | Das Handle zu einem Objekt wurde geschlossen |
Protokolliert das Ende einer Dateiaktivität | Wie lange es gedauert hat |
Ein Schritt, den Sie nicht auslassen dürfen, ist Windows so einzustellen, dass diese Ereignisse protokolliert werden, was nicht die Standardeinstellung ist. Ein Tutorial, wie sie das tun, finden Sie hier.
Das Konzept sollte jetzt klar sein: Sie haben mit einer Menge unterschiedlicher untergeordneter Ereignisse zu tun, die in Verbindung zu übergeordneten Dateiaktionen stehen. Nehmen wir uns nun das Problem vor, diese miteinander zu korrelieren, um anwenderfreundliche Informationen zu produzieren.
„Accesses“ interpretieren
Um die tatsächliche Aktion zu identifizieren, müssen wir die ausgeübte Berechtigung gemäß Meldung in der Ereigniseigenschaft „Accesses“ dekodieren. Leider handelt es sich um keine eineindeutige Beziehung. Jede Dateiaktion setzt sich aus vielen kleineren, von Windows ausgeführten Operationen zusammen, und diese kleineren Operationen werden protokolliert.
Die wichtigeren Werte der Eigenschaft „Accesses“ sind:
- „WriteData“ bedeutet, dass eine Datei erstellt oder geändert wurde, sofern kein Zugriff des Typs „Delete“ (Löschen) für denselben Handle aufgezeichnet wurde.
- „ReadData“ wird praktisch im Zusammenhang mit jeder Aktion protokolliert. Es bedeutet „Access“ (Zugriff), wenn zum ungefähr gleichen Zeitpunkt kein „Delete“ oder „WriteData“ für denselben Handle und für denselben Dateinamen aufgetreten ist.
- „Delete“ (Löschen) kann vieles bedeuten: Löschen, Umbenennen (selber Ordner), Verschieben (in einen anderen Ordner) oder Recyceln, was im Grunde ein Verschieben in den Papierkorb ist. Ereignis 4660 mit demselben Handle unterscheidet zwischen Löschen oder Recyceln, wofür ein Ereignis 4660 ausgegeben wird, und Umbenennen oder Verschieben, bei denen dies nicht der Fall ist.
Komplex?
Sie sollten sich klar sein, dass dies nur der Anfang ist. Die oben beschriebene Analyse ist ein wenig vereinfacht und für die Umsetzung unter realen Bedingungen sind weitere Untersuchungen erforderlich. Einige zu untersuchende Bereiche sind:
- Unterscheidung zwischen Löschen und Recyceln und zwischen Verschieben und Umbenennen.
- Analysieren der Zugriffseigenschaften (mit oder ohne Zugriffs-Operationen).
- Umgang mit Ereignis 4659, das dem Ereignis 4660 ähnlich ist, aber bei einer Anfrage zum Löschen einer gesperrten Datei bei dem nächsten Neustart und nicht auf der Stelle protokolliert wird.
- Untersuchung von Berichten, dass Ereignisse nicht in der richtigen Reihenfolge erfolgen und das „Ereignis Handle anfordern“ (4656) nicht unbedingt das erste seiner Serie ist.
Es könnte sich lohnen, dieses PowerShell-Skript zu prüfen, das Windows-Ereignisse ausliest und aus ihnen einen aussagekräftigen Dateiaktivitätsbericht erstellt, um die Analyse ein wenig zu vereinfachen. Aber seien Sie gewarnt: es ist nichts für schwache Nerven!
Grenzen des Windows-Ereignisprotokolls für die Überwachung von Dateizugriffen
Obwohl die Dateiaktivitätsereignisse von Windows so umfassend sind, gibt es Dinge, die sich nicht nur mit dem Ereignisprotokoll ermitteln lassen. Hier sind einige Beispiele:
- Erstellen vs. Ändern: Um festzustellen, ob es sich um eine neue oder eine geänderte Datei handelt, muss man auf jeden Fall den vorherigen Zustand kennen, also ob die Datei vorher vorhanden war.
- Fehlende Informationen über Störungen: Wenn eine Operation aufgrund unzureichender Berechtigungen abgewiesen wurde, wird nur das Ereignis 4656 ausgegeben. Ohne eine Reihenfolge sind die meisten in diesem Artikel beschriebenen Verarbeitungsschritte nicht möglich.
- Ausschneiden und Einfügen: Obwohl man annehmen könnte, dass „Ausschneiden und Einfügen“ der Operation Verschieben ähnlich ist, verhält es sich tatsächlich in der Praxis so ähnlich wie eine Operation Löschen gefolgt von einer Operationen Erstellen, ohne dass zwischen diesen beiden Operationen ein Zusammenhang besteht.
Überlegungen zur Skalierbarkeit
Die Windows-Dateiaktivität zu erfassen stellt einen enormen Ereignisstrom dar, und die Ereignisstruktur von Windows, bei der zahlreiche Ereignisse für eine einzige Dateiaktivität erstellt werden, ist auch nicht hilfreich. Die Erfassung wird zusätzliche Netzwerkbandbreite für die Übertragung von Ereignissen und zusätzlichen Speicherplatz für deren Archivierung erforderlich machen. Außerdem wird für die benötigte anspruchsvolle Logik möglicherweise ein leistungsfähiger Prozessor und eine Menge Arbeitsspeicher gebraucht.
Um die Gemeinkosten zu reduzieren, sind die folgenden Schritte empfehlenswert:
- Wählen Sie die Dateien, die Sie überwachen, sorgfältig anhand des Szenarios aus, das Sie umsetzen möchten. Sie können sich beispielsweise auf Systemdateien oder Speicherbereiche mit sensiblen Daten beschränken.
- Grenzen Sie die Sammlung nicht benötigter Ereignisse an der Quelle ein. Wenn Ihre Erfassungsinfrastruktur mit Event-Forwarding von Microsoft arbeitet, können Sie auf der Grundlage von Ereignis-IDs und Ereigniseigenschaften leistungsfähige Filter aufbauen. In unserem Fall würden Sie nur die Ereignisse 4656, 4660, 4663 und optional 4658 für die benötigten Werte von „Accesses“ herausfiltern.
- Begrenzen Sie die Speicherung und die Größe von Ereignissen, weil unbehandelte Windows-Ereignisse viel Platz einnehmen.
Ein alternativer Ansatz
Praktische Erfahrungen haben gezeigt, dass nicht viele Organisationen dabei Erfolg haben, das Windows-Ereignisprotokoll zur Überwachung der Dateiaktivität zu verwenden. Ein alternativer Ansatz zur Umsetzung dieser wichtigen Sicherheits- und Compliance-Maßnahme wäre, einen kompakten Agenten auf jedem überwachten Windows-System unter besonderer Berücksichtigung von Dateiservern einzusetzen. Ein derartiger Agent würde, ähnlich wie der Varonis-Agent von DatAdvantage, die Dateiaktivität mit minimaler Belastung des Servers und Netzwerks protokollieren und damit die Bedrohungserkennung erleichtern.
