Nettoyez votre AD
Vous avez vu que dans un Active Directory, il peut y avoir des milliers d’objets, et des millions de droits entre ces objets. C’est très difficile de maîtriser tous ces éléments. En plus, avec le temps, un système d’information a tendance à se complexifier ; de nouveaux utilisateurs, groupes ou ordinateurs sont ajoutés, mais ceux qui sont obsolètes sont rarement supprimés.
Il est donc temps de faire un nettoyage de printemps dans votre Active Directory !
Dans un premier temps, il peut être utile de faire la liste des objets qui n’ont pas été utilisés depuis longtemps. Il y a fort à parier que ce sont des objets qui ne servent plus, et qui peuvent être supprimés. Cela vous permettra de réduire la surface d’attaque disponible pour un attaquant.
Pour identifier ces comptes, vous pouvez utiliser les résultats récoltés par BloodHound. En effet, l’outil a enregistré l’ensemble des objets d’intérêt dans une base de données Neo4J. En écrivant des requêtes pour cette base, vous pourrez extraire les informations qui vous intéressent. Par exemple, pour récolter les utilisateurs ou ordinateurs de votre Active Directory qui ne se sont pas connectés depuis plus d’un an, la requête suivante peut être utilisée :
MATCH (n {enabled:true}) WHERE ((n:User) OR (n:Computer)) AND n.lastlogontimestamp < (datetime().epochseconds - (365 * 86400)) AND n.lastlogon < (datetime().epochseconds - (365 * 86400)) and NOT (n.lastlogontimestamp IN [-1.0, 0.0] AND n.lastlogon IN [-1.0, 0.0]) RETURN DISTINCT n.name AS Name, CASE WHEN n.lastlogontimestamp > n.lastlogon THEN DATETIME({epochseconds: ToInteger(n.lastlogontimestamp)}) ELSE DATETIME({epochseconds: ToInteger(n.lastlogon)}) END AS LastUsed
Vous pouvez également utiliser BloodHound pour identifier et supprimer des droits qui permettent de prendre la main sur le domaine. Vous pouvez par exemple utiliser la requête affichant les chemins les plus courts pour compromettre le domaine, et en fonction des résultats, vous verrez si ce sont des chemins que vous aviez anticipés, ou non. Tous les droits que vous identifiez comme non nécessaires doivent être supprimés.
Il en va de même pour les comptes de service. Vous avez vu que le Kerberoasting était une attaque très puissante, permettant de prendre la main sur des comptes qui peuvent avoir des privilèges élevés. Il est donc important d’identifier ces comptes, et de les remplacer soit par des comptes machine, soit par des gMSA (Group Managed Service Account).
Vous aviez déjà identifié ces comptes avec l’utilitaire GetUsersSPN.py d’Impacket. Vous pouvez également utiliser la requête Neo4J suivante pour les extraire :
MATCH (n:User {enabled:true,hasspn:true}) RETURN DISTINCT n.name AS Name, n.serviceprincipalnames AS SPN
Les comptes d’administration sont les cibles de choix des attaquants. S’ils sont compromis, cela leur permet d’élever leurs privilèges au sein du domaine, et peut-être le compromettre. Vous devez donc limiter le nombre de comptes à privilèges sur votre domaine.
La requête Neo4J suivante vous permet de dresser la liste de tous les utilisateurs faisant partie de groupes privilégiés. Il y a notamment les administrateurs du domaine, les administrateurs de l’entreprise, mais il existe d’autres groupes permettant d’effectuer des actions d’administration sur le domaine.
MATCH (u:User)-[:MemberOf*1..]->(g:Group {admincount:true}) RETURN u.name AS Name, COLLECT(g.name) AS Group;
Cette liste doit être réduite au strict minimum, pour réduire encore le périmètre d’attaque.
Les comptes en délégation sans contrainte présentent un vrai risque, car s’ils sont compromis, il est souvent possible de rapidement compromettre le domaine, notamment avec la technique que nous avons vu avec la coercition des contrôleurs de domaine. Cette délégation devrait être transformée en une délégation contrainte, en explicitant les services vers lesquels une délégation est nécessaire.
Sécurisez vos mots de passe
La politique de mot de passe joue un rôle essentiel dans la sécurité d’un environnement Active Directory. Vous devez vous assurer que celle-ci est bien paramétrée, pour éviter que des attaques de type password spraying soient efficaces. Vous savez récupérer cette politique grâce à la première partie de ce cours, en utilisant Get-ADDefaultDomainPasswordPolicy.
Ainsi, assurez-vous que les mots de passe aient au moins 12 caractères, que la complexité des mots de passe soit requise, et qu’au bout d’un certain nombre de tentatives, le compte soit temporairement bloqué. Il est courant de voir comme paramétrage 3 tentatives échouées sur une fenêtre de 30 minutes avant que le compte ne soit bloqué pendant 30 minutes.
Vous pouvez également faire un audit régulier des mots de passe. Cela signifie que les hashs NT des utilisateurs sont extraits des contrôleurs de domaine, et qu’une tentative de casser ces hashs est lancée pendant quelques heures. Les mots de passe retrouvés sont considérés comme faibles, et doivent être changés. Vous pourrez ainsi affiner votre politique de mot de passe, et peut-être également sensibiliser les collaborateurs à ce que leur mot de passe soit robuste.
Durcissez les protocoles
Les attaques sur les protocoles peuvent être souvent évitées en paramétrant correctement les clients et les serveurs.
La signature des flux permet par exemple de se protéger des attaques par relais. La signature SMB est disponible sur toutes les versions de Windows, mais n’est requise par défaut que sur les contrôleurs de domaine. Faire en sorte que tous les flux SMB soient obligatoirement signés vous permettra de vous prémunir des attaques où une personne se place en position d’homme du milieu, notamment le relais NTLM lorsque le relais se fait via SMB. Un article de Microsoft est dédié à ce sujet. Il indique comment paramétrer la signature en modifiant des clés de registre, ou par GPO.
De la même manière, il est possible de requérir la signature LDAP sur les contrôleurs de domaine. Cela peut également être paramétré via GPO.
Concernant NTLM, je vous avais rapidement dit qu’il y avait deux versions du protocole, NTLMv1 et NTLMv2. Sachez que la première version est obsolète, et n’est en aucun cas sécurisée. Il est très important de vous assurer que c’est bien la version 2 du protocole qui est en place. C’est le cas par défaut, mais pour vous en assurer, vous pouvez vérifier cette clé de registre sur les contrôleurs de domaine :
HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevelSi la valeur présente ici est 0, 1 ou 2, alors NTLMv1 peut être utilisé en se connectant sur un contrôleur de domaine, et les contrôleurs de domaine risquent d’également utiliser ce protocole obsolète, ce qui présente un vrai risque, notamment quand on a en tête les techniques de coercition d’authentification. Les différents niveaux de cette clé sont détaillés dans un article de Microsoft, ainsi il faut absolument que cette valeur soit 3 ou plus. Vous pouvez également modifier ce paramètre par GPO.
Enfin, les protocoles NBT-NS et LLMNR sont très dangereux s’ils sont activés. Ils permettent à un attaquant de se positionner en homme du milieu pour soit relayer une authentification, soit tenter de casser les mots de passe des utilisateurs. Les désactiver sur les postes vous permettra de vous protéger de ces attaques.
Pour désactiver LLMNR, il suffit d’activer le paramètre Désactiver la résolution de noms multidiffusion accessible ici : Configuration ordinateur > Modèles d'administration > Réseau et Client DNS
Pour NBT-NS, c’est moins simple. Il n’y a pas de GPO permettant de le faire simplement. Vous pouvez en revanche faire en sorte que ce script soit exécuté au démarrage des machines. Il récupérera les interfaces réseau sur les postes et désactivera Netbios :
# Récupération des cartes réseau
$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
# Désactivation de Netbios sur chacune des cartes
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}En résumé
Pour protéger correctement votre environnement Active Directory, plusieurs points d’attention peuvent être suivis :
Nettoyer votre environnement en supprimant les objets et droits inutiles, en vue de limiter la surface d’attaque d’un acteur malveillant.
Sécuriser vos mots de passe en imposant une politique de mot de passe forte.
Durcir les protocoles usuels afin de limiter les attaques qui en profitent, notamment en mettant en place la signature des flux et en désactivant les protocoles obsolètes, comme LLMNR et NBT-NS.
D'autres points d'attention peuvent être réalisés. Comme implémenter un modèle d'administration via l'administration en silos. C'est ce qu'on nous allons voir dans le prochain chapitre.
