Der Benutzerarbeitsplatz ist im Hinblick auf die Informationssicherheit der anfälligste Punkt der Infrastruktur. Benutzer erhalten möglicherweise einen Brief an ihre geschäftliche E-Mail-Adresse, der scheinbar von einer sicheren Quelle stammt, jedoch einen Link zu einer infizierten Website enthält. Vielleicht lädt jemand ein für die Arbeit nützliches Dienstprogramm von einem unbekannten Ort herunter. Ja, Sie können sich Dutzende Fälle vorstellen, in denen Malware über Benutzer in interne Unternehmensressourcen eindringen kann. Daher erfordern Workstations erhöhte Aufmerksamkeit. In diesem Artikel erfahren Sie, wo und welche Maßnahmen zur Überwachung von Angriffen erforderlich sind.
Um einen Angriff im frühestmöglichen Stadium zu erkennen, verfügt WIndows über drei nützliche Ereignisquellen: das Sicherheitsereignisprotokoll, das Systemüberwachungsprotokoll und die Power Shell-Protokolle.
Sicherheitsereignisprotokoll
Dies ist der Hauptspeicherort für Systemsicherheitsprotokolle. Dazu gehören Ereignisse der Benutzeranmeldung/-abmeldung, des Zugriffs auf Objekte, Richtlinienänderungen und anderer sicherheitsrelevanter Aktivitäten. Natürlich, wenn die entsprechende Richtlinie konfiguriert ist.
Aufzählung von Benutzern und Gruppen (Ereignisse 4798 und 4799). Gleich zu Beginn eines Angriffs durchsucht Malware häufig lokale Benutzerkonten und lokale Gruppen auf einer Workstation, um Anmeldeinformationen für ihre zwielichtigen Machenschaften zu finden. Diese Ereignisse tragen dazu bei, bösartigen Code zu erkennen, bevor er weitergeht und sich mithilfe der gesammelten Daten auf andere Systeme ausbreitet.
Erstellung eines lokalen Kontos und Änderungen in lokalen Gruppen (Ereignisse 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 und 5377). Der Angriff kann beispielsweise auch durch das Hinzufügen eines neuen Benutzers zur lokalen Administratorengruppe beginnen.
Anmeldeversuche mit einem lokalen Konto (Ereignis 4624). Seriöse Benutzer melden sich mit einem Domänenkonto an, und die Identifizierung eines Logins unter einem lokalen Konto kann den Beginn eines Angriffs bedeuten. Ereignis 4624 umfasst auch Anmeldungen unter einem Domänenkonto. Daher müssen Sie bei der Verarbeitung von Ereignissen Ereignisse herausfiltern, bei denen sich die Domäne vom Namen der Arbeitsstation unterscheidet.
Ein Versuch, sich mit dem angegebenen Konto anzumelden (Ereignis 4648). Dies geschieht, wenn der Prozess im Modus „Ausführen als“ ausgeführt wird. Dies sollte während des normalen Betriebs von Systemen nicht passieren, daher müssen solche Ereignisse kontrolliert werden.
Sperren/Entsperren der Workstation (Ereignisse 4800–4803). Die Kategorie der verdächtigen Ereignisse umfasst alle Aktionen, die auf einem gesperrten Arbeitsplatz ausgeführt wurden.
Änderungen an der Firewall-Konfiguration (Ereignisse 4944–4958). Offensichtlich können sich bei der Installation neuer Software die Firewall-Konfigurationseinstellungen ändern, was zu Fehlalarmen führen kann. In den meisten Fällen besteht keine Notwendigkeit, solche Änderungen zu kontrollieren, aber es kann definitiv nicht schaden, darüber Bescheid zu wissen.
Anschließen von Plug'n'Play-Geräten (Ereignis 6416 und nur für Windows 10). Es ist wichtig, dies im Auge zu behalten, wenn Benutzer normalerweise keine neuen Geräte an den Arbeitsplatz anschließen, dies aber plötzlich der Fall ist.
Windows umfasst 9 Überwachungskategorien und 50 Unterkategorien zur Feinabstimmung. Der Mindestsatz an Unterkategorien, die in den Einstellungen aktiviert werden sollten:
Anmelden/Abmelden
- Einloggen;
- Abmelden;
- Kontosperrung;
- Andere Anmelde-/Abmeldeereignisse.
Kundenbetreuung
- Benutzerkontenverwaltung;
- Sicherheitsgruppenverwaltung.
Richtlinienänderung
- Änderung der Prüfrichtlinie;
- Änderung der Authentifizierungsrichtlinie;
- Änderung der Autorisierungsrichtlinie.
Systemmonitor (Sysmon)
Sysmon ist ein in Windows integriertes Dienstprogramm, das Ereignisse im Systemprotokoll aufzeichnen kann. Normalerweise müssen Sie es separat installieren.
Dieselben Ereignisse können im Prinzip im Sicherheitsprotokoll gefunden werden (durch Aktivieren der gewünschten Überwachungsrichtlinie), Sysmon bietet jedoch detailliertere Informationen. Welche Ereignisse können aus Sysmon übernommen werden?
Prozesserstellung (Ereignis-ID 1). Das Systemsicherheitsereignisprotokoll kann Ihnen auch sagen, wann eine *.exe gestartet wurde, und sogar ihren Namen und Startpfad anzeigen. Im Gegensatz zu Sysmon kann der Anwendungs-Hash jedoch nicht angezeigt werden. Schädliche Software wird vielleicht sogar harmlos „notepad.exe“ genannt, aber es ist der Hash, der sie ans Licht bringt.
Netzwerkverbindungen (Ereignis-ID 3). Offensichtlich gibt es viele Netzwerkverbindungen und es ist unmöglich, den Überblick über alle zu behalten. Es ist jedoch wichtig zu berücksichtigen, dass Sysmon im Gegensatz zu Security Log eine Netzwerkverbindung an die Felder ProcessID und ProcessGUID binden kann und den Port und die IP-Adressen der Quelle und des Ziels anzeigt.
Änderungen in der Systemregistrierung (Ereignis-ID 12-14). Der einfachste Weg, sich zu Autorun hinzuzufügen, besteht darin, sich in der Registrierung zu registrieren. Das Sicherheitsprotokoll kann dies tun, aber Sysmon zeigt an, wer die Änderungen wann und von wo vorgenommen hat, die Prozess-ID und den vorherigen Schlüsselwert.
Dateierstellung (Ereignis-ID 11). Im Gegensatz zum Sicherheitsprotokoll zeigt Sysmon nicht nur den Speicherort der Datei, sondern auch ihren Namen an. Es ist klar, dass Sie nicht den Überblick behalten können, aber Sie können bestimmte Verzeichnisse überwachen.
Und was steht nun nicht in den Sicherheitsprotokollrichtlinien, sondern in Sysmon:
Änderung der Dateierstellungszeit (Ereignis-ID 2). Manche Malware kann das Erstellungsdatum einer Datei fälschen, um sie vor Berichten über kürzlich erstellte Dateien zu verbergen.
Laden von Treibern und dynamischen Bibliotheken (Ereignis-IDs 6–7). Überwachen des Ladens von DLLs und Gerätetreibern in den Speicher, Überprüfen der digitalen Signatur und ihrer Gültigkeit.
Erstellen Sie einen Thread in einem laufenden Prozess (Ereignis-ID 8). Eine Angriffsart, die ebenfalls überwacht werden muss.
RawAccessRead-Ereignisse (Ereignis-ID 9). Festplatten-Lesevorgänge mit „.“ In den allermeisten Fällen sollte eine solche Aktivität als abnormal angesehen werden.
Erstellen Sie einen benannten Dateistream (Ereignis-ID 15). Ein Ereignis wird protokolliert, wenn ein benannter Dateistream erstellt wird, der Ereignisse mit einem Hash des Dateiinhalts ausgibt.
Erstellen einer benannten Pipe und Verbindung (Ereignis-ID 17–18). Verfolgen Sie bösartigen Code, der über die Named Pipe mit anderen Komponenten kommuniziert.
WMI-Aktivität (Ereignis-ID 19). Registrierung von Ereignissen, die beim Zugriff auf das System über das WMI-Protokoll generiert werden.
Um Sysmon selbst zu schützen, müssen Sie Ereignisse mit der ID 4 (Sysmon-Stoppen und -Starten) und ID 16 (Sysmon-Konfigurationsänderungen) überwachen.
Power Shell-Protokolle
Power Shell ist ein leistungsstarkes Tool zur Verwaltung der Windows-Infrastruktur, daher ist die Wahrscheinlichkeit hoch, dass ein Angreifer es wählt. Es gibt zwei Quellen, die Sie zum Abrufen von Power Shell-Ereignisdaten verwenden können: das Windows PowerShell-Protokoll und das Microsoft-WindowsPowerShell/Operational-Protokoll.
Windows PowerShell-Protokoll
Datenprovider geladen (Ereignis-ID 600). PowerShell-Anbieter sind Programme, die PowerShell eine Datenquelle zum Anzeigen und Verwalten bereitstellen. Integrierte Anbieter könnten beispielsweise Windows-Umgebungsvariablen oder die Systemregistrierung sein. Das Aufkommen neuer Anbieter muss überwacht werden, um böswillige Aktivitäten rechtzeitig zu erkennen. Wenn Sie beispielsweise WSMan unter den Anbietern sehen, wurde eine Remote-PowerShell-Sitzung gestartet.
Microsoft-WindowsPowerShell / Betriebsprotokoll (oder MicrosoftWindows-PowerShellCore / Betriebsprotokoll in PowerShell 6)
Modulprotokollierung (Ereignis-ID 4103). Ereignisse speichern Informationen über jeden ausgeführten Befehl und die Parameter, mit denen er aufgerufen wurde.
Protokollierung der Skriptblockierung (Ereignis-ID 4104). Die Protokollierung der Skriptblockierung zeigt jeden ausgeführten Block des PowerShell-Codes. Selbst wenn ein Angreifer versucht, den Befehl zu verbergen, zeigt dieser Ereignistyp den tatsächlich ausgeführten PowerShell-Befehl an. Dieser Ereignistyp kann auch einige durchgeführte API-Aufrufe auf niedriger Ebene protokollieren. Diese Ereignisse werden normalerweise als „Ausführlich“ aufgezeichnet. Wenn jedoch ein verdächtiger Befehl oder ein verdächtiges Skript in einem Codeblock verwendet wird, wird dies als Schweregrad „Warnung“ protokolliert.
Bitte beachten Sie, dass, sobald das Tool zum Sammeln und Analysieren dieser Ereignisse konfiguriert ist, zusätzliche Debugging-Zeit erforderlich ist, um die Anzahl falsch positiver Ergebnisse zu reduzieren.
Teilen Sie uns in den Kommentaren mit, welche Protokolle Sie für Informationssicherheitsaudits sammeln und welche Tools Sie dafür verwenden. Einer unserer Schwerpunkte sind Lösungen zur Prüfung von Informationssicherheitsereignissen. Um das Problem des Sammelns und Analysierens von Protokollen zu lösen, können wir vorschlagen, einen genaueren Blick darauf zu werfen , das gespeicherte Daten mit einem Verhältnis von 20:1 komprimieren kann, und eine installierte Instanz davon ist in der Lage, bis zu 60000 Ereignisse pro Sekunde aus 10000 Quellen zu verarbeiten.
Source: habr.com