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.

Über den Autor

Marius Elmiger hat seit den frühen 2000er Jahren Erfahrung in verschiedenen Rollen als Administrator, Engineer, Architekt und Consultant gesammelt. Sein Fokus lag hauptsächlich in der Implementierung von komplexen IT-Infrastruktur Projekten, Umsetzung von Sicherheitskonzepten und Compromise Recoveries. Später wechselte er zur offensiven Seite, um sein Wissen weiter auszubauen. Als Grundlage neben zahlreichen Zertifikaten absolvierte Marius ein MSc in Advanced Security & Digital Forensics an der Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://academy.bluraven.io/blog/beaconing-detection-using-mde-aggregated-report-telemetry
• https://bruteratel.com/
• https://github.com/BC-SECURITY/Empire
• https://github.com/HavocFramework/Havoc
• https://github.com/Ne0nd0g/merlin
• https://github.com/activecm/rita
• https://github.com/elastic/protections-artifacts/tree/main/behavior/rules/windows
• https://github.com/its-a-feature/Mythic
• https://github.com/sevagas/Advanced_Initial_access_in_2024_OffensiveX
• https://howto.thec2matrix.com/
• https://nighthawkc2.io/about/
• https://sliver.sh/
• https://www.balliskit.com/#products
• https://www.msecops.de/products
• https://www.scip.ch/?labs.20241114
• https://www.shellterproject.com/
• https://www.youtube.com/watch?v=hEhQDmJ4Jx8
• https://www.youtube.com/watch?v=iYKItfBbPoY