Case Study zu Red Teaming Assessment: Unser Weg zum Command & Control-Kanal

Dies ist ein Beitrag unseres LinkedIn-Newsletters CyberPulse News.
Abonniere den Newsletter, um kein Update mehr zu verpassen.

 

Red Teaming Assessments werden eingesetzt, um die Abwehrmechanismen eines Unternehmens gegen gezielte Angriffe zu überprüfen und zu verbessern. Sie simulieren reale Bedrohungsszenarien, um Schwachstellen zu identifizieren und die tatsächliche Effektivität von Sicherheitsmaßnahmen sowie Reaktionsprozessen zu bewerten.
In dieser Case Study stellen wir die Ergebnisse eines Red Teaming Assessments bei einem unserer Kunden vor. Dieses wurde von unseren Kollegen Timo Sablowski, Senior Security Consultant und Pascal Waffenschmidt, Security Consultant, durchgeführt.

 

Ziel des Assessments

Unser Kunde wollte in einem Red Teaming Assessment überprüfen lassen, ob es trotz der bestehenden Sicherheitslösungen möglich ist, Schadsoftware auf sein System zu bringen, einen Command & Control (C2)-Kanal aufzubauen und darüber Kommandos auszuführen.
Zusätzlich sollten die Incident Response Prozesse des Kunden getestet werden, sobald unser Angriff entdeckt würde. Die Mitarbeitenden der Security-Abteilung wurden deshalb nicht eingeweiht, um ein realistisches Szenario zu simulieren. Als Testobjekt diente ein regulär konfigurierter Arbeitslaptop mit einem normal eingerichteten E-Mail-Konto.
Für unser Assessment wählten wir zusammen mit dem Kunden einen „assumed breach“-Ansatz. Hierbei wird davon ausgegangen, dass Social Engineering-Angriffe zu einem bestimmten Zeitpunkt immer erfolgreich sind und Angreifer mit ausreichendem Aufwand immer ein System infiltrieren können.

 

Vorbereitung der Angriffssimulation

Die Vorbereitung der Angriffssimulation erfolgte in drei sorgfältig geplanten Schritten.

1. Abstimmung der TTPs gemäß dem Mitre ATT@CK Framework

Zu Beginn stimmten wir gemeinsam mit unserem Kunden die zu testenden Taktiken, Techniken und Prozeduren (TTPs) des Mitre ATT@CK Frameworks ab. Der Fokus unserer Tests lag explizit auf dem Bereich Command & Control. Die zu testenden TTPs waren konkret:

• Initial Access über Phishing-Attacken wie Spearphishing-Attachments (T1556.001) und -Links (T1556.002) sowie die Verbreitung über Wechseldatenträger wie USB-Sticks (T1091).
• User Execution über eine schädliche Datei (T1204.002).
• Im Bereich Command & Control konzentrierten wir uns auf verschlüsselte Kommunikationskanäle (T1573.001) und die Nutzung von Non-Standard Ports (T1571).

---

Über das Mitre ATT@CK Framework
Die umfangreiche Wissensdatenbank enthält gegnerische Taktiken und Techniken, die auf realen Beobachtungen von Cyberangriffen basieren. Das Mitre ATT&CK Framework wird weltweit von Sicherheitsexperten eingesetzt, um Bedrohungen zu identifizieren, abzuwehren und zu analysieren.

---

2. Entwicklung eines maßgeschneiderten C2-Kanals

Im zweiten Schritt programmierten wir eine speziell auf dieses Assessment zugeschnittene Serversoftware und einen Agenten, der auf dem Arbeitslaptop des Kunden eingeschleust werden sollte.
Damit unser C2-Kanal nicht direkt entdeckt werden konnte, bauten wir einige Features ein:

• Unser Agent meldete sich in unregelmäßigen Abständen beim Server (Beaconing & Jitter), um die Regelmäßigkeit der Kommunikation zu verschleiern.
• Wir haben die Kommunikation mit AES (Advanced Encryption Standard) verschlüsselt, damit sie trotz SSL-Inspektion durch die Firewall nicht als verdächtig erkannt wird.
• Wir hatten vorab für den Server eine unauffällige Domain registriert. So fällt der Server in der Kommunikation kaum auf.

3. Erstellung eines ausführlichen Testplans

Schließlich erstellten wir einen umfassenden Testplan, der verschiedene Szenarien abdeckte. Zentrale Fragestellungen waren:

• Über welche Wege kann der Agent in das Zielsystem eingeschleust werden?
• Welcher Kommunikationskanal wird für die Verbindung zwischen Agent und Server verwendet (z.B. HTTPS, Kommunikation über Non-Standard Ports)?
• Können Kommandos über den C2-Kanal auf dem Zielsystem ausgeführt werden?
• Ist eine Local Privilege Escalation möglich, um Administrationsrechte auf dem Gerät zu erlangen?

 

Durchführung des Assessments

Um die Sicherheitsmaßnahmen des Kunden umfassend zu prüfen, gliederten wir das Assessment in mehrere wesentliche Schritte.

1. Infiltration des Zielsystems

Im ersten Schritt testeten wir verschiedene Methoden, um den Agenten auf das Zielsystem zu bringen.
Per USB-Stick:
Diese häufig übersehene, aber sehr effektive Methode nutzt physische Zugangsmöglichkeiten aus. Wir hatten Erfolg und konnten unseren Agenten mit Hilfe eines USBs-Sticks schlussendlich auf den Testrechner laden.
Phishing:
Auch per E-Mail verschickte Links und Anhänge konnten auf dem Testrechner geöffnet und so unser Agent eingeschleust werden.

2. Ausführung der Schadsoftware

Als nächstes prüften wir, ob wir den C2-Kanal aufbauen und darüber Kommandos auf dem Testrechner ausführen konnten.
C2-Kommunikation über HTTPS:
Diese Methode erwies sich als effektiv. Der C2-Kanal konnte aufgebaut und Kommandos erfolgreich ausgeführt werden.
Weitere getestete Methoden:
Wir haben zudem verschiedene andere Kommunikationsmethoden getestet:

• Bad USB (Flipper Zero): Der Flipper Zero ist ein tragbares Gerät, das verschiedene drahtlose Protokolle und physische Zugangstechniken testen und analysieren kann, einschließlich RFID, NFC, Bluetooth, Infrarot und GPIO-Interaktionen. Mit Hilfe dieses kleinen Multitools konnten wir Tatstaureingaben simulieren und so erfolgreich Schadcode auf dem Testrechner ausführen.
• Word-Makro als E-Mail-Anhang: Der Empfang von E-Mails, die Word-Dokumente mit Makros im Anhang enthielten, wurde durch die Sicherheitslösung zumindest teilweise blockiert. Diese Sicherheitsmaßnahme konnte jedoch mit einfachen Techniken umgangen und die Word-Dokumente schließlich per E-Mail auf das Testsystem gebracht werden. Die Ausführung der Word-Makros auf dem Testrechner war jedoch ohne weiteres möglich, so dass auf diesem Weg Schadcode ausgeführt werden konnte.
• Zip-Dateien als Download: Mit Hilfe einer Zip-Datei konnten wir die Security-Lösung umgehen und die Schadsoftware auf dem Testrechner ausführen.
• Virtuelles Laufwerk mit Schadsoftware in PDF: Wir prüften auch, ob wir Schadsoftware über ein PDF einschleusen und mit Hilfe eines virtuellen Laufwerks ausführen konnten. Dieser Ansatz scheiterte allerdings an fehlenden Administrationsrechten zum Einbinden des Laufwerks.

Insgesamt ist es uns gelungen, über mehrere Wege unseren Agenten auszuführen, den C2-Kanal aufzubauen und auf dem Testsystem Kommandos auszuführen. Diese wurden von der Sicherheitslösung zumindest eine Zeit lang nicht erkannt.

3. Testen weiterer C2-Kommunikationsmöglichkeiten

Nachdem wir das Hauptziel, unentdeckt einen C2-Kanal aufzubauen und Kommandos auszuführen, erreicht hatten, konzentrierten wir uns im weiteren Assessment darauf, die Flexibilität und Robustheit des C2-Kanals zu testen. Dazu überprüften wir verschiedene Protokolle und Ports. Allerdings mussten wir schnell feststellen, dass lediglich HTTPS zuverlässig funktionierte. Andere Ports konnten aus dem internen Netzwerk heraus nicht erreicht werden.

4. Versuch einer Local Privilege Escalation

Zusätzlich führten wir eine grundlegende Überprüfung des Rechtemanagements auf dem Testrechner durch. Dazu verwendeten wir gängige Methoden zur Erlangung von Administratorrechten, einschließlich der Nutzung von Exploits für bekannte Schwachstellen oder der Ausnutzung von Schwächen in der Benutzerkontensteuerung (User Account Control, UAC). Diese Versuche blieben jedoch erfolglos, das System war angemessen gehärtet.

5. Entdeckung und Incident Response

Wir blieben lange Zeit unentdeckt und konnten den C2-Kanal für einige Kommandos nutzen. Erst als wir dem Testplan weiter folgten und weitere Wege zur Ausführung von Schadsoftware prüften, reagierte die EDR-Lösung aufgrund der abnehmenden Verschleierung unserer Aktionen, blockierte schlussendlich einen unserer Versuche und alarmierte den Kunden.
Nach der Entdeckung des Angriffs durch das Security Operations Center (SOC) griffen effiziente Incident Response Prozesse. Unsere vorherige Angriffe konnten im SIEM nachvollzogen werden und die Meldewege wurden eingehalten.

6. Erstellung des Testprotokolls und Reports

Abschließend haben wir alle Ergebnisse ausführlich dokumentiert und einen detaillierten Report erstellt. Dieser zeigt alle gefundenen Schwachstellen auf und bietet unserem Kunden eine fundierte Grundlage für weitere Sicherheitsmaßnahmen.

 

Empfehlungen für unseren Kunden

Optimierung der Endpoint Detection & Response (EDR)-Lösung notwendig
Unsere Analyse zeigte, dass die Endpoint Detection & Response (EDR)-Lösung des Kunden nicht ausreichend alarmiert. Gründe dafür können Konfigurationsprobleme oder mangelndes Fachwissen sein. Unser Kunde sollte daher die Konfiguration der Endpoint Protection überprüfen und anpassen, um Angriffe wie in unserem Test zukünftig früher zu erkennen.

Einführung eines Application Allow Listings
Um die Sicherheitsmaßnahmen zu verbessern, empfehlen wir die Einführung eines Application Allow Listing. Dieses blockiert alle unbekannten Anwendungen und verhindert somit auch die Ausführung von Schadsoftware.

Office-Makros standardmäßig blockieren
Die Ausführung von Office-Makros sollte jederzeit blockiert werden, um das Risiko durch Makro-basierte Malware zu minimieren.

Unbekannte USB-Geräte blockieren
Unbekannte USB-Geräte sollten immer blockiert werden, um das Risiko von Bad USB-Angriffen zu minimieren. In unseren Tests war das nicht der Fall und wir konnten über eine USB-Schnittstelle Schadcode auf den Testrechner spielen.

Regelmäßige Sensibilisierung der Benutzer
Regelmäßige Schulungen und Sensibilisierungsmaßnahmen sind unerlässlich, um das Bewusstsein der Mitarbeitenden für mögliche Bedrohungen zu schärfen und die Sicherheitskultur im Unternehmen zu stärken.

Fazit

Im Rahmen des Assessments konnten wir ungehindert Schadsoftware auf das Testsystem spielen, diese ausführen und Command-and-Control-Kanäle aufbauen, ohne dass die Endpoint Protection wirksam eingreifen konnte.
Dies bedeutet, dass unser Kunde nicht ausreichend gegen die im Scope definierten Szenarien geschützt ist. Die Eintrittswahrscheinlichkeit einer erfolgreichen gezielten Kompromittierung von Benutzern und deren Endgeräten stufen wir aufgrund der Größe des Kundens und seines Geschäftsmodells als sehr hoch ein, wenn die anvisierten Benutzer unaufmerksam sind.

Regelmäßige Assessments durchführen!
Regelmäßige Tests wie das von uns durchgeführte Red Teaming-Assement sind für Unternehmen unerlässlich. Solchen Tests zeigen nicht nur technische Schwachstellen, sondern auch Lücken in den Sicherheitsprozessen und Verantwortlichkeiten auf. So haben Unternehmen die Chance zu reagieren und ihre Sicherheit zu verbessern, bevor Schwachstellen von Cyberkriminellen ausgenutzt werden können.
Wir empfehlen daher, regelmäßige Assessments durchzuführen und auch neue Systeme direkt mit der Einführung testen zu lassen, um die Effektivität der Incident Response und Prozesse sicherzustellen.

Suchst Du Informationen über Angriffssimulationen zur Erkennung von Schwachstellen in Deinem Unternehmen?
Hier findest Du eine Übersicht über unsere Leistungen im Bereich Offensive Security