Vorbereitungen zur Untersuchung von Vorfällen

Ist es möglich, sich vollständig gegen Cyber-Angriffe zu verteidigen? Wahrscheinlich können Sie dies, wenn Sie sich mit allen vorhandenen Schutzmitteln umgeben und ein großes Expertenteam für die Verwaltung der Prozesse einstellen. Es ist jedoch klar, dass dies in der Realität unmöglich ist: Das Budget für Informationssicherheit ist nicht unendlich, und es wird dennoch zu Zwischenfällen kommen. Und da sie passieren werden, müssen Sie sich auf sie vorbereiten!

In diesem Artikel werden typische Szenarien für die Untersuchung von Malware-Vorfällen vorgestellt, in den Protokollen angegeben, worauf zu achten ist, und technische Empfehlungen zur Konfiguration von Informationsschutz-Tools gegeben, um die Erfolgsaussichten einer Untersuchung zu erhöhen.



Der klassische Prozess zur Reaktion auf einen Vorfall mit Malware umfasst Phasen wie Erkennung, Eindämmung, Wiederherstellung usw. Alle Ihre Funktionen werden jedoch in der Vorbereitungsphase festgelegt. Beispielsweise hängt die Erkennungsrate von Infektionen direkt davon ab, wie gut das Audit im Unternehmen konfiguriert ist.


Klassischer SANS Incident Response Cycle

Im Allgemeinen sind die Aktionen der Analysten während der Untersuchung wie folgt:

1. Generierung von Versionen, in denen die Ursachen des Vorfalls erläutert werden (z. B. „Die Malware wurde auf dem Host installiert, weil der Benutzer sie über eine Phishing-E-Mail gestartet hat“ oder „Der Vorfall ist ein Fehlalarm, weil der Benutzer eine legitime Site auf demselben Hosting wie der Verwaltungsserver besucht hat Malware ”).
2. Priorisierung von Versionen nach Wahrscheinlichkeitsgrad. Die Wahrscheinlichkeit wird auf der Grundlage von Statistiken über vergangene Vorfälle, der Kritikalität des Vorfalls oder Systems und auch auf der Grundlage persönlicher Erfahrungen berechnet (aber eher vorgetäuscht).
3. Studieren Sie jede Version, suchen Sie nach Fakten, die sie beweisen oder widerlegen.

Natürlich macht es keinen Sinn, alle möglichen Hypothesen zu testen - zumindest weil die Zeit begrenzt ist. Daher werden wir uns hier die wahrscheinlichsten Versionen und typischen Szenarien für die Untersuchung von Malware-Vorfällen ansehen.

Szenario 1

Sie vermuten, dass ein unkritisches System durch Malware kompromittiert wurde. Aufgrund des unkritischen Charakters des Systems wurde ein wenig Zeit für die Überprüfung bereitgestellt.

Das erste, was die meisten Antwortingenieure tun, ist eine Antivirenprüfung durchzuführen. Wie wir jedoch wissen, ist ein Antivirus nicht so schwer zu umgehen. Daher lohnt es sich, die folgende höchstwahrscheinliche Version zu generieren und zu erarbeiten: Malware ist eine separate ausführbare Datei oder ein Dienst.

Im Rahmen dieser Version müssen drei einfache Schritte ausgeführt werden:

1. Filtern Sie das Sicherheitsprotokoll nach Ereignis 4688, damit eine Liste aller gestarteten Prozesse angezeigt wird.
2. Filtern Sie das Systemprotokoll nach Ereignis 7045, damit eine Liste der Installationen aller Dienste angezeigt wird.
3. Identifizieren Sie neue Prozesse und Services, die zuvor nicht im System vorhanden waren. Kopieren Sie diese Module und analysieren Sie sie auf schädlichen Code (scannen Sie mit mehreren Virenschutzprogrammen, überprüfen Sie die Gültigkeit der digitalen Signatur, dekompilieren Sie den Code usw.).

Listen Sie alle laufenden Prozesse und Dienste im Ereignisprotokoll-Explorer auf

Theoretisch ist dies ein ziemlich trivialer Prozess. In der Praxis gibt es jedoch eine Reihe von Fallstricken, auf die man sich einstellen muss.

Erstens protokolliert das Standard-Windows-Überwachungssetup nicht die Fakten des Prozessstarts (Ereignis 4688), sodass es im Voraus in der Domänengruppenrichtlinie aktiviert werden muss. Wenn diese Prüfung nicht im Voraus enthalten war, können Sie versuchen, eine Liste der ausführbaren Dateien von anderen Windows-Artefakten abzurufen , z. B. von der Amcache- Registrierung. Sie können Daten aus dieser Registrierungsdatei mit dem Dienstprogramm AmcaheParser extrahieren .


Ein Beispiel für das Extrahieren der Fakten zum Starten von Prozessen aus Amcache.hve

Diese Methode ist jedoch nicht sehr zuverlässig, da sie keine genauen Informationen darüber liefert, wann genau und wie oft der Prozess gestartet wurde.

Zweitens sind Hinweise auf den Start von Prozessen wie cmd.exe, Powershell.exe, wscript.exe und anderen Interpreten ohne Informationen über die Befehlszeile, mit der die Prozesse gestartet wurden, von geringem Nutzen Es enthält den Pfad zu einer möglicherweise schädlichen Skriptdatei.


Ausführen des Skriptinterpreters ohne Informationen darüber, welches Skript gestartet wurde

Eine weitere Funktion von Windows besteht darin, dass die Befehlszeilenüberwachung des gestarteten Prozesses durch separate Konfiguration der Domänengruppenrichtlinie durchgeführt wird: Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> System -> Prozesserstellung überwachen -> Befehlszeile in Prozesserstellungsereignisse einbeziehen . Gleichzeitig protokolliert das recht beliebte Windows 7/2008 die Befehlszeile nicht, ohne dass das KB3004375- Update installiert ist.

Wenn Sie im Voraus nichts konfiguriert oder das Update vergessen haben, können Sie versuchen, den Speicherort des Skripts in den Prefetch- Dateien zu ermitteln (ein Hilfsprogramm ). Sie enthalten Informationen zu allen Dateien (hauptsächlich DLLs), die in den ersten 10 Sekunden des Lebens in den Prozess geladen wurden. Und das in den Befehlszeilenargumenten des Interpreters enthaltene Skript wird dort sicherlich vorhanden sein.


Beispiel für das Auffinden eines "verlorenen" Befehlszeilenarguments in Prefetch

Diese Methode ist jedoch überhaupt nicht zuverlässig. Wenn Sie das nächste Mal den Prozess starten, wird der Prefetch-Cache überschrieben.

Vorbereitung auf die Untersuchung:

• Schließen Sie eine erweiterte Prüfung der Erstellung und des Abschlusses von Prozessen ein.
• Aktivieren Sie die Protokollierung von Prozessbefehlszeilenargumenten.
• Installieren Sie das Update KB3004375 unter Windows 7 / Server 2008.

Szenario 2

Auf dem Perimeter-Router wurde ein Zugriff auf den Malware-Verwaltungsserver aufgezeichnet. Die IP-Adresse des böswilligen Servers wurde aus einem Abonnement für Bedrohungsinformationen mit mittlerer Sicherheit abgerufen.

In einem unserer vorherigen Artikel haben wir gesagt, dass TI-Analysten sündigen, indem sie die Liste der Indikatoren für kompromittierte IP-Adressen von Servern ergänzen, auf denen gleichzeitig Malware-Kontrollzentren und legitime Websites gehostet werden. Wenn Sie gerade erst mit der Formulierung von Antwortprozessen begonnen haben, ist es in den ersten Phasen besser, auf die Verwendung solcher Indikatoren zu verzichten, da jeder Versuch eines Benutzers, eine legitime Website aufzurufen, wie ein vollständiger Vorfall aussieht.

Eine der Möglichkeiten, auf solche Alarme zu reagieren, besteht darin, zu überprüfen, welcher Prozess die Verbindung hergestellt hat. Wenn es sich um einen Internetbrowser handelt, kann der Vorfall als Fehlalarm angesehen werden, wenn keine anderen Fakten vorliegen, die auf einen Kompromiss hinweisen.

Es gibt viele Möglichkeiten, um herauszufinden, welcher Prozess die Verbindung initiiert hat: Sie können netstat ausführen und die aktuellen Sockets anzeigen oder einen Speicherauszug sammeln und dann die Volatilität festlegen, die auch bereits abgeschlossene Verbindungen anzeigen kann. Aber das alles ist lang, nicht skalierbar und vor allem nicht zuverlässig. Es ist viel zuverlässiger, alle erforderlichen Informationen aus dem Windows-Sicherheitsprotokoll abzurufen.


Korrelation des Ereignisses "Zugriff auf schädliche IP-Adresse" im HPE Arcsight SIEM-System und des entsprechenden Prozesses im Windows-Sicherheitsprotokoll

Untersuchungsvorbereitung

Um dieses Szenario auf einem Benutzercomputer zu erarbeiten, sollten Sie die Protokollierung aller Netzwerkverbindungen im Sicherheitsprotokoll aktivieren. Dies kann basierend auf Überwachungsereignissen der Filterplattform und Paketüberwachungsüberwachung erfolgen .

Gleichzeitig kann das Magazin schnell verstopfen. Erhöhen Sie die Größe auf 2-3 GB. Nach unserer Erfahrung reicht dieser Betrag auf einem regulären Benutzerhost für etwa 3 Tage aus, um alle Sockets aufzuzeichnen, und dieser Zeitraum reicht für eine erfolgreiche Untersuchung völlig aus.

Auf stark ausgelasteten Servern wie Domänencontrollern, Webservern usw. sollten Sie dies nicht tun, da das Protokoll viel schneller überläuft.

Szenario 3

Ihr NG / ML / Anti-APT-Anomalieerkennungssystem meldet, dass 30 Hosts nach denselben Konten suchen.

Wenn Angreifer in ein neues Netzwerk eintreten, versuchen sie normalerweise herauszufinden, welche Dienste darin vorhanden sind und welche Konten verwendet werden. Dies hilft sehr bei der weiteren Bewegung entlang der Infrastruktur. Diese Informationen können insbesondere mit dem Befehl net user / domain von Active Directory selbst abgerufen werden.

Wenn potenzielle Informationen von einem Host ausgeführt werden, können sie untersucht werden, einschließlich der Verwendung der Protokolle laufender Prozesse. Wenn es jedoch viele Hosts gibt und die Angriffe vom gleichen Typ sind (zur gleichen Zeit aufgetreten sind oder dieselbe Gruppe von Entitäten von AD angefordert wurde), ist es zunächst sinnvoll, ein typisches falsches Positiv auszuschließen. Erstellen und überprüfen Sie dazu die folgenden Versionen:

1. Die Intelligenz ist auf 30 Hosts für dieselben AD-Objekte festgelegt, da der legitime Netzbenutzer, der Administrator, den Befehl net gestartet hat.
2. Die Intelligenz ist auf 30 Hosts für dieselben AD-Objekte festgelegt, da dieselbe legitime Software erstellt wurde.

Die statistische Analyse von Protokollen hilft dabei, diese Knotenpunkte zu finden (ein häufiger Benutzer oder Prozess). Wir haben diese Methode in einem früheren Artikel für DNS-Serverprotokolle demonstriert. Solche wirksamen Untersuchungsmethoden können jedoch nicht angewendet werden, wenn die Speicherung der Daten nicht im Voraus organisiert wurde.

Untersuchungsvorbereitung

Es ist erforderlich, die Langzeitspeicherung von mindestens den folgenden Daten aus den Protokollen allgemeiner Netzwerkdienste zu organisieren:

• Domänencontroller - Eingaben, Ausgaben von Konten und Ausgabe von Tickets Kerberos (Kategorie Kontoanmeldung in den erweiterten Überwachungseinstellungen).
• Proxies - Adressen, Quell- und externe Server-Ports sowie die vollständige URL.
• DNS-Server - erfolgreiche und erfolglose DNS-Abfragen und deren Quelle im Netzwerk.
• Perimeter-Router - Erstellt und heruntergefahren für alle TCP / UDP-Verbindungen sowie für Verbindungen, die versuchen, die Regeln des logischen Zugriffs zu brechen: Versuchen Sie beispielsweise, eine DNS-Abfrage direkt unter Umgehung des DNS-Servers des Unternehmens nach außen zu senden.

Szenario 4

Ihre Domain wurde kompromittiert und Sie befürchten, dass ein Angreifer mithilfe der DCShadow-Technik in der Infrastruktur Fuß fassen könnte.

Angenommen, es ist etwas Schreckliches passiert: Sie stellen fest, dass das Domänenadministratorkonto kompromittiert wurde.

Die Reaktion auf einen solchen Vorfall umfasst einen sehr großen Arbeitsaufwand, einschließlich einer Analyse aller Aktionen, die unter diesem Konto ausgeführt werden. Ein Teil dieser Untersuchung kann nur mit Domänencontrollerprotokollen durchgeführt werden. Sie können beispielsweise die Ereignisse im Zusammenhang mit der Ausstellung von Kerberos-Tickets untersuchen, um zu verstehen, woher sie unter diesem Konto stammen. Sie können auch die Ereignisse analysieren, die mit der Änderung kritischer AD-Objekte verbunden sind, um zu überprüfen, ob sich die Zusammensetzung von Gruppen mit hohen Berechtigungen (dieselben Domänenadministratoren) geändert hat. All dies erfordert natürlich ein vorkonfiguriertes Audit.

Es besteht jedoch das Problem, dass ein Angreifer mit Domänenadministratorrechten AD-Objekte mithilfe der DCShadow-Technik ändern kann, die auf dem Replikationsmechanismus zwischen Domänencontrollern basiert.

Das Wesentliche ist, dass der Angreifer selbst ein Domänencontroller zu sein scheint, Änderungen an AD vornimmt und diese Änderungen dann mit legitimen Controllern repliziert (synchronisiert), wodurch die Prüfung der auf ihnen konfigurierten Objektänderungen umgangen wird. Das Ergebnis eines solchen Angriffs kann das Hinzufügen eines Benutzers zu einer Gruppe von Domänenadministratoren oder schwierigere Bindungen durch Ändern des SID- Verlaufsattributs oder durch Ändern des AdminSDHolder- ACL-Objekts sein.

Um die Version auf das Vorhandensein nicht festgeschriebener Änderungen in AD zu überprüfen, müssen Sie die Replikationsprotokolle der Controller untersuchen: Wenn andere IP-Adressen als Domänencontroller an der Replikation beteiligt waren, können Sie sicher sagen, dass der Angriff erfolgreich war.


Entfernen eines unbekannten Domänencontrollers aus der AD-Replikation

Vorbereitung auf die Untersuchung:

• Um die von einem kompromittierten Konto begangenen Aktionen zu untersuchen, müssen Sie im Voraus Folgendes angeben:
  
  • Überwachen von Kontoein- und -ausgaben und Ausstellen von Kerberos-Tickets ( Kontoanmeldekategorie in erweiterten Überwachungseinstellungen).
  • Überwachen von Änderungen an Konten und Gruppen (Kategorie " Kontoverwaltung ").
• So untersuchen Sie Versionen im Zusammenhang mit möglichen DCShadow-Angriffen:
  
  • Aktivieren Sie die ausführliche Prüfung der Verzeichnisdienstreplikation .
  • Organisieren Sie die Langzeitspeicherung von Ereignissen 4928/4929, bei denen die Ereignisquelle kein legitimer Domänencontroller ist (DCShadow-Attribut).

Fazit

In diesem Artikel haben wir einige typische Szenarien für die Untersuchung von Vorfällen im Bereich der Informationssicherheit und Maßnahmen zu ihrer vorbeugenden Vorbereitung erörtert. Wenn Sie sich für dieses Thema interessieren und bereit sind, weiter zu gehen, empfehlen wir Ihnen, dieses Dokument zu lesen , in dem beschrieben wird, in welchen Windows-Ereignissen Sie Spuren der Verwendung gängiger Hacking-Techniken finden.

Ich möchte mit einem Zitat aus einer aktuellen Studie eines Cybersicherheitsunternehmens enden:

„Russische Direktoren für Informationssicherheit geben zum größten Teil pessimistische Antworten [auf Forschungsfragen]. Die Hälfte (48%) glaubt daher, dass sich das Budget in keiner Weise ändern wird, und 15% glauben, dass die Mittel gekürzt werden. “

Für mich persönlich ist dies ein Signal dafür, dass das verbleibende Budget im neuen Jahr besser nicht für den Kauf eines neuartigen SZI wie Detektoren für maschinelles Lernen, eines anderen IDS der nächsten Generation usw. ausgegeben wird, sondern für die Feinabstimmung des bereits vorhandenen SZI. Und das beste SZI ist korrekt konfigurierte Windows-Protokolle. IMHO.