Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
flashingestor — Coletor de dados do Active Directory baseado em TUI que ingere objetos LDAP, realiza coleta remota via RPC/SMB/HTTP e gera dumps compatíveis com BloodHound CE para análise de caminhos de ataque. | Kitploit
Ferramentas/GitHubGitHub/macmod/flashingestor
ReconhecimentoMapeamento de RedeColeta de InformaçõesTestes de PenetraçãoRed Teaming
GitHubmacmod/flashingestor

flashingestor

Coletor de dados do Active Directory baseado em TUI que ingere objetos LDAP, realiza coleta remota via RPC/SMB/HTTP e gera dumps compatíveis com BloodHound CE para análise de caminhos de ataque.

Ver Repositório
1731316há 6 mesesRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

flashingestor

Uma TUI para coleta do Active Directory.

GitHub Release Go Version Code Size License Build Status Go Report Card GitHub Downloads Twitter Follow

Filosofia

Os principais objetivos deste projeto são:

  1. Ser um ingestor de dados completo compatível com o BloodHound CE (Community Edition)
  2. Ser mais rápido, menos ruidoso e mais customizável que outros coletores
  3. Fornecer uma TUI amigável (interface de usuário em terminal) com acompanhamento de progresso

Demonstração

Detalhes de Implementação

Flashingestor implementa 3 etapas básicas separadas: Injeção LDAP, Coleta Remota e Conversão, ao contrário de outros coletores que executam os métodos especificados em uma única etapa:

  • Injetar (Ctrl+l) - Coleta dados de atributos brutos de objetos do LDAP e os armazena em output/ldap em arquivos msgpack intermediários. As consultas podem ser personalizadas no config.yaml.

  • Remoto (Ctrl+r) - Lê esses arquivos intermediários na memória, calcula a lista de computadores a coletar e realiza uma série de requisições RPC/SMB/HTTP para obter informações remotas relevantes para objetos Computer e EnterpriseCA, que são armazenadas em output/remote.

  • Converter (Ctrl+s) - Lê os arquivos intermediários na memória, mescla informações das etapas de injeção e coleta remota, e gera um dump compatível com o Bloodhound em output/bloodhound - esta etapa é totalmente offline.

Para mais detalhes técnicos e insights, confira nossa 📖 Wiki.

Instalação

$ git clone https://github.com/Macmod/flashingestor
$ cd flashingestor

# Para compilar apenas:
$ go build ./cmd/flashingestor

# Para instalar o executável em $GOBIN ou $GOPATH/bin:
$ go install ./cmd/flashingestor

[!NOTE] Você também pode usar binários pré-compilados dos Releases fornecidos.

Uso

Primeiro autentique-se com uma das seguintes opções:

# Anônimo
# [Requer dSHeuristics de 0000002 no objeto DirectoryServices
#  e pode ter visibilidade limitada devido à falta de ACEs de leitura]
$ ./flashingestor -u '@<DOMINIO>' -p '' [...]

# Usuário + Senha
$ ./flashingestor -u <USUARIO>@<DOMINIO> -p <SENHA> [-k] [...]

# Usuário + NTHash
$ ./flashingestor -u <USUARIO>@<DOMINIO> -H <NTHASH> [-k] [...]

# Usuário + PFX
$ ./flashingestor -u <USUARIO>@<DOMINIO> --pfx <CAMINHO_PFX> [--pfx-password <SENHA_PFX>] [-k] [...]

# Usuário + PEM
$ ./flashingestor -u <USUARIO>@<DOMINIO> --cert <CAMINHO_PEM> --key <CAMINHO_KEY> [-k] [...]

# Usuário + AESKey
$ ./flashingestor -u <USUARIO>@<DOMINIO> --aes-key <CHAVE_AES> -k [...]

# Usuário + Ticket
$ ./flashingestor -u <USUARIO>@<DOMINIO> --ccache /caminho/para/ticket.ccache -k [...]
ou
$ KRB5CCNAME=/caminho/para/ticket.ccache ./flashingestor -u <USUARIO>@<DOMINIO> -k [...]

Em seguida, execute as etapas conforme desejado. Para uma coleta apenas LDAP (DCOnly com exceção de GPOLocalGroup e CertServices), basta executar Ctrl+l, verificar se a injeção foi bem-sucedida e então executar Ctrl+s para gerar o dump final.

Descoberta de DC e DNS

Especificar --dc e --dns para executar o flashingestor é recomendado. Se você não especificar --dc, o flashingestor tentará encontrá-lo com consultas SRV / A, o que pode atrasar a etapa inicial de Injeção.

Você deve então especificar --dns se seu servidor DNS padrão não conhece o domínio - quando o DNS integrado ao AD está em uso, basta apontar --dns para o DC que o hospeda. Além disso, independentemente de --dc, se você quiser executar a etapa de Coleta Remota e seu servidor DNS não conhece os computadores no domínio, então você deve especificar --dns para as consultas.

[!TIP] Em ambientes com múltiplos DCs, você também pode usar o utilitário dcprobe para medir a latência para todos os DCs e encontrar um bom candidato alvo para a injeção:

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

Arquivo de configuração

Se o arquivo de configuração não estiver presente no diretório atual como config.yaml ou no caminho fornecido via --config, as opções padrão (as mesmas do config.yaml fornecido) serão assumidas - elas estão codificadas em config/fallback.go. Para mais informações, leia Arquivo de Configuração.

Outras Opções

Considere usar --log para especificar um arquivo de saída para logs (caso precise revisá-los após fechar a TUI) e -vv para ver mensagens de log de depuração, pois isso pode ajudar a solucionar possíveis problemas. Para uma referência completa dos argumentos de linha de comando, leia Argumentos de Linha de Comando.

Injeção

[!NOTE] As consultas padrão no config.yaml fornecido são projetadas com as informações necessárias para a conversão do Bloodhound em mente. Você pode optar por personalizar consultas ou atributos no config.yaml, mas é melhor evitar remover atributos necessários e evitar alterar o significado dos filtros de busca.

Se recurse_trusts estiver definido como true, ele irá ingerir quaisquer domínios confiáveis encontrados recursivamente com a credencial inicial fornecida para a injeção.

Se search_forest estiver definido como true, ele irá ingerir domínios que fazem parte da mesma floresta que o domínio inicial a partir da partição Configuration - nenhuma consulta adicional será emitida, pois isso já faz parte do plano de injeção padrão. Ambas as opções podem ser definidas ao mesmo tempo, e o flashingestor irá ingerir qualquer domínio encontrado apenas uma vez (seja por uma confiança ou pela floresta atual).

Se recurse_trusts estiver habilitado e recurse_feasible_only também estiver definido como true, ele só tentará ingerir um domínio confiável se a confiança for:

  1. Entrante/bidirecional e
  2. A confiança envolve o domínio inicial ou é transitiva.

Isso significa que confianças apenas de saída não serão percorridas e, além do primeiro nível de confianças, os caminhos de injeção param em confianças não transitivas - se B confia em A de forma não transitiva, então A ainda pode autenticar em B; mas se C também confia em B de forma não transitiva, então A não pode autenticar em C.

Baixar ferramenta