nvisosecurity/pycobalthoundpyCobaltHound est une extension de script Aggressor pour Cobalt Strike qui vise à fournir une intégration profonde entre Cobalt Strike et Bloodhound.
pyCobaltHound est une extension de script Aggressor pour Cobalt Strike qui vise à fournir une intégration profonde entre Cobalt Strike et Bloodhound.
pyCobaltHound s'efforce d'aider les opérateurs red team en :
BloodHound pour découvrir les chemins d'escalade ouverts par des identifiants nouvellement collectés.Pour y parvenir, pyCobaltHound utilise un ensemble de requêtes intégrées. Les opérateurs peuvent également ajouter/supprimer leurs propres requêtes pour affiner les capacités de surveillance de pyCobaltHound. Cela leur offre la flexibilité d'adapter à la volée pendant les engagements pour tenir compte de cibles spécifiques à l'engagement (utilisateurs, hôtes, etc.).
pyCobaltHoundPour installer pyCobaltHound, clonez ce dépôt. N'oubliez pas de cloner également le sous-module inclus !
Vous pouvez utiliser la commande suivante :
git clone https://github.com/NVISOsecurity/pyCobaltHound.git --recurse-submodulesAssurez-vous que les dépendances suivantes sont correctement installées :
PyCobalt est une API Python pour Cobalt Strike. Elle expose de nombreuses fonctions Aggressor pour être utilisées directement depuis Python.
Assurez-vous d'avoir Python3+ installé. Bien que PyCobalt puisse fonctionner sur macOS et Windows également, nous ne l'avons vraiment testé que sur Linux.
Il existe deux façons d'utiliser la bibliothèque Python PyCobalt :
pyCobaltHound adopte cette approche, en définissant le chemin de recherche depuis le programme Python à l'aide de la variable sys.path variable.PyCobalt. Pour ce faire, exécutez python3 setup.py install. Vous devrez modifier pycobalthound.py pour vous assurer qu'il utilise la bibliothèque installée au lieu de celle du dépôt inclus.PyCobalt sera maintenu à l'avenir. En fait, la dernière mise à jour du projet visait à incorporer les modifications apportées dans Cobalt Strike 4.2. Cependant, comme pyCobaltHound n'utilise que des fonctions Aggressor de base pour s'interfacer avec Cobalt Strike et son opérateur, ce n'est pas un gros problème pour pyCobaltHound.PyCobalt utilisé dans ce projet est un fork réalisé par nos soins. Cependant, nous ne contrôlons pas le dépôt PyCobalt.PyCobalt est livré avec quelques commandes de la console de script pour gérer les scripts Python en cours d'exécution. Lorsque vous rechargez votre script Aggressor, vous devez d'abord arrêter explicitement les scripts Python. Sinon, ils tourneront indéfiniment sans rien faire. Pendant le développement de pyCobaltHound, nous avons remarqué que cela pouvait également conduire à un comportement indéfini.
Le rechargement de pyCobaltHound peut être effectué comme suit :
aggressor> python-stop-all`
[pycobalt] Asking script to stop: /root/pycobalthound/pycobalthound.py
[pycobalt] Script process exited: /root/pycobalthound/pycobalthound.py
aggressor> reload example.cna`
[pycobalt] Executing script /root/pycobalthound/pycobalthound.py
Pour que PyCobalt fonctionne correctement, vous ne pouvez appeler PyCobalt que dans un seul script Aggressor. Gardez cela à l'esprit si vous souhaitez utiliser pyCobaltHound avec d'autres scripts Aggressor qui utilisent PyCobalt. Notre approche consiste à avoir un script Aggressor avec des appels à python() et include() pour chaque outil basé sur PyCobalt.
notify2 est - ou était - un paquet pour afficher des notifications de bureau sur Linux. Comme nous le verrons plus tard, pyCobaltHound prend en charge plusieurs façons de notifier l'opérateur. notify2 est utilisé sur Linux pour envoyer des notifications au démon de notification via D-Bus.
Pour activer cela, notify2 doit être installé en utilisant :
pip install notify2
Utiliser pyCobaltHound dans Cobalt Strike est aussi simple que d'importer le script Aggressor pycobalthound.cna dans votre client. Une fois cela fait, vous devriez voir un menu pyCobaltHound apparaître dans votre barre de menus Cobalt Strike.
L'objectif initial de pyCobaltHound était de surveiller le cache d'identifiants de Cobalt Strike (View > Credentials) pour détecter les nouvelles entrées. Il le fait en réagissant à l'événement on_credentials que Cobalt Strike déclenche lors des modifications du magasin d'identifiants.
Lorsque cet événement est déclenché, pyCobaltHound va :
Cobalt StrikeBloodHoundBloodHound pour chaque nouvelle entité en utilisant à la fois les requêtes intégrées et personnalisées.Comme tout cela se produit de manière asynchrone par rapport au client principal Cobalt Strike, ce processus ne devrait pas bloquer votre interface utilisateur, vous pouvez donc continuer à travailler pendant que pyCobaltHound enquête en arrière-plan.
pyCobaltHound utilise des caches séparés par teamserver pour éviter les problèmes lors de l'utilisation de plusieurs teamservers.
Il existe parfois des situations où vous souhaiteriez enquêter à nouveau sur des utilisateurs spécifiques (ou l'ensemble du magasin d'identifiants). Cela peut être le cas lorsque vous avez téléchargé de nouvelles données dans la base de données BloodHound.
Comme pyCobaltHound a déjà dû enquêter (et donc mettre en cache) toutes les entités de votre magasin d'identifiants, il ne les évaluera pas par rapport à ces nouvelles données sans une intervention de l'opérateur.
Deux méthodes sont disponibles pour les opérateurs afin de contrôler quelles entités sont mises en cache.
Dans les cas où vous souhaitez supprimer une entité spécifique (ou plusieurs) du cache, vous pouvez le faire dans le visualiseur d'identifiants (View > Credentials). Sélectionnez simplement votre(vos) cible(s) et cliquez sur l'option remove from cache sous l'entrée de menu pyCobaltHound.
Dans les cas où vous souhaitez supprimer toutes les entités du cache, vous pouvez le faire dans le menu principal de pyCobaltHound (Cobalt Strike > pyCobaltHound > Wipe cache). C'est très utile lorsque vous souhaitez réévaluer l'ensemble de votre magasin d'identifiants.
Après avoir supprimé vos cibles du cache, vous pouvez demander manuellement à pyCobaltHound de ré-enquêter sur le contenu du magasin d'identifiants. Cela suit exactement le même processus que ci-dessus.
pyCobaltHound contient des fonctionnalités pour interagir avec les sessions beacon existantes. Cela se trouve dans le menu contextuel du beacon. Notez que ces commandes peuvent être exécutées sur un seul beacon ou une sélection de beacons.
Cette fonctionnalité est particulièrement utile lorsqu'il s'agit d'utilisateurs et d'ordinateurs dont les identifiants n'ont pas encore été compromis, mais qui sont effectivement sous notre contrôle (par exemple parce que nous avons un beacon fonctionnant sous leur jeton de session).
La fonctionnalité Mark as owned (pyCobaltHound > Mark as owned) peut être utilisée pour marquer un beacon (ou une collection de beacons) comme possédé dans la base de données BloodHound.
Cette boîte de dialogue demandera à l'opérateur les informations suivantes :
pyCobaltHound ne marquera les ordinateurs comme possédés que si la session beacon s'exécute en tant qu'administrateur local, SYSTEM ou une session de haute intégrité en tant qu'un autre utilisateur.La fonctionnalité Investigate (pyCobaltHound > Mark as owned) peut être utilisée pour enquêter sur les utilisateurs et les hôtes associés à un beacon (ou une collection de beacons).
Cette boîte de dialogue demandera à l'opérateur les informations suivantes :
pyCobaltHound n'examinera les ordinateurs que si la session beacon s'exécute en tant qu'administrateur local, SYSTEM ou une session de haute intégrité en tant qu'un autre utilisateur.pyCobaltHound examinera toutes les entités sans vérifier les niveaux d'intégrité.pyCobaltHound contient des fonctionnalités pour enquêter librement sur des entités. Cela se trouve dans le menu principal (Cobalt Strike > pyCobaltHound > Investigate).
Cette fonctionnalité est particulièrement utile lorsqu'il s'agit d'utilisateurs et d'ordinateurs dont les identifiants n'ont pas été compromis et qui ne sont pas sous notre contrôle.
Cette boîte de dialogue demandera à l'opérateur les informations suivantes :
Le menu des paramètres de pyCobaltHound se trouve sous Cobalt Strike > pyCobaltHound > Settings.
pyCobaltHound sauvegardera vos paramètres sur le disque. Chaque fois que pyCobaltHound est rechargé, il vérifiera l'existence d'un fichier de paramètres et chargera les paramètres sauvegardés s'il en trouve un.
pyCobaltHound sauvegarde un fichier de paramètres par teamserver, il est donc possible d'avoir des paramètres différents sur différents teamservers.
Pour s'authentifier à la base de données BloodHound, pyCobaltHound aura besoin des informations suivantes :
Note : si vous choisissez de sauvegarder vos paramètres de manière persistante (pour les conserver lors des redémarrages du client/hôte), pyCobaltHound désérialisera et stockera ces identifiants sur le disque.
Comme discuté précédemment, pyCobaltHound utilise un cache pour s'assurer de ne pas effectuer de travail inutile. Ce cache peut être désactivé dans les paramètres. C'est surtout utile lors du développement de nouvelles requêtes pour ne pas avoir à gérer/vider le cache constamment.
pyCobaltHound prend en charge plusieurs méthodes de notification de l'opérateur lorsqu'il a identifié une entité d'intérêt. Il est possible de désactiver ces notifications.
Par défaut, pyCobaltHound notifiera l'opérateur en utilisant la boîte de message Aggressor par défaut. Cette option peut le flux de travail de l'opérateur. C'est cependant la méthode par défaut car elle est prise en charge sur chaque plateforme où vous pouvez exécuter un client Cobalt Strike.
pyCobaltHound prend également en charge l'affichage de notifications de bureau sur Linux. C'est notre option préférée car elle n'interrompt pas le flux de travail de l'opérateur.
Lors de certains de ses flux de travail, pyCobaltHound générera un rapport HTML. Ce choix de conception a été fait pour éviter de spammer l'opérateur avec des notifications géantes dans le cas où beaucoup d'entités étaient examinées. Ces rapports seront générés dans le dossier reports. Il est possible de désactiver la génération de rapports.
Par défaut, pyCobaltHound synchronisera les requêtes entre les teamservers en utilisant un fichier central pour tous les paramètres liés aux requêtes. Cela signifie que les requêtes activées, ajoutées ou supprimées sur un teamserver seront également activées, ajoutées, supprimées pour les requêtes faites par d'autres teamservers. C'est surtout une option de commodité et peut être désactivée, ce qui est utile dans les cas où vous exécutez des requêtes spécifiques à un engagement qui ne s'appliquent pas à tous les teamservers auxquels vous êtes connecté.
Lorsque la synchronisation des requêtes est désactivée, pyCobaltHound vérifiera l'existence de fichiers de requêtes uniques. S'ils existent, il les chargera et utilisera ces requêtes lors de ses flux de travail. Si les fichiers n'existent pas, il les créera et les chargera. Ce paramètre persistera après les rechargements.
Lorsque la synchronisation des requêtes est activée, pyCobaltHound vérifiera l'existence de fichiers de requêtes uniques. S'ils existent, l'opérateur sera invité à faire un choix.
L'opérateur a les choix suivants :
pyCobaltHound supprimera simplement les fichiers de requêtes uniques. Toutes les requêtes personnalisées seront perdues.pyCobaltHound tentera de fusionner les fichiers de requêtes uniques dans les fichiers de requêtes généraux. Avant de fusionner une requête, il vérifiera s'il n'y a pas de requête dans le fichier général portant le même nom ou la même instruction Cypher. En cas de conflit de fusion, l'opérateur sera invité à savoir s'il souhaite conserver les requêtes non fusionnées. Elles seront sauvegardées dans un fichier séparé. Les fichiers de requêtes uniques seront ensuite supprimés.pyCobaltHound laissera simplement les fichiers de requêtes uniques. Toutes les requêtes personnalisées seront préservées et les fichiers seront rechargés si la synchronisation des requêtes est à nouveau désactivée.pyCobaltHound prend actuellement en charge les requêtes intégrées suivantes :
La gestion des différentes requêtes que pyCobaltHound utilise peut être effectuée via le menu principal (Cobalt Strike > pyCobaltHound > Queries).
La boîte de dialogue Update queries permet aux opérateurs d'activer/désactiver des requêtes spécifiques. Lors de l'utilisation de cette boîte de dialogue, l'opérateur sera d'abord invité à indiquer quel type de requêtes il souhaite mettre à jour. Cela est fait pour afficher/charger dynamiquement les bonnes requêtes au cours de ce flux de travail.
Après avoir répondu à la première boîte de dialogue, l'opérateur se verra présenter une liste de toutes les requêtes disponibles de ce type. Il peut alors choisir les requêtes qu'il souhaite activer/désactiver.
L'option de type de requête est un contournement laid pour passer le type de requête à la fonction suivante du flux de travail et ne concerne pas l'opérateur.
La fonctionnalité Add query permet aux opérateurs d'ajouter/supprimer leurs propres requêtes pour affiner les capacités d'enquête de pyCobaltHound. Cela leur offre la flexibilité d'adapter pyCobaltHound à la volée pendant les engagements pour tenir compte de cibles spécifiques à l'engagement (utilisateurs, hôtes, etc.).
Cette boîte de dialogue demandera à l'opérateur les informations suivantes :
pyCobaltHound.pyCobaltHound doit exécuter. Les opérateurs sont assez libres de définir leurs requêtes. Les seules exigences sont les suivantes :
pyCobaltHound génère dynamiquement la chaîne Cypher suivante en fonction des noms d'entités qu'il examine :
WITH [account names here] AS samAccountNames UNWIND samAccountNames AS names.MATCH (x) WHERE x.name STARTS WITH names(x:User)) selon le type de requête que vous ajoutez.pyCobaltHound attend que la requête retourne un ensemble distinct de noms d'utilisateurs.
RETURN DISTINCT (x.name)pyCobaltHound utilise pour la requête personnalisée. Il sera utilisé dans les notifications et les rapports lors des flux de travail de pyCobaltHound.
pyCobaltHound remplacera par le nombre de résultats pour cette requête.La boîte de dialogue Delete query permet aux opérateurs de supprimer des requêtes personnalisées spécifiques de pyCobaltHound. Lors de l'utilisation de cette boîte de dialogue, l'opérateur sera d'abord invité à indiquer quel type de requête il souhaite supprimer. Cela est fait pour afficher/charger dynamiquement les bonnes requêtes au cours de ce flux de travail.
Après avoir répondu à la première boîte de dialogue, l'opérateur se verra présenter une liste de toutes les requêtes disponibles de ce type. Il peut alors choisir les requêtes qu'il souhaite supprimer.
L'option de type de requête est un contournement laid pour passer le type de requête à la fonction suivante du flux de travail et ne concerne pas l'opérateur.
pyCobaltHound utilise/s'inspire de ce qui suit :