external_c2 framework

Python-Framework zum Erstellen und Verwenden von Schnittstellen zur Datenübertragung zwischen Frameworks, mit besonderem Fokus auf die Erweiterung von Command-and-Control-Frameworks.

Aktuell ist dies nur als Implementierung der External-C2-Spezifikation von Cobalt Strike gedacht, wie in diesem Spezifikationsdokument beschrieben, unterliegt aber Änderungen, wenn das Projekt reifer wird.

Credits

Ein großer Dank geht an xychix. Ohne die wertvollen Beiträge von xychix wäre dieses Projekt überhaupt nicht möglich gewesen. Im Grunde ist dieses Projekt ein Neuaufbau und eine Erweiterung von Outflank's External C2 project

Architektur

Dieses Projekt besteht aus den folgenden Hauptteilen:

• Builder
• Skeletons
• Frameworks
• Transports
• Encoders
• Manager (noch nicht implementiert)

Builder

Der Builder liest eine Konfigurationsdatei ein und verwendet die konfigurierten Optionen, um einen Build zu erzeugen, indem er markers innerhalb von skeletons ersetzt.

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:

#################
# Skeleton Code #
#################

# Skeleton contains the following line of code:
foo = ```[var:::bar]```

##############
# End Result #
##############

# Stored in config as:
#   foo = bar
# Written as:
foo = 'bar'

# Stored in config as:
#   foo = "bar"
# Written as:
foo = "bar"

# Stored in config as:
#   foo = 2
# Written as:
foo = 2

# Stored in config as:
#  foo = "2"
# Written as:
foo = "2"

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.