falconforceteam/falconhoundAtualizador automatizado de gráficos BloodHound para equipes azuis. Enriquece caminhos de ataque do AD com dados em tempo real de sessões, grupos e CVEs de SIEMs, permitindo monitoramento e alerta contínuos.
A partir do lançamento do BloodHound CE 7.0, o banco de dados padrão foi alterado para Postgres. Esta versão do FalconHound ainda depende do Neo4j como banco de dados padrão. Se quiser continuar usando o FalconHound enquanto executa a versão mais recente do BloodHound, adicione a seguinte linha ao seu arquivo bloodhound.config.json.```json "graph_driver": "neo4j",
A equipe do BloodHound manterá suporte ao Neo4j por pelo menos um ano. Dentro deste período, esperamos que haja uma grande melhoria na API ou que tenhamos implementado suporte a PGSQL no FalconHound.
---
FalconHound é uma ferramenta multifuncional para blue team. Ela permite utilizar e ampliar o poder do BloodHound de forma mais automatizada. Foi projetada para ser usada em conjunto com um SIEM ou outra ferramenta de agregação de logs.
Um dos aspectos desafiadores do BloodHound é que ele é um instantâneo no tempo. O FalconHound inclui funcionalidades que podem ser usadas para manter um grafo do seu ambiente atualizado. Isso permite que você veja seu ambiente como ele é AGORA. Isso é especialmente útil para ambientes que estão em constante mudança.
Um dos relacionamentos mais difíceis de obter para o BloodHound são as associações a grupos locais e as informações de sessão. Como membros do blue team, temos essas informações prontamente disponíveis em nossos logs. O FalconHound pode ser usado para coletar essas informações e adicioná-las ao grafo, permitindo que sejam usadas pelo BloodHound.
Este é apenas um exemplo de como o FalconHound pode ser usado. Ele pode ser usado para coletar qualquer informação que você tenha em seus logs ou ferramentas de segurança e adicioná-la ao grafo do BloodHound.
Além disso, o grafo pode ser usado para acionar alertas ou gerar listas de enriquecimento. Por exemplo, se um usuário for adicionado a um determinado grupo, o FalconHound pode ser usado para consultar o banco de dados do grafo em busca do caminho mais curto para um grupo sensível ou de alto privilégio. Se houver um caminho, isso pode ser registrado no SIEM ou usado para acionar um alerta.
Outros exemplos onde o FalconHound pode ser usado:
- Adicionar, remover ou expirar sessões no grafo, com base em eventos de logon e logoff.
- Marcar usuários e computadores como comprometidos no grafo quando tiverem um incidente no Sentinel ou MDE.
- Adicionar informações de CVE e se há um exploit público disponível ao grafo.
- Todos os tipos de atividades do Azure.
- Recalcular o caminho mais curto para grupos sensíveis quando um usuário é adicionado a um grupo ou tem uma nova função.
- Adicionar novos usuários, grupos e computadores ao grafo.
- Gerar listas de enriquecimento para Sentinel e Splunk de, por exemplo, usuários Kerberoastable ou usuários com propriedades de determinadas entidades.
As possibilidades são infinitas aqui. Por favor, adicione mais ideias ao rastreador de issues ou envie um PR.
Um blog detalhando mais sobre por que o desenvolvemos e alguns exemplos de casos de uso pode ser encontrado [aqui](https://medium.com/falconforce/falconhound-attack-path-management-for-blue-teams-42adedc9cae5?source=friends_link&sk=9f64b6b3028c5a2a6087d63b4fd2c82f)
Index:
- [Fontes de dados e destinos suportados](#supported-data-sources-and-targets)
- [Instalação](#installation)
- [Uso](#usage)
- [Ações](#actions)
- [Extensões ao grafo](#extensions-to-the-graph)
- [Gerenciamento de credenciais](#credential-management)
- [Implantação](#deployment)
- [Licença](#license)
## Supported data sources and targets
O FalconHound foi projetado para ser usado com o BloodHound. Não é um substituto para o BloodHound. Ele foi projetado para aproveitar o poder do BloodHound e de todas as outras plataformas de dados que ele suporta, de forma automatizada.
Atualmente, o FalconHound suporta as seguintes fontes de dados e/ou destinos:
- Azure Sentinel
- Azure Sentinel Watchlists
- Splunk
- Microsoft Defender for Endpoint
- Neo4j
- MS Graph API (em estágio inicial)
- arquivos CSV
- Azure Data Explorer (ADX) - beta
- LogScale
- BloodHound CE and BHE (em estágio inicial)
- arquivos MarkDown
- Elastic (em estágio inicial)
Fontes de dados e destinos adicionais estão planejados para o futuro.
No momento, o FalconHound suporta apenas o banco de dados Neo4j para BloodHound. O suporte para a API do BH CE e BHE está em desenvolvimento ativo.
---
## Installation
Como o FalconHound é escrito em Go, não é necessária instalação. Basta baixar o binário da seção de releases e executá-lo. Existem binários compilados disponíveis para Windows, Linux e MacOS. Você pode encontrá-los na seção [releases](https://github.com/FalconForceTeam/FalconHound/releases).
Antes de executá-lo, você precisa criar um arquivo de configuração. Você pode encontrar um arquivo de configuração de exemplo na pasta raiz. Instruções sobre como criar todas as credenciais podem ser encontradas [aqui](https://github.com/falconforceteam/falconhound/blob/HEAD/docs/required_permissions.md).
A forma recomendada de executar o FalconHound é como uma tarefa agendada ou cron job. Isso permitirá que você o execute regularmente e mantenha seu grafo, alertas e enriquecimentos atualizados.
### Requisitos
- BloodHound, ou pelo menos o banco de dados Neo4j por enquanto.
- Um SIEM ou outra ferramenta de agregação de logs. Atualmente, Azure Sentinel e Splunk são suportados.
- Credenciais para cada endpoint com o qual você deseja se comunicar, com as [permissões necessárias](https://github.com/falconforceteam/falconhound/blob/HEAD/docs/required_permissions.md).
### Configuração
O FalconHound é configurado usando um arquivo YAML. Você pode encontrar um arquivo de configuração de exemplo na pasta raiz.
Cada seção do arquivo de configuração é explicada abaixo.
---
## Usage
#### Execução padrão
Para executar o FalconHound, basta executar o binário e adicionar o parâmetro `-go` para que ele execute todas as consultas na pasta actions.```bash
./falconhound -go
Para listar todas as ações ativadas, use o parâmetro -actionlist. Isso listará todas as ações que estão ativadas nos arquivos de configuração na pasta actions. Isso deve ser usado em combinação com o parâmetro -go.```bash
./falconhound -actionlist -go
### Executar com um conjunto selecionado de ações
Para executar um conjunto selecionado de ações, use o parâmetro `-ids`, seguido por um ou uma lista de IDs de ações separados por vírgula. Isso executará as ações especificadas no parâmetro, o que pode ser muito útil ao testar, solucionar problemas ou quando você precisa de atualizações específicas mais frequentes. Isso deve ser usado em combinação com o parâmetro `-go`.```bash
./falconhound -ids action1,action2,action3 -go
Por padrão, o FalconHound procurará um arquivo de configuração no diretório atual. Você também pode especificar um arquivo de configuração usando a flag -config. Isso permite executar várias instâncias do FalconHound com diferentes configurações, em diferentes ambientes.```bash
./falconhound -go -config /path/to/config.yml
#### Executar com uma pasta de ações diferente
Por padrão, o FalconHound procurará a pasta de ações no diretório atual. Você também pode especificar uma pasta diferente usando o sinalizador `-actions-dir`. Isso facilita os testes e a solução de problemas, mas também permite executar várias instâncias do FalconHound com diferentes configurações, em diferentes ambientes ou em intervalos de tempo diferentes.```bash
./falconhound -go -actions-dir /path/to/actions
Por padrão, o FalconHound usará as credenciais no config.yml (ou em um personalizado carregado). Ao definir a flag -keyvault, o FalconHound obterá o cofre de chaves do config e recuperará todos os segredos de lá. Se houver itens faltando no cofre de chaves, ele voltará ao arquivo de configuração. Caso deseje obter os segredos de um cofre de chaves do Azure usando uma identidade gerenciada, defina a variável authtype como msi.```bash
./falconhound -go -keyvault
---
## Ações
As ações são o núcleo do FalconHound. Elas são as consultas que o FalconHound executará. São escritas na linguagem nativa da fonte e do destino e armazenadas na pasta de ações. Cada ação é um arquivo separado e é armazenada no diretório da fonte da informação, o destino da consulta. O nome do arquivo é usado como nome da ação.
### Estrutura da pasta de ações
A pasta de ações é dividida em subdiretórios por fonte de consulta. Todas as pastas serão processadas recursivamente e todos os arquivos YAML serão executados em ordem alfabética.
As ações do Neo4j **devem** ser processadas por último, pois sua saída depende que outras fontes de dados tenham atualizado primeiro o banco de dados de grafos, para obter os resultados mais atualizados.
### Arquivos de ação
Todos os arquivos são arquivos YAML. O arquivo YAML contém a consulta, alguns metadados e o(s) destino(s) da informação consultada.
Há um arquivo de modelo disponível na pasta raiz. Você pode usá-lo para criar suas próprias ações. Dê uma olhada nas ações na pasta de ações para mais exemplos.
Embora a maioria dos itens seja bastante autoexplicativa, há algumas coisas importantes a serem observadas sobre as ações:
#### Ativado
Como o nome indica, isso é usado para ativar ou desativar uma ação. Se estiver definido como falso, a ação não será executada.```yaml
Enabled: true
Isto é usado para ativar ou desativar o modo de debug para uma ação. Se definido como verdadeiro, a ação será executada em modo de debug. Isto irá imprimir os resultados da consulta no console. Isto é útil para testes e resolução de problemas, mas não é recomendado para uso em produção. Irá retardar o processamento da ação dependendo do número de resultados.```yaml Debug: false
#### Query
O campo `Query` é a consulta que será executada contra a fonte. Pode ser uma consulta KQL, uma consulta SPL ou uma consulta Cypher, dependendo do seu `SourcePlatform`.
IMPORTANTE: Tente manter a consulta o mais exata possível e retorne apenas os campos necessários. Isso tornará o processamento dos resultados mais rápido e eficiente.
Além disso, ao executar consultas Cypher, certifique-se de RETORNAR um objeto JSON como resultado, caso contrário o processamento falhará.
Por exemplo, isso retornará o Name, Count, Role e Owners das Azure Subscriptions:```cypher
MATCH p = (n)-[r:AZOwns|AZUserAccessAdministrator]->(g:AZSubscription)
RETURN {Name:g.name , Count:COUNT(g.name), Role:type(r), Owners:COLLECT(n.name)}
Cada alvo possui várias opções que podem ser configuradas. Dependendo do alvo, alguns podem exigir mais configuração do que outros.
Todos os alvos possuem os campos Name e Enabled. O campo Name é usado para identificar o alvo. O campo Enabled é usado para ativar ou desativar o alvo. Se for definido como falso, o alvo será ignorado.
O CSV suporta a variável {{date}}, que será substituída pela data atual no formato YYYY-MM-DD. Isso pode ser usado para criar relatórios diários.
Isso pode ser usado em um nome de pasta ou arquivo (ex.: path/to/filename-{{date}}.csv) ou no próprio nome da pasta.```yaml
#### Markdown
O Markdown suporta a variável {{date}}, que será substituída pela data atual no formato `YYYY-MM-DD`. Isso pode ser usado para criar relatórios diários.
Isso pode ser usado em um nome de pasta ou arquivo (por exemplo, `path/to/filename-{{date}}.md`) ou no próprio nome da pasta.```yaml
- Name: Markdown
Enabled: true
Path: path/to/filename.md
Exemplo de saída:```markdown
Description: Get a list of Domain Admins. Date: 2024-02-19
| Name | ObjectID |
|---|---|
| [email protected] | S-1-5-21-1122334455-112233445-1112223334-11223344 |
#### Neo4j
O alvo Neo4j escreverá os resultados da consulta em um banco de dados Neo4j. Esta saída é por linha e, portanto, requer algumas configurações adicionais.
Como podemos transferir todos os tipos de dados em todas as direções, o FalconHound precisa entender o que fazer com os dados. Isso é feito usando variáveis de substituição na primeira linha de suas consultas Cypher. Elas são passadas para o Neo4j como parâmetros e podem ser usadas na consulta.
Os campos `ReplacementFields` estão configurados abaixo.```yaml
- Name: Neo4j
Enabled: true
Query: |
MATCH (x:Computer {name:$Computer}) MATCH (y:User {objectid:$TargetUserSid}) MERGE (x)-[r:HasSession]->(y) SET r.since=$Timestamp SET r.source='falconhound'
Parameters:
Computer: Computer
TargetUserSid: TargetUserSid
Timestamp: Timestamp
A seção Parâmetros define um conjunto de parâmetros que serão substituídos pelos valores dos resultados da consulta. Eles podem ser referenciados como parâmetros Neo4j usando a sintaxe $parameter_name.
O destino Sentinel gravará os resultados da consulta em uma tabela Sentinel. A tabela será criada se não existir. A tabela será criada no workspace especificado no arquivo de configuração. Os dados da consulta serão adicionados ao campo EventData. O EventID será o ID da ação e a Description será o nome da ação.
É por isso que também a saída da consulta precisa ser controlada, caso contrário você pode inundar seu destino.```yaml
#### Sentinel Watchlists
O destino Sentinel Watchlists escreverá os resultados da consulta em uma lista de observação do Sentinel. A lista de observação será criada se não existir. A lista de observação será criada no espaço de trabalho especificado no arquivo de configuração. Todas as colunas retornadas pela consulta serão adicionadas à lista de observação.```yaml
- Name: Watchlist
Enabled: true
WatchlistName: FH_MDE_Exploitable_Machines
DisplayName: MDE Exploitable Machines
SearchKey: DeviceName
Overwrite: true
O campo WatchlistName é o nome da watchlist. O campo DisplayName é o nome de exibição da watchlist.
O campo SearchKey é a coluna que será usada como chave de busca.
O campo Overwrite é usado para determinar se a watchlist deve ser sobrescrita ou complementada. Se isso for definido como falso, os resultados da consulta serão anexados à watchlist. Se isso for definido como verdadeiro, a watchlist será excluída e recriada com os resultados da consulta.
Assim como o Sentinel, o Splunk escreverá os resultados da consulta em um índice do Splunk. O índice precisará ser criado e vinculado a um endpoint HEC. Os dados da consulta serão adicionados ao campo EventData. O EventID será o ID da ação e a Descrição será o nome da ação.```yaml
#### Azure Data Explorer
Tal como o Sentinel, o Splunk escreverá os resultados da consulta numa tabela ADX. Os dados da consulta serão adicionados ao campo EventData. O EventID será o ID da ação e a Description será o nome da ação.```yaml
- Name: ADX
Enabled: true
Table: "name"
Para criar uma tabela no ADX, você pode usar o seguinte comando:```kql .create table FalconHound (Name: string, Description: string, EventID: string, BHQuery: string, EventData: dynamic, Timestamp: datetime)
### Extensões ao grafo
#### Relacionamento: HadSession
Uma vez que uma sessão terminou, ela tinha de ser removida do grafo, mas isso parecia um desperdício de informação. Então, em vez de remover a sessão, ela será adicionada como um relacionamento entre o computador e o usuário. O relacionamento será chamado `HadSession`. O relacionamento terá as seguintes propriedades:```json
{
"till": "2021-08-31T14:00:00Z",
"source": "falconhound",
"reason": "logoff",
}
Isso permite descobertas adicionais de caminhos onde podemos investigar se o usuário alguma vez fez login em um determinado sistema, mesmo que a sessão tenha terminado.
FalconHound adicionará as seguintes propriedades aos nós no grafo:
Computador: - 'exploitable': verdadeiro/falso - 'exploits': lista de CVEs - 'exposed': verdadeiro/falso - 'ports': lista de portas acessíveis pela internet - 'alertids': lista de IDs de alertas
As formas atualmente suportadas de fornecer credenciais ao FalconHound são:
O arquivo de configuração contém todos os detalhes exigidos por cada plataforma. Todos os itens no arquivo de configuração são sensíveis a maiúsculas/minúsculas. A melhor prática é separar os aplicativos por nível de serviço, mas você pode usar 1 AppID/AppSecret para todas as ações baseadas no Azure.
As permissões necessárias para seu AppID/AppSecret estão listadas aqui.
Uma forma mais segura de armazenar as credenciais seria usar um Azure KeyVault. Esteja ciente de que há um pequeno aspecto de custo associado ao uso de Keyvaults. O acesso a KeyVaults atualmente suporta autenticação baseada em uma Identidade de Sistema Gerenciada ou AppID/AppSecret que precisa ser configurado no arquivo config.yml.
A forma recomendada de configurar isso é atribuir uma Identidade de Sistema Gerenciada à VM onde o FalconHound está sendo executado e atribuir a ela a função Key Vault Secrets User para este Keyvault. Isso permitirá que o FalconHound autentique-se no Keyvault sem a necessidade de qualquer configuração adicional.
Alternativamente, você pode usar um ServicePrincipal que tenha apenas a função Key Vault Secrets User para este Keyvault. Essa função permite apenas acesso aos segredos, nem mesmo listá-los. NÃO reutilize o ServicePrincipal que tem acesso ao Sentinel e/ou MDE, pois isso quase anula completamente o uso de um Keyvault.
Os itens a serem configurados no Keyvault estão listados abaixo. Observe que os segredos do Keyvault não são sensíveis a maiúsculas/minúsculas.``` SentinelAppSecret SentinelAppID SentinelTenantID SentinelTargetTable SentinelResourceGroup SentinelSharedKey SentinelSubscriptionID SentinelWorkspaceID SentinelWorkspaceName MDETenantID MDEAppID MDEAppSecret Neo4jUri Neo4jUsername Neo4jPassword GraphTenantID GraphAppID GraphAppSecret AdxTenantID AdxAppID AdxAppSecret AdxClusterURL AdxDatabase SplunkUrl SplunkApiToken SplunkIndex SplunkApiPort SplunkHecToken SplunkHecPort BHUrl BHTokenID BHTokenKey LogScaleUrl LogScaleToken LogScaleRepository LimaCharlieAPIUrl LimaCharlieOrgId LimaCharlieIngestKey ElasticCloudID ElasticApiKey
Uma vez configurado, pode adicionar o parâmetro `-keyvault` ao iniciar o FalconHound.
#### Modo misto / fallback
Quando o parâmetro `-keyvault` é definido na linha de comando, esta será a fonte primária para todos os segredos necessários. Caso o FalconHound não consiga recuperar itens, ele recorrerá ao item equivalente no `config.yml`.
Se ambos falharem e houver ações ativadas para essa origem ou destino, será exibido um aviso e a(s) ação(ões) será(ão) ignorada(s).
## Implantação
O FalconHound foi projetado para ser executado como uma tarefa agendada ou cron job. Isso permitirá que você o execute regularmente e mantenha seu grafo, alertas e enriquecimentos atualizados.
Dependendo da quantidade de ações que você ativou, da quantidade de dados que está processando e da quantidade de dados que está escrevendo no grafo, isso pode demorar um pouco.
Todas as consultas baseadas em log são construídas para serem executadas a cada 15 minutos. Se o processamento demorar muito, talvez seja necessário ajustar isso um pouco.
Se for esse o caso, pode ser recomendável desativar certas ações.
Além disso, pode haver alguma sobreposição, por exemplo, com as ações de sessão. Se você tiver muitas sessões, pode ser interessante desativar as ações de sessão para o Sentinel e confiar nas do MDE. Isso pressupõe que você tenha o MDE e o Sentinel conectados e que a maioria das máquinas seja integrada ao MDE.
### Sharphound / Azurehound
Embora o FalconHound tenha sido projetado para ser usado com o BloodHound, ele não substitui o Sharphound e o Azurehound. Ele foi criado para complementar a coleta e eliminar o problema do momento específico da coleta periódica. Tanto o Sharphound quanto o Azurehound ainda são necessários para coletar os dados, pois nem todos os dados semelhantes estão disponíveis nos logs.
Recomenda-se executar o Sharphound e o Azurehound regularmente, por exemplo, uma vez por dia/semana ou mês, e o FalconHound a cada 15 minutos.
## Licença
Este projeto está licenciado sob a Licença BSD3 - consulte o arquivo [LICENSE](https://github.com/falconforceteam/falconhound/blob/HEAD/LICENSE) para obter detalhes.
Isso significa que você pode usar este software gratuitamente, mesmo em produtos comerciais, desde que nos credite.
Você não pode nos responsabilizar por quaisquer danos causados por este software.