
TUI-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.
[!IMPORTANT]
recurse_trusts/search_forestauthentifizieren sich nur dann bei LDAP in entdeckten Domänen mit den angegebenen Anmeldeinformationen aus der Quelldomäne, wenn die bereitgestellten Anmeldeinformationen entweder einplain passwordoder einNT hashsind; die Verwendung eines TGT zur Ausstellung eines Verweis-Tickets für diesen Zweck ist theoretisch möglich, aber noch nicht implementiert in deradauth-Bibliothek.
Middleware-Ketten von Macmod/ldapx können auch direkt mit flashingestor verwendet werden, um die LDAP-Abfragen im Ingestion-Schritt zu verschleiern, indem die Optionen -f (--ldapx-filter), -a (--ldapx-attrs) und -b (--ldapx-basedn) verwendet werden. Mit -vv werden die rohen Abfragen vor und nach der Verschleierung ebenfalls im Log angezeigt.
Wenn Sie den Remote Collection-Schritt ausführen möchten, überprüfen Sie die aktivierten methods – diese entsprechen in etwa den von SharpHound angebotenen Methoden und können verwendet werden, um bestimmte Sammlungen über RPC oder HTTP umzuschalten.
Die --remote-*-Argumente können verwendet werden, um einen separaten Satz von Anmeldeinformationen für die Remote Collection anzugeben. Wenn nicht angegeben, wird flashingestor versuchen, dieselben Anmeldeinformationen für den Benutzer zu verwenden, die in den Standard-Ingestion-Argumenten (--user, --password, etc.) bereitgestellt wurden.
Ein lokaler Administrator kann auch für die Remote Collection verwendet werden, indem Sie beispielsweise --remote-user Administrator@. angeben, aber die Wirksamkeit dieses Ansatzes hängt davon ab, ob das Konto der integrierte Administrator ist oder nicht, sowie von den Werten der Registrierungsschlüssel FilterAdministratorToken / LocalAccountTokenFilterPolicy. Weitere Einzelheiten zu diesem Verhalten finden Sie unter Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy.
Die Optionen compress_output und cleanup_after_compression können helfen, die Festplattennutzung gering zu halten. Nachdem Sie den endgültigen Dump in Bloodhound geladen haben, können Sie die Dateien unter output/ldap und output/remote manuell löschen, wenn Sie sie nicht benötigen, aber diese Dateien können aufbewahrt werden, um wichtige Informationen nachzuschlagen, ohne die vollständige Sammlung erneut ausführen zu müssen.
[!TIP] Der primäre Zweck der
msgpack-Dateien in den Ordnernoutput/ldapundoutput/remotebesteht darin, als Zwischenformat zu dienen, um die Verantwortlichkeiten für den gesamten Prozess zu trennen, aber diese Dateien können auch als Informationsquelle verwendet werden, indem sie in JSON konvertiert werden – auf diese Weise müssen Sie nicht die rohen Objektattribute oder Remote Collection-Ergebnisse nachschlagen:$ go build ./cmd/ingest2json $ ./ingest2json output/ldap/YOURDOMAIN/SelectedFile.msgpack -o output.jsonEine gute Möglichkeit, diese Dateien zu inspizieren, wäre die Verwendung von JQ/FX oder Ihrer bevorzugten Programmiersprache 🙂
Beiträge sind willkommen, indem Sie ein Issue eröffnen oder einen Pull Request einreichen.
Großer Dank an SpecterOps für BloodHound, SharpHound / SharpHoundCommon und an dirkjanm für BloodHound.py, die die Hauptreferenzen für dieses Tool waren.
Danke an rtpt-erikgeiser & RedTeamPentesting für adauth und an p0dalirius für winacl, beide wirklich nützliche Bibliotheken.
Danke an oiweiwei für go-msrpc, da seine Bibliothek es ermöglichte, Remote Collection-Methoden basierend auf RPCs zu implementieren.
Protected Users ist oder wenn die NTLM-Authentifizierung durch Sicherheitseinstellungen blockiert wird) oder mit Zertifikaten (die unter der Haube PKINIT verwenden) nicht versucht, sich bei Computern von Domänen zu authentifizieren, die sich von der Domäne unterscheiden, zu der der Benutzer gehört. Dies gilt auch für die Methode GPOLocalGroup, die in diesen Fällen keine GPO-Dateien von DCs anderer Domänen lesen wird, selbst wenn mehrere Domänen in den erfassten Daten vorhanden sind.SmbInfo für den Typ Computer ist immer noch eine einfache Implementierung (nur Registry-Prüfungen).HttpEnrollmentEndpoints funktioniert nur mit einem bereitgestellten Benutzernamen/Passwort.AllowedToDelegateTo / ServicePrincipalNames ist immer noch eine einfache Implementierung.Fast alle in SharpHound implementierten Eigenschaften werden unterstützt, aber es gibt viele architektonische Unterschiede zwischen diesem Tool und SharpHound, daher sollte man nicht erwarten, dass die Ausgabe exakt mit der offiziellen Implementierung übereinstimmt (mit Ausnahme eventueller Fehler). Wesentliche Unterschiede können insbesondere bei den komplexeren Implementierungen auftreten, wie z. B. Remote Collections über RPC und Sammlungen im Zusammenhang mit CA/Zertifikatsmissbrauch.
Timeouts sind noch größtenteils statisch – SharpHounds Implementierung verwendet ein adaptives Timeout (ziemlich clever!), aber ich hatte noch keine Zeit, das zu studieren. Passen Sie bei Bedarf die Timeouts mit den Optionen --timeout, --computer-timeout und --method-timeout an (config/config.go gibt andere operationsspezifische Timeouts an).
Tests sind derzeit nicht implementiert und ich habe nur eine kleine Teilmenge der Funktionen manuell getestet.
Die MIT-Lizenz (MIT)
Copyright (c) 2023 Artur Henrique Marzano Gonzaga
Hiermit wird jeder Person, die eine Kopie dieser Software und der zugehörigen Dokumentationsdateien (die "Software") erhält, kostenlos die Erlaubnis erteilt, die Software ohne Einschränkung zu nutzen, einschließlich und ohne Einschränkung der Rechte zur Verwendung, Vervielfältigung, Änderung, Zusammenführung, Veröffentlichung, Verteilung, Unterlizenzierung und/oder zum Verkauf von Kopien der Software, und Personen, denen die Software zur Verfügung gestellt wird, dies zu gestatten, unter den folgenden Bedingungen:
Der obige Urheberrechtshinweis und dieser Genehmigungshinweis müssen in allen Kopien oder wesentlichen Teilen der Software enthalten sein.
DIE SOFTWARE WIRD "WIE BESEHEN" ZUR VERFÜGUNG GESTELLT, OHNE JEGLICHE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE GEWÄHRLEISTUNG, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF DIE GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT, DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND DER NICHTVERLETZUNG VON RECHTEN. IN KEINEM FALL SIND DIE AUTOREN ODER URHEBERRECHTSINHABER HAFTBAR FÜR JEGLICHE ANSPRÜCHE, SCHADENERSATZANSPRÜCHE ODER SONSTIGE HAFTUNG, WEDER AUS EINEM VERTRAG, EINER UNERLAUBTEN HANDLUNG ODER ANDERWEITIG, DIE AUS ODER IN VERBINDUNG MIT DER SOFTWARE ODER DER NUTZUNG ODER ANDEREN GESCHÄFTEN MIT DER SOFTWARE ENTSTEHEN.