GraphStrike

Release-Blog: GraphStrike: Verwendung der Microsoft Graph API, um Beacon-Traffic verschwinden zu lassen
Entwickler-Blog: GraphStrike: Anatomie der Entwicklung von Offensiv-Tools

Einleitung

GraphStrike ist eine Suite von Tools, die es dem HTTPS-Beacon von Cobalt Strike ermöglicht, Microsoft Graph API für die C2-Kommunikation zu nutzen. Der gesamte Beacon-Traffic wird über zwei Dateien übertragen, die auf der SharePoint-Seite des Angreifers erstellt werden, und alle Kommunikationen vom Beacon werden an https://graph.microsoft.com weitergeleitet:

GraphStrike enthält einen Provisioner zur Erstellung der erforderlichen Azure-Assets für Cobalt Strike HTTPS über Graph API:

GraphStrike erstellt keine kostenpflichtigen Assets in Azure, sodass durch die Nutzung von GraphStrike oder seines Provisioners keine zusätzlichen Kosten entstehen.

Warum?

Es wurden Threat-Intelligence-Informationen zu mehreren verschiedenen APTs veröffentlicht, die Microsoft Graph API und andere Microsoft-Dienste für offensive Kampagnen nutzen:

1. BLUELIGHT - APT37/InkySquid/ScarCruft
2. Graphite - APT28/Fancy Bear
3. Graphican - APT15/Nickel/The Flea
4. SiestaGraph - UNBEKANNT

Bedrohungsakteure nutzen weiterhin legitime Dienste für illegitime Zwecke. Die Verwendung einer hochvertrauenswürdigen Domain wie graph.microsoft.com für C2-Kommunikation ist äußerst effektiv und wünschenswert, aber oft kompliziert und aus Zeit- und Aufwandsgründen hinderlich. Die meisten C2-Frameworks unterstützen keine Methoden zum Abrufen oder Rotieren von Zugriffstoken, was sie daran hindert, Graph API zu verwenden. Dies kann es für Red Teams schwierig machen, diese Techniken zu replizieren, und nimmt Verteidigern die Möglichkeit, diese Art von Aktivitäten zu beobachten und Signaturen zu entwickeln. GraphStrike möchte diese Last verringern und einen zuverlässigen und wiederholbaren Prozess zur Nutzung der Microsoft Graph API bereitstellen, während die Vertrautheit und Zuverlässigkeit der Cobalt Strike-Benutzererfahrung erhalten bleibt.

Ist dies ein External C2?

Technisch gesehen nein. Nachdem bereits ein echter External C2 unter Verwendung von Graph API entwickelt wurde (der Beacon-Traffic als Microsoft Teams-Nachrichten sendete), ist die Last, ein benutzerdefiniertes Implantat zu entwickeln, zu warten und zu integrieren, das die External C2-Spezifikation erfüllt und die Arbeit erledigt, nur allzu vertraut. GraphStrike nutzt stattdessen einen Open-Source-User Defined Reflective Loader(UDRL) namens AceLdr von Kyle Avery (in diesem Projekt als 'GraphLdr' adaptiert), um die WinINet-Bibliotheksaufrufe, die Beacon normalerweise tätigt, zu hooken und sie nach Bedarf zu manipulieren, um Graph API zu verwenden. Es gibt kein benutzerdefiniertes Implantat oder zusätzlichen Prozess – nur den Beacon-Prozess mit ein paar gehookten Windows-APIs. Auf der Serverseite gibt es ein Python3-Programm, das den Traffic des Cobalt Strike Team Servers in Graph API-Traffic übersetzt und umgekehrt.

Funktionen

GraphStrike unterstützt fast alle normalen Cobalt Strike-Aktivitäten, einschließlich:

1. Verwendung von Proxychains über einen Cobalt Strike SOCKS-Proxy (allerdings sehr langsam...)
2. Upload/Download großer Dateien
3. BOFs, execute-assembly, etc.

Dies umfasst auch die Integration der Befehle sleep, exit und remove in GraphStrike, um die Schlafzeiten des GraphStrike-Servers mit denen des Beacons zu synchronisieren sowie Dateien in SharePoint zu löschen, wenn ein Beacon beendet oder entfernt wird.

GraphStrike integriert darüber hinaus alle Funktionen und Möglichkeiten des ursprünglichen AceLdr, wobei zusätzliche APIs hinzugefügt wurden, um auch Call Stack Spoofing zu nutzen.

Anforderungen

GraphStrike erfordert Folgendes, bevor Sie beginnen:

1. Einen Microsoft Azure-Mandanten mit einer SharePoint/O365-Lizenz + erstellter Website. Die Standardwebsite ist in Ordnung.
2. Ein Azure-Konto mit globalen Administratorberechtigungen in diesem Mandanten.
3. Python 3.8-3.11^{Anmerkung #4} (und zusätzliche Abhängigkeiten, die während des Einrichtungsprozesses installiert werden)

Firewall-Regeln

1. Stellen Sie sicher, dass jeder Rechner, auf dem der Cobalt Strike-Client läuft, eine Verbindung zum Cobalt Strike Team Server auf den Ports 443 und 5000 herstellen kann.

Einrichtung

Beachten Sie Folgendes, bevor Sie mit dem Einrichtungsprozess fortfahren:

1. Bestimmte Komponenten verwenden relative Pfade, um andere Assets zu finden. Bitte wechseln Sie die Verzeichnisse wie unten angegeben.
2. Das Cobalt Strike-Profil darf NUR VOR Schritt 5 des untenstehenden Einrichtungsprozesses bearbeitet werden^{Anmerkung #1}.

Auf dem Rechner, der den Cobalt Strike Team Server ausführt:

1. Klonen Sie das Repository.
2. Führen Sie vom Repository-Verzeichnis aus sudo setup/install_dependencies.sh aus, um die erforderlichen Systemabhängigkeiten zu installieren.
3. Führen Sie python3 -m venv virtual und dann source virtual/bin/activate aus, um die virtuelle Umgebung zu erstellen und zu betreten.
4. Wechseln Sie in das setup-Verzeichnis und führen Sie pip3 install -r requirements.txt aus.
5. Führen Sie ./provisioner.py new aus und schließen Sie den Einrichtungsprozess ab.
6. Starten Sie den Cobalt Strike Team Server mit graphstrike.profile als malleable C2-Profil.
7. Starten Sie eine Instanz des Cobalt Strike-Clients (Sie können dies auf einem Client-Rechner oder auf der TS-Box tun und danach beenden) und erstellen Sie einen Cobalt Strike HTTPS-Listener auf Port 443 mit graph.microsoft.com als HTTPS Hosts und HTTPS Host(Stager)-Feldern.
8. Wechseln Sie zurück in das Hauptverzeichnis des Repositories und starten Sie den GraphStrike-Server mit ./GraphStrike.py.

Auf ALLEN Rechnern, die den Cobalt Strike-Client ausführen:

9. Kopieren Sie das Verzeichnis GraphStrike/client vom TS-Rechner auf den Client-Rechner. Dies darf erst NACH Abschluss der Bereitstellung erfolgen!
10. Importieren Sie GraphStrike.cna in Cobalt Strike über den Script Manager.
11. Erstellen Sie Cobalt Strike-Payloads, sei es roher Shellcode oder kompilierte Artefakte mit dem Artifact Kit oder einem alternativen Payload-Generierungsframework. Artifact Kit-Benutzer siehe unten!
12. Profitieren Sie.

Artifact Kit-Benutzer

Aufgrund der Größe von GraphLdr müssen Benutzer des Artifact Kits dieses mit bestimmten Optionen neu kompilieren, damit GraphStrike mit den vom Artifact Kit generierten Payloads kompatibel ist. Insbesondere müssen die Felder 'Stage Size' und 'RDLL Size' so angegeben werden, dass die 100K RDLL-Größe verwendet wird. Zwei Beispiele für funktionierende Syntax sind unten angegeben:

./build.sh pipe VirtualAlloc 505029 100 false false none /opt/cobaltstrike/artifacts
./build.sh peek HeapAlloc 492376 100 false true indirect /opt/cobaltstrike/artifacts

Bereinigung

Auf dem Rechner, der den TS + GraphStrike-Server ausführt:

1. Stoppen Sie den GraphStrike-Server
2. Wechseln Sie zurück in das setup-Verzeichnis und führen Sie ./provisioner.py delete aus, um die erstellten Azure-Assets zu entfernen.

Hinweise

In keiner bestimmten Reihenfolge finden Sie hier einige Vorschläge und Beobachtungen, um GraphStrike optimal zu nutzen.

1. Das mit GraphStrike mitgelieferte Profil ist sehr minimalistisch; das ist beabsichtigt. Das Ändern bestehender Felder im Profil kann/wird GraphStrike beschädigen! Sie sollten in der Lage sein, zusätzliche Profilsprache/-verhalten zu anderen Abschnitten hinzuzufügen, die noch nicht definiert sind (z.B. Pipe-Namen anpassen, Injektionsverhalten usw.). Alle Änderungen am Profil MÜSSEN vor dem Ausführen des Provisioners vorgenommen werden!
2. Die Azure-Anwendung, die für die C2-Kommunikation sowohl von Beacon als auch vom GraphStrike-Server verwendet wird, ist auf 1200 Anfragen/Minute limitiert. Der GraphStrike-Server verwendet 120/Minute als Grundlage zum Funktionieren. Je niedriger die Schlafzeit eines Beacons ist, desto mehr Anfragen stellt er; zusätzlich nutzt jeder mit GraphStrike erstellte Beacon einen Teil des Limits von 1200/Minute. Interaktives Arbeiten mit einem Beacon ist machbar, aber interaktives Arbeiten mit mehr als einem Beacon ist wahrscheinlich nicht möglich. Wenn Sie auf Ratenbegrenzungsprobleme stoßen, erwägen Sie, die Schlafzeit Ihrer Beacons zu erhöhen, die Anzahl der laufenden Beacons zu verringern oder beides.
3. Obwohl sich die Schlafzeit des GraphStrike-Servers pro Beacon entsprechend der ausgegebenen sleep-Befehle ändert, bedeutet dies eigentlich, dass der GraphStrike-Server für die angegebene Zeit schläft, bevor er beim TS nach Aufgaben fragt. Es bedeutet NICHT, dass der Beacon die Aufgaben sofort erhält und verarbeitet, sobald sie vom GraphStrike-Server vom TS abgerufen wurden. Der Beacon schläft die angegebene Zeit, bevor er SharePoint kontaktiert, um TS-Aufgaben abzurufen, aber aufgrund der Natur asynchroner C2 wird dies nicht im Gleichschritt mit dem Hochladen durch den GraphStrike-Server erfolgen.
4. Wenn ein Beacon stirbt, ohne ordnungsgemäß beendet worden zu sein (AV, Absturz usw.), wird der Beacon weiterhin so aussehen, als würde er sich beim TS melden, und die Tatsache, dass er tot ist, wird erst deutlich, wenn Sie ihm einen Befehl erteilen. Was sich tatsächlich mit dem TS verbindet / den Anschein erweckt, dass der Beacon noch eincheckt, ist der GraphStrike-Server, was also nicht wirklich die Gesundheit eines Beacons widerspiegelt. Das ist die Natur asynchroner C2.
5. GraphStrike arbeitet nach einem 1:1:1-Modell: 1 SharePoint-Website ist mit 1 GraphStrike-Server verbunden, der mit 1 TS verbunden ist. Sie werden Probleme haben, wenn Sie versuchen, zwei TS/GraphStrike-Server mit einer einzigen SharePoint-Website zu verbinden. Sie können natürlich mehrere Cobalt Strike-Clients mit einem einzigen TS / GraphStrike-Server verbinden; jeder Client benötigt lediglich eine Kopie des 'client'-Ordners, der während des Bereitstellungsprozesses erstellt wurde.
6. Es gibt ein bekanntes Problem bezüglich der Kompatibilität des von GraphStrike verwendeten az-Dienstprogramms mit Python 3.12.
7. Ich empfehle, die Dokumentation für zu lesen, da alle Anmerkungen aus diesem Projekt auch hier gelten.

Einschränkungen

Die folgenden Einschränkungen bestehen in GraphStrike:

1. Es werden nur x64-Beacons unterstützt.
2. Gestaffelte Beacons werden nicht unterstützt.
3. GraphStrike ist nur mit der WinINet-Bibliothek kompatibel; die neue WinHTTP-Bibliotheksoption für Beacons wird nicht unterstützt.
4. Keine Unterstützung für das Ausgeben eines sleep-Befehls über das Rechtsklick-Menü des Beacons. Verwenden Sie stattdessen die Befehlszeilenoption, um Beacons in den Schlaf zu versetzen.
5. GraphStrike wird nur auf Linux-Instanzen von Cobalt Strike unterstützt. Windows-Unterstützung ist sicherlich implementierbar und ist eigentlich nur eine Frage der Änderung einiger Pfade innerhalb der Python-Dateien und des Aggressor-Skripts.

Danksagungen

GraphStrike wäre nicht möglich ohne die Beiträge der folgenden Personen:

1. Kyle Avery für AceLdr
2. Didier Stevens für cs-decrypt-metadata.py
3. Mike Saunders, Corey Overstreet, Chris Truncer und Justin Palk vom Red Siege-Team, die alle freundlicherweise GraphStrike beta-getestet und mehrere Probleme identifiziert haben, die vor der Veröffentlichung behoben wurden.