Un constat revient sur presque tous nos audits internes. Les mêmes défauts de configuration, d'un client à l'autre, d'un secteur à l'autre : le paramètre qui autorise n'importe quel utilisateur du domaine à joindre dix machines à l'annuaire, des protocoles d'authentification obsolètes encore actifs, des comptes d'administration qui se connectent indifféremment sur un contrôleur de domaine, un serveur de fichiers ou sur un poste bureautique.

Ce n'est pas un problème de compétence. Les équipes savent, dans leur immense majorité, ce qu'il faudrait faire. Le problème est ailleurs : appliquer tout cela proprement représente des dizaines d'actions unitaires, chacune avec son temps imparti, son pilotage plus ou moins encadré, ses prérequis, ses effets de bord et son risque d'interruption de service. Mais  ce qui est long, fastidieux et risqué finit presque toujours au bas de la pile.

Ce constat, nous le faisons au quotidien au sein du pôle Remédiation de Login Sécurité, qui accompagne les entreprises sur ces chantiers. C'est de ce quotidien qu'est né LOCKmeAD, un outil développé pour industrialiser la partie mécanique du durcissement.

‍

LOCKmeAD : industrialiser ce qui peut l'être

Le durcissement AD n'est pas une seule tâche, mais une centaine

Prenons un exemple concret : celui du modèle d'administration en tier.
On parle ici de séparer les comptes qui administrent les machines critiques du domaine comme les contrôleurs de domaine ou les serveurs de mise à jour, de ceux qui administrent les serveurs métier et de ceux qui administrent les postes de travail.
Loué par Microsoft, toujours recommandé dans les rapports de pentest, c'est aujourd'hui l'une des mesures les plus efficaces contre la propagation d'une intrusion, mais quasiment impossible à créer seul sans connaissance spécifique en sécurité ou une expérience accrue en administration Active Directory.

Concrètement, cela suppose dans l'ordre : créer une arborescence d'unités d'organisation qui correspond à la logique de l'entreprise tout en prenant en compte les prérequis de segmentation, créer les groupes qui porteront les droits, imbriquer ces groupes correctement, écrire les stratégies de groupe qui empêchent les connexions croisées, cibler ces stratégies sur les bons groupes pour éviter les trous de sécurité, déterminer qui a besoin de quel type de compte en fonction de la criticité de son rôle, puis vérifier que rien n'a cassé...

Chaque étape dépend de la précédente. Une seule erreur d'ordre, et la stratégie s'applique à un périmètre qui n'était pas prévu, ou va laisser un périmètre sans protection.

Deux issues classiques à cette situation :

• Soit une documentation Word de quarante pages, périmée six mois plus tard,
• soit un script maison qui ne fait qu'une chose, ne se combine avec rien, et que plus personne n'ose relancer.

‍

Ce que fait l'outil

LOCKmeAD est une suite de modules PowerShell 7 qui automatise ce travail de plomberie. Chaque sujet est traité par un module indépendant, et l'ordre d'exécution est imposé par l'outil lui-même pour que les dépendances soient toujours respectées.

‍

Tous les modules de LOCKmeAD sont idempotents, sans risque de casser ou saturer l'annuaire en cas de déploiement multiples, et hautement personnalisables.

Le point commun à tous ces modules : rien n'est codé en dur. L'intégralité de la configuration vit dans des fichiers de configuration JSON, lisibles, que l'on peut relire, versionner, faire valider, rejouer à l'identique sur un autre environnement.
Ici, pas de fichier de configuration unique interminable, pas de sauvegardes de stratégies opaques importées telles quelles et qui embarquent les informations du domaine d'export : ce sont des décisions de sécurité explicites, templatisées, que LOCKmeAD vient créer à l'exécution pour correspondre exactement au domaine.

Une interface graphique permet de tout configurer et de tout déclencher sans jamais ouvrir une console. Les modifications faites dans l'interface se retrouvent dans les fichiers de configuration, et inversement.

‍

‍

LOCKmeAD embarque également une interface en pure PowerShell pour donner des permissions temporaires (Just-In-Time Administration) aux comptes administrateurs qui en auraient besoin. JIT Access Manager tient un historique qui permet aux administrateurs de tracer quels comptes ils ont ajouté à quels groupes de permissions entre chaque lancement de l'outil.

‍

Les garde-fous, qui sont le vrai sujet

Un outil qui modifie en masse un annuaire de production est un outil dangereux. Nous avons donc passé autant de temps sur les protections que sur les actions elles-mêmes.

Simulation avant application. Un mode simulation affiche ce qui serait modifié, sans rien toucher, sur les modules les plus critiques.

Le déploiement se fait par vagues. Chaque stratégie créée est accompagnée de deux groupes, un groupe « appliquer » et un groupe « exclure ». La stratégie ne s'applique qu'aux machines explicitement placées dans le premier. On commence donc par un périmètre pilote de quelques machines, on observe, puis on élargit. Peu importe où la stratégie est liée lors du déploiement, les serveurs et postes de travail doivent explicitement être placés dans le groupe d'application, assurant de ne rien casser à l'introduction de la stratégie dans le domaine.

Les mesures les plus bloquantes démarrent en observation. Les silos d'authentification, qui peuvent empêcher un compte de service de se connecter, sont déployés en mode audit. On regarde ce qui aurait été bloqué, pendant plusieurs jours, avant de basculer en mode réellement contraignant.

Les politiques de mot de passe déployées ne ciblent que les groupes d'utilisateurs désignés dans l'outil, pour éviter que l'équipe d'administration ne découvre qu'une politique de seize caractères s'est appliquée sans prévenir au prochain renouvellement.

Les permissions modifiées dans le cadre du déploiement sont sauvegardées avant modification, pour que l'outil sache revenir en arrière en cas de souci : restaurer les droits tels qu'ils étaient, supprimer les groupes créés par LOCKmeAD, avec plusieurs vérifications d'identité avant chaque suppression.

Chaque exécution laisse une trace. Journaux horodatés, clairs et explicites par exécution, et rapport au format tableur listant ce qui a été créé, ce qui existait déjà, ce qui a échoué. De quoi documenter les chantiers de durcissement.

‍

Ce que l'outil ne fait pas

Soyons clairs : LOCKmeAD ne remplace pas une analyse d'impact.

Il sait créer une structure, poser des droits, appliquer des stratégies. Il ne sait pas si votre application métier de 2009 dépend d'un protocole d'authentification que vous vous apprêtez à désactiver. Il ne sait pas si ce serveur non maintenu survivra à l'exigence de signature des communications. Il ne sait pas combien de cas d'usage sont servis par ce compte de service isolé qui n'a été documenté nulle part.

L'outil fait gagner du temps sur la partie mécanique. Ce temps gagné n'a d'intérêt que s'il est réinvesti là où il compte vraiment : dans la compréhension de l'existant, l'étude des impacts et le séquençage du déploiement des mesures de hardening. Et c'est précisément notre métier.

‍

II. Le pôle Remédiation : refermer les portes que l'on sait ouvrir

Des pentesters, pas des intégrateurs

Il y a une particularité chez Login Sécurité sur laquelle la philosophie de notre travail est basée : tous les opérateurs du pôle Remédiation sont pentesters. Pas des profils « exploitation » que l'on aurait formés à la sécurité, ni des intégrateurs qui appliquent un référentiel, mais des gens dont le métier consiste, le reste du temps, à compromettre des annuaires Active Directory chez nos clients. Ils connaissent les outils, les méthodologies, les enjeux et les impératifs des métiers de l'administration système, car ils y ont été confrontés en assurant ces professions dans leurs carrières, ou en étant exposés à de nombreux environnements de production pour en assurer la sécurisation (SOC, réponse à incidents, ...). Cette connaissance des réalités que sont la maintenance et l'administration d'un système d'information permettent d'assurer l'un des aspects les plus importants d'une mission de durcissement : celui de la transmission. La vision du hardening AD chez Login Sécurité implique que les équipes clients participent à part entière aux actions tout en étant formées aux bonnes pratiques de sécurité. Le but recherché étant de ne pas reproduire les vulnérabilités que les opérateurs viennent corriger, mais surtout que les équipes internes puissent faire évoluer le SI à l'avenir de façon sécurisée par elles-mêmes.

Cette double casquette n'est pas cosmétique, car elle change la nature du travail.

Un consultant qui a passé la semaine précédente à enchaîner une élévation de privilèges sur un domaine ne raisonne pas comme un catalogue de bonnes pratiques. Il sait quelles mesures ferment réellement un chemin d'attaque et lesquelles ne font que le déplacer. Il sait aussi, et c'est plus rare, lesquelles ne servent à rien dans un contexte donné.

Résultat ? Nous émettons des recommandations de sécurité au plus proche de la réalité opérationnelle, en pentest comme en remédiation, parce qu'elles sont formulées par les mêmes personnes et à partir de la même expérience du terrain.

‍

Remédier ce qui est exploitable

Les vulnérabilités que traite le pôle Remédiation de Login Sécurité ne sortent pas d'un référentiel générique, car elles sont directement issues des découvertes des pentesters pendant les prestations d'audit. Ce sont les chemins qui ont effectivement été empruntés, sur l'infrastructure, pour arriver jusqu'à l'administration du domaine. Cette vision permet une méthodologie très différente des approches habituelles.

Les plans de hardening passent souvent par le déploiement d'un modèle de sécurité complet : on refait l'arborescence, on repense l'ensemble des délégations, on migre les comptes, on réécrit les stratégies. Cocher les cases du référentiel et faire baisser son score PingCastle est rassurant, voire satisfaisant. C'est aussi un chantier de plusieurs mois, coûteux, anxiogène pour les équipes d'exploitation, et qui multiplie mécaniquement les occasions de casse. Beaucoup de ces projets s'enlisent avant d'avoir produit le moindre gain de sécurité, au point que les attaquants et les pentesters n'ont plus nécessairement peur devant un tiering, tant les erreurs durant son élaboration et les trous de sécurité sont fréquents. L'élaboration d'un modèle en tiers est une excellente mesure de sécurité pour un domaine AD, mais celle-ci doit aller de pair avec une véritable rigueur formelle : à quoi bon avoir 3 tiers parfaitement segmentés si les comptes de service sont tous privilégiés avec des mots de passe de 4 caractères qui n'expirent jamais ?

L'approche du pôle Remédiation de Login Sécurité est plus modeste et plus honnête : refermer d'abord ce qui rend l'infrastructure vulnérable. Ce qui a servi, ou ce qui servirait, à un attaquant pour progresser. Concrètement, la différence se voit dès la restitution. Une liste de deux cents recommandations et points de contrôle classée peut servir pour des impératifs de conformité, mais n'aide concrètement pas à élever le niveau de sécurité de l'infrastructure. Une liste de dix actions dont on peut dire « celles-ci coupent le chemin qui nous a menés à l'administrateur du domaine en une journée, et voici dans quel ordre les traiter », c'est un plan d'action.

L'avantage collatéral est important : moins on touche à l'annuaire, moins on risque l'interruption de production. Un périmètre de modification restreint et ciblé est un périmètre que l'on peut tester, dérouler par vagues et annuler si besoin.

‍

Rien n'est magique

Il faut le dire aussi clairement que possible, parce que c'est l'erreur la plus souvent rencontrée : aucune mesure de durcissement n'est sans conséquence.

Désactiver un protocole d'authentification ancien, exiger la signature des communications, restreindre les droits d'un compte de service, empêcher les administrateurs de se connecter sur les postes bureautiques : chacune de ces actions est parfaitement justifiée sur le papier. Chacune d'entre elles peut aussi mettre à l'arrêt un applicatif métier, un équipement industriel, un copieur multifonction ou une sauvegarde, selon l'état réel du parc.

Avant toute modification, il faut donc regarder :

• l'état de l'infrastructure : ce qui est encore supporté, ce qui ne l'est plus, ce qui est en cours de migration
• la vétusté : les systèmes anciens qu'on ne peut pas mettre à jour à court terme et qui vont contraindre le calendrier
• les mauvaises pratiques installées : le compte de service, administrateur du domaine depuis 2014, le partage ouvert à tous, le modèle de certification auprès duquel tout le monde peut s'enrôler
• les dépendances non documentées, qui sont la première cause d'incident lors d'un durcissement

Ce travail d'analyse n'est pas automatisable, et il n'existe pas de raccourci. C'est un métier, et c'est notre quotidien : nous intervenons très régulièrement sur ce type de problématiques, aux côtés des équipes d'exploitation, précisément parce que la difficulté n'est presque jamais technique : elle est contextuelle.

‍

La philosophie dont découle l'outil

C'est en effectuant ce travail, mission après mission, qu'un besoin a émergé. Parce qu'une fois l'analyse d'impact faite, une fois le périmètre arbitré avec le client, une fois le calendrier posé : reste l'application. Et l'application, elle, est répétitive. Créer les groupes, poser les délégations, écrire les mêmes stratégies, avec les mêmes clics dans les mêmes assistants, chez le client suivant. Du temps passé sur de la mécanique, au détriment du temps passé sur ce qui a réellement de la valeur : comprendre l'environnement et déterminer les actions.

LOCKmeAD est né de là, et il en porte la philosophie :

• Déployer ce qui a été décidé, en restant au plus près de ce qui est exploitable : les modèles fournis correspondent aux chemins d'attaque que nous rencontrons réellement, pas à un référentiel exhaustif.
• Préserver la production : simulation, déploiement par vagues, périmètres pilotes, audit avant application, sauvegarde et retour arrière.

L'outil ne décide de rien. Il exécute vite et proprement des décisions prises par des humains qui ont examiné l'infrastructure, et pas juste au travers de quelques slides ou d'un rapport PingCastle. Et c'est exactement le rôle que nous voulions lui donner.

‍

Pour conclure

Le durcissement Active Directory souffre de deux excès symétriques. D'un côté, l'inaction, parce que le chantier paraît trop lourd. De l'autre, le projet de refonte totale est un écueil dans lequel tombe beaucoup d'organisation : cocher le plus de cases possibles sur un référentiel. Cette approche consomme souvent des mois avant de produire un gain mesurable et ne finit souvent que partiellement aboutie (avec les trous de sécurité qui vont avec), voire abandonnée.
Entre les deux, il y a une voie : identifier ce qui rend réellement l'infrastructure vulnérable, mesurer l'impact de chaque correction sur l'existant, puis déployer de façon industrialisée, réversible et progressive. C'est cette voie que suivent les opérateurs du pôle Remédiation de Login Sécurité, et c'est celle que LOCKmeAD outille.

Un modèle de sécurité parfait qui correspondrait à toutes les organisations est une illusion, car une telle vision ne peut aboutir qu'à un modèle lourd et peu flexible. Savoir refermer exactement la porte qui a été empruntée, sans en condamner trois autres qui font tourner la production, est un métier à part entière. C'est celui que nous exerçons tous les jours.

Si vous vous interrogez sur l'état de votre annuaire, sur les chemins d'attaque qui y subsistent ou sur la façon de mener un chantier de durcissement sans mettre votre production en péril, nos équipes d'audit et de remédiation sont là pour en discuter : contact@login-securite.com

‍