Windows-Betriebssysteme verfügen über ein ziemlich gutes Sicherheitsereignisprotokollierungssystem. In verschiedenen Publikationen und Rezensionen wurde viel Gutes über sie geschrieben, aber dieser Artikel handelt von etwas anderem. Hier sprechen wir über Probleme und Mängel in diesem System. Einige der in Betracht gezogenen Probleme sind nicht kritisch und erschweren lediglich die Analyse von Ereignissen, während andere schwerwiegende Sicherheitsbedrohungen darstellen.
Die identifizierten Probleme wurden unter Windows 7 Maximum (russische Version), Windows 7 Professional (englische Version), Windows 10 Pro (russische Version) und Windows Server 2019 Datacenter (russische Version) getestet. Alle Betriebssysteme wurden vollständig aktualisiert.
Problem Nr. 1. Fehlerhaftes Prüfparameter-Verwaltungssystem
Das Problem wurde unter Windows 7/10 / Server 2019 bestätigt.Problembeschreibung
Nehmen Sie Windows 7 und installieren Sie es mit den Standardeinstellungen. Wir werden die Domain nicht betreten. Sehen wir uns die Einstellungen für die Sicherheitsereignisüberwachung an. Öffnen Sie dazu das Snap-In "Lokale Sicherheitsrichtlinien" (secpol.msc oder "Systemsteuerung -> Verwaltung -> Lokale Sicherheitsrichtlinien") und sehen Sie sich die grundlegenden Überwachungseinstellungen an ("Sicherheitseinstellungen -> Lokale Richtlinien -> Überwachungsrichtlinien"). )
Wie Sie sehen, ist das Audit nicht konfiguriert. Sehen wir uns nun die erweiterten Überwachungsrichtlinien an ("Sicherheitseinstellungen -> Erweiterte Konfiguration von Überwachungsrichtlinien -> Systemüberwachungsrichtlinien - Lokales Gruppenrichtlinienobjekt").
Auch hier ist das Audit nicht konfiguriert. Wenn ja, sollten theoretisch keine Sicherheitsereignisse in den Protokollen vorhanden sein. Wir prüfen. Öffnen Sie das Sicherheitsprotokoll (eventvwr.exe oder "Systemsteuerung -> Verwaltung -> Ereignisse anzeigen").
Frage: "Woher kommt das Ereignis im Sicherheitsprotokoll, wenn das Audit überhaupt nicht konfiguriert ist?!"Erklärung
Um den Grund für dieses Verhalten zu verstehen, müssen Sie sich "unter die Haube" des Betriebssystems begeben. Zunächst beschäftigen wir uns mit grundlegenden und erweiterten Prüfungsrichtlinien.
Vor Windows Vista gab es nur eine Überwachungsrichtlinie, die jetzt als einfach bezeichnet wird. Das Problem war, dass die Granularität des Prüfungsmanagements zu diesem Zeitpunkt sehr gering war. Wenn es also erforderlich war, den Zugriff auf Dateien zu verfolgen, enthielten diese die Kategorie der Grundrichtlinie "Zugriff auf Objekte überwachen". Zusätzlich zu den Dateioperationen wurden daher eine Reihe anderer "Rausch" -Ereignisse in das Sicherheitsprotokoll geschrieben. Dies erschwerte die Verarbeitung von Protokollen und irritierten Benutzern erheblich.
Microsoft hörte diesen "Schmerz" und entschied sich zu helfen. Das Problem ist, dass Windows auf dem Konzept der Abwärtskompatibilität basiert und Änderungen am vorhandenen Überwachungsverwaltungsmechanismus diese Kompatibilität zunichte gemacht hätten. Daher ging der Verkäufer den umgekehrten Weg. Er hat ein neues Tool erstellt und es Advanced Audit Policies genannt.
Das Tool basiert im Wesentlichen auf der Tatsache, dass erweiterte Richtlinienkategorien aus den Kategorien der grundlegenden Überwachungsrichtlinien erstellt wurden und diese wiederum in Unterkategorien unterteilt wurden, die einzeln aktiviert und deaktiviert werden können. Wenn Sie nun den Zugriff auf Dateien in erweiterten Überwachungsrichtlinien verfolgen müssen, müssen Sie nur die Unterkategorie "Dateisystem" aktivieren, die in der Kategorie "Objektzugriff" enthalten ist. Gleichzeitig werden "Störungsereignisse", die sich auf den Zugriff auf die Registrierung oder das Filtern des Netzwerkverkehrs beziehen, nicht in das Sicherheitsprotokoll aufgenommen.
Die enorme Verwirrung in diesem gesamten Schema wird durch die Tatsache verursacht, dass die Namen der Kategorien der grundlegenden Prüfungsrichtlinien und der fortgeschrittenen Prüfungsrichtlinien nicht übereinstimmen, und es mag zunächst den Anschein haben, dass dies völlig unterschiedliche Dinge sind, aber dem ist nicht so.
Hier finden Sie eine Konformitätstabelle mit den Namen der grundlegenden und erweiterten Kategorien des Auditmanagements
Es ist wichtig zu verstehen, dass sowohl grundlegende als auch erweiterte Kategorien im Wesentlichen dasselbe steuern. Die Einbeziehung einer grundlegenden Prüfungsrichtlinienkategorie führt zur Einbeziehung der entsprechenden erweiterten Prüfungsrichtlinienkategorie und folglich aller ihrer Unterkategorien. Um unvorhergesehene Konsequenzen zu vermeiden,
empfiehlt Microsoft nicht, grundlegende und erweiterte Überwachungsrichtlinien gleichzeitig zu verwenden.
Jetzt müssen Sie herausfinden, wo die Überwachungseinstellungen gespeichert sind. Zunächst führen wir eine Reihe von Konzepten ein:
- Effektive Überwachungsrichtlinien - Informationen, die im RAM gespeichert sind und die aktuellen Betriebsparameter von Betriebssystemmodulen bestimmen, die Überwachungsfunktionen implementieren.
- Gespeicherte Überwachungsrichtlinien - Informationen, die in der Registrierung unter HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv gespeichert sind und zum Ermitteln der effektiven Überwachungsrichtlinien nach einem Systemneustart verwendet werden.
Wir werden verschiedene Verwaltungstools betrachten und angeben, welche Prüfparameter angezeigt und welche festgelegt werden. Die Angaben in der Tabelle beruhen auf Versuchen.
Erklären wir die Tabelle anhand von Beispielen.
Beispiel 1Wenn Sie auditpol ausführen, um die Überwachungseinstellungen anzuzeigen:
auditpol /get /category:* , dann werden die gespeicherten Audit-Einstellungen angezeigt, dh diejenigen, die in der Registrierung unter HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv gespeichert sind.
Beispiel 2Wenn Sie dasselbe Dienstprogramm ausführen, die Parameter jedoch bereits festgelegt haben:
auditpol /set /category:* werden die effektiven Audit-Einstellungen und die gespeicherten Audit-Einstellungen geändert.
Für einen separaten Kommentar ist die Reihenfolge erforderlich, in der die Überwachungseinstellungen in den "Grundlegenden Überwachungsrichtlinien" des Snap-Ins "Lokale Sicherheitsrichtlinien" angezeigt werden. Die Kategorie der grundlegenden Überwachungsrichtlinie wird als festgelegt angezeigt, wenn alle Unterkategorien der entsprechenden erweiterten Überwachungsrichtlinie installiert sind. Wenn mindestens einer von ihnen nicht installiert ist, wird die Richtlinie als nicht installiert angezeigt.
Beispiel 3Mit dem
auditpol /set /category:* stellte der
auditpol /set /category:* alle
auditpol /set /category:* den
auditpol /set /category:* . Wenn Sie außerdem zum Snap-In "Grundlegende Überwachungsrichtlinien" des Snap-Ins "Lokale Sicherheitsrichtlinien" wechseln, wird gegenüber jeder Kategorie eine Erfolgsprüfung installiert.
Beispiel 4Jetzt hat der Administrator
auditpol /clear Befehl
auditpol /clear ausgeführt und alle
auditpol /clear zurückgesetzt. Anschließend richtete er die Dateisystemüberwachung ein, indem er
auditpol /set /subcategory:" " . Wenn Sie nun zum Snap-In "Grundlegende Überwachungsrichtlinien" des Snap-Ins "Lokale Sicherheitsrichtlinien" wechseln, werden alle Kategorien im Status "Keine Überwachung" definiert, da keine einzige Kategorie der erweiterten Überwachungsrichtlinie vollständig definiert ist.
Jetzt können wir endlich die Frage beantworten, woher die Protokolle im frisch installierten Betriebssystem stammen. Die Sache ist, dass nach der Installation die Überwachung in Windows in den gespeicherten Überwachungseinstellungen konfiguriert und definiert wird. Sie können dies überprüfen, indem Sie den
auditpol /get /category:* .
In den grundlegenden Überwachungsrichtlinien des Snap-Ins Lokale Sicherheitsrichtlinien werden diese Überwachungsinformationen nicht angezeigt, da eine oder mehrere Unterkategorien nicht in allen Kategorien definiert sind. In den erweiterten Überwachungsrichtlinien des Snap-Ins Lokale Sicherheitsrichtlinien werden diese Informationen nicht angezeigt, da das Snap-In nur mit den Überwachungseinstellungen funktioniert, die in der Datei% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv gespeichert sind.
Worin besteht das Problem?
Auf den ersten Blick scheint das alles kein Problem zu sein, ist es aber nicht. Die Tatsache, dass alle Tools die Überwachungsparameter auf unterschiedliche Weise anzeigen, bietet die Möglichkeit, Richtlinien und damit die Überwachungsergebnisse in böswilliger Weise zu manipulieren.
Betrachten Sie das wahrscheinliche SzenarioLassen Sie eine auf Windows 7 basierende technologische Workstation im Unternehmensnetzwerk arbeiten.
Die Maschine ist nicht in der Domäne enthalten und führt die Funktionen eines Roboters aus, der täglich Berichte an die Regulierungsbehörden sendet. Angreifer auf die eine oder andere Weise erhielten mit Administratorrechten Fernzugriff darauf. Gleichzeitig ist das Hauptziel der Angreifer Spionage und die Aufgabe, im System unentdeckt zu bleiben. Die Angreifer haben heimlich entschieden, dass im Sicherheitsprotokoll keine Ereignisse mit dem Code
4719 "Änderungen der
Überwachungsrichtlinie" aufgetreten sind. Deaktivieren Sie die Überwachung des Zugriffs auf Dateien, während alle Verwaltungstools angeben, dass die Überwachung aktiviert ist. Um die Aufgabe zu erfüllen, haben sie die folgenden Aktionen ausgeführt:
- Auf der angegriffenen Arbeitsstation erteilten sie sich selbst Schreibberechtigungen für den Registrierungsschlüssel HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv und exportierten diesen Schlüssel in eine Datei mit dem Namen "+ fs.reg".
- Wir haben diese Datei auf einen anderen Computer importiert, neu gestartet und dann die Prüfung des Dateisystems mit auditpol deaktiviert. Anschließend haben wir den obigen Registrierungsschlüssel in die Datei "-fs.reg" exportiert.
- Auf dem angegriffenen Computer wurde die Datei "-fs.reg" in die Registrierung importiert.
- Wir haben eine Sicherungskopie der Datei% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv erstellt, die sich auf dem angegriffenen Computer befindet, und dann die Unterkategorie "Dateisystem" daraus gelöscht.
- Sie haben die angegriffene Arbeitsstation neu gestartet und anschließend die Datei% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv durch eine zuvor gespeicherte Sicherungskopie ersetzt und auch die Datei "+ fs.reg" importiert.
Aufgrund all dieser Manipulationen befinden sich keine Richtlinienänderungseinträge im Sicherheitsprotokoll. Alle Tools zeigen, dass die Überwachung aktiviert ist, aber tatsächlich funktioniert sie nicht.
Problem Nr. 2. Fehlgeschlagene Protokollierung von Vorgängen zum Löschen von Dateien, Verzeichnissen und Registrierungsschlüsseln
Das Problem wurde unter Windows 7/10 / Server 2019 bestätigt.Problembeschreibung
Für einen Vorgang zum Löschen einer Datei, eines Verzeichnisses oder eines Registrierungsschlüssels generiert das Betriebssystem eine Ereignissequenz mit den Codes
4663 und
4660 . Das Problem ist, dass es aus dem ganzen Strom von Ereignissen nicht so einfach ist, sich miteinander zu verbinden. Zu diesem Zweck müssen die analysierten Ereignisse die folgenden Parameter aufweisen:
Ereignis 1. Code 4663 "Es wurde versucht, auf das Objekt zuzugreifen." Ereignisparameter:
"ObjectType" = Datei.
"ObjectName" = Name der zu löschenden Datei oder des zu löschenden Verzeichnisses.
"HandleId" = Handle zu der zu löschenden Datei.
“AcessMask” = 0x10000 (Dieser Code entspricht der DELETE-Operation. Die Entschlüsselung aller Operationscodes finden Sie
auf der Microsoft-Website. )
Ereignis 2. Code 4660 "Objekt gelöscht."Ereignisparameter:
"HandleId" = "HandleId-Ereignisse 1"
"System \ EventRecordID" = "System \ EventRecordID von Ereignis 1" + 1.
Mit dem Entfernen des Registrierungsschlüssels (key) ist alles gleich, nur im ersten Ereignis mit Code 4663 der Parameter "ObjectType" = Key.
Beachten Sie, dass das Entfernen von Werten in der Registrierung durch ein anderes Ereignis (Code
4657 ) beschrieben wird und keine derartigen Probleme verursacht.
Funktionen zum Löschen von Dateien in Windows 10 und Server 2019
In Windows 10 / Server 2019 gibt es zwei Möglichkeiten, eine Datei zu löschen.
- Wenn die Datei in den Papierkorb gelöscht wird, wird die Abfolge der Ereignisse 4663 und 4660 wie zuvor fortgesetzt.
- Wenn die Datei dauerhaft gelöscht wird (nach dem Papierkorb), dann mit einem einzelnen Ereignis mit dem Code 4659 .
Eine seltsame Sache ist passiert. Wenn früher zum Ermitteln gelöschter Dateien die Gesamtheit der Ereignisse 4663 und 4660 überwacht werden musste, hat Microsoft jetzt "Benutzer getroffen", und anstelle von zwei Ereignissen müssen jetzt drei Ereignisse überwacht werden. Es ist auch anzumerken, dass sich die Prozedur zum Löschen von Verzeichnissen nicht geändert hat und wie zuvor aus zwei Ereignissen 4663 und 4660 besteht.
Worin besteht das Problem?
Das Problem ist, dass es keine einfache Aufgabe ist, herauszufinden, wer die Datei oder das Verzeichnis gelöscht hat. Anstatt banal nach dem entsprechenden Ereignis im Sicherheitsprotokoll zu suchen, ist es notwendig, die Abfolge der Ereignisse zu analysieren, was manuell ziemlich schwierig ist. Auf habr sogar darüber gab es einen Artikel:
"Überprüfen der Entfernung und des Zugriffs auf Dateien und Aufzeichnen von Ereignissen in einer Protokolldatei mit Powershell .
"Problem Nummer 3 (kritisch). Fehlerhafte Protokollierung des Umbenennungsvorgangs für Dateien, Verzeichnisse und Registrierungsschlüssel
Das Problem wurde unter Windows 7/10 / Server 2019 bestätigt.Problembeschreibung
Dieses Problem hat zwei Unterprobleme:
- In Ereignissen, die vom System beim Umbenennen generiert werden, ist der neue Objektname nirgendwo festgelegt.
- Das Umbenennen ist dem Löschen sehr ähnlich. Es kann nur dadurch unterschieden werden, dass das erste Ereignis mit dem Code 4663 mit dem Parameter "AcessMask" = 0x10000 (DELETE) kein Ereignis 4660 hat.
Es ist erwähnenswert, dass dieses Problem in Bezug auf die Registrierung nur für Schlüssel gilt. Das Umbenennen von Werten in der Registrierung wird durch eine Abfolge von Ereignissen 4657 beschrieben und verursacht keine derartigen Beschwerden, obwohl es natürlich viel praktischer wäre, wenn es nur ein einziges Ereignis gäbe.
Worin besteht das Problem?
Zusätzlich zu den Schwierigkeiten bei der Suche nach Operationen zum Umbenennen von Dateien ermöglicht diese Journalfunktion nicht die Verfolgung des gesamten Lebenszyklus von Dateisystemobjekten oder Registrierungsschlüsseln. Infolgedessen ist es äußerst schwierig, den Verlauf einer Datei zu ermitteln, die auf einem aktiv genutzten Dateiserver häufig umbenannt wurde.
Problem Nummer 4 (kritisch). Verzeichnis- und Registrierungsschlüsselerstellung können nicht verfolgt werden
Das Problem wurde unter Windows 7/10 / Server 2019 bestätigt.Problembeschreibung
Windows verfolgt die Erstellung eines Dateisystemverzeichnisses und eines Registrierungsschlüssels nicht. Dies besteht darin, dass das Betriebssystem kein Ereignis generiert, das den Namen des erstellten Verzeichnisses oder Registrierungsschlüssels enthält und dessen Parameter darauf hinweisen, dass dies der Erstellungsvorgang ist.
Theoretisch ist durch indirekte Zeichen die Erstellung eines Katalogs möglich. Wenn es beispielsweise über den "Explorer" erstellt wurde, werden während des Erstellungsprozesses Abfrageereignisse für die Attribute des neuen Verzeichnisses generiert. Das Problem ist, dass, wenn Sie ein Verzeichnis mit dem Befehl
mkdir erstellen, überhaupt keine Ereignisse generiert werden. Gleichwohl gilt dies für das Erstellen von Schlüsseln in der Registrierung.
Worin besteht das Problem?
Dieses Problem erschwert die Untersuchung von Sicherheitsvorfällen. Es gibt keine vernünftige Erklärung dafür, dass diese Informationen nicht in den Journalen erfasst sind.
Problem Nummer 5 (kritisch). Schlechte Überwachungseinstellungen in russischen Windows-Versionen
Das Vorhandensein des Problems wird in den russischen Editionen von Windows 7/10 / Server 2019 bestätigt.Problembeschreibung
In russischen Windows-Versionen ist ein Fehler aufgetreten, der das Sicherheitsüberprüfungsverwaltungssystem funktionsunfähig macht.
Symptome
Das Ändern erweiterter Sicherheitsrichtlinien wirkt sich nicht auf die effektiven Überwachungseinstellungen aus. Mit anderen Worten, die Richtlinien werden nicht angewendet. Der Administrator hat beispielsweise die Unterkategorie "Anmelden" aktiviert, das System neu gestartet, den
auditpol /get /category:* ausgeführt und diese Unterkategorie bleibt
auditpol /get /category:* . Das Problem ist sowohl für Domänencomputer relevant, die über Gruppenrichtlinien verwaltet werden, als auch für Nicht-Domänencomputer, die über ein lokales Gruppenrichtlinienobjekt verwaltet werden, das über das Snap-In Lokale Sicherheitsrichtlinien konfiguriert wird.
Gründe
Das Problem tritt auf, wenn der Administrator mindestens eine der „fehlgeschlagenen“ Unterkategorien der erweiterten Überwachungsrichtlinien aktiviert hat. Zu diesen fehlgeschlagenen Kategorien gehören insbesondere:
- Nutzung von Rechten -> Prüfen Sie die Nutzung von Rechten, die sich auf vertrauliche Daten auswirken. GUID: {0cce9228-69ae-11d9-bed3-505054503030}.
- Nutzung von Rechten -> Prüfen Sie die Nutzung von Rechten, die keine Auswirkungen auf vertrauliche Daten haben. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
- Zugriff auf Objekte -> Audit-Ereignisse, die von Anwendungen erstellt wurden. GUID: {0cce9222-69ae-11d9-bed3-505054503030}.
Empfehlungen zur Lösung des Problems
Wenn das Problem noch nicht aufgetreten ist, aktivieren Sie die angegebenen "fehlgeschlagenen" Unterkategorien nicht. Wenn die Ereignisse dieser Unterkategorien sehr wichtig sind, können Sie sie mit dem Dienstprogramm auditpol aktivieren oder das Audit mithilfe grundlegender Richtlinien verwalten.
Wenn ein Problem auftritt, müssen Sie:
- Löschen Sie im Richtlinienverzeichnis für Domänengruppen die Datei \ Machine \ microsoft \ windows nt \ Audit \ audit.csv
- Löschen Sie auf allen Computern, auf denen Probleme mit der Überwachung auftreten, die folgenden Dateien:% SystemRoot% \ security \ audit \ audit.csv,% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv
Worin besteht das Problem?
Das Vorhandensein dieses Problems verringert die Anzahl der Sicherheitsereignisse, die regelmäßig über erweiterte Überwachungsrichtlinien überwacht werden können, und führt außerdem zu Bedrohungen beim Trennen, Blockieren und Destabilisieren der Verwaltung des Prüfsystems im Unternehmensnetzwerk.
Problem Nummer 6 (kritisch). Verdammt "Neuer Text document.txt ... sowie Neue bitmap.bmp"
Das Problem wurde unter Windows 7 bestätigt. In Windows 10 / Server 2019 fehlt das Problem.Problembeschreibung
Dies ist ein sehr seltsames Problem, das zufällig entdeckt wurde. Das Problem besteht im Wesentlichen darin, dass das Betriebssystem eine Lücke aufweist, mit der Sie die Prüfung der Erstellung von Dateien umgehen können.
Vorbereitungsteil:- Nimm ein frisch installiertes Windows 7.
- Setzen Sie alle
auditpol /clear mit dem Befehl auditpol /clear . Dieser Punkt ist optional und dient nur zur bequemen Analyse von Magazinen. - Wir richten die Dateisystemprüfung ein, indem
auditpol /set /subcategory:" " . - Lassen Sie uns das Verzeichnis C: \ TEST erstellen und Überwachungsparameter für das Konto "Everything" zuweisen: "Dateien erstellen / Daten schreiben", "Ordner erstellen / Daten schreiben", "Attribute schreiben", "Zusätzliche Attribute schreiben", "Unterordner löschen" und files “,„ Delete “,„ Change of permissions “,„ Change of Ownership “, also alles, was mit dem Schreiben von Daten in das Dateisystem zu tun hat.
Aus Gründen der Übersichtlichkeit löschen wir vor jedem Test das Sicherheitsprotokoll des Betriebssystems.
Versuch 1.Wir machen:Führen Sie in der Befehlszeile den folgenden Befehl aus:
echo > "c:\test\ .txt"Wir beobachten:Beim Erstellen der Datei wurde im Sicherheitsprotokoll ein Ereignis mit dem Code 4663 angezeigt, das den Namen der zu erstellenden Datei im Feld "ObjectName" und 0x2 im Feld "AccessMask" ("Schreiben von Daten oder Hinzufügen einer Datei") enthielt.
Um die folgenden Experimente durchzuführen, löschen wir den Ordner und das Ereignisprotokoll.
Versuch 2.Wir machen:Öffnen Sie den Ordner C: \ TEST über den "Explorer" und erstellen Sie über das Kontextmenü "Erstellen -> Textdokument", das Sie mit der rechten Maustaste aufrufen, die Datei "New Text Document.txt".
Wir beobachten:Diese Aktion spiegelte sich nicht im Ereignisprotokoll wider !!! Es gibt auch keine Einträge, wenn Sie dasselbe Kontextmenü verwenden, um eine „Bitmap“ zu erstellen.
Versuch 3.Wir machen:Öffnen Sie im Explorer den Ordner C: \ TEST und erstellen Sie über das Kontextmenü "Erstellen -> Dokument im RTF-Format", das Sie mit der rechten Maustaste aufrufen, die Datei "Neues Dokument im RTF.rtf-Format".
Wir beobachten:Wie beim Erstellen der Datei über die Befehlszeile wurde im Protokoll ein Ereignis mit dem Code 4663 und dem entsprechenden Inhalt angezeigt.
Worin besteht das Problem?
Natürlich ist das Erstellen von Textdokumenten oder Bildern nicht besonders schädlich. Wenn der "Explorer" jedoch in der Lage ist, die Protokollierung von Dateivorgängen zu umgehen, kann Malware dies tun.
Dieses Problem ist möglicherweise das bedeutendste, das in Betracht gezogen wird, da es die Glaubwürdigkeit der Ergebnisse der Prüfung von Dateioperationen ernsthaft untergräbt.
Fazit
Die obige Liste der Probleme erhebt keinen Anspruch auf Vollständigkeit. Dabei ist es uns gelungen, auf eine immer noch recht große Anzahl kleinerer Fehler zu stoßen, darunter die Verwendung lokalisierter Konstanten als Parameterwerte für eine Reihe von Ereignissen, wodurch wir gezwungen sind, unsere Analyseskripten für jede Lokalisierung des Betriebssystems zu schreiben. Das Löschen eines Registrierungsschlüssels ist beispielsweise eine Folge von Ereignissen 4663 und 4660, und das Löschen eines Werts in der Registrierung ist 4657, und sogar die kleinen Dinge ...
Aus Gründen der Fairness stellen wir fest, dass das Sicherheitsereignisprotokollierungssystem in Windows trotz aller Mängel eine Vielzahl von positiven Aspekten aufweist. Durch die Behebung der hier aufgeführten kritischen Probleme könnte die Krone wieder zu einer besseren Lösung für die sofortige Protokollierung von Sicherheitsereignissen werden.
MACHEN SIE WINDOWS SECURITY EVENT LOGGING WIEDER GROSS!