
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.
Uma TUI para coleta do Active Directory.
Os principais objetivos deste projeto sã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.
$ 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.
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.
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
dcprobepara 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
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.
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.
[!NOTE] As consultas padrão no
config.yamlfornecido 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 noconfig.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:
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.