Threat Hunting oder TH ist eine proaktive Suche nach Spuren von Hacking oder der Funktionsweise von Malware, die nicht mit Standardschutzmitteln erkannt werden. Heute werden wir darüber sprechen, wie dieser Prozess funktioniert, welche Tools zur Suche nach Bedrohungen verwendet werden können und was beim Erstellen und Testen von Hypothesen zu beachten ist.
Was ist Bedrohungsjagd und warum wird sie benötigt?
Bei der Bedrohungssuche wartet der Analyst nicht, bis die Sensoren der Schutzsysteme ausgelöst werden, sondern sucht gezielt nach Spuren von Kompromissen. Zu diesem Zweck werden Annahmen darüber entwickelt und überprüft, wie Angreifer in das Netzwerk eingedrungen sein könnten. Solche Kontrollen sollten konsistent und regelmäßig sein.
Bei der korrekten Durchführung des Prozesses sollten die folgenden Grundsätze berücksichtigt werden:
- Es ist davon auszugehen, dass das System bereits kompromittiert wurde. Das Hauptziel ist es, Spuren der Penetration zu finden.
- Für die Suche benötigen Sie eine Hypothese darüber, wie genau das System kompromittiert wurde.
- Die Suche sollte iterativ durchgeführt werden, dh nach dem Testen der nächsten Hypothese schlägt der Analyst eine neue vor und setzt die Suche fort.
Traditionelle automatisierte Abwehrmechanismen verpassen häufig ausgefeilte gezielte Angriffe . Der Grund dafür ist, dass solche Angriffe häufig über die Zeit verteilt sind, sodass Sicherheitstools die beiden Phasen eines Angriffs nicht miteinander korrelieren können. Gleichzeitig denken Angreifer sorgfältig über die Penetrationsvektoren nach und entwickeln Szenarien für Aktionen in der Infrastruktur. Dies ermöglicht es ihnen, keine Demaskierungsaktionen durchzuführen und ihre Aktivität als legitim auszugeben. Angreifer verbessern ständig ihr Wissen, kaufen oder entwickeln neue Tools.
Die Probleme bei der Identifizierung gezielter Angriffe sind besonders relevant für Organisationen, die zuvor gehackt wurden. Laut dem BerichtFireEye M-Trends, 64% der zuvor kompromittierten Organisationen wurden erneut angegriffen. Es stellt sich heraus, dass mehr als die Hälfte der gehackten Unternehmen immer noch gefährdet sind. Dies bedeutet, dass Maßnahmen zur Früherkennung von Kompromissfakten ergriffen werden müssen - dies kann mit Hilfe von TH erreicht werden.
Mithilfe der Bedrohungssuche können Informationssicherheitsspezialisten die Zeit für die Erkennung eines Verstoßes verkürzen und das Wissen über die geschützte Infrastruktur aktualisieren. TH ist auch nützlich, wenn Threat Intelligence (TI) verwendet wird - insbesondere, wenn bei der Erstellung einer Hypothese TI-Indikatoren verwendet werden.
Wie man Hypothesen zum Testen bildet
Da bei der Durchführung von TH a priori davon ausgegangen wird, dass der Angreifer bereits in die Infrastruktur eingedrungen ist, muss zunächst der Ort der Suche nach Spuren von Hacking lokalisiert werden. Sie kann ermittelt werden, indem eine Hypothese aufgestellt wird, wie die Penetration stattgefunden hat und welche Bestätigung dies in der Infrastruktur findet. Nachdem der Analytiker eine Hypothese formuliert hat, überprüft er die Wahrheit seiner Annahme. Wenn die Hypothese nicht bestätigt wird, entwickelt und testet der Experte eine neue. Wenn beim Testen der Hypothese Spuren von Hacking gefunden werden oder das Vorhandensein von Malware festgestellt wird, beginnt eine Untersuchung.
Abbildung 2. Schema der Bedrohungssuche
Die Idee einer Hypothese kann aus der persönlichen Erfahrung des Analytikers hervorgehen, es gibt jedoch andere Quellen für ihre Konstruktion, zum Beispiel:
- threat intelligence (TI-). , : X, MD5- Y.
- , (TTPs). TTPs MITRE ATT&CK. : .
- . . , asset management . .
- , .
threat hunting
Nach der Formulierung der Hypothese müssen die Datenquellen identifiziert werden, die Informationen zum Testen enthalten können. Oft enthalten solche Quellen zu viele Daten, unter denen Sie relevante finden müssen. Der TH-Prozess läuft daher darauf hinaus, eine große Menge von Daten darüber zu recherchieren, zu filtern und zu analysieren, was in der Infrastruktur geschieht. Betrachten Sie die Quellen, in denen Informationen gefunden werden können, um die Suchhypothese zu testen:
Abbildung 3. Klassifizierung von Informationsquellen für die Durchführung von TH
Die größte Menge relevanter Informationen ist in Protokollen und im Netzwerkverkehr enthalten. Produkte der Klassen SIEM (Sicherheitsinformationen und Ereignisverwaltung) und NTA (Netzwerkverkehrsanalyse) helfen bei der Analyse von Informationen aus diesen Klassen. Externe Quellen (wie TI-Feeds) sollten ebenfalls in den Analyseprozess einbezogen werden.
Wie es in der Praxis funktioniert
Das Hauptziel von TH besteht darin, einen Verstoß zu erkennen, der von automatisierten Sicherheitstools nicht erkannt wurde.
Betrachten Sie beispielsweise das Testen von zwei Hypothesen. In der Praxis werden wir zeigen, wie sich Verkehrsanalyse- und Protokollanalysesysteme beim Testen von Hypothesen ergänzen.
Hypothese Nr. 1: Ein Angreifer ist über eine Workstation in das Netzwerk eingetreten und versucht, mithilfe der Ausführung von WMI-Befehlen die Kontrolle über andere Knoten im Netzwerk zu erlangen.
Die Angreifer haben die Anmeldeinformationen eines Root-Benutzers erhalten. Dann versuchen sie, die Kontrolle über andere Knoten im Netzwerk zu erlangen, um mit wertvollen Daten zum Host zu gelangen. Eine der Methoden zum Starten von Programmen auf einem Remote-System ist die Verwendung der WMI- Technologie ( Windows Management Instrumentation ). Sie ist verantwortlich für die zentrale Verwaltung und Überwachung der verschiedenen Teile der Computerinfrastruktur. Die Entwickler sahen jedoch die Möglichkeit voraus, diesen Ansatz auf die Komponenten und Ressourcen nicht nur eines einzelnen Hosts, sondern auch eines Remotecomputers anzuwenden. Hierzu wurde die Übertragung von Befehlen und Antworten über das DCERPC-Protokoll implementiert.
Um die Hypothese zu testen, müssen Sie daher die DCERPC-Abfragen untersuchen. Lassen Sie uns zeigen, wie dies mithilfe der Verkehrsanalyse und eines SIEM-Systems erreicht werden kann. In Abb. 4 zeigt alle gefilterten DCERPC-Netzwerkinteraktionen. Zum Beispiel haben wir das Zeitintervall von 06:58 bis 12:58 gewählt. Abbildung 4. Gefilterte DCERPC-Sitzungen . 4 Wir sehen zwei Dashboards. Auf der linken Seite befinden sich die Knoten, die DCERPC-Verbindungen initiiert haben. Auf der rechten Seite befinden sich die Knoten, mit denen Clients verbunden sind. Wie Sie der Abbildung entnehmen können, greifen alle Clients im Netzwerk nur auf den Domänencontroller zu. Dies ist eine legitime Aktivität, da Hosts, die in einer Active Directory-Domäne vereint sind, das DCERPC-Protokoll verwenden, um einen Domänencontroller zur Synchronisierung zu kontaktieren. Im Falle einer solchen Kommunikation zwischen Benutzerhosts wird dies als verdächtig angesehen.
Da für den ausgewählten Zeitraum entlang der Zeitachse nichts Verdächtiges festgestellt wurde, wählen wir die nächsten 4 Stunden aus. Jetzt ist es ein Intervall von 12:59 bis 16:46. Darin haben wir eine merkwürdige Änderung in der Liste der Zielhosts festgestellt (siehe Abb. 5). Abbildung 5. Nach dem Ändern des Zeitintervalls wurden zwei neue Knoten in der Serverliste angezeigt. In der Liste der Zielhosts gibt es zwei neue Knoten. Betrachten Sie die ohne DNS-Namen (10.125.4.16). Abbildung 6. Verfeinerung des Filters, um herauszufinden, wer mit 10.125.4.16 verbunden ist Wie Sie in Abbildung sehen können. In 6 greift der Domänencontroller 10.125.2.36 darauf zu (siehe Abbildung 4), was bedeutet, dass diese Interaktion legitim ist.
Als Nächstes müssen Sie analysieren, wer mit dem zweiten neuen Knoten verbunden ist (siehe Abb. 1). 5 ist win-admin-01.ptlab.ru (10.125.3.10). Aus dem Namen des Knotens folgt, dass dies der Computer des Administrators ist. Nachdem der Filter verfeinert wurde, bleiben nur zwei Sitzungsquellknoten übrig. Abbildung 7. Verfeinern Sie den Filter, um herauszufinden, wer mit win-admin-01 verbunden ist. Ähnlich wie im vorherigen Fall war einer der Initiatoren ein Domänencontroller. Diese Sitzungen sind nicht verdächtig, da sie in einer Active Directory-Umgebung häufig vorkommen. Der zweite Knoten (w-user-01.ptlab.ru) ist jedoch, gemessen am Namen, der Computer des Benutzers - solche Verbindungen sind Anomalien. Wenn Sie mit diesem Filter zur Registerkarte Sitzungen wechseln, können Sie den Datenverkehr herunterladen und die Details in Wireshark anzeigen. Abbildung 8. Relevante Sitzungen herunterladen
Im Datenverkehr sehen Sie einen Aufruf der IWbemServices-Schnittstelle, der die Verwendung einer WMI-Verbindung anzeigt. Abbildung 9. Aufrufen der IWbemServices (Wireshark) -Schnittstelle Darüber hinaus werden die übertragenen Anrufe verschlüsselt, sodass die spezifischen Befehle unbekannt sind. Abbildung 10. Der DCERPC-Verkehr ist verschlüsselt, sodass der übertragene Befehl nicht sichtbar ist (Wireshark). Um die Hypothese zu bestätigen, dass eine solche Kommunikation unzulässig ist, müssen Sie die Hostprotokolle überprüfen. Sie können zum Host gehen und die Systemprotokolle lokal anzeigen, es ist jedoch bequemer, ein SIEM-System zu verwenden. In der SIEM-Schnittstelle haben wir eine Bedingung in den Filter eingeführt, bei der zum Zeitpunkt des Herstellens einer DCERPC-Verbindung nur die Protokolle des Zielknotens übrig blieben, und das folgende Bild angezeigt:
Abbildung 11. Systemprotokolle win-admin-01 zum Zeitpunkt des Aufbaus einer DCERPC-Verbindung
In den Protokollen wurde eine genaue Übereinstimmung mit der Startzeit der ersten Sitzung festgestellt (siehe Abbildung 9). Der Initiator der Verbindung ist Host w-user-01. Eine weitere Analyse der Protokolle zeigt, dass sie sich unter dem Konto PTLAB \ Admin verbunden haben und den Befehl (siehe Abb. 12) ausgeführt haben, um den Benutzer John mit dem Kennwort Passwort zu erstellen !!!: Netzbenutzer John Passwort !!! / hinzufügen. Abbildung 12. Befehl während der Verbindung ausgeführt
Wir haben herausgefunden, dass ab Knoten 10.125.3.10 jemand, der WMI im Namen des PTLAB \ Admin-Kontos verwendet, dem Host win-admin-01.ptlab.ru einen neuen Benutzer hinzugefügt hat. Wenn Sie eine echte TH durchführen, müssen Sie im nächsten Schritt herausfinden, ob es sich um eine administrative Aktivität handelt. Dazu müssen Sie den Eigentümer des PTLAB \ Admin-Kontos kontaktieren und herausfinden, ob er die beschriebenen Aktionen ausgeführt hat. Da das betrachtete Beispiel synthetisch ist, gehen wir davon aus, dass diese Aktivität unzulässig ist. Wenn Sie eine echte TN durchführen und die Tatsache der illegalen Nutzung des Kontos aufdecken, müssen Sie einen Vorfall erstellen und eine detaillierte Untersuchung durchführen.
Hypothese Nr. 2: Ein Angreifer ist in das Netzwerk eingedrungen und befindet sich im Stadium der Datenexfiltration, wobei Daten mithilfe von Verkehrstunneln ausgegeben werden.
Tunnelverkehr - Organisieren eines Kanals so, dass Pakete eines Netzwerkprotokolls (möglicherweise in modifizierter Form) innerhalb der Felder eines anderen Netzwerkprotokolls übertragen werden. Ein häufiges Beispiel für das Tunneln ist das Erstellen verschlüsselter Pipes wie SSH. Verschlüsselte Kanäle gewährleisten die Vertraulichkeit übertragener Informationen und sind in modernen Unternehmensnetzwerken üblich. Es gibt jedoch exotische Optionen wie ICMP- oder DNS-Tunnel. Solche Tunnel werden von Cyberkriminellen benutzt, um ihre Aktivitäten als legitim zu tarnen.
Beginnen wir damit, den gebräuchlichsten Weg zu finden, um den Verkehr über das SSH-Protokoll zu tunneln. Dazu filtern wir alle Sitzungen mithilfe des SSH-Protokolls: Abbildung 13. Suchen nach DNS-Sitzungen im Datenverkehr
In der Abbildung sehen Sie, dass in der Infrastruktur kein SSH-Verkehr vorhanden ist. Sie müssen daher das folgende Protokoll auswählen, das für das Tunneln verwendet werden kann. Da DNS-Verkehr in Unternehmensnetzwerken immer zulässig ist, werden wir ihn im Folgenden berücksichtigen.
Wenn Sie den Datenverkehr nach DNS filtern, können Sie feststellen, dass einer der Knoten eine ungewöhnlich große Anzahl von DNS-Abfragen aufweist.
Abbildung 14. Widget mit Statistiken zu DNS-Clientsitzungen
Nach dem Filtern von Sitzungen nach Anforderungsquelle haben wir erfahren, wohin diese anomale Verkehrsmenge gesendet wird und wie sie zwischen den Zielknoten verteilt wird. In Abb. Abbildung 15 zeigt, dass ein Teil des Datenverkehrs an den Domänencontroller geht, der als lokaler DNS-Server fungiert. Ein großer Teil der Anfragen geht jedoch an einen unbekannten Host. In einem auf Active Directory basierenden Unternehmensnetzwerk sollten Benutzercomputer für die DNS-Namensauflösung keinen externen DNS-Server verwenden, um den Unternehmensnetzwerk zu umgehen. Wenn eine solche Aktivität erkannt wird, müssen Sie herausfinden, was im Datenverkehr übertragen wird und wohin all diese Anforderungen gesendet werden. Abbildung 15. Durchsuchen des Datenverkehrs nach SSH-Sitzungen
Wenn Sie zur Registerkarte "Sitzungen" wechseln, können Sie sehen, was in Anfragen an den verdächtigen Server übertragen wird. Die Zeit zwischen den Anfragen ist ziemlich kurz und es gibt viele Sitzungen. Solche Parameter sind für legitimen DNS-Verkehr ungewöhnlich.
Abbildung 16. DNS-Verkehrsparameter
Nachdem Sie eine Sitzungskarte geöffnet haben, wird eine detaillierte Beschreibung der Anforderungen und Antworten angezeigt. Die Antworten vom Server enthalten keine Fehler, aber die angeforderten Einträge sehen sehr verdächtig aus, da die Knoten normalerweise kürzere und aussagekräftigere DNS-Namen haben. Abbildung 17. Anforderung eines verdächtigen DNS-Eintrags Die Verkehrsanalyse ergab, dass auf dem Host win-admin-01 verdächtige Aktivitäten beim Senden von DNS-Anforderungen stattfinden. Es ist Zeit, die Protokolle des Netzwerkknotens zu analysieren - der Quelle dieser Aktivität. Gehen Sie dazu zu SIEM.
Wir müssen die Systemprotokolle win-admin-01 finden und sehen, was um 17:06 Uhr passiert ist. Sie können sehen, dass gleichzeitig ein verdächtiges PowerShell-Skript ausgeführt wurde. Abbildung 18. PowerShell-Ausführung gleichzeitig mit dem Senden verdächtiger Anforderungen In den Protokollen wird aufgezeichnet, welches Skript ausgeführt wurde. Abbildung 19. Festlegen des Namens des ausgeführten Skripts in den Protokollen Der Name des ausgeführten Skripts admin_script.ps1 weist auf die Legitimität hin, aber Administratoren geben den Skripten normalerweise den Namen für eine bestimmte Funktion, und hier ist der Name allgemein. Darüber hinaus befindet sich das Skript im Ordner für temporäre Dateien. Es ist unwahrscheinlich, dass ein wichtiges Verwaltungsskript in einem Ordner landet, der jederzeit geleert werden kann.
Unter den entdeckten Ereignissen befand sich die Erstellung einer ungewöhnlichen kryptografischen Klasse aus der Logos.Utility-Bibliothek. Diese Bibliothek ist selten und wird vom Entwickler nicht mehr unterstützt. Daher ist das Erstellen ihrer Klassen ungewöhnlich. Versuchen wir, Projekte zu finden, die es verwenden. Abbildung 20. Erstellen einer benutzerdefinierten kryptografischen Klasse Wenn Sie die Suche verwenden, können Sie ein Dienstprogramm finden, das einen DNS-Tunnel organisiert und diese Klasse über den zweiten Link verwendet. Abbildung 21. Suchen nach Informationen zu einem Skript anhand des Klassennamens Um sicherzustellen, dass dies das Dienstprogramm ist, das wir benötigen, suchen wir in den Protokollen nach zusätzlichen Zeichen. So kamen die Beweise ans Licht. Das erste besteht darin, das Dienstprogramm nslookup mithilfe eines Skripts auszuführen. Abbildung 22. Ausführen des Dienstprogramms nslookup über das Skript
Das Dienstprogramm nslookup.exr wird während der Netzwerkdiagnose verwendet und nur selten von normalen Benutzern ausgeführt. Start ist in den Quellcodes des Dienstprogramms sichtbar. Abbildung 23. Code zum Starten des Dienstprogramms nslookup (GitHub) Der zweite Beweis ist eine ziemlich eindeutige Zeichenfolge zum Generieren von Zufallswerten. Abbildung 24. Generieren von Zufallswerten durch das Skript Wenn Sie die Suche in den Quellcodes verwenden, können Sie genau diese Zeile sehen. Abbildung 25. Code zum Generieren eines Zufallswerts Die Tunnelhypothese wurde bestätigt, aber das Wesentliche der durchgeführten Aktionen blieb unklar. Bei der anschließenden Analyse der Protokolle haben wir zwei Prozessstarts festgestellt. Abbildung 26. Suchen Sie nach Office-Dokumenten für die weitere Exfiltration
Die Startzeilen der gefundenen Prozesse zeigen die Suche nach Dokumenten zum Herunterladen an. Damit wurde die Hypothese vollständig bestätigt, die Angreifer nutzten das Verkehrstunneln wirklich, um Daten herunterzuladen.
Schlussfolgerungen
Da die neuesten Forschungsberichte , die durchschnittliche Zeit , dass Angreifer in der Infrastruktur bleiben bleibt lang. Warten Sie daher nicht auf Signale von automatisierten Abwehrmechanismen - handeln Sie proaktiv. Untersuchen Sie Ihre Infrastruktur und moderne Angriffsmethoden und verwenden Sie Untersuchungen von TI-Teams ( FireEye , Cisco , PT Expert Security Center ).
Ich fordere nicht die Aufgabe des automatisierten Schutzes. Man sollte jedoch nicht davon ausgehen, dass die Installation und korrekte Konfiguration eines solchen Systems der letzte Punkt ist. Dies ist nur der erste notwendige Schritt. Als nächstes müssen Sie die Entwicklung und Funktionsweise der kontrollierten Netzwerkumgebung überwachen und stets am Puls der Zeit bleiben.
Die folgenden Tipps helfen Ihnen dabei:
- . . , .
- . , .
- . , . . , TH , .
- Automatisieren Sie Routineaufgaben, damit Sie mehr Zeit haben, kreativ zu werden und kreative Lösungen auszuprobieren.
- Vereinfachen Sie die Analyse großer Datenmengen. Zu diesem Zweck ist es hilfreich, Tools zu verwenden, mit denen der Analyst die Vorgänge im Netzwerk und auf den Netzwerkknoten als ein einziges Bild sehen kann. Diese Tools umfassen eine Plattform zum Austausch von TI-Indikatoren , ein Verkehrsanalysesystem und ein SIEM-System .
Gepostet von Anton Kutepov, PT Expert Security Center bei Positive Technologies.
Die gesamte Analyse wurde im Verkehrsanalysesystem PT Network Attack Discovery und im Sicherheitsereignismanagementsystem MaxPatrol SIEM durchgeführt.