GraphStrike

Blog de publication : GraphStrike : Utiliser l'API Microsoft Graph pour faire disparaître le trafic Beacon
Blog du développeur : GraphStrike : Anatomie du développement d'outils offensifs

Introduction

GraphStrike est une suite d'outils qui permet au Beacon HTTPS de Cobalt Strike d'utiliser l'API Microsoft Graph pour les communications C2. Tout le trafic Beacon est transmis via deux fichiers créés sur le site SharePoint de l'attaquant, et toutes les communications du Beacon sont routées vers https://graph.microsoft.com :

GraphStrike inclut un provisionneur pour créer les ressources Azure nécessaires à Cobalt Strike HTTPS via l'API Graph :

GraphStrike ne crée aucune ressource payante dans Azure, donc aucun coût supplémentaire n'est engendré par l'utilisation de GraphStrike ou de son provisionneur.

Pourquoi ?

Des renseignements sur les menaces ont été publiés concernant plusieurs APT différentes qui exploitent l'API Microsoft Graph et d'autres services Microsoft pour des campagnes offensives :

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

Les acteurs malveillants continuent d'utiliser des services légitimes à des fins illégitimes. Utiliser un domaine à haute réputation comme graph.microsoft.com pour les communications C2 est extrêmement efficace et souhaitable, mais souvent compliqué et prohibitif en termes de temps et d'efforts. La plupart des frameworks C2 ne prennent pas en charge les méthodes pour récupérer ou renouveler les jetons d'accès, ce qui les rend incapables d'utiliser l'API Graph. Cela peut rendre difficile pour les équipes rouges de reproduire ces techniques, et prive les défenseurs d'une chance d'observer et de développer des signatures pour ce type d'activité. GraphStrike cherche à alléger ce fardeau et à fournir un processus fiable et reproductible pour exploiter l'API Microsoft Graph tout en conservant la familiarité et la fiabilité de l'expérience utilisateur de Cobalt Strike.

S'agit-il d'un External C2 ?

Techniquement, non. Ayant déjà construit un véritable External C2 utilisant l'API Graph (qui envoyait le trafic Beacon sous forme de messages Microsoft Teams), le fardeau de devoir développer, maintenir et intégrer une sonde personnalisée répondant aux spécifications d'External C2 et faisant le travail est bien trop familier. GraphStrike exploite plutôt un Chargeur Réflexif Défini par l'Utilisateur (UDRL) open source appelé AceLdr par Kyle Avery (adapté sous le nom 'GraphLdr' dans ce projet) pour intercepter les appels à la bibliothèque WinINet que Beacon effectue normalement et les manipuler si nécessaire afin d'utiliser l'API Graph. Il n'y a pas de sonde personnalisée ni de processus supplémentaire à proprement parler, seulement le processus Beacon avec quelques API Windows interceptées. Côté serveur, un programme Python3 traduit le trafic du serveur d'équipe Cobalt Strike en trafic API Graph et vice-versa.

Fonctionnalités

GraphStrike prend en charge presque toutes les activités normales de Cobalt Strike, y compris :

1. Utilisation de Proxychains via un proxy SOCKS de Cobalt Strike (bien que très lent...)
2. Téléversement/Téléchargement de fichiers volumineux
3. BOFs, execute-assembly, etc.

Cela inclut également l'intégration par GraphStrike des commandes sleep, exit et remove pour faire correspondre les temps de sommeil du serveur GraphStrike avec ceux du Beacon, ainsi que la suppression des fichiers dans SharePoint lorsqu'un Beacon est quitté ou supprimé.

GraphStrike intègre également toutes les fonctionnalités de l'AceLdr original, avec quelques API supplémentaires ajoutées pour utiliser également le spoofing de pile d'appels.

Prérequis

GraphStrike nécessite ce qui suit avant de commencer :

1. Un locataire Microsoft Azure avec une licence SharePoint/O365 attribuée et un site créé. Le site par défaut convient.
2. Un compte Azure avec des autorisations d'administrateur général dans ce locataire.
3. Python 3.8-3.11^{Note #4} (et les dépendances supplémentaires qui seront installées lors du processus d'installation)

Règles de pare-feu

1. Assurez-vous que chaque machine exécutant le client Cobalt Strike peut se connecter à la machine du serveur d'équipe Cobalt Strike sur les ports 443 et 5000.

Configuration

Prenez note de ce qui suit avant de poursuivre le processus de configuration :

1. Certains composants utilisent des chemins relatifs pour localiser d'autres ressources. Veuillez changer de répertoire comme indiqué ci-dessous.
2. Le profil Cobalt Strike ne peut être modifié qu'AVANT l'étape 5 du processus de configuration ci-dessous^{Note #1}.

Sur la machine qui exécutera le serveur d'équipe Cobalt Strike :

1. Clonez le dépôt.
2. Depuis le répertoire du dépôt, exécutez sudo setup/install_dependencies.sh pour installer les dépendances système requises.
3. Exécutez python3 -m venv virtual puis source virtual/bin/activate pour créer et entrer dans l'environnement virtuel.
4. Changez dans le répertoire setup et exécutez pip3 install -r requirements.txt.
5. Exécutez ./provisioner.py new et terminez le processus de configuration.
6. Démarrez le serveur d'équipe Cobalt Strike en utilisant graphstrike.profile comme profil C2 malleable.
7. Lancez une instance du client Cobalt Strike (vous pouvez le faire sur une machine cliente, ou sur la machine TS et la tuer ensuite) et créez un écouteur HTTPS Cobalt Strike sur le port 443 avec graph.microsoft.com dans les champs Hôtes HTTPS et Hôte HTTPS (Stager).
8. Revenez au répertoire principal du dépôt et exécutez le serveur GraphStrike avec ./GraphStrike.py.

Sur TOUTES les machines qui exécuteront le client Cobalt Strike :

9. Copiez le répertoire GraphStrike/client depuis la machine TS vers la machine cliente. Cela doit être fait UNIQUEMENT après avoir terminé le provisionnement !
10. Importez GraphStrike.cna dans Cobalt Strike à l'aide du Gestionnaire de scripts.
11. Créez des charges utiles Cobalt Strike, qu'il s'agisse de shellcode brut ou d'artefacts compilés avec Artifact Kit ou un autre framework de génération de charges utiles. Les utilisateurs d'Artifact Kit, voir ci-dessous !
12. Profitez.

Utilisateurs d'Artifact Kit

En raison de la taille de GraphLdr, les utilisateurs d'Artifact Kit devront le recompiler avec des options spécifiques pour que GraphStrike soit compatible avec les charges utiles générées par Artifact Kit. Plus précisément, les champs 'Stage Size' et 'RDLL Size' doivent être spécifiés pour utiliser la taille RDLL de 100K. Deux exemples de syntaxes fonctionnelles sont fournis ci-dessous :

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

Nettoyage

Sur la machine exécutant le TS + le serveur GraphStrike :

1. Arrêtez le serveur GraphStrike
2. Revenez au répertoire setup et exécutez ./provisioner.py delete pour supprimer les ressources Azure créées.

Remarques

Sans ordre particulier, voici quelques suggestions et observations pour utiliser GraphStrike à son plein potentiel.

1. Le profil inclus avec GraphStrike est très minimaliste ; c'est intentionnel. Modifier l'un des champs EXISTANTS du profil peut/va casser GraphStrike ! Vous devriez pouvoir ajouter du langage/comportement de profil supplémentaire à d'autres sections non encore définies (par exemple personnaliser le nom du tube, le comportement d'injection, etc.). Toute modification du profil DOIT être effectuée avant d'exécuter le provisionneur !
2. L'application Azure utilisée pour les communications C2 à la fois par Beacon et le serveur GraphStrike est limitée à 1200 requêtes/min. Le serveur GraphStrike utilise 120/min comme base pour fonctionner. Plus le temps de sommeil d'un Beacon est bas, plus il effectuera de requêtes ; de plus, chaque Beacon créé avec GraphStrike utilise une partie de cette limite de 1200/min. Passer en mode interactif avec un Beacon est faisable, mais le faire avec plus d'un Beacon ne l'est probablement pas. Si vous rencontrez des problèmes de limitation de débit, envisagez d'augmenter le temps de sommeil de vos beacons, de diminuer le nombre de beacons en cours d'exécution, ou les deux.
3. Bien que le temps de sommeil du serveur GraphStrike change par Beacon en fonction des commandes sleep émises, cela signifie en réalité que le serveur GraphStrike dormira pendant le temps spécifié avant de vérifier auprès du TS pour les tâches. Cela ne signifie PAS que Beacon recevra et traitera immédiatement les tâches dès qu'elles seront récupérées du TS par le serveur GraphStrike. Beacon dormira le temps spécifié avant de contacter SharePoint pour récupérer les tâches du TS, mais en raison de la nature asynchrone du C2, cela ne sera pas en synchronisation avec le moment où le serveur GraphStrike les téléverse.
4. Si un Beacon meurt sans s'être arrêté proprement (AV, crash, etc.), le Beacon semblera toujours contacter le TS, et le fait qu'il soit mort ne deviendra apparent qu'une fois que vous lui aurez envoyé une commande. Ce qui se connecte réellement au TS / donne l'impression que le Beacon est toujours en contact, c'est le serveur GraphStrike, donc cela ne reflète pas vraiment la santé d'un Beacon. Telle est la nature du C2 asynchrone.
5. GraphStrike fonctionne selon un modèle 1:1:1 ; 1 site SharePoint est associé à 1 serveur GraphStrike, lui-même associé à 1 TS. Vous rencontrerez des problèmes si vous essayez de connecter deux serveurs TS/GraphStrike à un seul site SharePoint. Vous pouvez bien sûr connecter plusieurs clients Cobalt Strike à un seul serveur TS / GraphStrike, chaque client a simplement besoin d'une copie du dossier 'client' produit par le processus de provisionnement.
6. Il existe un problème connu concernant la compatibilité de l'utilitaire az utilisé par GraphStrike avec Python 3.12.
7. Je vous recommande de consulter la documentation d'AceLdr, car toutes les notes de ce projet s'appliquent également ici.

Limitations

Les limitations suivantes existent dans GraphStrike :

1. Seuls les Beacons x64 sont pris en charge.
2. Les Beacons stagés ne sont pas pris en charge.
3. GraphStrike est uniquement compatible avec la bibliothèque WinINet ; la nouvelle option de bibliothèque WinHTTP pour les Beacons n'est pas prise en charge.
4. Pas de support pour envoyer une commande sleep via le menu contextuel du Beacon. Utilisez plutôt la ligne de commande pour mettre les beacons en sommeil.
5. GraphStrike n'est pris en charge que sur les instances Linux de Cobalt Strike. Le support Windows est certainement possible à implémenter, et ne relève vraiment que d'une question de modification de quelques chemins dans les fichiers Python et le script Aggressor.

Crédits

GraphStrike ne serait pas possible sans les contributions des personnes suivantes :

1. Kyle Avery pour AceLdr
2. Didier Stevens pour cs-decrypt-metadata.py
3. Mike Saunders, Corey Overstreet, Chris Truncer et Justin Palk de l'équipe Red Siege qui ont tous aimablement participé aux tests bêta de GraphStrike et identifié plusieurs problèmes qui ont été corrigés avant la publication.