# FalconHound: keeping a BloodHound graph fed from your SIEM logs > A Go multi-tool that pulls sessions, group memberships and enrichment data out of a SIEM and writes them into the BloodHound graph. It still assumes Neo4j, which the latest BloodHound Community Edition no longer defaults to. **FalconForceTeam/FalconHound** — FalconHound is a blue team multi-tool. It allows you to utilize and enhance the power of BloodHound in a more automated fashion. It is designed to be used in conjunction with a SIEM or other log aggregation tool. - Repository: https://github.com/FalconForceTeam/FalconHound - Stars: 829 · Forks: 59 - Language: Go - License: BSD-3-Clause - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/falconforceteam-falconhound ## A graph that reflects the estate now, not at collection time FalconHound is described as a blue team multi-tool that lets you use BloodHound in a more automated fashion, and the README is explicit that it is not a replacement for BloodHound. The problem it addresses is that BloodHound gives you a snapshot in time. A graph built on Monday says nothing about the account that was added to a privileged group on Thursday, and for a constantly changing environment that staleness is the weakness. FalconHound closes the loop by taking information you already have in a SIEM and writing it into the graph, so the graph can be queried for what is true now. The design assumption is that a log aggregation tool exists in the first place, and the tool is meant to sit beside it rather than replace it. ## BloodHound CE 7.0 changed the default database and FalconHound has not followed The first thing the README flags is a compatibility problem, and it is the most decision relevant fact on the page. As of the BloodHound Community Edition 7.0 release, the default database has been switched to Postgres, while this version of FalconHound still relies on Neo4j as the default database. To keep using FalconHound alongside the latest BloodHound, one line has to be added to bloodhound.config.json: ```json "graph_driver": "neo4j", ``` The README says the BloodHound team will keep support for Neo4j for at least a year, and that within that window there hopefully is either a large API improvement or Postgres support has been implemented in FalconHound. That is the state of the project: the fix is a configuration line plus an expectation, not a supported backend. Anyone planning to standardise on the Postgres backend of BloodHound CE 7.0 should treat FalconHound as blocked until that support lands. ## A single binary, a YAML config and a folder of actions FalconHound is written in Go, so there is nothing to install. You download a binary from the releases section, with compiled builds for Windows, Linux and MacOS, and run it. Configuration is a YAML file, with an example in the root of the repository, and the credentials and permissions needed for each endpoint are documented separately in docs/required_permissions.md. The action model is the interesting part: the tool loads actions from a folder, and the repository ships an actions-template.yml alongside the actions directory, so the set of things it does is data you can extend rather than code you must rebuild. The default run executes every action in that folder: ```bash ./falconhound -go ``` To see which actions are enabled in the configuration before running them, list them first: ```bash ./falconhound -actionlist -go ``` ## Running a subset of actions and pointing at another config Two more flags shape a run. The -ids parameter takes one or more comma separated action IDs, which the README recommends when testing, troubleshooting, or when a specific check needs to run more often than the rest: ```bash ./falconhound -ids action1,action2,action3 -go ``` The -config flag replaces the config file that would otherwise be looked up in the current directory, and the README notes this is what lets several instances run against different environments with different configurations: ```bash ./falconhound -go -config /path/to/config.yml ``` There is a matching flag for the actions folder, so the same binary can be pointed at a different set of actions. The repository layout mirrors this structure, with cmd/, internal/, input_processor/ and output_processor/ holding the code and the actions directory holding the behaviour. ## Sessions and group memberships are the data blue teams already have The README names the hardest relationships to collect for BloodHound, and they are the ones blue teams already receive in their logs. Local group memberships and session information are the two that the collection process typically misses, and FalconHound gathers them from the log source and adds them to the graph so BloodHound can use them. The listed use cases spread wider than that: adding, removing or timing out sessions based on logon and logoff events, marking users and computers as compromised when an incident appears in Sentinel or Microsoft Defender for Endpoint, adding CVE information and whether a public exploit exists, adding new users, groups and computers, and generating enrichment lists for Sentinel and Splunk such as Kerberoastable users or users with ownerships of certain entities. ## The graph can also be a trigger for your alerts The second half of the tool is about detection rather than collection. Because the graph is queryable, it can be asked for the shortest path to a sensitive or high privilege group after a user is added to a group or given a new role, and the result can be logged to the SIEM or used to trigger an alert. That turns the graph from a report you read into a control you can wire into a pipeline. The data sources and targets listed for this are broad: Azure Sentinel, Sentinel watchlists, Splunk, Microsoft Defender for Endpoint, Neo4j, the MS Graph API at an early stage, CSV files, Azure Data Explorer in beta, LogScale, BloodHound CE and BHE at an early stage, MarkDown files, and Elastic at an early stage. The honest reading of that list is that the mature integrations are the Microsoft stack and Splunk, and several entries are marked early stage or beta. ## Version 1.4.x in 2024, with a push in April 2026 Maintenance information is mixed and worth reading carefully. The repository carries a maintenance badge marked for 2026, and the last push was on 2026-04-18. The tagged releases are older: v1.4.0 on 2024-06-11 with BloodHound API support, v1.4.1 on 2024-09-20 described as a minor update, and v1.4.2 on 2024-12-30. The Go module targets Go 1.25.0, and the dependency list shows the reach of the tool, with the Neo4j Go driver, the Microsoft Graph SDKs, the Azure Kusto and security insights clients, Key Vault secret clients, the Elasticsearch Go client and viper for configuration. The licence is BSD-3-Clause, which is permissive and fits internal security team tooling. ## Conclusion FalconHound suits a blue team that runs BloodHound with Neo4j, keeps its logs in Sentinel or Splunk, and wants the graph and its alert rules to reflect the current state of the estate rather than a collection snapshot. It does not suit a team that has already moved to the Postgres backend introduced in BloodHound CE 7.0, since the README states the tool still relies on Neo4j. Before deploying, add the graph_driver setting to bloodhound.config.json, write the YAML config from the sample in the repository root, and schedule the binary rather than running it by hand. ## FAQ ### Does FalconHound replace BloodHound? No. The README states it is not a replacement for BloodHound, and is designed to work with it and with the other data platforms BloodHound supports, in an automated fashion. At the moment it supports only the Neo4j database. ### What is the graph_driver setting for in FalconHound? BloodHound CE 7.0 switched its default database to Postgres while FalconHound still relies on Neo4j. Adding the line "graph_driver": "neo4j" to bloodhound.config.json keeps FalconHound working with the latest BloodHound version. ### How do I install and run FalconHound? There is no installation step because it is a Go binary. Download the build for Windows, Linux or MacOS from the releases section, create a YAML config file from the example in the repository root, and run ./falconhound -go. ### Which data sources can FalconHound read from and write to? The README lists Azure Sentinel, Sentinel watchlists, Splunk, Microsoft Defender for Endpoint, Neo4j, the MS Graph API at an early stage, CSV files, Azure Data Explorer in beta, LogScale, BloodHound CE and BHE at an early stage, MarkDown files and Elastic at an early stage. ### How often should FalconHound run? The README recommends running it as a scheduled task or a cron job, so the graph, alerts and enrichment lists stay current, and suggests using the -ids parameter when a specific action needs to run more frequently than the rest. ## Sources - [FalconForceTeam/FalconHound on GitHub](https://github.com/FalconForceTeam/FalconHound) - [Issues](https://github.com/FalconForceTeam/FalconHound/issues) - [License: BSD-3-Clause](https://github.com/FalconForceTeam/FalconHound/blob/main/LICENSE) - [README](https://github.com/FalconForceTeam/FalconHound/blob/main/README.md) - [Releases](https://github.com/FalconForceTeam/FalconHound/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/falconforceteam-falconhound