Tools sind ein wesentlicher Bestandteil moderner Cyberangriffe und daher auch in Red Teaming Projekten. Die Open-Source-Community ist dabei Fluch und Segen zugleich – sie entwickelt und teilt frei Tools, die viele mühsame manuelle Schritte automatisieren. Diese Tools werden sowohl von Verteidigern als auch Angreifern eingesetzt. Viele dieser Tools entsprechen heutzutage einem De-facto-Standard für bestimmte Arten von Angriffen, beispielsweise Tools wie SharpHound. Natürlich kennen Verteidiger diese Tools ebenfalls und stufen sie dementsprechend als verdächtig ein. Daher werden sie von modernen AV/EDR-Lösungen in der Regel blockiert. Um sie dennoch verwenden zu können, kommen Obfuscation- und Evasion-Techniken ins Spiel. Dieser Artikel zeigt, wie wir diesen Obfuscation- und Evasion-Prozess automatisiert haben.

Einführung

Dieses Kapitel gibt eine Einführung in die Malware Obfuscation und erläutert, warum sie in heutigen Red Team Projekten relevant und notwendig ist. Zusätzlich wird erklärt, was Obfuscation und Evasion sind, wie dies auf einem hohen Level funktioniert und was uns dazu veranlasst hat, den Obfuscation-Prozess zu automatisieren. Im Verlauf dieses Artikels wird der Begriff Malware allgemein verwendet und schliesst offensive Security-Tools und Frameworks ein, die häufig in Red Team Projekten eingesetzt werden.

Warum Obfuscation (und Evasion) in Red Team Projekten wichtig ist

Wie oben erwähnt, ist der Einsatz von bekannten Tools notwendig, um manuelle Arbeit zu automatisieren und damit die Kosten für Kunden minimal zu halten und dennoch eine dedizierte Lösung für jeden Kunden zu haben. Die individuelle Entwicklung von Tools für jedes Projekt ist weder praktisch noch kosteneffizient, kann aber auf Wunsch oder unter besonderen Umständen Sinn ergeben. Entsprechend ist die Wiederverwendung von bekannten Open-Source-Tools unerlässlich. Da der Quellcode der meisten dieser Tools öffentlich verfügbar ist, können Verteidiger sie leicht erkennen und dementsprechend reagieren. Die Reaktionen können von der Blockierung bis zur Isolierung der Bedrohung reichen. Die Erkennung selbst hat sich erheblich weiterentwickelt – angefangen bei Anti Virus (AV) Systemen bis hin zu modernen Endpoint Detection and Response (EDR) Lösungen, welche Systeme durch den Einsatz verschiedener Erkennungstechniken schützen. Um diese bekannten Tools dennoch einsetzen zu können, muss das Konzept der Evasion angewendet werden. Wir haben hierzu bereits einen Artikel über die Umgehung von AV Systemen veröffentlicht. Dieser ist zwar keine Voraussetzung für diesen Artikel, dient jedoch als wertvolle Ergänzung.

Was ist Evasion und Obfuscation und wie wird es angewendet

Evasion kombiniert verschiedene Techniken, um einer Erkennung von Malware durch Sicherheitslösungen zu entgehen. Diese Techniken umfassen beispielsweise Sandbox-Evasion, das Deaktivieren verschiedener Erkennungsfunktionen, aber auch Obfuscation (Verschleierung zu Deutsch). Obfuscation beschreibt Techniken, die Attribute von Malware so verändern, dass sie von einem AV/EDR-System nicht mehr erkannt wird. Diese Attributveränderungen können dazu führen, dass die Malware ihre Signaturen verändert, ihr Verhalten anpasst oder sogar ihren eigenen Code dynamisch modifiziert. Die gewählte Obfuscation-Technik hängt in der Regel von der im Zielsystem eingesetzten Sicherheitslösung und deren Erkennungsmethoden ab. Beispiele für solche Verschleierungen könnten das Verschlüsseln von Teilen des Codes mit anschliessender Entschlüsselung zur Laufzeit, das Verändern des Kontrollflusses der Malware oder das Hashen von Funktionsnamen und deren Auflösung zur Laufzeit mittels einer Lookup-Tabelle sein. Da diese Techniken wertvoller sind, wenn sie nicht bekannt sind, neigt die Community dazu, nicht alles zu teilen. Dennoch gibt es grossartige Bücher, Artikel und Fachbeiträge zu EDR-Evasion. Die folgenden werden empfohlen, ohne hier weiter in die Tiefe zu gehen:

• MITRE ATT&CK Technik T1027
• Evasive Malware (Buch Kyle Cucci, 2024)
• Evading EDR (Buch Matt Hand, 2024)
• MalDevAcademy (Online-Plattform)

Hürden der manuellen Obfuscation

Manuelle Obfuscation umfasst viele iterative Schritte. Um Malware ordnungsgemäss zu verschleiern und sicherzustellen, dass sie einer Erkennung entgeht, sind vor allem bei weit verbreiteten und bekannten Open-Source-Tools wie SharpHound oder Seatbelt selbst bereits verschleierte Varianten häufig noch erkennbar. Dies liegt daran, dass Verteidiger nicht nur die originalen Tools, sondern auch deren gängige verschleierte Varianten mit Signaturen versehen. Nach einer Erkennung muss die nächste Obfuscation-Methode ausprobiert werden. Dies ist frustrierend und zeitaufwändig, besonders bei Kundenprojekten mit begrenzten Zeitbudgets. Daher haben wir uns zum Ziel gesetzt, diesen Prozess durch eine Malware Obfuscation CI/CD-Pipeline zu automatisieren. Das wird im folgenden Kapitel genauer erläutert.

Umsetzung

Um eine nützliche Pipeline zu erstellen, wurden Anforderungen definiert. Das stellt sicher, dass die Pipeline, insbesondere in ihrer Anfangsphase, die relevantesten Anwendungsfälle abdeckt. Die folgenden Anforderungen wurden festgelegt.

• Die Pipeline muss die Obfuscation von mindestens C#/.NET und PowerShell-Skripten unterstützen
• Die Pipeline soll einem modularen Ansatz folgen, um einfache Modifikationen und Erweiterungen um andere Programmtypen, Obfuscation- und Evasion-Methoden sowie zusätzliche Obfuscation-Skripte, Tools und Erkennungslösungen nachrüsten zu können
• Verschleierte Malware muss gegen AV/EDR-Lösungen validiert werden
• Verschleierte Malware, die die AV/EDR-Validierung besteht, wird automatisch in das interne Repository für den Einsatz übertragen
• Obfuscation muss auf Arbeitskopien durchgeführt werden, die Originaldateien dürfen nicht verändert werden
• Falls möglich, sollen Tests durchgeführt werden, um festzustellen, ob die Obfuscation die Malware beschädigt hat
• Die Pipeline muss sämtliche Aktivitäten protokollieren, um eine Rekonstruktion der durchgeführten Aktionen pro Pipeline-Durchlauf zu ermöglichen
• Nutzung, Einrichtung und Fehlerbehebung der Pipeline müssen dokumentiert werden

Vorgehen

Basierend auf den festgelegten Anforderungen wurde zunächst ein minimales Konzept der Pipeline erarbeitet. Wie bereits erwähnt, wurde entschieden, eine Continuous Integration und Continuous Delivery/Deployment (CI/CD) Pipeline zu verwenden. Dabei handelt es sich um eine Software-Entwicklungspraxis, die verschiedene Phasen wie Build, Test und Release des Entwicklungszyklus automatisiert. Diese Pipelines entstammen der DevOps-Bewegung. Eine ausführliche Erklärung zu CI/CD-Pipelines ist bei GeeksForGeeks zu finden.

Basierend auf den Anforderungen und dem Konzept wurden die Architektur und die Tools für diese Pipeline ausgewählt, sowie bestimmte Konfigurationsentscheidungen getroffen. Anschliessend wurde ein Pipeline-Ablauf erarbeitet. Die folgenden Unterkapitel erläutern die Ergebnisse dieser Schritte auf einem hohen Level.

Konzept

Um die Iterationen der Malware-Obfuscation in eine Pipeline zu überführen, muss der Prozess in einzelne reproduzierbare Schritte zerlegt werden. Jeder dieser Schritte benötigt einen klar definierten Input und Output. Zudem sollte sich jeder Schritt auf eine spezifische Aufgabe konzentrieren. Dies ermöglicht Modularität, da ein einzelner Schritt einfacher angepasst werden kann als ein gesamtes Programm. Die übergeordneten erforderlichen Schritte sind:

1. Repository auf eine Obfuscation-Maschine übertragen
2. Malware in ein Arbeitsverzeichnis kopieren
3. Malware-Kopien verschleiern
4. Verschleierte Malware validieren
   1. Falls erkannt, Obfuscation wiederholen
   2. Falls nicht erkannt, verschleierte Malware in das interne Repository übertragen

Pipeline-Architektur, Tools und Konfiguration

Zunächst mussten die einzusetzenden Tools ausgewählt werden. Wie bereits erläutert, war CI/CD der bevorzugte Ansatz, mit Gitea als Plattform der Wahl. Gitea ist eine Open-Source-Alternative zu GitHub, die CI/CD-Funktionalität über den Gitea Act Runner integriert. Der Act Runner muss auf einem Zielsystem installiert werden, um die Software bereitzustellen und mit ihr zu interagieren. Windows wurde als Betriebssystem des Zielsystems gewählt, da der Grossteil der in Red Team Projekten eingesetzten Malware auf Windows-Systeme abzielt. Um die Malware zu kompilieren und zu transformieren, kann der Act Runner entweder Docker-Container bereitstellen oder direkt auf dem Hostsystem ausgeführt werden. Die direkte Ausführung auf dem Host wurde gewählt, da die Unterstützung von Windows Docker-Containern in unserem Setup unzuverlässig war. Der Act Runner musste auf dem Windows-System installiert und bei der Gitea-Instanz registriert werden.

Weitere Tools umfassen Malware-Obfuscation-Tools wie CodeCepticon oder yetAnotherObfuscator sowie Erkennungslösungen wie DefenderCheck, Yara oder THOR Lite. Diese müssen auf dem Windows-System installiert und entsprechend konfiguriert werden. Da DefenderCheck und andere Tools auf Windows Defender angewiesen sind, bleibt dieser aktiviert. Jedoch sollten Ausnahmen für das Malware-Repository und die Transformationsordner erstellt werden. Zusätzlich muss die Funktion Automatic Sample Submission von Microsoft Defender deaktiviert werden, da sonst das Risiko besteht, dass die neu verschleierte Malware unmittelbar von Microsoft identifiziert werden kann.

Pipeline Ablauf Übersicht

Der folgende übergeordnete Pipeline-Ablauf wurde etabliert:

Der Prozess beginnt mit der Gitea Actions Pipeline auf der Gitea-Weboberfläche. Alle Schritte der Pipeline sind in der Datei .gitea/workflows/runner.yaml dokumentiert. Diese YAML-Datei enthält jeden Schritt, wo die Schritte ausgeführt werden sollen, sowie die für das Pullen und Pushen benötigten Secrets. Die verwendete Datei wird in diesem Artikel nicht geteilt. Für diese Implementierung wurde das manuelle Auslösen der Pipeline gegenüber einer automatischen Planung bevorzugt. Beim manuellen Start können einige optionale Parameter eingegeben werden. Solche Parameter umfassen die zu wählende Build-Architektur oder ob alle Malware-Dateien verschleiert werden sollen.

Zunächst wird das aktuelle Repository mit der Malware gepullt. Anschliessend werden einige Verfügbarkeitsprüfungen durchgeführt, um sicherzustellen, dass alle benötigten Programme wie Compiler, Erkennungslösungen und Obfuscation-Tools vorhanden sind. Dann startet die erste Schleife. Diese erste Schleife ist ein dedizierter Schritt, der prüft, ob jede Malware-Datei erfolgreich kompiliert und ob sie bereits von den Erkennungslösungen erkannt wird. Falls eine Kompilierung erforderlich ist und fehlschlägt, sind wahrscheinlich Fehler in der Malware vorhanden, die vor der Obfuscation behoben werden sollten. Falls die Malware nicht erkannt wird, besteht technisch gesehen keine Notwendigkeit zur Obfuscation. Dies kann durch den der Pipeline übergebenen Parameter geändert werden. Der gesamte Prozess wird für alle verfügbaren Malware-Dateien wiederholt. Alle Malware-Dateien, die einer Obfuscation bedürfen, werden in ein Obfuscation-Verzeichnis kopiert. Anschliessend wird die Eignung der Malware für die Obfuscation geprüft. Bei einigen Malware-Dateien sind bekannte Fehler im Zusammenhang mit Obfuscation vorhanden. Diese Fälle sollten erkannt und die betroffene Malware aus der Warteschlange entfernt werden.

Als nächstes startet eine weitere Schleife, die Obfuscation und Validierung versucht. Beide im selben Schritt auszuführen vermeidet den Overhead der Kommunikation zwischen einzelnen Schritten. Falls beim Start der Pipeline keine spezifischen Parameter gesetzt wurden, beginnt die Schleife mit der ersten Malware-Datei im Obfuscation-Verzeichnis. Diese wird mit der ersten Technik verschleiert und direkt gegen die Erkennungslösung getestet. Die verwendete Technik wird durch den Zähler j repräsentiert. Die Obfuscation-Runde wird durch den Zähler i repräsentiert. Da eine Obfuscation-Technik nicht immer dieselbe Ausgabe produziert, kann es sinnvoll sein, dieselbe Technik auf einer frischen Kopie der Datei zu wiederholen. Dieser Ansatz wurde von Pavel Tsakalidis in seinem Vortrag über CodeCepticon vorgeschlagen. Dieselbe Obfuscation-Technik wird bis zu fünfmal wiederholt. Anschliessend wird eine andere Technik angewendet, j wird erhöht und i auf eins zurückgesetzt. Falls fünf Techniken fehlschlagen, markiert die Pipeline die Malware als fehlgeschlagen und fährt fort. Falls die Obfuscation erfolgreich war, kopiert die Pipeline die verschleierte Malware zusammen mit unterstützenden Dateien, wie einer Mapping-Datei für Funktionsnamen, in den Gitea-Repository-Ordner. Sobald alle Malware-Dateien verarbeitet wurden, wird das Gitea-Repository gepusht und Bereinigungsaufgaben werden ausgeführt, um das System auf den nächsten Durchlauf vorzubereiten.

Limitierungen

Es ist wichtig zu beachten, dass diese Pipeline ihre Limitierungen und Schwächen hat. Es gibt zwei wesentliche Schwachstellen einer solchen Pipeline; fehlerhafter Code und Erkennung nach der Obfuscation.

Das grössere Problem besteht darin, dass der Malware-Code nach der Obfuscation beschädigt sein kann und daher nicht mehr verwendet werden kann. Zusätzlich ist es nicht möglich zu verifizieren, dass jede verschleierte Malware wie beabsichtigt funktioniert, da bestimmte Malware spezifische Voraussetzungen wie beispielsweise eine Active Directory-Umgebung benötigt. Darüber hinaus wären Testfälle für jede Malware-Datei sehr spezifisch und müssten mit jeder Aktualisierung der Malware angepasst werden.

Das kleinere Problem ist die Erkennung der Malware auch nach der Obfuscation. Dies kann sehr häufig vorkommen und ist auch der Grund, warum eine Validierung in den Pipeline-Ablauf integriert wurde. Selbst nach erfolgreicher Umgehung der Erkennung während der Validierung kann eine verschleierte Malware aus verschiedenen Gründen erkannt werden, beispielsweise durch ein EDR-System mit mehr Kontext oder durch eine manuelle Untersuchung und die Hinzufügung neuer Signaturen. Dies ist einfach zu beheben, da die Pipeline einfach erneut ausgeführt werden kann, um eine neue verschleierte Variante zu erzeugen.

Ein alternativer Ansatz , basierend auf Azure DevOps, wurde von Chester Adams dokumentiert.

Fazit

Die Pipeline ist etabliert und hat den manuellen Aufwand für unsere Tester erheblich reduziert, erfordert von Zeit zu Zeit noch manuelle Überprüfungen, Anpassungen und Fehlerbehebungen, insbesondere bei komplexer oder sehr gezielter Malware. Mit der Zeit und Erfahrung wird sich dies weiter verbessern. Es ist geplant, die Pipeline mit weiteren Obfuscation-Techniken und Tools, granulareren Obfuscation-Optionen für spezifische Payloads, einer Sandbox-Integration sowie weiteren Erkennungslösungen, Code-Signing, mehrschichtiger Obfuscation und der Unterstützung weiterer Betriebssysteme und Architekturen zu erweitern.

Dank der Durchführung von Red- und Purple Team Projekten konnte die Resilienz, gegen gezielte und ausgeklügelte Cyberangriffe, unserer Kunden nachweislich erhöht werden. Zu Teilen auch Dank der Etablierung der in diesem Artikel umschriebenen Obfuscation Pipeline.

Ein Hauptziel eines offensiven Sicherheitsengagements, wie zum Beispiel einer Red Team Übung, besteht darin, Angriffe zu simulieren, um die Abwehrmechanismen einer Organisation zu testen und zu verbessern. Bei solchen Einsätzen werden häufig Command and Control (C2) Systeme verwendet, um Code auf kompromittierten Endpunkten aus der Ferne auszuführen. Dafür ist eine gut gestaltete und abgesicherte C2-Infrastruktur erforderlich, um die Umgebung des Kunden nicht zu gefährden. Eine falsch konfigurierte C2-Architektur oder unzureichend geschützte C2-Komponenten auf den Client-Endpunkten können selbst zu Angriffszielen für reale Angreifer werden.

Dieser Artikel untersucht die Schlüsselkomponenten einer Command and Control (C2) -Implementierung, hebt potenzielle Erkennungsvektoren hervor und skizziert Strategien zum Aufbau einer sicheren und unauffälligen C2-Infrastruktur.

Was ist ein Command and Control (C2) System?

Command and Control (C2) ist ein wesentlicher Bestandteil offensiver Sicherheitstests, insbesondere bei Red Team Übungen, bei denen die Taktiken von Bedrohungsakteuren simuliert werden. Ziel ist es, die Abwehrmechanismen einer Organisation zu überprüfen und die Kontrolle über kompromittierte Geräte, Netzwerke oder Systeme aufrechtzuerhalten. Penetrationstester und Red Teams verwenden häufig kommerzielle C2-Frameworks wie Cobalt Strike, während Angreifer in der realen Welt auf geleakte kommerzielle C2-Versionen, massgeschneiderte Lösungen oder Open-Source-Alternativen wie Sliver zurückgreifen. Zusätzlich zu dedizierten C2-Tools verwenden Angreifer auch legitime IT-Verwaltungssoftware wie AnyDesk oder TeamViewer für verdeckte Command-and-Control-Operationen.

C2-Systeme bestehen in der Regel aus einem zentralen Server, der mit kompromittierten Systemen über verschiedene Protokolle kommuniziert, oft mit Verschlüsselung. Diese Systeme ermöglichen es C2-Betreibern, Befehle zu erteilen und Daten oder Rückmeldungen von infizierten Endpunkten zu empfangen, und dienen so effektiv als Fernsteuerung für böswillige Aktivitäten. Dies ermöglicht es Angreifern:

• Code aus der Ferne auf kompromittierten Endpunkten ausführen
• Daten exfiltrieren
• Persistenz aufrechterhalten, um die Kontrolle über das System zu behalten
• Malware oder Ransomware auf infizierten Endpunkten einsetzen
• Aktionen auf dem Endpunkt ausführen, z. B. Webcams und Mikrofone aktivieren, Tastenanschläge protokollieren oder Screenshots erstellen

C2 Frameworks

Es gibt verschiedene C2-Frameworks, die jeweils unterschiedliche Möglichkeiten für Command and Control bei offensiven Sicherheitsoperationen bieten. Einen umfassenden Überblick über die vorhandenen C2-Frameworks und ihre Funktionen ist auf der Website The C2 Matrix zu finden. Diese Ressource bietet Einblicke in verschiedene C2-Lösungen und beschreibt deren Funktionen, unterstützte Protokolle und Umgehungstechniken. Für Unterhaltung sorgt neben nützlichen Informationen auch die Videos Official OffSec C2 Tier List und Atomics on a Friday || Purple March Madness || C2 Winner.

Zu den fortschrittlichsten kommerziellen C2-Frameworks gehören heute Nighthawk C2 und BruteRatel. Diese Frameworks zeichnen sich durch ihre modernen Umgehungstechniken aus, die darauf ausgelegt sind, Endpoint Detection & Response (EDR), Antivirus (AV) und andere Sicherheitslösungen effektiver zu umgehen als herkömmliche C2-Systeme wie Cobalt Strike.
Nighthawk C2 bietet eine benutzerfreundliche Plattform, die die Bediener in den ersten Entwicklungsphasen von Payloads unterstützt und gleichzeitig Verschleierungs- und Umgehungsstrategien integriert. Dadurch ist es für Bediener zugänglich und reduziert gleichzeitig die Komplexität der Einrichtung. Dies hat einen Preis von 10.000 US-Dollar pro Benutzer und Jahr, wobei mindestens drei Benutzerlizenzen erforderlich sind (Stand: März 2025).
Im Gegensatz dazu bietet Brute Ratel eine umfangreiche Palette an Anpassungsoptionen, erfordert jedoch ein tiefes Verständnis der Loader-Entwicklung. Im Gegensatz zum Nighthawk C2-Framework, bei dem die Loader-Erstellung stärker automatisiert ist, erwartet Brute Ratel, dass der Bediener den Loader manuell erstellt, was eine grössere Flexibilität auf Kosten einer steileren Lernkurve bietet. Einmal konfiguriert, ist es jedoch aufgrund seiner Fähigkeit, modernen Sicherheitslösungen zu umgehen, eines der leistungsstärksten C2-Frameworks auf dem Markt. Der Preis für eine Lizenz beträgt 3000 US-Dollar (Stand: März 2025).
Beide Frameworks entwickeln sich laufend weiter, da die Sicherheitsmassnahmen immer ausgefeilter werden. Beide Frameworks bieten Red Teams fortschrittliche Funktionen und reduzieren gleichzeitig den Bedarf an interner Entwicklung und Forschung, sodass sich die Betreiber mehr auf die Ausführung konzentrieren können, anstatt Umgehungstechniken von Grund auf neu zu entwickeln.

Neben kommerziellen C2-Frameworks gibt es mehrere leistungsstarke Open-Source-Alternativen, wie z. B. Sliver, Mythic, Merlin, Havoc und Empire. Diese Frameworks bieten robuste Command-and-Control-Funktionen, die häufig moderne Umgehungstechniken und Anpassungsflexibilität beinhalten. Open-Source-C2-Lösungen werden aufgrund ihrer Zugänglichkeit und der kontinuierlichen, von der Community vorangetriebenen Verbesserungen häufig von Red Teams, Penetrationstestern und Angreifern eingesetzt. Sie erfordern zwar im Vergleich zu kommerziellen Lösungen möglicherweise mehr Konfiguration und Anpassung, bieten aber eine gute Grundlage für offensive Sicherheitseinsätze ohne die Kosten und Lizenzbeschränkungen kommerzieller Tools.

Die letzte Option ist die Entwicklung eines benutzerdefinierten C2. Dieses kann mehr Tarnung und Flexibilität bieten als kommerzielle oder Open-Source-Alternativen. Dieser Ansatz erfordert jedoch Zeit sowie Fachwissen in der Entwicklung sicherer Codes, Netzwerk- und Umgehungstechniken. Ein benutzerdefiniertes C2 ist zwar ressourcenintensiv, gibt den Red Teams aber die volle Kontrolle über die Kommunikationsmethoden und kann die Umgehungsfähigkeit von Sicherheitsmassnahmen verbessern.

Ob eine kommerzielle, Open-Source- oder massgeschneiderte C2-Lösung gewählt wird, der Erfolg hängt letztlich vom C2-Betreiber ab. Selbst die ausgefeiltesten Umgehungstechniken in kommerziellen C2-Frameworks sind wirkungslos, wenn der Betreiber nicht über das nötige OPSEC Wissen verfügt, um eine Entdeckung zu vermeiden.

C2 Evaluierung

Bei der Auswahl eines C2 kann es hilfreich sein, dessen Fähigkeiten, Kompatibilität und Sicherheitsmerkmale zu bewerten, um sicherzustellen, dass es den betrieblichen Anforderungen entspricht. Eine Bewertungstabelle ermöglicht einen objektiven Vergleich und erleichtert die Identifizierung von Stärken, Schwächen und Eignung. Nachfolgend ein Beispiel einer Bewertungstabelle für einen C2, basierend auf den Hauptmerkmalen:

Zur Bewertung eines C2 kann das folgende Bewertungssystem angewendet werden:

Jedes Merkmal wird anhand seiner Wichtigkeit bewertet. Kritische fehlende Anforderungen erhalten eine negative Bewertung, während zusätzliche, aber nicht wesentliche Merkmale dennoch positiv zur Bewertung beitragen. Durch die Anwendung dieses Systems können die Red Teams verschiedene C2-Systeme objektiv vergleichen und so sicherstellen, dass sie eines auswählen, das ihren Bedürfnissen am besten entspricht.

Nach der Bewertung von C2-Systemen sind Tests in einer kontrollierten Umgebung unerlässlich. Das ausgewählte Framework sollte die betrieblichen Anforderungen erfüllen und gleichzeitig Sicherheit und Integrität gewährleisten. Der Netzwerkverkehr sollte auf ungewöhnliche Aktivitäten analysiert werden, um potenzielle Hintertüren oder nicht autorisierte Kommunikationen zu identifizieren. Wo möglich, kann eine Codeüberprüfung für Open-Source-Frameworks dabei helfen, Sicherheitsrisiken oder versteckte Funktionen aufzudecken. Die Überprüfung von Datenverkehr und Code reduziert das Risiko, bevor das Framework in einer Produktionsumgebung eingesetzt wird.

C2 Architektur

Die folgende Abbildung zeigt ein Beispiel für eine C2-Architektur.

C2 Komponenten

Wie in der Architektur dargestellt, besteht eine C2-Infrastruktur aus mehreren miteinander verbundenen Komponenten, die es Angreifern oder Red Teams ermöglichen, den Fernzugriff auf kompromittierte Systeme aufrechtzuerhalten. Eine ordnungsgemäss konfigurierte Einrichtung gewährleistet eine zuverlässige Befehlsausführung, die Betriebssicherheit und senkt das Risiko Entdeckt zu werden. Die Architektur umfasst in der Regel Loader, Redirectoren, Firewalls, Proxys, den C2-Server sowie unterstützende interne und externe C2-Dienste.

Loader

Ein Loader dient als die initiale Ausführungskomponente, die dafür verantwortlich ist, von einer C2-Infrastruktur generierten Shellcode, typischerweise einen Beacon, auf dem Zielsystem auszuführen. Sein primäres Ziel ist es, den Shellcode auszuführen und dabei die Erkennung durch Sicherheitslösungen wie Endpoint Detection and Response (EDR) sowie Antivirensoftware (AV) zu umgehen. Loader können unterschiedliche Formen annehmen, etwa eine eigens erstellte PE-Datei, eine legitime PE-Datei mit injiziertem Code, ein Installer, ein Skript oder ein Office-Dokument mit eingebetteten Makros. Ein hervorragender Vortrag zu möglichen Loader-Formaten unter Windows, präsentiert von Emeric Nasi, ist hier verfügbar: Breach the Gates.

Um signaturbasierte Erkennung zu umgehen, wird der Shellcode üblicherweise verschlüsselt und entweder direkt im Loader eingebettet, aus dem Internet heruntergeladen oder aus einer anderen abgelegten Datei geladen, oft getarnt als Bilddatei oder ein anderes legitim wirkendes Format. Bei der Ausführung wird er im Speicher entschlüsselt und stellt anschliessend eine Verbindung zum C2-Server her. Ein weiterer Ansatz besteht darin, den Prozess in Stufen zu unterteilen: Zunächst wird ein einfacher Stage-1-Loader ausgeführt, der mit minimaler Logik und grundlegenden Evasion-Techniken unauffälligen Erstzugriff ermöglicht. Seine Hauptaufgabe besteht darin, einen leistungsfähigeren Stage-2-Loader zu laden und zu entschlüsseln, der dann Aufgaben übernimmt wie das Entschlüsseln der Kernlogik des Beacons, das Injizieren von Shellcode in den Speicher, das Umgehen von EDR-Mechanismen und das Herstellen der Verbindung zum C2-Server.

Die initiale Ausführung stellt eine kritische Phase in der Angriffskette dar, da sie einen zentralen Fokus moderner EDR-Lösungen bildet. Auch wenn ein Beacon selbst im Ruhezustand verbleibt oder verschleiert ist, werden die Ausführungsmuster des Loaders häufig durch statische, heuristische und verhaltensbasierte Analysen erkannt. Besonders selbst entwickelte Binärdateien ziehen Aufmerksamkeit auf sich, da sie einzigartige Signaturen und Build-Metadaten enthalten. Compiler betten beispielsweise Zeitstempel in ausführbare Dateien ein, wenn diese zu aktuell erscheinen, kann ein EDR die Datei als neuartig oder verdächtig einstufen. Dadurch kann ein Loader aufgrund des Verhaltens der Datei oder des Prozesses sowie deren Neuartigkeit oder Auffälligkeit bereits früh erkannt werden.

Zusätzlich zu Event-Tracing, dynamischer, statischer und zeitlicher Analyse untersuchen EDRs auch Prozessnutzungsmuster und validieren API-Call-Flows. EDRs erwarten, dass die Ausführung legitimen Aufrufketten durch vertrauenswürdige Module wie kernel32.dll und ntdll.dll folgt. Techniken wie direkte oder indirekte System Calls, Inline Hooks oder unbacked Call Stacks lösen häufig Warnungen aus, insbesondere wenn die Ausführung vom Standardverhalten der Windows-API abweicht. Darüber hinaus überwachen EDRs neu erstellte ausführbare Dateien besonders genau, insbesondere solche, die:

• Innerhalb weniger Minuten nach dem Schreiben auf die Festplatte ausgeführt werden
• Aus benutzerzugänglichen Verzeichnissen wie dem Desktop gestartet werden
• Unmittelbar nach dem Start ausgehende Netzwerkverbindungen initiieren

Solche Verhaltensmuster gelten als verdächtig. Daher werden schlecht konstruierte Loader in der Regel frühzeitig erkannt.

In den letzten Jahren sind mehrere kommerzielle Lösungen entstanden, die darauf abzielen, Loader zu generieren, die bestimmten Erkennungsmethoden entgehen. Bekannte Beispiele sind Balliskit, msecops und Shellter. Auch wenn diese Tools in manchen Fällen wirksam sind, erhöhen wiedererkennbare Muster oft das Risiko einer Erkennung. Ein massgeschneiderter Loader, der speziell auf das Zielsystem abgestimmt ist und unauffällig im Kontext legitimer Aktivitäten agiert, erzielt in der Regel die besten Ergebnisse.

Die folgende Abbildung zeigt ein abstrahiertes Beispiel der Schritte, die ein Loader zur Ausführung von Shellcode durchlaufen kann:

Ablaufschritte:

• Execution Guardrails: Das schädliche Programm wird nur ausgeführt, wenn bestimmte Bedingungen erfüllt sind, etwa die erwartete Umgebung oder ein bestimmter Kunde während eines Red-Team-Einsatzes.
• Entschlüsselung & Laden: Der Loader entschlüsselt den eingebetteten oder extern geladenen Shellcode im Speicher, sodass keine Spuren auf der Festplatte entstehen
• Ausführung: Der entschlüsselte Shellcode wird im Speicher ausgeführt, ohne Spuren auf dem Dateisystem zu hinterlassen
• Evasion-Techniken: Der Loader kann Techniken wie Prozessinjektion, API-Unhooking oder Shellcode-Stomping einsetzen
• Beacon Deployment: Bei Staged-Setups lädt das Shellcode den Beacon als zweite Stufe nach. Bei Stageless-Setups ist der Beacon direkt eingebettet und wird sofort ausgeführt
• Evasion-Techniken: Nach der Ausführung kann der Beacon weitere Tarntechniken einsetzen, z.B. indirekte Syscalls, Stack-Spoofing oder Stomping
• C2-Kommunikation: Der ausgeführte Beacon stellt die Verbindung zum C2-Server her und ermöglicht Remote-Kontrolle

Redirector

Ein Redirector (auch als Relay oder Bridge bekannt) dient als Relaispunkt zwischen dem kompromittierten Ziel und dem eigentlichen C2-Server und verhindert so, dass die tatsächliche IP-Adresse des C2-Servers direkt offengelegt wird. Dadurch wird eine zusätzliche Ebene der Betriebssicherheit hinzugefügt, indem die Infrastruktur des Angreifers vor der Erkennung geschützt wird.

Umgeleiteter Verkehr kann beispielsweise über folgende Routen geleitet werden:

• Kompromittierte Hosts: Zuvor gehackte Maschinen, die als Relais fungieren
• Cloud-Dienste und CDNs: Plattformen wie Azure, Cloudflare, AWS und Fastly helfen dabei, C2-Verkehr mit legitimer Cloud-Kommunikation zu verschmelzen
• Verdeckte Umleitungen: Die Umleitung kann beispielsweise auch durch die Nutzung von Microsoft Teams, Slack oder Cloud-APIs wie Microsoft Graph implementiert werden, um C2-Verkehr innerhalb des legitimen Anwendungsverkehrs zu tunneln, wodurch der C2-Traffic viel schwerer zu erkennen ist.

Über einfaches Weiterleiten von Datenverkehr hinaus fungiert ein Redirector als Proxy oder setzt eine Web Application Firewall (WAF) vor dem C2-Server ein. Er stellt sicher, dass nur C2-relevanter Datenverkehr an den C2-Server weitergeleitet wird, während nicht-C2-bezogener Traffic entweder blockiert oder auf eine legitim wirkende Website umgeleitet wird.

Firewall

Eine Firewall innerhalb einer C2-Infrastruktur wird verwendet, um den Datenverkehr zwischen dem Angreifer, den kompromittierten Computern und dem C2-Server zu filtern, zu untersuchen und zu kontrollieren. Indem die Firewall nur Datenverkehr von vorab genehmigten Umleitungsadressen akzeptiert, stellt sie sicher, dass die echte C2-Infrastruktur verborgen bleibt, was es für Verteidiger erheblich erschwert, die Command-and-Control-Einrichtung des Angreifers zu identifizieren. Dies trägt dazu bei, das Erkennungsrisiko zu minimieren und den unbefugten Zugriff auf das C2-Netzwerk zu verhindern.

Beispielsweise kann der C2-Betreiber daran gehindert werden, eine direkte Verbindung zum C2-Server herzustellen. Stattdessen muss der Zugriff über einen internen Jump-Server erfolgen, der als zwischengeschaltetes Gateway fungiert. Um diesen Zugriff weiter zu sichern, kann für die Verbindung zum Jump-Server beispielweise ein VPN-Tunnel mit IPSEC-EAP-TLS erforderlich sein, der eine verschlüsselte und authentifizierte Kommunikation gewährleistet.

Interner Proxy

Ein interner Proxy, ähnlich einem externen Redirector, untersucht eingehenden HTTP-Verkehr und stellt sicher, dass nur C2-bezogene Anfragen an den eigentlichen C2-Server weitergeleitet werden. Diese zusätzliche Filterebene trägt zur Aufrechterhaltung der Betriebssicherheit bei, verbirgt die C2-Infrastruktur und verringert das Risiko einer Entdeckung.

C2 Server und Services

Der C2-Server ist die zentrale Komponente einer Command-and-Control-Infrastruktur, die für den Empfang des Beacon Datenverkehrs, die Erteilung von Befehlen und die Verwaltung kompromittierter Hosts verantwortlich ist. Er dient Angreifern oder Red Teams als primäre Schnittstelle, um ihre Operationen zu steuern, Aufgaben auszuführen und die Persistenz auf Zielsystemen aufrechtzuerhalten. Ein C2-Server ist häufig auf zusätzliche Dienste angewiesen, um die Funktionalität und Tarnung zu erhöhen. Dazu können zusätzliche Clients zur Verwendung von Proxychains, ein C2-SIEM zur Protokollierung und Überwachung, gefälschte Websites zur Nachverfolgung oder für Phishing-Angriffe oder DNS over HTTPS (DoH) gehören.

Um die Betriebssicherheit und die Datentrennung zu gewährleisten, sollte für jeden Einsatz eines Red Teams ein dediziertes Segement mit einem eigenen C2-Server und eigenen Diensten vorhanden sein. Dadurch wird sichergestellt, dass Kundendaten aus verschiedenen Einsätzen getrennt bleiben. Eine gut strukturierte Abschottungsstrategie erleichtert auch die saubere Ausserbetriebnahme nach einem Einsatz und verringert das Risiko einer versehentlichen Offenlegung von Daten oder von zurückgelassenen Artefakten.

Alle C2-Server sollten verschlüsselt sein und eine Entsperr-PIN erfordern, um gestartet zu werden, wenn sie offline geschaltet werden. Dies fügt eine zusätzliche Sicherheitsebene hinzu, um im Falle einer Kompromittierung einen unbefugten Zugriff zu verhindern. Wenn Backups erforderlich sind, müssen diese ebenfalls verschlüsselt werden, um den Zugriff auf sensible Betriebsdaten zu verhindern.

Häufig werden der C2-Server und die damit verbundenen Dienste in virtualisierten Umgebungen eingesetzt, um die Flexibilität, Skalierbarkeit und Isolierung zu verbessern. Die Sicherung dieser Komponenten allein reicht jedoch nicht aus, auch der Hypervisor selbst muss vor unbefugtem Zugriff geschützt werden. Ein kompromittierter Hypervisor stellt ein hohes Risiko dar, da er die vollständige Kontrolle über die gesamte virtualisierte C2-Infrastruktur gewährt und es Angreifern ermöglicht, Sicherheitsmassnahmen des Gastbetriebssystems zu umgehen und uneingeschränkten Zugriff auf C2-Vorgänge zu erhalten. Um dieses Risiko zu mindern, muss der Zugriff auf den Hypervisor eingeschränkt werden, was Authentifizierungsmechanismen wie Multi-Faktor-Authentifizierung (MFA) und rollenbasierte Zugriffskontrollen erfordert. Logs und Überwachung sollten verwendet werden, um unbefugte Zugriffsversuche zu erkennen. Darüber hinaus müssen virtuelle C2-Maschinen von anderen Workloads isoliert werden, die auf demselben Hypervisor ausgeführt werden. Es sollte eine strenge Netzwerksegmentierung implementiert werden, um unnötige Kommunikation zwischen VMs zu verhindern und das Risiko einer lateralen Ausbreitung im Falle einer Kompromittierung zu minimieren.

C2 Detection

Die Erkennung von C2-Aktivitäten konzentriert sich typischerweise auf drei Hauptbereiche: den Loader, das Beacon und den Netzwerkverkehr selbst.

• Loader-Erkennung: Die meisten Erkennungen erfolgen während der initialen Ausführung, wenn EDRs verhaltensbasierte Analysen und Heuristiken einsetzen, um verdächtige Aktivitäten wie Prozessinjektionen, die Nutzung von PowerShell oder anderen Skriptsprachen sowie unsignierte Binärdateien zu erkennen. Moderne EDR-Lösungen wie Elastic, CrowdStrike und Microsoft Defender for Endpoint sind besonders effektiv bei der Erkennung bösartiger Aktivitäten, etwa durch die Analyse des Laufzeitverhaltens und von Speicherstrukturen, einschliesslich Anomalien bei API-Aufrufen, Remote-Thread-Erstellung, Speicherzuweisungen mit verdächtigen Attributen und Shellcode-ähnlicher Entropie in Speicherbereichen. Loader, die kurz nach dem Schreiben auf das System ausgeführt werden, aus benutzerzugänglichen oder ungewöhnlichen Verzeichnissen starten oder manipulierte Metadaten enthalten, werden besonders häufig erkannt. Elastic bietet unter dem Repository protections-artifacts eine Reihe hervorragender Regelsätze.
• Beacon-Erkennung: Gut gestaltete Beacons sind schwerer zu erkennen, dennoch kann sich wiederholende Kommunikation, insbesondere über Standardprotokolle wie HTTP oder DNS, auch mit Jitter durch verhaltensbasierte Analysen und Traffic Muster erkannt werden. Erkennungen treten häufig auf, wenn der C2-Operator keine sauberen OPSEC-Praktiken anwendet.
• Traffic-Erkennung: C2-Kommunikation kann durch Netzwerküberwachung und Flow-Analyse erkannt werden, insbesondere wenn sie unverschlüsselt erfolgt, Protokolle zweckentfremdet (z.B. DNS zur Datenexfiltration) oder auffällige zeitliche Muster aufweist. Lösungen wie Microsoft Defender for Endpoint (MDE) liefern aggregierte Telemetriedaten, die beacon-artige Aktivität sichtbar machen können. Eine gute Analyse dazu bietet Bluraven Academy. Open-Source-Tools wie RITA – Real Intelligence Threat Analytics wurden speziell zur Erkennung von C2-Mustern im Netzwerkverkehr entwickelt, insbesondere Beaconing. RITA analysiert Flow-Daten und identifiziert Indikatoren wie lange Verbindungsdauern, gleichmässige Paketgrössen und regelmässige Kommunikationsintervalle.

Fazit

Der Aufbau einer C2-Infrastruktur erfordert mehr, als nur einen Server bereitzustellen und Payloads zu generieren. Jede Komponente innerhalb der C2-Architektur erfüllt eine spezifische Rolle, um die Tarnung zu wahren und eine zuverlässige Befehlsübermittlung zu gewährleisten. Loader müssen der Früherkennung entgehen, während die Netzwerkkomponenten des C2 den Backend-Zugriff absichern und Zugriffskontrollen durchsetzen. Der C2-Server selbst sollte streng abgesichert sein und nur über gehärtete, eingeschränkte Kommunikationskanäle erreichbar sein.

Über die Infrastruktur hinaus müssen C2-Operatoren mögliche Erkennungspunkte entlang der gesamten Angriffskette berücksichtigen. Loader werden häufig durch verhaltensbasierte Analysen erkannt, während Beaconing-Aktivitäten durch Kommunikationsmuster und Endpoint-Telemetrie auffallen können. Darüber hinaus können auch Fehler des Operators, wie zu offensichtliche Payloads, fehlerhafte Konfigurationen oder nicht plausibler Netzwerkverkehr, die Erkennung begünstigen.

Dieser Artikel hat die zentralen Komponenten einer C2-Infrastruktur erläutert und gängige Umgehungsstrategien angeschnitten. Damit soll einerseits Red Teams beim Aufbau ihrer C2-Infrastruktur unterstützt werden und andererseits Verteidigern ein besseres Verständnis dafür vermittelt werden, wie solche C2-Systeme aufgebaut sind.

• LLM agent memory at 0.12% of model parameters (venturebeat.com)
• We Stopped Choosing LLMs by Vibe. Here’s the Eval Harness We Built Instead (magicsword.io)
• Best Small Language Models on Hugging Face Right Now! (kdnuggets.com)
• Alleged Kimwolf Botmaster ‘Dort’ Arrested, Charged in U.S. and Canada (krebsonsecurity.com)
• DPRK Activity Evolution Through Campaign Linkage (krypt3ia.wordpress.com)
• Six Signals for Threat Attribution (zeltser.com)
• Hackers Find That Inaudible Sounds Hidden in Podcasts or Random Videos Can Hijack Your AI Voice Chatbot (futurism.com)
• CISA Admin Leaked AWS GovCloud Keys on Github (krebsonsecurity.com)
• APT Operations Against AI Systems (krypt3ia.wordpress.com)
• Cyber-crime increasingly coming with threats of physical violence (bbc.com)
• UK schools should remove pupils’ online photos as AI blackmail threat grows, say experts (theguardian.com)
• Teaching Claude why (anthropic.com)
• Mythos finds a curl vulnerability (daniel.haxx.se)
• LLMs can hide text in other text of the same length (arxiv.org)
• A Mac Studio for Local AI 6 Months Later (spicyneuron.substack.com)
• The Must-Know Topics for an LLM Engineer (towardsdatascience.com)
• Islamic Cyber Resistance in Iraq 313 (ICR-313) Ubuntu DD0S Actor Profile (krypt3ia.wordpress.com)
• A Ransomware Negotiator Pleads Guilty to Being a Double Agent (gizmodo.com)
• Researchers built a chatbot that only knows the world before 1931 (malwarebytes.com)
• An AI Just Beat Doctors at Diagnosing ER Patients (singularityhub.com)