macmod/flashingestorTUI-basierter Active Directory-Datensammler, der LDAP-Objekte aufnimmt, entfernte RPC/SMB/HTTP-Sammlungen durchführt und BloodHound CE-kompatible Dumps für Angriffspfadanalyse erzeugt.
Eine TUI für die Active Directory-Sammlung.
Die Hauptziele dieses Projekts sind:
Flashingestor implementiert 3 grundlegende separate Schritte: LDAP Ingestion, Remote Collection und Conversion, im Gegensatz zu anderen Collectors, die die angegebenen Methoden in einem einzigen Schritt ausführen:
Ingest (Ctrl+l) – Sammelt Rohdaten von Objektattributen aus LDAP und speichert sie unter output/ldap in intermediate msgpack-Dateien. Abfragen können in config.yaml angepasst werden.
Remote (Ctrl+r) – Liest diese intermediate Dateien in den Speicher, berechnet die Liste der zu sammelnden Computer und führt eine Reihe von RPC/SMB/HTTP-Anfragen durch, um relevante Remote-Informationen für Computer- und EnterpriseCA-Objekte zu erhalten, die unter output/remote gespeichert werden.
Convert (Ctrl+s) – Liest die intermediate Dateien in den Speicher, führt Informationen aus den Schritten Ingestion und Remote Collection zusammen und erzeugt einen Bloodhound-kompatiblen Dump unter output/bloodhound – dieser Schritt erfolgt vollständig offline.
Für weitere technische Details und Einblicke besuchen Sie unser 📖 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] Sie können auch vorgefertigte Binärdateien aus den bereitgestellten Releases verwenden.
Authentifizieren Sie sich zunächst mit einer der folgenden Methoden:
# 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 [...]
Führen Sie dann die Schritte nach Bedarf aus. Für eine reine LDAP-Sammlung (DCOnly mit Ausnahme von GPOLocalGroup und CertServices) führen Sie einfach Ctrl+l aus, prüfen Sie, ob die Ingestion erfolgreich war, und führen Sie dann Ctrl+s aus, um den endgültigen Dump zu generieren.
Es wird empfohlen, --dc und --dns für die Ausführung von flashingestor anzugeben. Wenn Sie --dc nicht angeben, wird flashingestor versuchen, es mit SRV-/A-Abfragen zu finden, was den ersten Ingest-Schritt verzögern kann.
Sie müssen dann --dns angeben, wenn Ihr Standard-DNS-Server die Domain nicht kennt – wenn AD-integriertes DNS verwendet wird, zeigen Sie einfach mit --dns auf den DC, der es hostet. Zusätzlich, unabhängig von --dc, wenn Sie den Remote Collection-Schritt ausführen möchten und Ihr DNS-Server die Computer in der Domain nicht kennt, müssen Sie --dns für die Lookups angeben.
[!TIP] In Umgebungen mit mehreren DCs können Sie auch das Dienstprogramm
dcprobeverwenden, um die Latenz zu allen DCs zu messen und einen guten Zielkandidaten für die Ingestion zu finden:$ go build ./cmd/dcprobe $ ./dcprobe --dns 192.168.88.6 -d creta.local -r 10
Wenn die Konfigurationsdatei nicht im aktuellen Verzeichnis als config.yaml oder im über --config angegebenen Pfad vorhanden ist, werden die Standardoptionen (dieselben wie in der bereitgestellten config.yaml) angenommen – sie sind in config/fallback.go hartcodiert. Weitere Informationen finden Sie unter Configuration File.
Erwägen Sie die Verwendung von --log, um eine Ausgabedatei für Logs anzugeben (falls Sie diese nach dem Schließen der TUI überprüfen müssen) und -vv, um Debug-Log-Nachrichten zu sehen, da diese bei der Fehlersuche helfen können. Eine vollständige Referenz der Befehlszeilenargumente finden Sie unter Command-Line Arguments.
[!NOTE] Die Standardabfragen in der bereitgestellten
config.yamlsind im Hinblick auf die für die Bloodhound-Konvertierung benötigten Informationen konzipiert. Sie können Abfragen oder Attribute inconfig.yamlanpassen, aber es ist am besten, zu vermeiden, benötigte Attribute zu entfernen und die Bedeutung der Suchfilter zu ändern.
Wenn recurse_trusts auf true gesetzt ist, werden alle gefundenen vertrauenswürdigen Domänen rekursiv mit den für die Ingestion bereitgestellten Anmeldeinformationen erfasst.
Wenn search_forest auf true gesetzt ist, werden Domänen erfasst, die Teil des gleichen Forests wie die anfängliche Domäne aus der Configuration-Partition sind – es werden keine zusätzlichen Abfragen durchgeführt, da dies bereits Teil des standardmäßigen Ingestion-Plans ist. Beide Optionen können gleichzeitig gesetzt werden, und flashingestor wird jede gefundene Domäne nur einmal erfassen (entweder über eine Vertrauensstellung oder über den aktuellen Forest).
Wenn recurse_trusts aktiviert ist und recurse_feasible_only ebenfalls auf true gesetzt ist, wird nur dann versucht, eine vertrauenswürdige Domäne zu erfassen, wenn die Vertrauensstellung:
Das bedeutet, dass reine Outbound-Vertrauensstellungen nicht durchlaufen werden, und abgesehen von der ersten Ebene der Vertrauensstellungen enden die Ingestion-Pfade bei nichttransitiven Vertrauensstellungen – wenn B A nichttransitiv vertraut, kann A sich immer noch bei B authentifizieren; aber wenn C auch B nichttransitiv vertraut, kann A sich nicht bei C authentifizieren.