Was sind C2 Frameworks und wofür werden sie eingesetzt?

Zuerst einmal: Was bedeutet eigentlich „C2“? „C2“ steht für „Command and Control“ und beschreibt eine Software, die Angreifer nutzen können, um einen infizierten Rechner über das Internet fernzusteuern. Hierüber können weitere Angriffe geplant und durchgeführt werden. Fast in jedem größeren Cyber-Angriff kommt daher eine Schadsoftware mit C2-Funktion zum Einsatz. Da während eines Red-Teaming-Projekts realistische Angreifer simuliert werden sollen, nutzen dementsprechend auch professionelle Red-Teams solche C2-Frameworks.

Kommerziell oder Open Source?

Während Cobalt Strike lange der Platzhirsch unter den kommerziellen „Adversary Simulation“ Programmen war, kamen in den letzten Jahren einige kommerzielle Frameworks (Nighthawk, Brute Ratel C4), sowie einige OpenSource Frameworks (Mythic Agents, Sliver, Havoc, …) hinzu. Doch das Problem von öffentlich bekannten und quelloffenen Schadsoftware-Frameworks ist leider, dass diese oft bereits durch signaturbasierte Antivirus-Erkennung entdeckt werden. Das liegt erstens daran, dass die Hersteller von Antiviren-Software für quelloffene Programme sehr leicht Detektionen erstellen können, und zweitens, dass freie Software auch bei Kriminellen beliebt ist, was sie wiederum bei Antivirus-Herstellern umso bekannter macht. Zudem werden solche Projekte, wie auch andere Open-Source-Projekte, oft nicht durch professionelle Entwickler betreut, wodurch Verfügbarkeit und Stabilität nicht immer in einem solchen Maß gewährleistet sind, wie man es bei einem großen Red-Teaming-Projekt benötigt. Natürlich kann es auch bei kommerziellen Frameworks zu technischen Problemen und Bugs kommen, allerdings gibt es hier meistens entsprechenden professionellen Support durch die Entwickler. Aus diesen Gründen verwenden Red-Teams in der Regel kommerziell verfügbare Software.

„Selber machen!“

Wie aus dem oberen Abschnitt hervorgeht, gibt es viele Vorteile, die dafür sprechen, als Firma auf ein kommerzielles C2 Framework zurückzugreifen. Die NSIDE verwendet unter anderem die Tools Brute Ratel und Cobalt Strike.

Da eine eigene Malware jedoch auch offensichtliche Vorteile mit sich bringt, die in einem Red Teaming entscheidend sein können, hat sich die NSIDE für einen zweigleisigen Ansatz entschieden: Neben der Verwendung von Brute Ratel soll ein minimales C2 Framework mit sehr limitiertem Funktionsumfang entstehen. Der Fokus liegt dabei ganz klar darauf, nur eine geringe Anzahl an Features zu implementieren, dafür aber möglichst unerkannt zu bleiben.

Das Rad soll nicht neu erfunden werden – daher werden nicht die gleichen üblichen Features implementiert, die sowieso in allen gängigen Adversary Simulation Tools vorhanden sind, sondern lediglich die wichtigsten Befehle, um mit dem Betriebssystem zu interagieren. Dazu zählen unter anderem das Lesen und Schreiben von Dateien sowie das Enumerieren von Informationen, die für die Post-Exploitation-Phase relevant sind. Es dient in erster Linie dazu, genügend Informationen über das Zielsystem zu sammeln (sogenannte Situational Awareness), um den zweiten Teil des Angriffs gewissenhaft vorzubereiten, damit die Chance einer erfolgreichen Post-Exploitation-Phase steigt. Zur Ausführung der zweiten Phase werden unterschiedliche Methoden verwendet, wie beispielsweise DLL-Sideloads von auf dem System vorhandenen Programmen. NVOKE fungiert somit als erste Stage in einem Angriff. Die Kommunikation soll nach dem Prinzip „Slow and Steady“ stattfinden, wobei primär Funkstille herrscht, unterbrochen von einzelnen, kurzen Interaktionen.

Für die Kommunikation zum Teamserver selbst verwendet NVOKE dieselben Kanäle, die auch von unterschiedlichen sehr populären Anwendungen und Diensten genutzt werden. Diese Vorgehensweise ist nicht neu; es gibt einige Sicherheitsforscher und Red Teamer, die bereits etliche über das Internet erreichbare Services verwenden, um eigene Inhalte zu übertragen, zum Beispiel:

Bei diesem Vorgehen wird das Ziel verfolgt, im üblichen Netzwerkverkehr eines Unternehmens „mitzuschwimmen“ und keine detektierbaren Anomalien darzustellen. Eine erste Vorschau des NVOKE-Interfaces gibt der folgende Screenshot:

Operational Security – OPSEC

Auch bei der Verwendung eines Frameworks, das kaum verdächtige Aktivitäten ausführt, gibt es einige OPSEC-Themen zu beachten, um die Wahrscheinlichkeit eines „Auffliegens“ zu minimieren.

Beispielsweise sollten nicht die gleichen Kommunikationskanäle verwendet werden, die auch von kommerzieller Schadsoftware genutzt werden. Lädt man sonst eine solche Schadsoftware nach, läuft man Gefahr, beide Frameworks auf einen Schlag zu „verbrennen“, wenn eine der beiden Komponenten vom Blue Team erkannt wird. NVOKE soll nicht nur für den initialen Zugriff, sondern auch als dauerhafter Backup-Kanal fungieren, für den Fall, dass eine der C2-Verbindungen unterbrochen wird, sei es durch eine Erkennung oder durch einen Absturz. Deshalb ist es von großer Bedeutung, diese Komponente nicht preiszugeben.

Ebenfalls sollte man darauf achten, wie die zweite Phase, also das kommerzielle C2-Framework nachgeladen und ausgeführt wird. Sieht das Blue Team eine Verbindung (z.B. eine Parent-Child Beziehung) zwischen den Prozessen, läuft man ebenfalls Gefahr, beide Tools auf einen Schlag zu verbrennen.

Fazit

Eigenes Tooling ist essenziell für ein erfolgreiches Red Team, aber genauso auch die Stabilität und Verfügbarkeit eines kommerziellen C2-Frameworks. Das Red Team der NSIDE kombiniert beide Vorteile, indem zunächst ein eigenes „Stage 1 C2 Framework“, also eine leichtgewichtige und unverdächtige Schadsoftware genutzt wird, die sich möglichst dem Unternehmensnetzwerk anpasst. Für weitere Angriffe, nach der Situational Awareness Phase, wird BruteRatel C4 verwendet, das sämtliche Feature bietet, ohne die ein Red Team kaum erfolgreich sein kann: Ausführen von BOFs und .NET-Assemblies, Netzwerktunneling über SOCKS, Pivot Agents und Co.