Der Builder kann mit build_files.py verwendet werden. Eine Beispiel-Builder-Konfiguration wird als sample_builder_config.config.sample bereitgestellt.

Skeletons

skeletons sind die verschiedenen „Skelette“ aus Code, die der builder dynamisch befüllt, um einen vollständig nutzbaren Build zu erzeugen. skeletons enthalten markers, die vom builder durch nutzbare Werte ersetzt werden. Es gibt drei verschiedene „Typen“ von Skeletten:

Skeleton-Marker

Ein Marker kann in jeder Datei eines skeleton platziert werden und wird durch einen in der Builder-Konfiguration angegebenen Wert ersetzt. In der Praxis sollten Marker niemals verwendet werden, um Variablen direkt zu schreiben, sondern nur, um Werte zu setzen. Wenn der Wert eines Markers wiederverwendet werden muss, sollte man den Wert in einer Variablen speichern und auf diese Weise darauf referenzieren, anstatt denselben Marker erneut zu verwenden.

Das Format eines Markers lautet: ```[var:::identifier_for_the_marker]```

Strings werden direkt in ein Skeleton geschrieben, umgeben von einfachen Anführungszeichen, und Zahlen werden unverändert geschrieben.

Falls ein String in der Konfiguration in doppelte Anführungszeichen gesetzt ist, wird der String stattdessen direkt in doppelte Anführungszeichen geschrieben, und die umgebenden einfachen Anführungszeichen werden entfernt.

Dieser Zusammenhang lässt sich wie folgt veranschaulichen:

Frameworks

Frameworks sind die Basis-Anwendung, die bestimmt, welche Daten vom transport und encoder verwendet werden und wie diese Daten verwendet werden. Was ein bestimmtes framework tatsächlich tut, spielt keine große Rolle, solange eine Logik existiert, um den encoder und den transport zu importieren und zu verwenden. Die meisten wesentlichen Teile eines Frameworks (hauptsächlich die client-Logik) werden als ein skeleton gespeichert, wobei eine Schnittstelle zur Interaktion mit dem Server-Teil als Basis-framework-Objekt gespeichert wird.

Im Allgemeinen enthält ein Framework einen server und einen client und nutzt encoders und transports, um Daten zwischen ihnen weiterzuleiten.

Es gibt einige Grundprinzipien, die beim Erstellen eines framework zu beachten sind:

• Das framework ist dafür verantwortlich, dass der encoder dem transport zur Verwendung zur Verfügung gestellt wird.
• Wenn das framework eine Client-Server-Beziehung verwendet, sollte es entsprechend organisiert sein.
• Man sollte verstehen, dass der Endnutzer in den meisten Fällen niemals direkt mit dem client eines Frameworks interagiert. Wenn du also Dinge auf dem client neu konfigurierbar haben möchtest, muss dieser in der Lage sein, dies zur Laufzeit ohne direkte Interaktion zu tun.
• Es sollte kaum nötig sein, ein server-skeleton zu erstellen, da der Endnutzer direkt mit dem server eines Frameworks interagieren wird. Stattdessen sollte man sowohl Optionen aus einer Konfiguration einlesen als auch dem Endnutzer die Möglichkeit geben, Optionen (wie einen Block-Timer oder die Ausführlichkeit) zur Laufzeit zu ändern.
• Ein framework-skeleton wird vom Builder verarbeitet, der jede Datei darin durchläuft. Wenn also ein bestimmtes Argument zur Build-Zeit konfigurierbar sein muss, kann das leicht umgesetzt werden.
• Ein framework-server sollte über einen gemeinsamen framework_manager angesprochen werden können.

Framework-Server

Der Server ist die Anwendung, die die Kommunikation zwischen dem client und dem c2 server vermittelt. Die Serverlogik ist in erster Linie statisch. Die Logik für den Server des cobalt_strike-Frameworks, die in der Spezifikation als third-party Client Controller bezeichnet wird, ist unten dargestellt:

1. Die Konfiguration analysieren
2. Das angegebene Kodierungsmodul importieren
3. Das angegebene Transportmodul importieren
4. Eine Verbindung zum C2-Server herstellen
5. Einen Stager vom C2-Server anfordern
6. Den Stager mit dem encoder-Modul kodieren
7. Den Stager mit dem transport-Modul übertragen
8. Auf eine Metadaten-Antwort vom Client warten, die über den transport empfangen wird
9. Die Metadaten mit dem encoder-Modul dekodieren
10. Die Metadaten an den C2-Server weiterleiten
11. Eine neue Aufgabe vom C2-Server empfangen
12. Die neue Aufgabe kodieren
13. Die neue Aufgabe über den transport an den Client weiterleiten
14. Auf eine Antwort vom Client warten, die über den transport empfangen wird
15. Die Antwort über das encoder-Modul dekodieren
16. Die Antwort an den C2-Server weiterleiten
17. Schritte 11-16 wiederholen

Ein server sollte die Fähigkeit unterstützen, mehrere Clients zu verwalten (noch nicht implementiert), und über einen framework_manager angesprochen werden können.

Framework-Client

Der Client ist im Wesentlichen die Payload, die auf dem Endpunkt läuft. Die Logik des Clients für das cobalt_strike-Framework ist in erster Linie statisch und unten dargestellt:

1. Alle Vorbereitungen ausführen, die für die Nutzung des transport erforderlich sind
2. Den Stager empfangen
3. Den Stager injizieren und den Handle zum Beacon öffnen
4. Metadaten vom Beacon erhalten
5. Die Metadaten über den transport vom Beacon zum C2-Server weiterleiten
6. Den transport auf neue Aufgaben beobachten
7. Neue Aufgaben an den Beacon weiterleiten
8. Antworten vom Beacon über den transport weiterleiten
9. Schritte 6-8 wiederholen

Der Client verwendet den angegebenen encoder und transport, um Daten zwischen sich und dem jeweiligen server weiterzuleiten.

Encoders

Encoder empfangen Daten und verändern diese dann entweder, um sie für die Übertragung über den Transport vorzubereiten, oder dekodieren über den Transport empfangene Daten zurück in ihre Rohform, damit sie von der jeweiligen framework-Komponente interpretiert werden können, die sie verwendet.

Encoder sollten direkt vom Transport angesprochen werden und Daten auf eine Weise verarbeiten, die unabhängig von Framework und Komponente ist.

Transports

Transports übernehmen das Senden und Empfangen von Daten über einen Kommunikationskanal und arbeiten mit dem Encoder zusammen, um sicherzustellen, dass Daten in das jeweils erforderliche Format umgewandelt werden. Transports sollten Daten von einer Framework-Komponente oder über den Kommunikationskanal empfangen und in der Lage sein, Daten über den Kommunikationskanal weiterzuleiten. Transports sind dafür verantwortlich, den encoder aufzurufen, um Daten bei Bedarf zu kodieren oder zu dekodieren.

Transports sollten direkt von der framework-Komponente angesprochen werden und Daten auf eine Weise verarbeiten, die unabhängig von Framework und Komponente ist.

So verwendest du dieses Projekt

1. Bestimme zuerst, welches Transport- und welches Kodierungsmodul du verwenden möchtest. Wir verwenden für das folgende Beispiel transport_imgur und encoder_lsbjpg.

2. Erstelle als Nächstes eine builder_config.config, die deinen Anforderungen entspricht. Siehe die bereitgestellte Beispiel-Konfiguration und Vorlage für Hinweise, wie das geht.

3. Erzeuge einen Build mit build_files.py. Als Beispiel könnte man mit dem folgenden Befehl einen Build im Verzeichnis builds für Cobalt Strike mit encoder_lsbjpg und transport_imgur ausführlich erzeugen:

4. Starte als Nächstes den gebauten Server und verteile deinen Client.

Cobalt Strike

Führe auf dem Rechner, auf dem der Server läuft, Folgendes aus:

python server.py

Für eine ausführlichere Ausgabe kannst du Folgendes ausführen:

python server.py -v

Für eine noch ausführlichere Ausgabe sowie zusätzliche, für die Fehlersuche nützliche Ausgaben kannst du Folgendes ausführen:

python server.py -d

Führe anschließend den Client auf dem Ziel-Endpunkt aus.

Wenn alles funktioniert hat, wird ein neues Beacon in der Cobalt-Strike-Konsole registriert, mit dem du interagieren kannst.

FAQ

Warum hast du das geschrieben?: Es gab nur sehr wenige veröffentlichte Implementierungen der Cobalt-Strike-Spezifikation, und von den veröffentlichten waren entweder keine in einer Sprache, die ich beherrsche, oder sie boten nicht die Modularität und Abstraktion, die ich gesucht habe.

Warum Python 2?: Ich bin faul, und es ist einfach, darin neue Transport- und Kodierungskanäle zu implementieren.

Dein Code ist schlecht: Das ist keine Frage.

Kann ich neue Transport- und/oder Encoder-Module einreichen?: Ja, bitte! Reiche einen Pull-Request ein, und ich schaue ihn mir gerne an.

Wie kompiliere ich den Client in eine ausführbare Datei, die ich verteilen kann?: Ich habe das erfolgreich in Kali getestet. Um meine Umgebung nachzubilden, stelle einfach sicher, dass veil-evasion installiert ist und du dessen Setup durchlaufen hast. Es sollte eine Wine-Umgebung mit installiertem Python eingerichtet haben, die alle benötigten Abhängigkeiten enthält. Möglicherweise musst du das Modul pefile zusätzlich in dieser Umgebung installieren.

Dann kannst du in das Verzeichnis des Clients gehen, für den du eine ausführbare Datei erzeugen möchtest, und Folgendes ausführen:

Ersetze den Wert für key durch das, was du möchtest. Du solltest die ausführbare Client-Datei im Verzeichnis dist/ sehen. Wenn du eine ausführbare Datei erzeugen möchtest, die eine Konsole für das Debugging bereitstellt, kompiliere die ausführbare Datei mit wine "C:\\Python27\\python.exe" /usr/share/veil/pyinstaller/pyinstaller.py -F -r c2file.dll -c client.py