falconforceteam/falconhoundMise à jour automatisée du graphe BloodHound pour les équipes bleues. Enrichit les chemins d'attaque AD avec des données en temps réel sur les sessions, les groupes et les CVE provenant des SIEMs, permettant une surveillance et une alerte continues.
Depuis la sortie de BloodHound CE 7.0, la base de données par défaut est passée à Postgres. Cette version de FalconHound utilise toujours Neo4j comme base de données par défaut. Si vous souhaitez continuer à utiliser FalconHound tout en exécutant la dernière version de BloodHound, ajoutez la ligne suivante à votre fichier bloodhound.config.json.```json "graph_driver": "neo4j",
L'équipe BloodHound continuera de prendre en charge Neo4j pendant au moins un an. Dans ce délai, on espère soit une grande amélioration de l'API, soit l'implémentation du support PGSQL dans FalconHound.
---
FalconHound est un outil polyvalent pour l'équipe bleue. Il vous permet d'utiliser et d'améliorer la puissance de BloodHound de manière plus automatisée. Il est conçu pour être utilisé conjointement avec un SIEM ou un autre outil d'agrégation de journaux.
L'un des aspects difficiles de BloodHound est qu'il s'agit d'un instantané dans le temps. FalconHound inclut des fonctionnalités qui peuvent être utilisées pour maintenir un graphe à jour de votre environnement. Cela vous permet de voir votre environnement tel qu'il est MAINTENANT. Cela est particulièrement utile pour les environnements en constante évolution.
L'une des relations les plus difficiles à collecter pour BloodHound est l'appartenance aux groupes locaux et les informations de session. En tant qu'équipe bleue, nous avons ces informations facilement disponibles dans nos journaux. FalconHound peut être utilisé pour collecter ces informations et les ajouter au graphe, permettant ainsi à BloodHound de les utiliser. Ce n'est qu'un exemple de la façon dont FalconHound peut être utilisé. Il peut être utilisé pour collecter toute information que vous avez dans vos journaux ou outils de sécurité et l'ajouter au graphe BloodHound.
De plus, le graphe peut être utilisé pour déclencher des alertes ou générer des listes d'enrichissement. Par exemple, si un utilisateur est ajouté à un certain groupe, FalconHound peut être utilisé pour interroger la base de données de graphes afin de trouver le chemin le plus court vers un groupe sensible ou à privilèges élevés. S'il existe un chemin, cela peut être journalisé dans le SIEM ou utilisé pour déclencher une alerte.
Autres exemples où FalconHound peut être utilisé :
- Ajout, suppression ou mise en timeout des sessions dans le graphe, basé sur les événements de connexion et déconnexion.
- Marquage des utilisateurs et ordinateurs comme compromis dans le graphe lorsqu'ils ont un incident dans Sentinel ou MDE.
- Ajout d'informations CVE et de la disponibilité d'un exploit public dans le graphe.
- Toutes sortes d'activités Azure.
- Recalcul du chemin le plus court vers les groupes sensibles lorsqu'un utilisateur est ajouté à un groupe ou obtient un nouveau rôle.
- Ajout de nouveaux utilisateurs, groupes et ordinateurs au graphe.
- Génération de listes d'enrichissement pour Sentinel et Splunk, par exemple, d'utilisateurs Kerberoastable ou d'utilisateurs avec des propriétés sur certaines entités.
Les possibilités sont infinies ici. Veuillez ajouter d'autres idées au suivi des problèmes ou soumettre une PR.
Un blog détaillant davantage les raisons de son développement et quelques exemples de cas d'utilisation peut être trouvé [ici](https://medium.com/falconforce/falconhound-attack-path-management-for-blue-teams-42adedc9cae5?source=friends_link&sk=9f64b6b3028c5a2a6087d63b4fd2c82f)
Index :
- [Sources de données et cibles prises en charge](#supported-data-sources-and-targets)
- [Installation](#installation)
- [Utilisation](#usage)
- [Actions](#actions)
- [Extensions du graphe](#extensions-to-the-graph)
- [Gestion des identifiants](#credential-management)
- [Déploiement](#deployment)
- [Licence](#license)
## Sources de données et cibles prises en charge
FalconHound est conçu pour être utilisé avec BloodHound. Ce n'est pas un remplacement pour BloodHound. Il est conçu pour exploiter la puissance de BloodHound et de toutes les autres plateformes de données qu'il prend en charge de manière automatisée.
Actuellement, FalconHound prend en charge les sources de données et/ou cibles suivantes :
- Azure Sentinel
- Azure Sentinel Watchlists
- Splunk
- Microsoft Defender for Endpoint
- Neo4j
- MS Graph API (early stage)
- Fichiers CSV
- Azure Data Explorer (ADX) - beta
- LogScale
- BloodHound CE and BHE (early stage)
- Fichiers MarkDown
- Elastic (early stage)
Des sources de données et cibles supplémentaires sont prévues pour l'avenir.
À l'heure actuelle, FalconHound ne prend en charge que la base de données Neo4j pour BloodHound. La prise en charge de l'API de BH CE et BHE est en développement actif.
---
## Installation
Comme FalconHound est écrit en Go, aucune installation n'est nécessaire. Téléchargez simplement le binaire depuis la section des versions et exécutez-le.
Des binaires compilés sont disponibles pour Windows, Linux et MacOS. Vous pouvez les trouver dans la section [releases](https://github.com/FalconForceTeam/FalconHound/releases).
Avant de pouvoir l'exécuter, vous devez créer un fichier de configuration. Vous trouverez un exemple de fichier de configuration dans le dossier racine. Des instructions sur la création de tous les identifiants sont disponibles [ici](https://github.com/falconforceteam/falconhound/blob/HEAD/docs/required_permissions.md).
La manière recommandée d'exécuter FalconHound est de le faire en tant que tâche planifiée ou tâche cron. Cela vous permettra de l'exécuter régulièrement et de maintenir votre graphe, vos alertes et vos enrichissements à jour.
### Prérequis
- BloodHound, ou au moins la base de données Neo4j pour le moment.
- Un SIEM ou un autre outil d'agrégation de journaux. Actuellement, Azure Sentinel et Splunk sont pris en charge.
- Des identifiants pour chaque point de terminaison avec lequel vous souhaitez communiquer, avec les [autorisations requises](https://github.com/falconforceteam/falconhound/blob/HEAD/docs/required_permissions.md).
### Configuration
FalconHound est configuré à l'aide d'un fichier YAML. Vous trouverez un exemple de fichier de configuration dans le dossier racine.
Chaque section du fichier de configuration est expliquée ci-dessous.
---
## Utilisation
#### Exécution par défaut
Pour exécuter FalconHound, exécutez simplement le binaire et ajoutez le paramètre `-go` pour qu'il exécute toutes les requêtes dans le dossier actions.```bash
./falconhound -go
Pour lister toutes les actions activées, utilisez le paramètre -actionlist. Cela listera toutes les actions qui sont activées dans les fichiers de configuration dans le dossier actions. Cela doit être utilisé en combinaison avec le paramètre -go.```bash
./falconhound -actionlist -go
### Exécuter avec un ensemble sélectionné d'actions
Pour exécuter un ensemble sélectionné d'actions, utilisez le paramètre `-ids`, suivi d'un ou d'une liste d'identifiants d'action séparés par des virgules. Cela exécutera les actions spécifiées dans le paramètre, ce qui peut être très pratique lors des tests, du dépannage ou lorsque vous avez besoin de mises à jour spécifiques et plus fréquentes. Ce paramètre doit être utilisé en combinaison avec le paramètre `-go`.```bash
./falconhound -ids action1,action2,action3 -go
Par défaut, FalconHound recherchera un fichier de configuration dans le répertoire courant. Vous pouvez également spécifier un fichier de configuration à l'aide du drapeau -config. Cela vous permet d'exécuter plusieurs instances de FalconHound avec des configurations différentes, sur des environnements différents.```bash
./falconhound -go -config /path/to/config.yml
#### Exécuter avec un dossier d'actions différent
Par défaut, FalconHound cherchera le dossier d'actions dans le répertoire courant. Vous pouvez également spécifier un dossier différent à l'aide du drapeau `-actions-dir`. Cela facilite les tests et le dépannage, mais permet également d'exécuter plusieurs instances de FalconHound avec différentes configurations, sur différents environnements, ou à différents intervalles de temps.```bash
./falconhound -go -actions-dir /path/to/actions
Par défaut, FalconHound utilisera les identifiants du fichier config.yml (ou d'un fichier personnalisé chargé). En définissant l'indicateur -keyvault, FalconHound obtiendra le keyvault depuis la configuration et récupérera tous les secrets de celui-ci. S'il manque des éléments dans le keyvault, il reviendra au fichier de configuration. Si vous souhaitez récupérer les secrets d'un azure keyvault en utilisant une identité gérée, définissez la variable authtype sur msi.```bash
./falconhound -go -keyvault
## Actions
Les actions sont le cœur de FalconHound. Ce sont les requêtes que FalconHound exécutera. Elles sont écrites dans le langage natif de la source et de la cible et sont stockées dans le dossier actions. Chaque action est un fichier séparé et est stockée dans le répertoire de la source de l'information, la cible de la requête. Le nom du fichier est utilisé comme nom de l'action.
### Structure du dossier Actions
Le dossier Actions est divisé en sous-répertoires par source de requête. Tous les dossiers seront traités récursivement et tous les fichiers YAML seront exécutés dans l'ordre alphabétique.
Les actions Neo4j **devraient** être traitées en dernier, car leur sortie dépend d'autres sources de données ayant mis à jour la base de données graphique en premier, pour obtenir les résultats les plus récents.
### Fichiers d'action
Tous les fichiers sont des fichiers YAML. Le fichier YAML contient la requête, quelques métadonnées et la ou les cibles des informations interrogées.
Il existe un fichier modèle disponible dans le dossier racine. Vous pouvez l'utiliser pour créer vos propres actions. Jetez un coup d'œil aux actions dans le dossier actions pour plus d'exemples.
Bien que la plupart des éléments soient assez explicites,il y a quelques points importants à noter concernant les actions:
#### Enabled
Comme son nom l'indique, cela sert à activer ou désactiver une action. Si cette valeur est définie sur false, l'action ne sera pas exécutée.```yaml
Enabled: true
Ceci est utilisé pour activer ou désactiver le mode débogage pour une action. Si cette option est définie sur true, l'action sera exécutée en mode débogage. Cela affichera les résultats de la requête dans la console. Ceci est utile pour les tests et le dépannage, mais il n'est pas recommandé de l'utiliser en production. Cela ralentira le traitement de l'action en fonction du nombre de résultats.```yaml Debug: false
#### Query
Le champ `Query` est la requête qui sera exécutée sur la source. Cela peut être une requête KQL, une requête SPL ou une requête Cypher selon votre `SourcePlatform`.
IMPORTANT : Essayez de garder la requête aussi précise que possible et ne renvoyez que les champs dont vous avez besoin. Cela rendra le traitement des résultats plus rapide et plus efficace.
De plus, lorsque vous exécutez des requêtes Cypher, assurez-vous de RETURN un objet JSON comme résultat, sinon le traitement échouera.
Par exemple, cela renverra les Name, Count, Role et Owners des abonnements Azure :```cypher
MATCH p = (n)-[r:AZOwns|AZUserAccessAdministrator]->(g:AZSubscription)
RETURN {Name:g.name , Count:COUNT(g.name), Role:type(r), Owners:COLLECT(n.name)}
Chaque cible dispose de plusieurs options configurables. Selon la cible, certaines peuvent nécessiter plus de configuration que d'autres.
Toutes les cibles ont les champs Name et Enabled. Le champ Name est utilisé pour identifier la cible. Le champ Enabled est utilisé pour activer ou désactiver la cible. Si celui-ci est défini sur false, la cible sera ignorée.
CSV supporte la variable {{date}}, qui sera remplacée par la date courante au format YYYY-MM-DD. Cela peut être utilisé pour créer des rapports quotidiens.
Cela peut être utilisé dans un nom de dossier ou de fichier (par ex. path/to/filename-{{date}}.csv) ou dans le nom du dossier lui-même.```yaml
#### Markdown
Markdown prend en charge la variable {{date}}, qui sera remplacée par la date courante au format `YYYY-MM-DD`. Cela peut être utilisé pour créer des rapports quotidiens.
Cela peut être utilisé dans un nom de dossier ou de fichier (par ex. `path/to/filename-{{date}}.md`) ou dans le nom du dossier lui-même.```yaml
- Name: Markdown
Enabled: true
Path: path/to/filename.md
Exemple de sortie:```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
La cible Neo4j écrira les résultats de la requête dans une base de données Neo4j. Cette sortie est ligne par ligne et nécessite donc une configuration supplémentaire.
Puisque nous pouvons transférer toutes sortes de données dans toutes les directions, FalconHound doit comprendre quoi faire avec les données. Cela se fait en utilisant des variables de remplacement dans la première ligne de vos requêtes Cypher. Celles-ci sont passées à Neo4j en tant que paramètres et peuvent être utilisées dans la requête.
Les champs `ReplacementFields` sont configurés ci-dessous.```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
The Parameters section defines a set of parameters that will be replaced by the values from the query results. These can be referenced as Neo4j parameters using the $parameter_name syntax.
The Sentinel target will write the results of the query to a Sentinel table. The table will be created if it does not exist. The table will be created in the workspace that is specified in the config file. The data from the query will be added to the EventData field. The EventID will be the action ID and the Description will be the action name.
This is why also query output needs to be controlled, you might otherwise flood your target.```yaml
#### Sentinel Watchlists
La cible Sentinel Watchlists écrira les résultats de la requête dans une watchlist Sentinel. La watchlist sera créée si elle n'existe pas. La watchlist sera créée dans l'espace de travail spécifié dans le fichier de configuration. Toutes les colonnes retournées par la requête seront ajoutées à la watchlist.```yaml
- Name: Watchlist
Enabled: true
WatchlistName: FH_MDE_Exploitable_Machines
DisplayName: MDE Exploitable Machines
SearchKey: DeviceName
Overwrite: true
Le champ WatchlistName est le nom de la liste de surveillance. Le champ DisplayName est le nom d'affichage de la liste de surveillance.
Le champ SearchKey est la colonne qui sera utilisée comme clé de recherche.
Le champ Overwrite est utilisé pour déterminer si la liste de surveillance doit être écrasée ou complétée. Si cela est défini sur false, les résultats de la requête seront ajoutés à la liste de surveillance. S'il est défini sur true, la liste de surveillance sera supprimée et recréée avec les résultats de la requête.
Comme Sentinel, Splunk écrira les résultats de la requête dans un index Splunk. L'index devra être créé et lié à un point de terminaison HEC. Les données de la requête seront ajoutées au champ EventData. Le EventID sera l'ID de l'action et le Description sera le nom de l'action.```yaml
#### Azure Data Explorer
Comme Sentinel, Splunk écrira les résultats de la requête dans une table ADX. Les données de la requête seront ajoutées au champ EventData. Le EventID sera l'action ID et le Description sera l'action name.```yaml
- Name: ADX
Enabled: true
Table: "name"
Pour créer une table dans ADX, vous pouvez utiliser la commande suivante :```kql .create table FalconHound (Name: string, Description: string, EventID: string, BHQuery: string, EventData: dynamic, Timestamp: datetime)
### Extensions to the graph
#### Relationship: HadSession
Once a session has ended, it had to be removed from the graph, but this felt like a waste of information. So instead of removing the session,it will be added as a relationship between the computer and the user. The relationship will be called `HadSession`. The relationship will have the following properties:```json
{
"till": "2021-08-31T14:00:00Z",
"source": "falconhound",
"reason": "logoff",
}
This allows for additional path discoveries where we can investigate whether the user ever logged on to a certain system, even if the session has ended.
FalconHound ajoutera les propriétés suivantes aux nœuds du graphe :
Computer: - 'exploitable': true/false - 'exploits': liste de CVE - 'exposed': true/false - 'ports': liste des ports accessibles depuis internet - 'alertids': liste des alert-ids
Les méthodes actuellement prises en charge pour fournir des identifiants à FalconHound sont les suivantes :
Le fichier de configuration contient tous les détails requis par chaque plateforme. Tous les éléments du fichier de configuration sont sensibles à la casse (case-sensitive). La bonne pratique consiste à séparer les applications par niveau de service, mais vous pouvez utiliser 1 AppID/AppSecret pour toutes les actions basées sur Azure.
Les autorisations requises pour votre AppID/AppSecret sont listées ici.
Une façon plus sécurisée de stocker les identifiants consiste à utiliser un Azure KeyVault. Soyez conscient qu'il y a un petit aspect coût lié à l'utilisation de Keyvaults. L'accès aux KeyVaults prend actuellement en charge l'authentification basée sur une identité de système gérée (Managed System Identity) ou un AppID/AppSecret qui doit être configuré dans le fichier config.yml.
La méthode recommandée pour configurer cela est d'attribuer une identité de système gérée à la VM sur laquelle FalconHound s'exécute et de lui attribuer le rôle Key Vault Secrets User sur ce Keyvault. Cela permettra à FalconHound de s'authentifier auprès du Keyvault sans avoir besoin de configuration supplémentaire.
Alternativement, vous pouvez utiliser un ServicePrincipal qui a uniquement le rôle Key Vault Secrets User sur ce Keyvault. Ce rôle permet uniquement l'accès aux secrets, même pas de les lister. Ne réutilisez PAS le ServicePrincipal qui a accès à Sentinel et/ou MDE, car cela annule presque complètement l'utilisation d'un Keyvault.
Les éléments à configurer dans le Keyvault sont listés ci-dessous. Notez que les secrets Keyvault ne sont pas sensibles à la casse.``` 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
Une fois configuré, vous pouvez ajouter le paramètre `-keyvault` en lançant FalconHound.
#### Mode mixte / solution de repli
Lorsque le paramètre `-keyvault` est défini en ligne de commande, il devient la source principale de tous les secrets requis. Si FalconHound ne parvient pas à récupérer des éléments, il utilisera l'élément équivalent dans `config.yml` en solution de repli.
Si les deux échouent et que des actions sont activées pour cette source ou cette cible, un avertissement sera émis et l'(ou les) action(s) sera/seront ignorée(s).
## Déploiement
FalconHound est conçu pour être exécuté en tant que tâche planifiée ou tâche cron. Cela vous permettra de l'exécuter régulièrement et de maintenir votre graphe, vos alertes et vos enrichissements à jour.
En fonction du nombre d'actions que vous avez activées, de la quantité de données que vous traitez et de la quantité de données que vous écrivez dans le graphe, cela peut prendre un certain temps.
Toutes les requêtes basées sur les journaux sont conçues pour s'exécuter toutes les 15 minutes. Si le traitement prend trop de temps, vous devrez peut-être ajuster cela.
Si c'est le cas, il peut être recommandé de désactiver certaines actions.
Il peut également y avoir un certain chevauchement, par exemple avec les actions de session. Si vous avez beaucoup de sessions, vous voudrez peut-être désactiver les actions de session pour Sentinel et vous fier à celles de MDE. Cela suppose que vous ayez connecté MDE et Sentinel et que la plupart des machines soient intégrées à MDE.
### Sharphound / Azurehound
Bien que FalconHound soit conçu pour être utilisé avec BloodHound, il ne remplace pas Sharphound et Azurehound. Il est conçu pour compléter la collecte et éliminer le problème de l'instantané de la collecte périodique. Sharphound et Azurehound sont toujours nécessaires pour collecter les données, car toutes les données similaires ne sont pas disponibles dans les journaux.
Il est recommandé d'exécuter Sharphound et Azurehound régulièrement, par exemple une fois par jour/semaine ou mois, et FalconHound toutes les 15 minutes.
## Licence
Ce projet est sous licence BSD3 - voir le fichier [LICENSE](https://github.com/falconforceteam/falconhound/blob/HEAD/LICENSE) pour plus de détails.
Cela signifie que vous pouvez utiliser ce logiciel gratuitement, même dans des produits commerciaux, à condition de nous créditer.
Vous ne pouvez pas nous tenir responsables des dommages causés par ce logiciel.