flashingestor

A TUI for Active Directory collection.

Philosophy

The main goals of this project are:

1. Be a full data ingestor compatible with BloodHound CE (Community Edition)
2. Be faster, less noisy, and more customizable than other collectors
3. Provide a friendly TUI (terminal user interface) with progress tracking

Demo

Implementation Details

Flashingestor implements 3 basic separate steps LDAP Ingestion, Remote Collection and Conversion, contrary to other collectors which run the specified methods in a single step:

• Ingest (Ctrl+l) - Collects raw object attributes' data from LDAP and stores that under output/ldap into intermediate msgpack files. Queries can be customized in config.yaml.

• Remote (Ctrl+r) - Reads these intermediate files into memory, computes the list of computers to collect, and performs a series of RPC/SMB/HTTP requests to obtain relevant remote information for Computer and EnterpriseCA objects, which are stored under output/remote.

• Convert (Ctrl+s) - Reads the intermediate files into memory, merges information from the ingestion and remote collection steps, and generates a Bloodhound-compatible dump under output/bloodhound - this step is entirely offline.

For more technical details and insights, check our 📖 Wiki.

Installation

$ 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] You can also use pre-built binaries from the provided Releases.

Usage

First authenticate with one of the following:

# 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 [...]

Then run the steps as desired. For an LDAP-only collection (DCOnly with exception of GPOLocalGroup and CertServices), just run Ctrl+l, check whether the ingestion succeeded, and then run Ctrl+s to generate the final dump.

DC discovery & DNS

Specifying --dc and --dns to run flashingestor is recommended. If you don't specify --dc, flashingestor will try to find it with SRV / A lookups, which may delay the initial Ingest step.

You must then specify --dns if your standard DNS server is not aware of the domain - when AD-integrated DNS is in use, just point --dns to the DC that hosts it. Additionally, regardless of --dc, if you want to run the Remote Collection step and your DNS server is not aware of computers in the domain, then you must specify --dns for the lookups.

[!TIP] In environments with multiple DCs, you can also use the dcprobe utility to benchmark the latency to all DCs and find a good target candidate for the ingestion:

$ go build ./cmd/dcprobe
$ ./dcprobe --dns 192.168.88.6 -d creta.local -r 10

Config file

If the config file is not present under the current directory as config.yaml or in the path provided via --config, the default options (the same as in the provided config.yaml) will be assumed - they are hardcoded in config/fallback.go. For more information, read Configuration File.

Other Options

Consider using --log to specify an output file for logs (in case you will need to review them after closing the TUI) and -vv to see debug log messages, as these may help troubleshoot possible issues. For a full reference of command-line arguments, read Command-Line Arguments.

Ingestion

[!NOTE] The default queries in the provided config.yaml are designed with information needed by Bloodhound conversion in mind. You may choose to customize queries or attributes in config.yaml, but it's best to try to avoid removing needed attributes, and to avoid changing the meaning of the search filters.

If recurse_trusts is set to true, it will ingest any trusted domains found recursively with the initial credential provided for ingestion.

If search_forest is set to true, it will ingest domains that are part of the same forest as the initial domain from the Configuration partition - no additional queries will be issued, as this is already part of the default ingestion plan. Both options can be set at the same time, and flashingestor will only ingest any domain found once (either via a trust, or via the current forest).

If recurse_trusts is enabled and recurse_feasible_only is also set to true, it will only try to ingest a trusted domain if the trust is:

1. Inbound/bidirectional and
2. The trust either involves the initial domain, or is transitive.

This means outbound-only trusts will not be traversed, and apart from the first level of trusts, the ingestion paths stop at nontransitive trusts - if B trusts A nontransitively, then A can still authenticate into B; but if C also trusts B nontransitively, then A can't authenticate to C.

[!IMPORTANT] recurse_trusts / search_forest will only authenticate to LDAP in discovered domains with the specified credentials from the source domain when the provided credentials are either plain password or an NT hash; using a TGT to issue a referral ticket for this purpose is theoretically possible but not yet implemented in the adauth library.