Der Benutzerarbeitsplatz ist der anfälligste Punkt in der Infrastruktur in Bezug auf Informationssicherheit. Nutzer könnten eine E-Mail auf ihrer Arbeitsadresse erhalten, die scheinbar aus einer sicheren Quelle stammt, aber einen Link zu einer infizierten Website enthält. Möglicherweise lädt jemand ein nützliches Tool von einem unbekannten Ort herunter. Man kann eine Vielzahl von Szenarien entwickeln, in denen bösartige Software durch die Nutzer in interne Unternehmensressourcen eindringen kann. Daher erfordern Arbeitsstationen besondere Aufmerksamkeit, und in diesem Artikel werden wir erläutern, woher und welche Ereignisse zur Überwachung von Angriffen herangezogen werden können.
Um einen Angriff in der frühesten Phase zu erkennen, gibt es in Windows drei nützliche Ereignisquellen: das Sicherheitsereignisprotokoll, das Systemüberwachungsprotokoll und die PowerShell-Protokolle.
Sicherheitsprotokoll (Security Log)
Dies ist der Hauptspeicherort für systemrelevante Sicherheitsprotokolle. Hier werden Anmelde- und Abmeldeereignisse von Benutzern, Zugriffsereignisse auf Objekte, Änderungen von Richtlinien und andere sicherheitsrelevante Aktivitäten gespeichert. Vorausgesetzt, die entsprechende Richtlinie ist eingerichtet.
Benutzer- und Gruppenabruf (Ereignisse 4798 und 4799). Bösartige Software versucht zu Beginn eines Angriffs oft, lokale Benutzerkonten und lokale Gruppen auf der Arbeitsstation abzurufen, um Zugangsdaten für ihre dunklen Geschäfte zu finden. Diese Ereignisse helfen dabei, bösartigen Code früher zu entdecken, als dieser weiter vordringt und, basierend auf den gesammelten Daten, auf andere Systeme verbreitet wird.
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, sich mit einem lokalen Benutzerkonto anzumelden (Ereignis 4624). Ordentliche Benutzer melden sich mit einem Domänenbenutzerkonto an, und das Erkennen eines Logins unter einem lokalen Benutzerkonto kann den Beginn eines Angriffs bedeuten. Ereignis 4624 umfasst auch Anmeldungen unter Domänenkonten, weshalb bei der Verarbeitung der Ereignisse gefiltert werden sollte, dass der Domänenname nicht vom Namen der Arbeitsstation abweicht.
Versuch, sich mit einem angegebenen Benutzerkonto anzumelden (Ereignis 4648). Dies geschieht, wenn der Prozess im Modus „Als Administrator ausführen“ (run as) ausgeführt wird. Im normalen Betriebsmodus sollte dies nicht der Fall sein, daher müssen solche Ereignisse überwacht werden.
Sperren/Entsperren der Arbeitsstation (Ereignisse 4800-4803). Zu den verdächtigen Ereignissen zählen alle Aktionen, die auf einer gesperrten Arbeitsstation durchgeführt wurden.
Änderungen an 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 eine Überwachung solcher Änderungen nicht notwendig, aber es schadet nicht, darüber informiert zu sein.
Anschluss von Plug’n’Play-Geräten (Ereignis 6416 und nur für Windows 10). Das ist wichtig zu beobachten, wenn Benutzer normalerweise keine neuen Geräte an der Arbeitsstation anschließen, und plötzlich doch — und sie angeschlossen haben.
Windows umfasst 9 Kategorien der Überwachung und 50 Unterkategorien für eine feine Anpassung. Das minimale Set an Unterkategorien, das in den Einstellungen aktiviert werden sollte, lautet:
Anmeldung/Abmeldung
- Anmeldung;
- Abmeldung;
- Konto gesperrt;
- Andere Anmelde-/Abmeldeereignisse.
Kontoverwaltung
- Benutzerkontoverwaltung;
- Verwaltung von Sicherheitsgruppen.
Änderung von Richtlinien
- Änderung der Audit-Richtlinie;
- Änderung der Authentifizierungsrichtlinie;
- Änderung der Autorisierungsrichtlinie.
Systemmonitor (Sysmon)
Sysmon ist ein in Windows integriertes Dienstprogramm, das Ereignisse im Systemprotokoll aufzeichnen kann. In der Regel muss es separat installiert werden.
Diese Ereignisse lassen sich grundsätzlich auch im Sicherheitsprotokoll finden (wenn die entsprechende Audit-Richtlinie aktiviert ist), aber Sysmon bietet mehr Details. Welche Ereignisse können aus Sysmon entnommen werden?
Prozesserstellung (Ereignis-ID 1). Das Sicherheitsereignisprotokoll kann ebenfalls sagen, wann eine *.exe gestartet wurde, und zeigt sogar ihren Namen und den Startpfad an. Im Gegensatz zu Sysmon kann es jedoch den Hash der Anwendung nicht anzeigen. Schadsoftware kann sogar als harmlos klingende notepad.exe benannt sein, aber nur der Hash wird sie entlarven.
Netzwerkverbindungen (Ereignis-ID 3). Offensichtlich gibt es viele Netzwerkverbindungen, und man kann nicht alle verfolgen. Aber es ist wichtig zu beachten, dass Sysmon im Gegensatz zum Sicherheitsprotokoll eine Netzwerkverbindung den Feldern ProcessID und ProcessGUID zuordnen kann und den Port sowie IP-Adressen den Absender und den Empfänger zeigt.
Änderungen in der Registrierungsdatenbank (Ereignis-ID 12-14). Der einfachste Weg, sich selbst in den Autostart hinzuzufügen, besteht darin, sich im Register einzutragen. Security Log kann das, aber Sysmon zeigt, wer die Änderungen vorgenommen hat, wann, von wo, die Prozess-ID und den vorherigen Wert des Schlüssels.
Datei erstellen (Ereignis-ID 11). Im Gegensatz zu Security Log zeigt Sysmon nicht nur den Speicherort der Datei, sondern auch ihren Namen. Es ist klar, dass man nicht alles im Auge behalten kann, aber man kann doch bestimmte Verzeichnisse auditieren.
Und jetzt das, was in den Security Log Richtlinien nicht enthalten ist, aber in Sysmon vorhanden ist:
Änderung des Erstellungszeitpunkts der Datei (Ereignis-ID 2). Einige Malware kann das Erstellungsdatum der Datei ändern, um sie aus Berichten über kürzlich erstellte Dateien zu verbergen.
Laden von Treibern und dynamischen Bibliotheken (Ereignis-ID 6-7). Überwachung des Ladens von DLLs und Gerätetreibern in den Speicher, Überprüfung der digitalen Signatur und deren Gültigkeit.
Erstellen eines Threads in einem laufenden Prozess (Ereignis-ID 8). Eine Art von Angriff, die ebenfalls überwacht werden sollte.
Ereignisse RawAccessRead (Ereignis-ID 9). Lesevorgänge von der Festplatte unter Verwendung von „.“. In den meisten Fällen sollte eine solche Aktivität als abnormal angesehen werden.
Erstellen eines benannten Datei-Streams (Ereignis-ID 15). Ein Ereignis wird registriert, wenn ein benannter Datei-Stream erstellt wird, der Ereignisse mit dem Hash des Inhalts der Datei generiert.
Erstellen eines Named Pipes und Verbindungen (Ereignis-ID 17-18). Überwachung von schädlichem Code, der über Named Pipes mit anderen Komponenten kommuniziert.
Aktivitäten über WMI (Ereignis-ID 19). Registrierung von Ereignissen, die bei Zugriffsversuchen auf das System über das WMI-Protokoll generiert werden.
Um Sysmon selbst zu schützen, sollten Ereignisse mit der ID 4 (Stoppen und Starten von Sysmon) und ID 16 (Änderung der Sysmon-Konfiguration) überwacht werden.
Power Shell-Protokolle
Power Shell ist ein leistungsstarkes Verwaltungstool für die Windows-Infrastruktur, daher ist die Wahrscheinlichkeit hoch, dass ein Angreifer gerade dieses Tool wählt. Um Informationen über Power Shell-Ereignisse zu erhalten, können zwei Quellen verwendet werden: Windows PowerShell-Protokoll und Microsoft-WindowsPowerShell / Operational-Protokoll.
Windows PowerShell-Protokoll
Datenanbieter wurde geladen (Ereignis-ID 600). PowerShell-Anbieter sind Programme, die als Datenquellen für PowerShell dienen, um diese anzuzeigen und zu verwalten. Typische integrierte Anbieter können Umgebungsvariablen von Windows oder die Windows-Registrierung sein. Es ist wichtig, auf neue Anbieter zu achten, um böswillige Aktivitäten frühzeitig zu erkennen. Wenn Sie zum Beispiel sehen, dass plötzlich WSMan unter den Anbietern auftaucht, bedeutet dies, dass eine Remote-PowerShell-Sitzung gestartet wurde.
Microsoft-WindowsPowerShell / Operational-Protokoll (oder MicrosoftWindows-PowerShellCore / Operational in PowerShell 6)
Modul-Logging (Ereignis-ID 4103). In den Ereignissen sind Informationen zu jedem ausgeführten Befehl und den verwendeten Parametern gespeichert.
Skript-Block-Logging (Ereignis-ID 4104). Das Skriptblock-Logging zeigt jeden ausgeführten PowerShell-Codeblock an. Selbst wenn ein Angreifer versucht, den Befehl zu verbergen, wird dieser Ereignistyp den tatsächlich ausgeführten PowerShell-Befehl anzeigen. Auch können einige tiefere API-Aufrufe, die ausgeführt werden, in diesem Ereignistyp protokolliert werden; diese Ereignisse werden normalerweise als 'Verbose' vermerkt, aber wenn ein verdächtiger Befehl oder ein Skript in einem Codeblock verwendet wird, wird er mit der Schwere Warnung registriert.
Bitte beachten Sie, dass nach der Konfiguration des Tools zur Sammlung und Analyse dieser Ereignisse zusätzliche Zeit für die Fehlersuche erforderlich ist, um die Anzahl der Fehlalarme zu reduzieren.
Teilen Sie uns in den Kommentaren mit, welche Protokolle Sie zur Überprüfung der Informationssicherheit sammeln und welche Tools Sie dafür verwenden. Eine unserer Richtungen sind Lösungen zur Auditierung von Sicherheitsereignissen. Für die Aufgabe der Protokollsammlung und -analyse können wir empfehlen, sich für , das gespeicherte Daten mit einem Verhältnis von 20:1 komprimieren kann, und ein installierter Instanz kann bis zu 60.000 Ereignisse pro Sekunde aus 10.000 Quellen verarbeiten.
Quelle: habr.com
