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.