Get A Handle On Indicators Of Compromise

Es ist schon eine Weile her seit unserem letzten Blogbeitrag. Da wir mit Kundenprojekten und dem Wachstum unseres Unternehmens beschäftigt sind, kommt das Veröffentlichen unserer Research manchmal ein wenig zu knapp. Nichtsdestotrotz freue ich mich, diesen kurzen Blogbeitrag über ein Thema zu schreiben, das bei einem kürzlich erfolgten Einsatz aufkam. Dieser Blogbeitrag befasst sich mit der Frage, wie die Verwendung eines Tools zu Indicators Of Compromise (IoC) führen kann, indem Dateien auf die lokale Festplatte geschrieben werden, und wie ein Operator dies beim Testen des Tools in einem Lab feststellen kann.

In letzter Zeit hatten wir manchmal das Problem, dass SharpHound und SOAPHound nicht richtig ausgeführt wurden, wenn sie im Prozess unseres C2-Agenten liefen. Als Alternative wollten wir SharpView, die C#-Implementierung von PowerView, verwenden. Ich erinnerte mich jedoch daran, dass ich in diesem MDSec-Blogbeitrag über Active Directory Enumeration für Red Teams über einen IoC in SharpView gelesen hatte. Während die ausführbare Datei im Speicher ausgeführt werden kann, wird aufgrund der Verwendung einer bestimmten Bibliothek (PCRE.NET) ein Ordner im %TEMP%-Ordner des ausführenden Benutzers anlegt und eine DLL darin erstellt. Sicherheitsprodukte könnten dieses Ereignis entdecken und eine Warnung ausgeben, da die DLL immer denselben Namen hat. Siehe auch diesen Tweet für den IoC.

Ein Blick darauf, wie SharpView PCRE.NET nutzt, zeigt, dass es nur in zwei Methoden verwendet wird, um Regex-Matches zu finden. Diese Funktionalität kann auch durch die Verwendung der Regex.Match-Funktion von .NET erreicht werden, wodurch die Notwendigkeit einer externen Bibliothek entfällt. Eine aktualisierte Version von SharpView (einschliesslich einiger Pull-Requests aus dem ursprünglichen Repo sowie weiterer kleiner Korrekturen und Ergänzungen) ist auf meinem GitHub Fork zu finden.

Um zu prüfen, ob diese Änderungen die gewünschte Wirkung haben, habe ich zunächst den Ordner %TEMP% nach dem Ausführen der Version, die PCRE.NET verwendet, überprüft. Wie zu sehen ist, werden das Verzeichnis und die DLL erstellt.

Ich habe die Datei und den Ordner wieder entfernt und die neue SharpView-Datei ausgeführt, die die externe Bibliothek nicht mehr verwendet.

Und tatsächlich wurden in dem Ordner keine neuen Ordner oder Dateien erstellt.

Das ist alles schön und gut, aber was wäre, wenn es keinen Tweet oder Blogbeitrag gäbe, der uns vor diesem IoC warnt? Könnten wir sehen, dass ein Prozess etwas auf die Festplatte schreibt, auch wenn wir versuchen, nur im Speicher zu bleiben? Eine Möglichkeit, die mir in den Sinn kam, war die Verwendung von Process Hacker (jetzt System Informer), um zu sehen, welche Handles der Prozess geöffnet hat. Dies könnte uns einen Hinweis geben oder sogar direkt zeigen, dass eine Datei auf die Festplatte geschrieben wurde, einschliesslich ihres Pfads.

Ein Beispiel: Wenn man die PCRE.NET-Version von SharpView ausführt, werden die folgenden Handles angezeigt.

Der Pfad der DLL wird angezeigt, und es könnte durch Debugging sogar herausgefunden werden, welcher Befehl zur Erstellung dieser Datei geführt hat. Wird das Verzeichnis jetzt durchsucht, kann die DLL gesehen werden.

Mit den Änderungen in SharpView gibt es keinen solchen Handle mehr.

Dieses Beispiel funktioniert gut, wenn wir wissen, wonach wir suchen müssen und unseren Process Hacker zur Hand haben. Ich wollte die Möglichkeit haben, bestimmte Prozesse etwas programmatischer als mit Process Hacker und möglicherweise auch "in memory" zu überwachen, zum Beispiel wenn wir versuchen, einen Prozess auf einem kompromittierten Client statt in unserem Lab zu überwachen.

Daher habe ich HandleMonitor zusammengestellt. Der Code basiert fast vollständig auf der Funktionalität in einem Fork von MceController  (DetectOpenFiles.cs) und fragt regelmässig einen Prozess nach seinen offenen Handles ab. Das Tool protokolliert diese Handles, so dass sie, selbst wenn sie wieder geschlossen werden, in der Ausgabe des Tools sichtbar sind.

Das Tool ist bisher nur ein Proof of Concept, wenn also Fehler auftauchen, darf sehr gerne ein GitHub Issue oder sogar ein Pull Request eröffnet werden! Ich überlege auch, HandleMonitor in Zukunft als Task zu Covenant (we're so back...) hinzuzufügen, wenn es sich als hilfreich für uns erweist.

Danke fürs Lesen und wie immer können Fragen oder Anmerkungen an research@avantguard.io gesendet werden oder Kontakt mit mir via BloodHoundGang Slack (User @jannlemm0913) aufgenommen werden.