flashingestor - A TUI for Active Directory collection.

项目说明

<p align="center">
<h1 align="center"><b>flashingestor</b></h1>
<p align="center"><i>A TUI for Acti collection.</i></p>
<p align="center">
<img src=" alt="GitHub Release">
<img src=" alt="Go ">
<img src=" alt="Code Size">
<img src=" alt="License">
<img src=" alt="Build Status">
<a href=" src=" alt="Go Report Card"></a>
<img src=" alt="GitHub Downloads">
<a href=" alt="Twitter Follow" src="
</p>
</p>

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

<a href=" target="_blank"><img src=" /></a>

Implementation Details

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

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

Installation

> [!NOTE]
> You can also use pre-built binaries from the provided Releases.

Usage

First authenticate with one of the following:

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 en 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:
>

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 con 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 in the initial domain, or is transitive.

This means outbound-only trusts will not be tra, and apart from the first level of trusts, the ingestion paths stop at nontransiti - 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.

Middleware chains from Macmod/ldapx can also be used directly with flashingestor to obfuscate the LDAP queries in the ingestion step by using the -f (--ldapx-filter), -a (--ldapx-attrs) and -b (--ldapx-basedn) options. With -vv, the raw queries before and after obfuscation will also be shown in the log.

Remote Collection

If you intend to run the remote collection step, check the enabled methods - these roughly correspond to the methods offered by SharpHound and can be used to toggle specific collections via RPC or HTTP.

The --remote-* arguments can be used to specify a separate set of credentials for remote collection. If not specified, flashingestor will try to use the same credentials for the user provided in the standard ingestion arguments (--user, --password, etc).

A local admin can also be used for remote collection by specifying --remote-user Administrator@., for example, but the effecti of this approach will depend on whether the account is the built-in administrator or not, and on the of the FilterAdministratorToken / LocalAccountTokenFilterPolicy registry keys. For more detail on this behavior, refer to Pass-the-Hash Is Dead: Long LierPolicy

Con

The options compress_output and cleanup_after_compression can help keep the disk usage small. After loading the final dump in Bloodhound you can safely delete the files under output/ldap and output/remote manually if you don't need them, but these files can be retained to look up important information without having to re-run the full collection.

> [!TIP]
> The primary purpose of the msgpack files under the output/ldap and output/remote folders is to serve as an intermediary format to segregate responsibilities for the entire process, but these files can also be used as a source of information by con them to JSON - this way you don't have to look up raw object attributes or remote collection results:
>
>
> A nice way of inspecting these files would be to use JQ/FX, or your fa programming language 🙂

Contributing

Contributions are welcome by opening an issue or by submitting a pull request.

Acknowledgements

* Big thanks to SpecterOps for BloodHound, SharpHound / SharpHoundCommon and to dirkjanm for BloodHound.py, which were the main references for this tool.

* Thanks to rtpt-erikgeiser & RedTeamPentesting for adauth and to p0dalirius for winacl, both really useful libraries.

* Thanks to oiweiwei for go-msrpc, as his library made it possible to implement remote collection methods based on RPCs.

Known Issues

Remote Collection

* Similarly as the restriction of methods allowed for cross-domain authentication in ingestion, when running remote collection with Kerberos (for example, when the user is part of Protected Users or when NTLM authentication is blocked settings) or with certificates (which uses PKINIT under the hood), remote collection won't try to authenticate to computers of domains that differ from the domain to which the user belongs. This also applies to the GPOLocalGroup method, which in those cases won't try to read GPO files from DCs of other domains, even if there are multiple domains in the ingested data.
* SmbInfo for the Computer type is still a basic implementation (registry checks only).
* HttpEnrollmentEndpoints only works with a provided username/password.
* AllowedToDelegateTo / Ser resolution is still a basic implementation.

General

* Almost all properties implemented in SharpHound are supported, but there are many architectural differences between this tool and SharpHound, so don't expect the output to match the official implementation exactly (with exception of e bugs). Key differences may arise especially for the more complex implementations, such as remote collections via RPC and collections related to CA/certificate abuse.

* Timeouts are still mostly static - SharpHound's implementation uses an adapti (pretty clever!), but I haven't had time to study that yet. If needed, customize timeouts with the --timeout, --computer-timeout and --method-timeout options (config/config.go specifies other operation-specific timeouts).

* Tests are currently not implemented and I have only tested a small subset of features manually.

License

Copyright (c) 2023 Artur Henrique Marzano Gonzaga

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The abo notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

项目信息

开发语言：Go

Star 数：177

技术要点

该项目属于红蓝攻防方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕A TUI for Active Directory collection.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。