ImproHound

Identifier les chemins d'attaque dans BloodHound qui brisent votre tiering AD

ImproHound est un exe Windows x64 autonome dotnet avec interface graphique. Pour utiliser ImproHound, vous devez exécuter SharpHound afin de collecter les données nécessaires depuis l'AD. Vous téléchargerez ensuite les données sur votre installation BloodHound. ImproHound se connectera à la base de données Neo4j sous-jacente de BloodHound. Dans ImproHound, vous catégoriserez l'AD en couches via la structure des UO, et ImproHound identifiera les relations AD qui permettent à des objets AD de compromettre un objet d'une couche supérieure (plus proche de zéro) et enregistrera les violations de tiering dans un fichier csv.

Article de blog ImproHound

Vidéo de démonstration d'ImproHound

Présentation d'ImproHound au DEF CON Adversary Village

Table des matières

• Installation
• Utilisation
• Directives pour le tiering des objets AD
• Dernière version testée des dépendances

Installation

1. Configurez votre base de données BloodHound

1. Installer BloodHound

2. Collectez les données BloodHound avec SharpHound dans votre AD

   Note : cela générera du bruit dans votre antivirus, SIEM, etc.

   Exemple : Exécutez SharpHound.exe depuis cmd, collectez tout (oui, GPOLocalGroup n'est pas inclus dans All) :

   root@kitploit:~

   SharpHound.exe --CollectionMethods All,GPOLocalGroup
   

   Astuce 1 : Utilisez le paramètre Domain pour collecter des données depuis d'autres domaines de la forêt.

   Astuce 2 : Pour obtenir encore plus de données, utilisez La méthode de collecte par boucle de session

3. Téléchargez vos données BloodHound dans l'interface graphique BloodHound

   Il y a un bug dans BloodHound qui fait parfois sauter le fichier json du domaine lors du téléchargement d'un zip de données BloodHound. Vérifiez les statistiques de la base dans BloodHound après le téléchargement et assurez-vous que les objets du domaine existent.

2. Installez le plugin Neo4j APOC (permet les opérations graphiques géniales dont nous avons besoin)

1. Téléchargez la version d'APOC correspondant à votre version de Neo4j (apoc-x.x.x.x-all.jar).

   Trouvez la version d'APOC correspondant à votre version de Neo4j dans la matrice de compatibilité des versions.

2. Essayez de vous souvenir où vous avez installé Neo4j et placez le fichier jar APOC sous : $NEO4J_HOME/plugins/

   • $NEO4J_HOME sous Linux : /var/lib/neo4j/
   • $NEO4J_HOME sous Windows : Vérifiez le service Neo4j. Il révélera l'emplacement.

3. Modifiez neo4j.conf dans votre éditeur de texte préféré pour autoriser un accès APOC sans restriction en remplaçant la ligne : #dbms.security.procedures.unrestricted=my.extensions.example,my.procedures.* par dbms.security.procedures.unrestricted=apoc.*

   • neo4j.conf sous Linux : /etc/neo4j/neo4j.conf
   • neo4j.conf sous Windows : $NEO4J_HOME/conf/neo4j.conf

   Si vous souhaitez exécuter ImproHound sur un hôte et BloodHound sur un autre, vous devez autoriser les connexions à distance à la base de données Neo4j sur l'hôte BloodHound. Pour cela, supprimez le # de la ligne #dbms.default_listen_address=0.0.0.0 dans .

3. Téléchargez et exécutez la dernière version de ImproHound.exe sous Windows (x64)

    Confirmez que vous pouvez vous connecter à la base BloodHound avec les mêmes identifiants que ceux utilisés dans l'interface graphique BloodHound.

Utilisation

Connexion à la base de données

Saisissez les identifiants de la base de données et établissez une connexion. Ce sont les mêmes identifiants que ceux utilisés dans l'interface graphique BloodHound.

Continuer ou recommencer

ImproHound crée un label 'TierX' sur les nœuds de la base de données BloodHound. Si vous avez déjà utilisé ImproHound avec cette base BloodHound, il vous sera demandé si vous souhaitez continuer avec le tiering déjà créé ou recommencer.

Tiering par défaut ou tout en Tier 2

ImproHound vous donne la possibilité de définir un 'Tiering par défaut' qui placera les administrateurs de domaine en Tier 0, les utilisateurs du domaine en Tier 2, etc., ou de placer tous les objets en Tier 2.

Structure UO

C'est la page où vous catégoriserez les objets AD en couches. La fenêtre affiche la structure des UO. Chaque objet AD a une valeur de couche qui peut être augmentée ou diminuée avec les flèches.

Définir les enfants sur la couche

Si vous sélectionnez un domaine ou un conteneur AD, vous pouvez cliquer sur 'Définir les enfants sur la couche' pour attribuer à tous les enfants (récursivement) le niveau de couche du domaine/conteneur donné.

Définir les membres sur la couche

Si vous sélectionnez un groupe, vous pouvez cliquer sur 'Définir les membres sur la couche' pour attribuer à tous les membres (récursivement) le niveau de couche du groupe donné.

Définir la couche pour les GPO

Si vous cliquez sur 'Définir la couche pour les GPO', chaque GPO verra son niveau de couche défini sur celui de l'UO de couche la plus élevée (la plus proche de zéro) à laquelle le GPO est lié. Les GPO non liés à une UO ne verront pas leur niveau de couche modifié.

Obtenir les violations de tiering

Trouvez toutes les relations dans la base de données BloodHound où un objet AD contrôle un objet AD d'une couche supérieure (plus proche de zéro).

Deux fichiers CSV sont générés en sortie :

• adobjects-[horodatage].csv : Tous les objets AD et leur couche respective.

• tiering-violations-[horodatage].csv : Les violations de tiering.

Exemple d'enregistrements dans le CSV des violations :

Le premier enregistrement est un compte de service Tier 1 avec l'autorisation de changer le mot de passe d'un compte utilisateur Tier 0. La relation est héritée. Malheureusement, il n'est pas toujours possible de voir d'où la relation est héritée dans les données BloodHound, mais vous pouvez le vérifier manuellement en inspectant les autorisations sur l'objet AD cible dans Utilisateurs et ordinateurs. Le deuxième enregistrement est un groupe avec l'autorisation de modifier un GPO, qui est probablement lié à une UO contenant des serveurs Tier 0, car c'est un GPO Tier 0.

Vous pouvez consulter tous les types de relations et comment elles sont exploitées ici.

Si vous découvrez qu'un objet est dans une couche trop élevée (la plus proche de zéro), vous devez le corriger dans ImproHound, puis vérifier les violations avec cet objet comme SOURCE. Si un objet est dans une couche trop basse (la plus proche de l'infini), vous devez le corriger dans ImproHound et vérifier les violations avec l'objet comme CIBLE.

Supprimer le tiering

Tous les labels de couche et les nœuds créés par ImproHound dans la base de données BloodHound seront supprimés.

Directives pour le tiering des objets AD

Il est important de classer correctement les objets AD. Si vous définissez un contrôleur de domaine et un utilisateur normal peu privilégié comme objets Tier 0, ImproHound ne détectera pas que l'accès administrateur de l'utilisateur au contrôleur de domaine est une violation de tiering. Même chose si vous les ajoutez tous les deux en Tier 2.

Ordinateur

Les ordinateurs sont classés en fonction de la criticité de leur compromission.

• Tier 0 – Contrôleurs de domaine et autres systèmes catégorisés comme critiques. Systèmes tels que SCCM, ADFS, PKI, et serveurs de virtualisation (VMware, Hyper V, etc.)
• Tier 1 – Le reste de l'infrastructure serveur
• Tier 2 – Postes de travail normaux

Utilisateur

Les utilisateurs sont classés en fonction des ordinateurs auxquels ils peuvent se connecter et des objets AD sur lesquels ils ont un contrôle. Un exemple d'autorisation de contrôle pourrait être un utilisateur ayant les droits de modifier des GPO liés à des serveurs Tier 1, ce qui en ferait un objet Tier 1.

Groupe

Un groupe appartient à la couche la plus basse (la plus proche de l'infini) de ses membres, sauf si le groupe contient des membres indésirables, par exemple un utilisateur normal membre du groupe Admins du domaine.

Exemples : Le groupe Utilisateurs du domaine est un groupe Tier 2 même si vos utilisateurs Tier 0 en sont membres, car ce n'est pas l'appartenance au groupe Utilisateurs du domaine qui confère des privilèges aux utilisateurs. En revanche, le groupe Admins du domaine est un groupe Tier 0 car l'appartenance à ce groupe rend les utilisateurs très privilégiés. Cloneable Domain Controllers n'a pas de privilèges AD à ma connaissance, mais il ne devrait contenir que des objets Tier 0, c'est-à-dire des contrôleurs de domaine, c'est donc un groupe Tier 0.

Conteneur (y compris UO et domaine)

Un conteneur appartient à la couche la plus élevée (la plus proche de zéro) de ses objets enfants, ou plus élevée.

Exemple : Vous avez tous les utilisateurs Tier 0, Tier 1 et Tier 2 dans le conteneur Utilisateurs. Un utilisateur ayant l'autorisation de contrôle total sur le conteneur Utilisateurs pourrait compromettre tous les utilisateurs, y compris ceux de Tier 0 (sauf certains qui sont protégés, mais ce n'est pas important pour l'exemple), donc le conteneur Utilisateurs doit être un objet Tier 0.

GPO

Le niveau de couche d'un GPO est déterminé par le niveau de couche des UO auxquelles il est lié. Le GPO appartient à la couche la plus élevée (la plus proche de zéro) des UO auxquelles il est lié. Utilisez le bouton 'Définir la couche pour les GPO' pour vous assurer que tous les GPO respectent ce principe.

Exemple : Un utilisateur ayant l'autorisation de modifier un GPO lié à une UO Tier 1 pourrait contrôler l'appartenance au groupe Administrateurs sur tous les serveurs sous l'UO Tier 1 en modifiant le GPO.

Dernière version testée des dépendances

• BloodHound 4.2.0
• Neo4j 4.4.10
• APOC 4.4.0.8
• Java/OpenJDK 11.0.16.1 LTS

À FAIRE

• Filtrer les GetChanges / GetChangesAll lorsqu'un seul des deux existe.
• Ajouter plus d'objets Tier 0 par défaut : RODC (y compris krbtgt_xxxxxx), MSOL_, AdminSDHolder, etc.