macmod/flashingestorCollecteur de données Active Directory basé sur une interface TUI qui ingère des objets LDAP, effectue une collecte distante via RPC/SMB/HTTP et génère des dumps compatibles avec BloodHound CE pour l'analyse des chemins d'attaque.
Un TUI pour la collecte Active Directory.
Les objectifs principaux de ce projet sont :
Flashingestor implémente 3 étapes de base distinctes : Ingestion LDAP, Collecte distante et Conversion, contrairement à d'autres collecteurs qui exécutent les méthodes spécifiées en une seule étape :
Ingest (Ctrl+l) - Collecte les données brutes des attributs d'objets depuis LDAP et les stocke sous output/ldap dans des fichiers msgpack intermédiaires. Les requêtes peuvent être personnalisées dans config.yaml.
Remote (Ctrl+r) - Lit ces fichiers intermédiaires en mémoire, calcule la liste des ordinateurs à collecter et effectue une série de requêtes RPC/SMB/HTTP pour obtenir les informations distantes pertinentes pour les objets Computer et EnterpriseCA, qui sont stockés sous output/remote.
Convert (Ctrl+s) - Lit les fichiers intermédiaires en mémoire, fusionne les informations des étapes d'ingestion et de collecte distante, et génère un dump compatible avec Bloodhound sous output/bloodhound - cette étape est entièrement hors ligne.
Pour plus de détails techniques et d'informations, consultez notre 📖 Wiki.
$ git clone https://github.com/Macmod/flashingestor
$ cd flashingestor
# To build only:
$ go build ./cmd/flashingestor
# To install the executable to $GOBIN or $GOPATH/bin:
$ go install ./cmd/flashingestor
[!NOTE] Vous pouvez également utiliser les binaires pré-construits depuis les Releases proposées.
Authentifiez-vous d'abord avec l'une des méthodes suivantes :
# Anonymous
# [Requires dSHeuristics of 0000002 in the DirectoryServices object
# and can have limited visibility due to lack of Read ACEs]
$ ./flashingestor -u '@<DOMAIN>' -p '' [...]
# User + Password
$ ./flashingestor -u <USER>@<DOMAIN> -p <PASSWORD> [-k] [...]
# User + NTHash
$ ./flashingestor -u <USER>@<DOMAIN> -H <NTHASH> [-k] [...]
# User + PFX
$ ./flashingestor -u <USER>@<DOMAIN> --pfx <PFXPATH> [--pfx-password <PFXPASS>] [-k] [...]
# User + PEM
$ ./flashingestor -u <USER>@<DOMAIN> --cert <PEMPATH> --key <KEYPATH> [-k] [...]
# User + AESKey
$ ./flashingestor -u <USER>@<DOMAIN> --aes-key <AESKEY> -k [...]
# User + Ticket
$ ./flashingestor -u <USER>@<DOMAIN> --ccache /path/to/ticket.ccache -k [...]
or
$ KRB5CCNAME=/path/to/ticket.ccache ./flashingestor -u <USER>@<DOMAIN> -k [...]
Exécutez ensuite les étapes comme souhaité. Pour une collecte uniquement LDAP (DCOnly à l'exception de GPOLocalGroup et CertServices), exécutez simplement Ctrl+l, vérifiez si l'ingestion a réussi, puis exécutez Ctrl+s pour générer le dump final.
Il est recommandé de spécifier --dc et --dns pour exécuter flashingestor. Si vous ne spécifiez pas --dc, flashingestor tentera de le trouver avec des requêtes SRV / A, ce qui peut retarder l'étape initiale Ingest.
Vous devez alors spécifier --dns si votre serveur DNS standard ne connaît pas le domaine - lorsque le DNS intégré à AD est utilisé, pointez simplement --dns vers le DC qui l'héberge.
De plus, indépendamment de --dc, si vous voulez exécuter l'étape Collecte distante et que votre serveur DNS ne connaît pas les ordinateurs du domaine, vous devez spécifier --dns pour les requêtes.
[!TIP] Dans des environnements avec plusieurs DC, vous pouvez également utiliser l'utilitaire
dcprobepour évaluer la latence vers tous les DC et trouver un bon candidat cible pour l'ingestion :$ go build ./cmd/dcprobe $ ./dcprobe --dns 192.168.88.6 -d creta.local -r 10
Si le fichier de configuration n'est pas présent dans le répertoire courant sous le nom config.yaml ou dans le chemin fourni via --config, les options par défaut (les mêmes que dans le config.yaml fourni) seront utilisées - elles sont codées en dur dans config/fallback.go. Pour plus d'informations, lisez Fichier de configuration.
Envisagez d'utiliser --log pour spécifier un fichier de sortie pour les logs (au cas où vous auriez besoin de les consulter après avoir fermé le TUI) et -vv pour voir les messages de log de débogage, car ceux-ci peuvent aider à résoudre les éventuels problèmes. Pour une référence complète des arguments en ligne de commande, lisez Arguments en ligne de commande.
[!NOTE] Les requêtes par défaut dans le
config.yamlfourni sont conçues avec les informations nécessaires à la conversion Bloodhound. Vous pouvez choisir de personnaliser les requêtes ou attributs dansconfig.yaml, mais il est préférable d'éviter de supprimer les attributs nécessaires et de ne pas modifier la signification des filtres de recherche.
Si recurse_trusts est défini sur true, il ingérera tous les domaines approuvés trouvés de manière récursive avec les informations d'identification initiales fournies pour l'ingestion.
Si search_forest est défini sur true, il ingérera les domaines qui font partie de la même forêt que le domaine initial à partir de la partition Configuration - aucune requête supplémentaire ne sera effectuée, car cela fait déjà partie du plan d'ingestion par défaut.
Les deux options peuvent être définies en même temps, et flashingestor n'ingérera chaque domaine trouvé qu'une seule fois (soit via une approbation, soit via la forêt actuelle).
Si recurse_trusts est activé et que recurse_feasible_only est également défini sur true, il n'essaiera d'ingérer un domaine approuvé que si l'approbation est :
Cela signifie que les approbations sortantes uniquement ne seront pas parcourues, et en dehors du premier niveau d'approbations, les chemins d'ingestion s'arrêtent aux approbations non transitives - si B approuve A de manière non transitive, alors A peut encore s'authentifier auprès de B ; mais si C approuve également B de manière non transitive, alors A ne peut pas s'authentifier auprès de C.
[!IMPORTANT]
recurse_trusts/search_forestne s'authentifieront auprès de LDAP dans les domaines découverts qu'avec les informations d'identification spécifiées depuis le domaine source lorsque les informations fournies sont soit unmot de passe en clair, soit unNT hash; l'utilisation d'un TGT pour émettre un ticket de renvoi à cette fin est théoriquement possible mais pas encore implémenté dans la bibliothèqueadauth.
Les chaînes de middleware de Macmod/ldapx peuvent également être utilisées directement avec flashingestor pour obfusquer les requêtes LDAP lors de l'étape d'ingestion en utilisant les options -f (--ldapx-filter), -a (--ldapx-attrs) et -b (--ldapx-basedn). Avec -vv, les requêtes brutes avant et après obfuscation seront également affichées dans le journal.
Si vous avez l'intention d'exécuter l'étape de collecte distante, vérifiez les methods activées - celles-ci correspondent approximativement aux méthodes offertes par SharpHound et peuvent être utilisées pour activer/désactiver des collectes spécifiques via RPC ou HTTP.
Les arguments --remote-* peuvent être utilisés pour spécifier un jeu d'informations d'identification distinct pour la collecte distante. S'ils ne sont pas spécifiés, flashingestor essaiera d'utiliser les mêmes informations d'identification pour l'utilisateur fourni dans les arguments standard d'ingestion (--user, --password, etc).
Un administrateur local peut également être utilisé pour la collecte distante en spécifiant --remote-user Administrator@., par exemple, mais l'efficacité de cette approche dépendra du fait que le compte soit l'administrateur intégré ou non, et des valeurs des clés de registre FilterAdministratorToken / LocalAccountTokenFilterPolicy. Pour plus de détails sur ce comportement, référez-vous à Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy.
Les options compress_output et cleanup_after_compression peuvent aider à maintenir une faible utilisation du disque. Après avoir chargé le dump final dans Bloodhound, vous pouvez supprimer en toute sécurité les fichiers sous output/ldap et output/remote manuellement si vous n'en avez pas besoin, mais ces fichiers peuvent être conservés pour rechercher des informations importantes sans avoir à relancer la collecte complète.
[!TIP] Le but principal des fichiers
msgpacksous les dossiersoutput/ldapetoutput/remoteest de servir de format intermédiaire pour séparer les responsabilités de l'ensemble du processus, mais ces fichiers peuvent également être utilisés comme source d'informations en les convertissant en JSON - de cette façon, vous n'avez pas à rechercher les attributs bruts des objets ou les résultats de la collecte distante :$ go build ./cmd/ingest2json $ ./ingest2json output/ldap/YOURDOMAIN/SelectedFile.msgpack -o output.jsonUne bonne façon d'inspecter ces fichiers serait d'utiliser JQ/FX, ou votre langage de programmation préféré 🙂
Les contributions sont les bienvenues en ouvrant une issue ou en soumettant une pull request.
Un grand merci à SpecterOps pour BloodHound, SharpHound / SharpHoundCommon et à dirkjanm pour BloodHound.py, qui ont été les principales références pour cet outil.
Merci à rtpt-erikgeiser & RedTeamPentesting pour adauth et à p0dalirius pour winacl, deux bibliothèques très utiles.
Merci à oiweiwei pour go-msrpc, car sa bibliothèque a permis d'implémenter les méthodes de collecte distante basées sur RPC.
Protected Users ou que l'authentification NTLM est bloquée via les paramètres de sécurité) ou avec des certificats (qui utilise PKINIT en interne), la collecte distante n'essaiera pas de s'authentifier auprès des ordinateurs de domaines différents de celui auquel l'utilisateur appartient. Cela s'applique également à la méthode GPOLocalGroup, qui dans ces cas n'essaiera pas de lire les fichiers GPO des DC d'autres domaines, même s'il y a plusieurs domaines dans les données ingérées.SmbInfo pour le type Computer est encore une implémentation basique (vérifications du registre uniquement).HttpEnrollmentEndpoints ne fonctionne qu'avec un nom d'utilisateur/mot de passe fourni.AllowedToDelegateTo / ServicePrincipalNames est encore une implémentation basique.Presque toutes les propriétés implémentées dans SharpHound sont prises en charge, mais il existe de nombreuses différences architecturales entre cet outil et SharpHound, donc ne vous attendez pas à ce que la sortie corresponde exactement à l'implémentation officielle (à l'exception d'éventuels bogues). Des différences clés peuvent apparaître surtout pour les implémentations les plus complexes, comme les collectes distantes via RPC et les collectes liées à l'abus de CA/certificats.
Les délais d'attente sont encore principalement statiques - l'implémentation de SharpHound utilise un délai d'attente adaptatif (assez intelligent !), mais je n'ai pas encore eu le temps d'étudier cela. Si nécessaire, personnalisez les délais d'attente avec les options --timeout, --computer-timeout et --method-timeout (config/config.go spécifie d'autres délais d'attente spécifiques aux opérations).
Les tests ne sont actuellement pas implémentés et je n'ai testé qu'un petit sous-ensemble de fonctionnalités manuellement.
The MIT License (MIT)
Copyright (c) 2023 Artur Henrique Marzano Gonzaga
La permission est accordée par la présente, gratuitement, à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le « Logiciel »), de traiter le Logiciel sans restriction, y compris sans limitation les droits d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et/ou vendre des copies du Logiciel, et de permettre aux personnes à qui le Logiciel est fourni de le faire, sous réserve des conditions suivantes :
L'avis de copyright ci-dessus et cet avis d'autorisation doivent être inclus dans toutes les copies ou parties substantielles du Logiciel.
LE LOGICIEL EST FOURNI « EN L'ÉTAT », SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER LES GARANTIES DE QUALITÉ MARCHANDE, D'ADÉQUATION À UN USAGE PARTICULIER ET D'ABSENCE DE CONTREFAÇON. EN AUCUN CAS, LES AUTEURS OU TITULAIRES DU COPYRIGHT NE SERONT RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGE OU AUTRE RESPONSABILITÉ, QUE CE SOIT DANS LE CADRE D'UNE ACTION CONTRACTUELLE, DÉLICTUELLE OU AUTRE, DÉCOULANT DE OU EN RELATION AVEC LE LOGICIEL OU L'UTILISATION OU D'AUTRES TRANSACTIONS DANS LE LOGICIEL.