Die Benutzer-Workstation ist der anfälligste Punkt der Infrastruktur in Bezug auf Informationssicherheit. Benutzer können E-Mails erhalten, die scheinbar aus sicheren Quellen stammen, jedoch Links zu infizierten Websites enthalten. Möglicherweise lädt jemand eine nützliche Software aus unbekannter Quelle herunter. Man könnte zahlreiche Szenarien entwerfen, wie schadhafte Software über Benutzer in Unternehmensressourcen eindringen kann. Daher erfordern Workstations besondere Aufmerksamkeit. In diesem Artikel werden wir erläutern, welche Ereignisse zur Überwachung von Angriffen relevant sind und woher man sie bezieht.
Um Angriffe in der frühesten Phase zu erkennen, gibt es in Windows drei nützliche Ereignisquellen: das Sicherheitsereignisprotokoll, das Systemprotokoll und die PowerShell-Protokolle.
Sicherheitsereignisprotokoll (Security Log)
Dies ist der zentrale Speicherort für Sicherheitsprotokolle. Hier werden Ereignisse zu Benutzeranmeldungen/-abmeldungen, Objektzugriff, Änderung von Richtlinien und anderen sicherheitsrelevanten Aktivitäten aufgezeichnet. Selbstverständlich, vorausgesetzt, die entsprechende Richtlinie ist konfiguriert.
Durchsuchung von Benutzern und Gruppen (Ereignisse 4798 und 4799). Schadhafter Code durchsucht zu Beginn eines Angriffs oft lokale Benutzerkonten und Gruppen auf dem Arbeitsplatz, um Anmeldeinformationen für seine dunklen Machenschaften zu finden. Diese Ereignisse helfen, schädlichen Code früher zu erkennen, bevor er weiter vordringt und sich mittels der gesammelten Daten auf andere Systeme ausbreitet.
Erstellung eines lokalen Benutzerkontos und Änderungen in lokalen Gruppen (Ereignisse 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 und 5377). Ein Angriff kann beispielsweise auch mit der Hinzufügung eines neuen Benutzers zur Gruppe der lokalen Administratoren beginnen.
Versuche der Anmeldung mit einem lokalen Benutzerkonto (Ereignis 4624). Ordnungsgemäße Nutzer melden sich mit einem Domänenkonto an, und eine Anmeldung mit einem lokalen Konto könnte den Beginn eines Angriffs signalisieren. Ereignis 4624 umfasst auch Anmeldungen mit einem Domänenkonto, daher sollten bei der Verarbeitung von Ereignissen solche Ereignisse herausgefiltert werden, bei denen die Domäne von dem Namen der Arbeitsstation abweicht.
Anmeldeversuch mit dem angegebenen Konto (Ereignis 4648). Das tritt auf, wenn ein Prozess im Modus „Ausführen als“ arbeitet. Im Normalbetrieb der Systeme sollte dies nicht der Fall sein, daher sollten solche Ereignisse überwacht werden.
Sperren/Entsperren einer Arbeitsstation (Ereignisse 4800-4803). Zu den verdächtigen Ereignissen gehören alle Aktivitäten, die auf einer gesperrten Arbeitsstation stattgefunden haben.
Änderungen der Firewall-Konfiguration (Ereignisse 4944-4958). Offensichtlich können sich bei der Installation neuer Software die Einstellungen der Firewall-Konfiguration ändern, was zu Fehlalarmen führen kann. In den meisten Fällen ist es nicht notwendig, solche Änderungen zu überwachen, aber darüber informiert zu sein, schadet sicherlich nicht.
Anschließen von Plug’n’Play-Geräten (Ereignis 6416 und nur für Windows 10). Es ist wichtig darauf zu achten, wenn Benutzer normalerweise keine neuen Geräte an die Arbeitsstation anschließen und plötzlich eines anschließen.
Windows umfasst 9 Kategorien der Überwachung und 50 Unterkategorien zur Feinabstimmung. Das minimale Set von Unterkategorien, das in den Einstellungen aktiviert werden sollte, umfasst:
Anmeldung/Ausmeldung
- Anmeldung;
- Abmeldung;
- Konto sperren;
- Andere Anmelde-/Abmeldeereignisse.
Kontoverwaltung
- Benutzerkontoverwaltung;
- Verwaltung von Sicherheitsgruppen.
Richtlinienänderung
- Änderung der Prüfrichtlinie;
- Änderung der Authentifizierungsrichtlinie;
- Änderung der Genehmigungsrichtlinie.
Systemmonitor (Sysmon)
Sysmon ist ein in Windows integriertes Tool, das in der Lage ist, Ereignisse im Systemprotokoll aufzuzeichnen. Häufig muss es separat installiert werden.
Diese Ereignisse können grundsätzlich auch im Sicherheitsprotokoll gefunden werden (wenn die entsprechende Prüfpolitik aktiviert ist), aber Sysmon liefert mehr Details. Welche Ereignisse können aus Sysmon abgerufen werden?
Prozesserstellung (Ereignis-ID 1). Das Sicherheitsereignisprotokoll kann auch anzeigen, wann eine *.exe gestartet wurde, und sogar ihren Namen und den Startpfad zeigen. Im Gegensatz zu Sysmon kann es jedoch den Hash der Anwendung nicht anzeigen. Schadsoftware kann als harmloses notepad.exe aufgeführt werden, aber genau der Hash wird sie entlarven.
Netzwerkverbindungen (Ereignis-ID 3). Es gibt offensichtlich viele Netzwerkverbindungen, und es ist schwierig, den Überblick zu behalten. Wichtig zu beachten ist, dass Sysmon im Gegensatz zum Security Log die Netzwerkverbindung mit den Feldern ProcessID und ProcessGUID verknüpfen kann, zeigt den Port und IP-Adressen den Sender und Empfänger.
Änderungen in der Windows-Registry (Ereignis-ID 12-14). Der einfachste Weg, sich selbst beim Autostart hinzuzufügen, besteht darin, sich in der Registry einzutragen. Das Security Log kann das, aber Sysmon zeigt, wer die Änderungen vorgenommen hat, wann, von wo, die Process ID und den vorherigen Wert des Schlüssels.
Dateierstellung (Ereignis-ID 11). Sysmon zeigt im Gegensatz zum Security Log nicht nur den Speicherort der Datei, sondern auch ihren Namen an. Es ist klar, dass man nicht alles im Blick behalten kann, aber man kann bestimmte Verzeichnisse auditen.
Und jetzt das, was in den Richtlinien des Security Logs nicht vorhanden ist, aber in Sysmon vorhanden ist:
Änderung des Erstellungszeitpunkts einer Datei (Ereignis-ID 2). Einige Malware kann das Erstellungsdatum einer Datei ändern, um sie aus den Berichten über neu erstellte Dateien zu verbergen.
Laden von Treibern und DLLs (Ereignis-ID 6-7). Überwachung des Ladens von DLL und Gerätetreibern in den Arbeitsspeicher, Überprüfung der digitalen Signatur und deren Gültigkeit.
Erstellung eines Threads in einem laufenden Prozess (Ereignis-ID 8). Eine der Angriffsmethoden, die ebenfalls im Auge behalten werden sollte.
Ereignisse RawAccessRead (Ereignis-ID 9). Lesevorgänge von der Festplatte mithilfe von „.”. In den meisten Fällen sollte eine solche Aktivität als abnormal angesehen werden.
Erstellung eines benannten Dateistreams (Ereignis-ID 15). Das Ereignis wird registriert, wenn ein benannter Dateistream erstellt wird, der Ereignisse mit einem Hash des Dateiinhalts erzeugt.
Erstellung einer named pipe und Verbindungen (Ereignis-ID 17-18). Überwachung von Malware, die über named pipes mit anderen Komponenten kommuniziert.
Aktivitäten über WMI (Ereignis-ID 19). Registrierung von Ereignissen, die beim Zugriff auf das System über das WMI-Protokoll generiert werden.
Zum Schutz von Sysmon sollten die Ereignisse mit ID 4 (Beendigung und Start von Sysmon) und ID 16 (Änderung der Sysmon-Konfiguration) überwacht werden.
PowerShell-Protokolle
PowerShell ist ein leistungsstarkes Tool zur Verwaltung von Windows-Infrastrukturen, daher ist die Wahrscheinlichkeit hoch, dass ein Angreifer es wählt. Um Informationen über PowerShell-Ereignisse zu erhalten, können zwei Quellen verwendet werden: das Windows PowerShell-Protokoll und das Microsoft-WindowsPowerShell / Operational-Protokoll.
Windows PowerShell-Protokoll
Datenanbieter wurde geladen (Ereignis-ID 600). PowerShell-Anbieter sind Programme, die als Datenquelle für PowerShell dienen, um sie zu durchsuchen und zu verwalten. Eingebaute Anbieter können beispielsweise Windows-Umgebungsvariablen oder das Systemregister sein. Es ist wichtig, auf das Erscheinen neuer Anbieter zu achten, um böswillige Aktivitäten rechtzeitig zu erkennen. Zum Beispiel, wenn Sie sehen, dass WSMan unter den Anbietern erscheint, bedeutet dies, dass eine Remote-PowerShell-Sitzung gestartet wurde.
Microsoft-WindowsPowerShell / Betriebsprotokoll (oder MicrosoftWindows-PowerShellCore / Betriebsprotokoll in PowerShell 6)
Modulprotokollierung (Ereignis-ID 4103). In den Ereignissen wird jede ausgeführte Befehlszeile und die Parameter, mit denen sie aufgerufen wurde, aufgezeichnet.
Skriptblockprotokollierung (Ereignis-ID 4104). Die Protokollierung von Skriptblockaden zeigt jeden ausgeführten PowerShell-Codeblock an. Selbst wenn ein Angreifer versucht, den Befehl zu verbergen, wird diese Art von Ereignis den tatsächlich ausgeführten PowerShell-Befehl anzeigen. Zudem können in diesem Ereignistyp einige niedrigstufige API-Aufrufe protokolliert werden, die normalerweise als Verbose aufgezeichnet werden. Wird jedoch ein verdächtiger Befehl oder ein Skript in einem Codeblock verwendet, wird er mit der Schwere Warnung protokolliert.
Bitte beachten Sie, dass nach der Einrichtung des Tools zur Sammlung und Analyse dieser Ereignisse zusätzliche Zeit für das Debugging erforderlich ist, um die Anzahl der Fehlalarme zu reduzieren.
Teilen Sie uns in den Kommentaren mit, welche Protokolle Sie zur Auditierung der Informationssicherheit sammeln und welche Tools Sie dafür verwenden. Eine unserer Richtungen sind Lösungen zur Auditierung von Sicherheitsereignissen. Für die Herausforderung der Sammlung und Analyse von Protokollen können wir Ihnen empfehlen, sich für zu interessieren, das gespeicherte Daten mit einem Verhältnis von 20:1 komprimieren kann und dessen eine installierte Instanz bis zu 60.000 Ereignisse pro Sekunde aus 10.000 Quellen verarbeiten kann.
Quelle: habr.com
