aggrokatz

Qu'est-ce que c'est

aggrokatz est une extension de plugin Aggressor pour CobaltStrike qui permet à pypykatz d'interfacer avec les beacons à distance.
La version actuelle de aggrokatz permet à pypykatz d'analyser les fichiers de dump LSASS et les fichiers de ruche du Registre pour extraire les identifiants et autres secrets stockés sans télécharger le fichier et sans télécharger de code suspect sur le beacon (Cobalt Strike est déjà présent de toute façon). À l'avenir, ce projet vise à fournir des fonctionnalités supplémentaires pour les opérations furtives, telles que la recherche et le déchiffrement de tous les secrets DPAPI/kerberoasting/etc.

Nous avons publié un court article de blog pour cette version de l'outil, qui inclut également quelques captures d'écran.

NOTES IMPORTANTES - VEUILLEZ LIRE CECI

Le dump LSASS/Registre n'est pas l'objectif de ce projet, seulement l'analyse. Raisons :

1. De multiples techniques de dump sont déjà implémentées depuis Cobalt Strike (CS) et largement disponibles publiquement. Récemment, nous sommes passés à une version modifiée de CredBandit qui dumps les octets bruts sur le disque au lieu du base64. Cool outil, allez voir.
2. Nous souhaitons garder notre technique de dump privée.

Dans le client CS, n'utilisez pas "reload" et n'essayez pas de décharger puis recharger manuellement le script si vous l'avez modifié. Vous DEVEZ le décharger, fermer le client et le rouvrir, puis charger le script modifié. Sinon, vous aurez plusieurs versions s'exécutant simultanément et une tonne d'erreurs et de comportements étranges se produiront !
Pendant l'analyse des fichiers LSASS/Registre sur le poste distant, veuillez ne pas interagir avec le beacon spécifique sur lequel vous avez lancé le script. Normalement, cela ne causerait aucun problème, mais je ne peux donner aucune garantie.

Installation

• Vous aurez besoin d'installer et de configurer pycobalt. Un readme est disponible sur leur page GitHub.
• Vous devez installer pypykatz version >=0.4.8
• Vous aurez besoin de Cobalt Strike

Configuration

• Assurez-vous que le fichier aggressor.cna de pycobalt est configuré et connaît l'emplacement de votre interpréteur Python
• Modifiez le pycobalt_path dans aggrokatz.cna pour qu'il pointe vers pycobalt.cna
• Dans CS, utilisez les fenêtres View > Script Console et Cobalt Strike > Script Manager. À l'aide de Script Manager, chargez le script aggkatz.cna.

Utilisation

• Si le script aggkatz.cna est chargé avec succès, vous aurez un nouvel élément de menu pypykatz lors d'un clic droit sur un beacon.
• Pendant l'analyse, vous verrez des messages de débogage dans la fenêtre Script Console.
• Une fois l'analyse terminée, les résultats s'afficheront à la fois dans la fenêtre Script Console et dans la fenêtre du Beacon lui-même.

Paramètres du menu d'analyse du dump LSASS

• LSASS file : L'emplacement du fichier lsass.dmp sur l'ordinateur distant. Vous pouvez également utiliser des chemins UNC pour accéder aux fichiers lsass.dmp partagés via SMB
• chunksize : La quantité maximale lue en une seule fois
• BOF file : Le fichier BOF (Beacon Object File) qui permet les lectures par morceaux. Ce fichier sera téléchargé et exécuté (en mémoire) à chaque lecture d'un nouveau morceau.
• (module) : Spécifie quels modules seront analysés. Par défaut : all
• Output : Spécifie le(s) format(s) de sortie
• Populate Credential tab : Après une analyse réussie, tous les identifiants obtenus seront disponibles dans l'onglet Credential de Cobalt Strike. Cette fonctionnalité est en version bêta
• Delete remote file after parsing : Après une analyse réussie, le fichier de dump LSASS sera supprimé de la cible

Paramètres du menu d'analyse du dump Registre

• SYSTEM file : L'emplacement du fichier SYSTEM.reg sur l'ordinateur distant. Vous pouvez également utiliser des chemins UNC pour accéder aux fichiers partagés via SMB
• SAM file (optional) : L'emplacement du fichier SAM.reg sur l'ordinateur distant. Vous pouvez également utiliser des chemins UNC pour accéder aux fichiers partagés via SMB
• SECURITY file (optional) : L'emplacement du fichier SECURITY.reg sur l'ordinateur distant. Vous pouvez également utiliser des chemins UNC pour accéder aux fichiers partagés via SMB
• SOFTWARE file (optional) : L'emplacement du fichier SOFTWARE.reg sur l'ordinateur distant. Vous pouvez également utiliser des chemins UNC pour accéder aux fichiers partagés via SMB
• chunksize : La quantité maximale lue en une seule fois
• BOF file : Le fichier BOF (Beacon Object File) qui permet les lectures par morceaux. Ce fichier sera téléchargé et exécuté (en mémoire) à chaque lecture d'un nouveau morceau.
• Output : Spécifie le(s) format(s) de sortie

Limitations

Le BOF de lecture de fichier prend actuellement en charge des lectures de fichiers jusqu'à 4 Go. Cela peut être étendu avec quelques modifications, mais jusqu'à présent, de tels gros fichiers n'ont pas été observés.

Comment ça marche

TL;DR

Normalement, l'analyseur de pypykatz effectue une série d'opérations de lecture de fichiers sur le disque, mais avec l'aide d'aggrokatz, ces opérations de lecture sont tunnelisées vers le beacon à l'aide d'un BOF (Beacon Object File) spécialement conçu qui permet de lire le contenu du fichier distant par morceaux. Cela permet à pypykatz d'extraire tous les secrets des fichiers distants sans lire l'intégralité du fichier, en ne récupérant que les morceaux nécessaires où se trouvent les secrets.

En détail

Pour avoir une vue d'ensemble du processus complet, deux parties doivent être mises en évidence :

1. comment pypykatz s'intègre avec CobaltStrike
2. comment pypykatz effectue l'extraction des identifiants sans lire l'intégralité du fichier

Intégration de pypykatz à CobaltStrike

CobaltStrike (agent) est écrit en Java, pypykatz est écrit en Python. C'est un problème. Heureusement pour nous, une entité inconnue a créé pycobalt qui fournit une interface pratique entre les deux mondes, avec des API utiles pouvant être invoquées directement depuis Python. Malgré le fait que pycobalt soit une pièce d'ingénierie remarquable, il y a quelques problèmes/inconvénients à signaler :

1. Concernant la confiance dans le projet pycobalt :

• Nous avons essayé de contacter l'auteur mais nous n'avons pas eu de réponse.
• Nous ne pouvons pas garantir que le projet pycobalt sera maintenu à l'avenir.
• Nous ne contrôlons aucun aspect du développement de pycobalt.

2. Concernant les problèmes techniques observés :

• En général, il y a des problèmes d'encodage entre pycobalt et CobaltStrike. Cela entraîne certains appels API qui renverraient des octets inutilisables car certains octets sont altérés par l'encodeur. En examinant le code, nous concluons que la plupart des problèmes d'encodage/décodage viennent du fait que pycobalt utilise STDOUT/STDIN pour communiquer avec le processus Java.
• Plus précisément, l'appel API bof_pack qui est crucial pour ce projet a dû être implémenté comme un script purement Aggressor et invoqué uniquement depuis Python en utilisant des structures de données simples (chaîne et entier) et non des octets.
• Seules les API bloquantes fournies par le package pycobalt sans support du threading. Enfin, du moins avons-nous observé que le threading se casse aléatoirement, mais nous nous y attendions un peu.
• API bloquante + pas de threading + dépendance aux callbacks = nous avons dû employer des astuces étranges pour que cela fonctionne.

Analyse des identifiants sur une pile de cartes

pypykatz et son module compagnon minidump ont dû être modifiés pour permettre une analyse par morceaux plus efficace que ce qui était implémenté auparavant, mais c'est un sujet pour un autre jour.
Après que pypykatz a été capable d'interfacer avec CobaltStrike via pycobalt, l'étape suivante était de permettre la lecture de fichiers par morceaux. Malheureusement, cette fonctionnalité n'est pas disponible par défaut dans les solutions C2 que nous avons vues, nous avons donc dû l'implémenter. L'approche que nous avons adoptée pour ce problème consiste à implémenter la lecture par morceaux via l'utilisation de l'interface Beacon Object Files de CobaltStrike, BOF en abrégé. Les BOF sont des programmes C qui s'exécutent sur le beacon non pas comme un exécutable séparé mais comme une partie du beacon déjà en cours d'exécution. Cette interface est extrêmement utile car elle rend les BOF beaucoup plus furtifs puisque tout le code s'exécute en mémoire sans rien écrire sur le disque.
Notre solution BOF est une fonction simple qui prend 4 arguments :

• fileName : Chemin complet du fichier de dump LSASS ou de la ruche du Registre (sur le poste distant)
• buffsize : Quantité (en octets) à lire dans le fichier
• seekSize : Position à partir de laquelle l'opération de lecture doit commencer (depuis le début du fichier)
• rplyid : Numéro d'identification à intégrer dans la réponse pour éviter d'éventuelles collisions

Avec ces paramètres, pypykatz (s'exécutant sur l'agent) peut émettre des opérations de lecture de fichiers sur le beacon (ordinateur cible) qui ciblent spécifiquement certaines parties du fichier.
De l'autre côté (dans CobaltStrike), aggrokatz enregistre un callback pour surveiller chaque message renvoyé par le beacon cible. Si l'en-tête du message correspond à l'en-tête d'une opération de lecture de fichier, il sera traité comme un morceau d'un fichier minidump et sera envoyé à l'analyseur minidump qui transmettra le résultat à pypykatz. Si une lecture supplémentaire est nécessaire, pypykatz émettra une lecture via le lecteur minidump qui enverra une nouvelle commande de lecture sur le beacon via l'interface BOF. Ce processus se répète jusqu'à ce que le fichier soit analysé.

Résultats

Après avoir analysé environ 100 dumps LSASS avec cette méthode, nous pouvons énoncer ce qui suit (taille de morceau utilisée : 20k) :

• Selon la taille du fichier de dump LSASS (nos dumps faisaient entre 40 Mo et 300 Mo), en moyenne tous les secrets pouvaient être extraits en utilisant 3,5 Mo. Notez que ce nombre ne dépend pas de la taille du dump LSASS mais plutôt du nombre de secrets et du nombre de paquets que vous choisissez d'analyser.
• En moyenne, 250 opérations de lecture ont été utilisées pour une analyse réussie.
• Le temps d'analyse ne dépend que de votre configuration jitter/sleep, donc le mesurer est inutile.

Inconvénients

• Pour chaque opération de lecture, un BOF doit être téléchargé sur le beacon. (Nous espérons secrètement que quelqu'un chez CobaltStrike lira cet article et décidera d'implémenter des opérations de lecture de fichiers de base par défaut, afin que nous puissions éviter d'utiliser cette solution).
• Le nombre d'opérations de lecture peut être problématique si vous utilisez un beacon avec un jitter/sleep très élevé.

Remerciements

dcsync - auteur de pycobalt
@anthemtotheego Twitter - Créateur de CredBandit
Nicol Jos @shinepaw - conception du logo