aggrokatz

Was ist das?

aggrokatz ist eine Aggressor-Plugin-Erweiterung für CobaltStrike, die es pypykatz ermöglicht, aus der Ferne mit den Beacons zu interagieren.
Die aktuelle Version von aggrokatz ermöglicht es pypykatz, LSASS-Dump-Dateien und Registry-Hive-Dateien zu parsen, um Anmeldeinformationen und andere gespeicherte Geheimnisse zu extrahieren, ohne die Datei herunterzuladen und ohne verdächtigen Code auf den Beacon hochzuladen (Cobalt Strike ist sowieso bereits vorhanden). In Zukunft soll dieses Projekt zusätzliche Funktionen für verdeckte Operationen bieten, wie das Suchen und Entschlüsseln aller DPAPI-Geheimnisse/Kerberoasting usw.

Wir haben einen kurzen Blogbeitrag zu dieser Tool-Veröffentlichung veröffentlicht, der auch einige Screenshots enthält.

WICHTIGE HINWEISE - BITTE LESEN

Das Dumpen von LSASS/Registry ist nicht das Ziel dieses Projekts, sondern nur das Parsen. Gründe:

1. Mehrere Techniken zum Dumpen sind bereits in Cobalt Strike (CS) implementiert und der Öffentlichkeit weit zugänglich. Kürzlich sind wir auf eine modifizierte Version von CredBandit umgestiegen, die die Rohdaten anstelle von Base64 auf die Festplatte dumped. Cooles Tool, schaut es euch an.
2. Wir möchten unsere Dumping-Technik vertraulich halten.

Verwenden Sie im CS-Client nicht „reload“ und versuchen Sie nicht, das Skript manuell zu entladen und dann neu zu laden, wenn Sie es modifiziert haben. Sie MÜSSEN es entladen, den Client schließen und neu starten und dann das modifizierte Skript laden. Andernfalls laufen mehrere Versionen gleichzeitig und es treten zahlreiche Fehler und seltsame Verhaltensweisen auf!
Während des Parsens von LSASS/Registry-Dateien auf dem entfernten Ende interagieren Sie bitte nicht mit dem spezifischen Beacon, auf dem Sie das Skript gestartet haben. Normalerweise würde dies keine Probleme verursachen, aber ich kann keine Garantien geben.

Installation

• Sie benötigen pycobalt installiert und eingerichtet. Auf deren GitHub-Seite gibt es eine README.
• Sie müssen pypykatz installieren, die Version muss >=0.4.8 sein
• Sie benötigen Cobalt Strike

Einrichtung

• Stellen Sie sicher, dass die aggressor.cna-Datei von pycobalt eingerichtet ist und den Speicherort Ihres Python-Interpreters kennt.
• Ändern Sie den pycobalt_path in aggrokatz.cna, sodass er auf pycobalt.cna verweist.
• Verwenden Sie in CS die Fenster View > Script Console und Cobalt Strike > Script Manager. Laden Sie mit Script Manager das Skript aggkatz.cna.

Verwendung

• Wenn das aggkatz.cna-Skript erfolgreich geladen wurde, haben Sie ein neues Menüelement pypykatz, wenn Sie mit der rechten Maustaste auf einen Beacon klicken.
• Während des Parsens sehen Sie Debug-Meldungen im Fenster Script Console.
• Nach Abschluss des Parsens werden die Ergebnisse sowohl im Fenster Script Console als auch im eigenen Fenster des Beacons angezeigt.

Parameter des LSASS-Dump-Parse-Menüs

• LSASS file: Der Speicherort der lsass.dmp-Datei auf dem entfernten Computer. Sie können auch UNC-Pfade verwenden, um auf freigegebene lsass.dmp-Dateien über SMB zuzugreifen.
• chunksize: Die maximale Menge, die auf einmal gelesen wird
• BOF file: Die BOF-Datei (Beacon Object File), die chunked Reads ermöglicht. Diese Datei wird jedes Mal hochgeladen und (im Speicher) ausgeführt, wenn ein neuer Chunk gelesen wird.
• (module): Gibt an, welche Module geparst werden. Standard: all
• Output: Gibt das/die Ausgabeformat(e) an
• Populate Credential tab: Nach erfolgreichem Parsen werden alle erhaltenen Anmeldeinformationen auf dem Credential-Tab von Cobalt Strike verfügbar sein. Diese Funktion befindet sich in der Beta-Phase.
• Delete remote file after parsing: Nach erfolgreichem Parsen wird die LSASS-Dump-Datei vom Ziel entfernt.

Parameter des Registry-Dump-Parse-Menüs

• SYSTEM file: Der Speicherort der SYSTEM.reg-Datei auf dem entfernten Computer. Sie können auch UNC-Pfade verwenden, um auf freigegebene Dateien über SMB zuzugreifen.
• SAM file (optional): Der Speicherort der SAM.reg-Datei auf dem entfernten Computer. Sie können auch UNC-Pfade verwenden, um auf freigegebene Dateien über SMB zuzugreifen.
• SECURITY file (optional): Der Speicherort der SECURITY.reg-Datei auf dem entfernten Computer. Sie können auch UNC-Pfade verwenden, um auf freigegebene Dateien über SMB zuzugreifen.
• SOFTWARE file (optional): Der Speicherort der SOFTWARE.reg-Datei auf dem entfernten Computer. Sie können auch UNC-Pfade verwenden, um auf freigegebene Dateien über SMB zuzugreifen.
• chunksize: Die maximale Menge, die auf einmal gelesen wird
• BOF file: Die BOF-Datei (Beacon Object File), die chunked Reads ermöglicht. Diese Datei wird jedes Mal hochgeladen und (im Speicher) ausgeführt, wenn ein neuer Chunk gelesen wird.
• Output: Gibt das/die Ausgabeformat(e) an

Einschränkungen

Der Datei-Lese-BOF unterstützt derzeit Dateilesungen bis zu 4 GB. Dies kann mit einigen Modifikationen erweitert werden, aber bisher wurden solche großen Dateien nicht beobachtet.

So funktioniert es

Kurzfassung

Normalerweise führt der Parser von pypykatz eine Reihe von Leseoperationen auf der Festplatte durch, aber mit Hilfe von aggrokatz werden diese Leseoperationen über einen speziell angefertigten BOF (Beacon Object File) zum Beacon getunnelt, der das Lesen des entfernten Dateiinhalts in Blöcken ermöglicht. Dies erlaubt pypykatz, alle Geheimnisse aus den entfernten Dateien zu extrahieren, ohne die gesamte Datei zu lesen, sondern nur die notwendigen Blöcke zu erfassen, in denen sich die Geheimnisse befinden.

Im Detail

Um ein vollständiges Bild des gesamten Prozesses zu erhalten, müssen wir zwei Teile hervorheben:

1. wie pypykatz mit CobaltStrike integriert ist
2. wie pypykatz die Credential-Extraktion durchführt, ohne die gesamte Datei zu lesen

Integration von pypykatz in CobaltStrike

CobaltStrike (Agent) ist in Java geschrieben, pypykatz in Python. Das ist ein Problem. Zum Glück hat eine unbekannte Person pycobalt entwickelt, das eine elegante Schnittstelle zwischen den beiden Welten bietet, komplett mit nützlichen APIs, die direkt aus Python aufgerufen werden können. Obwohl pycobalt ein wunderbares Stück Technik ist, gibt es einige Probleme/Nachteile, auf die wir hinweisen müssen:

1. Vertrauen in das pycobalt-Projekt:

• Wir haben versucht, den Autor zu kontaktieren, aber wir haben keine Antwort erhalten.
• Wir können nicht garantieren, dass das pycobalt-Projekt in Zukunft weitergeführt wird.
• Wir haben keine Kontrolle über irgendeinen Aspekt der Entwicklung von pycobalt.

2. Beobachtete technische Probleme:

• Generell gibt es einige Kodierungsprobleme zwischen pycobalt und CobaltStrike. Dies führt dazu, dass einige API-Aufrufe Bytes zurückgeben, die nicht verwendet werden können, da einige Bytes durch den Encoder verstümmelt werden. Durch die Überprüfung des Codes schließen wir, dass die meisten Kodierungs-/Dekodierungsprobleme darauf zurückzuführen sind, dass pycobalt STDOUT/STDIN zur Kommunikation mit dem Java-Prozess verwendet.
• Insbesondere der bof_pack API-Aufruf, der für dieses Projekt entscheidend ist, musste als reines Aggressor-Skript implementiert werden und wurde nur aus Python mit grundlegenden Datenstrukturen (String und int) und nicht mit Bytes aufgerufen.
• Es werden nur blockierende APIs des pycobalt-Pakets ohne Threading-Unterstützung bereitgestellt. Nun, zumindest haben wir beobachtet, dass Threading zufällig kaputt geht, aber das haben wir irgendwie erwartet.
• Blockierende API + kein Threading + Abhängigkeit von Callbacks = wir mussten einige seltsame Hacks anwenden, um es zum Laufen zu bringen.

Credential-Parsing auf einem Stapel Karten

pypykatz und das dazugehörige Modul minidump mussten modifiziert werden, um ein effizienteres chunked Parsing zu ermöglichen, als zuvor implementiert, aber das ist ein Thema für einen anderen Tag.
Nachdem pypykatz in der Lage war, über pycobalt mit CobaltStrike zu interagieren, bestand der nächste Schritt darin, chunked Dateilesen zu ermöglichen. Leider ist diese Funktion bei keiner der uns bekannten C2-Lösungen standardmäßig verfügbar, also mussten wir sie implementieren. Unser Ansatz bestand darin, das chunked Lesen mithilfe der Beacon Object Files-Schnittstelle von CobaltStrike zu implementieren, kurz BOF. BOFs sind C-Programme, die auf dem Beacon laufen, nicht als separates ausführbares Programm, sondern als Teil des bereits laufenden Beacons. Diese Schnittstelle ist super nützlich, da sie BOFs viel heimlicher macht, da der gesamte Code im Speicher ausgeführt wird, ohne dass etwas auf die Festplatte geschrieben wird.
Unsere BOF-Lösung ist eine einfache Funktion und benötigt 4 Argumente:

• fileName: Vollständiger Dateipfad der LSASS-Dump-Datei oder der Registry-Hive (auf dem entfernten Ende)
• buffsize: Menge (in Bytes), die aus der Datei gelesen werden soll
• seekSize: Die Position, an der der Lesevorgang beginnen soll (vom Anfang der Datei)
• rplyid: Eine Identifikationsnummer, die in die Antwort eingebaut wird, um mögliche Kollisionen zu vermeiden

Mit diesen Parametern kann pypykatz (auf dem Agenten laufend) Leseoperationen auf dem Beacon (Zielcomputer) ausgeben, die gezielt bestimmte Teile der Datei ansprechen.
Auf der anderen Seite (in CobaltStrike) registriert aggrokatz einen Callback, um jede vom Zielbeacon zurückgegebene Nachricht zu überwachen. Wenn der Header der Nachricht mit dem Header einer Datei-Leseoperation übereinstimmt, wird sie als ein Chunk einer minidump-Datei verarbeitet und an den minidump-Parser weitergeleitet, der das Ergebnis an pypykatz weitergibt. Falls mehr Lesebedarf besteht, gibt pypykatz eine Leseanforderung über den minidump-Reader aus, der einen neuen Lesebefehl auf dem Beacon über die BOF-Schnittstelle absetzt. Dieser Vorgang wiederholt sich, bis die Datei geparst ist.

Ergebnisse

Nach dem Parsen von etwa 100 LSASS-Dumps mit dieser Methode können wir Folgendes feststellen (verwendete Chunk-Größe war 20k):

• Abhängig von der Größe der LSASS-Dump-Datei (unsere Dumps lagen zwischen 40 MB und 300 MB) konnten im Durchschnitt alle Geheimnisse mit 3,5 MB extrahiert werden. Beachten Sie, dass diese Zahl nicht von der Größe des LSASS-Dumps abhängt, sondern von der Anzahl der Geheimnisse und der Anzahl der Pakete, die Sie zum Parsen auswählen.
• Im Durchschnitt wurden 250 Leseoperationen für einen erfolgreichen Parse-Durchlauf verwendet.
• Die Parse-Zeit hängt ausschließlich von Ihrer Jitter/Sleep-Konfiguration ab, daher ist eine Messung sinnlos.

Nachteile

• Für jede Leseoperation muss ein BOF auf den Beacon hochgeladen werden. (Wir hoffen insgeheim, dass jemand von CobaltStrike diesen Artikel liest und beschließt, grundlegende Dateilesefunktionen als Standard zu implementieren, damit wir diese Lösung überspringen können.)
• Die Anzahl der Leseoperationen kann problematisch sein, wenn Sie einen Beacon mit einem sehr hohen Jitter/Sleep verwenden.

Danksagungen

dcsync - Autor von pycobalt
@anthemtotheego Twitter - Schöpfer von CredBandit
Nicol Jos @shinepaw - Logo-Design