Cet article met l'accent sur l'importance des autorisations de lecture par défaut dans la sécurité d'Active Directory (AD), qui est souvent négligée. La forêt AD n'est pas seulement une frontière de sécurité, mais elle devrait également être considérée comme le champ d'accès d'un intrus et l'évaluation de la sécurité des objets AD après avoir pénétré dans le réseau d'une organisation. La suppression d'autorisations de lecture spécifiques par défaut est une mesure à faible risque qui augmente la difficulté pour les intrus d'effectuer une reconnaissance et de planifier leurs prochaines étapes. Il est essentiel de comprendre la logique intégrée du mécanisme de protection de Microsoft pour les comptes les plus privilégiés de l'annuaire afin de comprendre les avantages et les inconvénients de ce mécanisme.
Ce document explique comment ajuster le mécanisme de protection en supprimant les autorisations de lecture par défaut risquées afin d'améliorer la sécurité d'AD. En outre, il aborde le problème de la dette de mauvaise configuration dans la plupart des infrastructures AD et explique comment corriger les autorisations sur les objets qui faisaient autrefois partie d'un groupe privilégié, mais qui ne le sont plus. En fin de compte, la sécurisation d'AD en limitant la visibilité des objets et les autorisations générales de lecture est essentielle pour réduire la surface d'attaque d'AD et améliorer sa posture de sécurité.
Restreindre la reconnaissance et les mouvements latéraux
Un verrouillage adéquat a un impact direct sur la difficulté - ou la facilité - pour les intrus d'utiliser Active Directory (AD) contre vous pendant la phase de reconnaissance d'une attaque.
Comme le montre la figure 1, cette phase survient après qu'un utilisateur malveillant a pris pied dans le réseau de votre entreprise, généralement en trompant vos employés par le biais d'e-mails de phishing ou de sites web spéciaux malveillants. À ce stade, l'intrus a généralement pris le contrôle du compte AD d'un utilisateur normal authentifié (c'est-à-dire tout compte d'employé non privilégié qui n'administre pas l'AD de votre entreprise). Vous pensez peut-être qu'un utilisateur non privilégié ne constitue pas une menace pour la sécurité de votre entreprise, mais combien de temps un intrus restera-t-il non privilégié ? Les intrus utilisent d'abord des vulnérabilités connues du système d'exploitation (OS) ou des pilotes sur des terminaux insuffisamment patchés pour élever leurs privilèges locaux et ainsi obtenir rapidement un accès administratif sur le client compromis. Cela leur permet de désactiver d'autres protections éventuellement présentes sur le client, de télécharger d'autres logiciels malveillants et d'établir un système de commande et de contrôle permettant généralement à d'autres membres du gang d'y accéder directement à distance. L'objectif suivant est de se déplacer latéralement vers d'autres clients, en effectuant une reconnaissance appropriée, dans le but de compromettre un compte d'administrateur de domaine pour finalement dominer le domaine.
Néanmoins, le véritable objectif de l'intrus est clair : atteindre et extraire les données sensibles de votre entreprise pour vous mettre sous pression. Mieux encore, il augmente cette pression en chiffrant le plus grand nombre possible de systèmes dans votre environnement, y compris tous les serveurs, leurs sauvegardes et les copies de sécurité de ces sauvegardes. Ces actions sont ensuite suivies d'une note de rançon amicale, demandant un paiement en bitcoins dans les heures ou les jours qui suivent, et promettant qu'en cas de paiement, vous recevrez une clé de décryptage et que vos données sensibles ne seront certainement pas divulguées au plus offrant sur le Dark Web. Seriez-vous prêt à payer ? Idéalement, vous n'aurez pas à répondre à cette question. Au lieu de cela, vous aurez déployé vos efforts pour empêcher les intrus d'atteindre leur objectif, de prendre le contrôle de votre AD et de détruire votre entreprise. La première étape consiste à faire en sorte qu'il soit difficile pour un intrus de localiser vos utilisateurs privilégiés et de lire les données sensibles de votre AD.
Le verrouillage de l'AD peut faire la différence
Un "verrouillage" de l'AD fait généralement référence à des changements de permissions dans le répertoire (c'est-à-dire à la modification de certaines des permissions par défaut). Malheureusement, ces permissions sont beaucoup trop ouvertes, ce qui donne aux malfaiteurs une trop grande partie des informations stockées dans votre système d'archivage. Les utilisateurs types et les applications professionnelles ont rarement besoin de ces informations. La suppression de certaines autorisations dans AD vous rapproche donc de la meilleure pratique générale en matière de sécurité informatique : le modèle du moindre privilège, dans lequel vous n'accordez aux utilisateurs que le nombre d'autorisations dont ils ont besoin pour faire leur travail. Cependant, pour toute modification des autorisations dans AD, vous devez toujours peser le pour et le contre de la manière dont ces modifications peuvent affecter vos applications professionnelles. Après tout, un système d'administration parfaitement sûr qui ne prend pas en charge vos applications professionnelles ne vous est d'aucune utilité. Idéalement, vous disposez d'un environnement de test solide qui contient non seulement une forêt AD de test (configurée comme votre AD de production), mais aussi une copie des applications professionnelles les plus critiques que vous utilisez. Cet environnement vous permet de tester l'impact de toute modification des autorisations dans AD avant de les mettre en œuvre en production.
Dans tous les cas, les changements de permissions doivent être planifiés avec soin (voir figure 2). La bonne nouvelle, c'est qu'il est assez facile de revenir aux autorisations initiales (par exemple, si vos tests ont négligé certains artefacts). Il est essentiel de documenter les autorisations que vous modifiez dans AD afin de pouvoir annuler ces modifications. Un outil d'audit AD approprié peut le faire pour vous, ce qui vous permet de rester en sécurité.
Vos objets privilégiés sont une cible privilégiée pour les intrus
Si vous devez choisir un domaine spécifique pour commencer à verrouiller votre AD, le premier choix devrait clairement être vos comptes et groupes privilégiés. Il s'agit des groupes d'administrateurs d'entreprise et de domaine et de leurs membres, mais aussi des autres groupes spéciaux tels que les opérateurs de compte, les opérateurs de serveur, etc. et de leurs membres. Dans un système AD correctement configuré, aucune de vos applications professionnelles n'utilisera ces groupes et comptes privilégiés. Ces applications n'ont pas non plus besoin d'effectuer une recherche LDAP (lightweight directory access protocol) telle que "qui est membre du groupe des administrateurs de domaine" pour fonctionner. Par conséquent, ce verrouillage d'AD est généralement une tâche à faible risque. AD utilise l'attribut "adminCount" sur les objets pour signaler ceux qu'il considère comme "privilégiés" ; les objets correspondants ont cet attribut fixé à 1. Pour comprendre quels groupes votre AD considère comme privilégiés, vous pouvez exécuter une simple requête LDAP avec le filtre suivant:1
(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))
Cette requête ne recherche que les groupes de sécurité, en particulier ceux dont l'attribut adminCount est marqué d'un '1'. Utilisez votre méthode d'interrogation LDAP préférée, par exemple DSQUERY :
dsquery * domainroot “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”
ou PowerShell :
Get-ADObject -LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”
ou le filtre LDAP directement dans la console de gestion Microsoft Users & Computers AD (MMC), avec l'option recherche personnalisée/avancée (voir figure 3). Les résultats dans votre domaine peuvent être différents, en particulier si vous avez imbriqué d'autres groupes dans ces groupes privilégiés par défaut, même temporairement. Les résultats dépendent également de la version du système d'exploitation de vos contrôleurs de domaine AD et de la manière dont vous avez effectué les mises à niveau entre les versions. Dans l'idéal, votre liste ne s'écarte pas trop de cette valeur par défaut. Si c'est le cas, il se peut que vous ayez du travail de nettoyage à faire (voir ci-dessous). Tout d'abord, il est important de comprendre la signification et l'origine de l'attribut adminCount, ainsi que certains principes de base du comportement et de la conception d'AD.
La délégation fine des autorisations a été la pierre angulaire de la réussite d'AD.
Lorsque Microsoft a conçu AD il y a plus de 23 ans, il a ajouté de puissantes capacités de délégation de permissions, jusqu'à chaque attribut des objets de l'annuaire. Cette capacité reposait sur le stockage d'autorisations distinctes, appelées descripteurs de sécurité ou listes de contrôle d'accès (ACL), pour chaque objet dans AD, en tant que partie de l'objet lui-même (stocké dans l'attribut nTSecurityDescriptor ). Le modèle de sécurité d'AD permettait d'hériter des autorisations dans toute une arborescence d'unités organisationnelles (OU) afin de configurer efficacement les autorisations sans avoir à les définir séparément pour tous les objets. Mais le modèle permettait également de définir des autorisations explicites directement sur un objet (par exemple une autre OU, un utilisateur ou un groupe) (voir figure 4). Les permissions explicites de cet objet peuvent être mélangées aux permissions héritées ou bloquer les permissions héritées de l'objet parent.
Cette flexibilité a permis aux plus grandes entreprises d'utiliser un répertoire informatique central et mondial qui pouvait déléguer des tâches d'assistance importantes à d'autres équipes. À l'époque où AD a été conçu, il était courant d'avoir des équipes d'assistance distinctes dans chaque pays où opérait une entreprise. Ces équipes effectuaient des tâches d'assistance classiques telles que la réinitialisation du mot de passe d'un compte utilisateur dans leur région, l'ajout d'objets informatiques ou même l'ajout d'utilisateurs à des groupes, en fonction des besoins de l'entreprise. Grâce à la délégation des autorisations au niveau de l'OU approprié (par exemple OU=PHX, OU=US, DC=mycompany, DC=com) et à l'héritage des autorisations dans toute la branche de l'OU jusqu'aux objets pertinents (par exemple utilisateur, ordinateur, groupe), les membres d'un groupe AD de helpdesk correspondant pouvaient effectuer toutes les tâches de support nécessaires pour les utilisateurs, les ordinateurs et les groupes dans n'importe quelle sous-UO. Cette capacité n'exigeait pas que les membres du groupe aient la permission d'administrer le service AD lui-même. En d'autres termes, le personnel du helpdesk n'était pas membre du groupe des administrateurs de domaine et ne pouvait pas modifier la configuration AD, promouvoir de nouveaux contrôleurs de domaine (DC) ou se connecter aux contrôleurs de domaine AD.
Ces utilisateurs du service d'assistance disposant d'autorisations spécifiques déléguées dans AD sont appelés administrateurs de données AD, tandis que les comptes réellement privilégiés, tels que les administrateurs de domaine, sont appelés administrateurs de service AD. Mais que se passe-t-il si un "vrai" compte d'administrateur de domaine se trouve dans une sous-OU à laquelle le personnel du service d'assistance est autorisé à réinitialiser les mots de passe des utilisateurs ? Ou pire encore, que se passe-t-il si quelqu'un n'accorde pas au service d'assistance les autorisations au niveau de la sous-OU appropriée, mais le fait à la racine du domaine ? Sans mécanisme de protection supplémentaire dans AD pour empêcher un administrateur de données, tel qu'un compte de service d'assistance, d'effectuer des modifications (telles que la réinitialisation du mot de passe) sur un administrateur de service, tel qu'un compte d'administrateur de domaine ou tout autre compte ou groupe privilégié, la sécurité globale de toute mise en œuvre d'AD serait dans un état désastreux. Tout membre du personnel du service d'assistance délégué pourrait facilement compromettre l'ensemble de l'AD.
SDPROP : la fonction de protection AD intégrée
La protection de ces objets AD privilégiés est exactement la tâche du processus Security Descriptor Propagation (SDPROP). Ce processus s'exécute périodiquement (toutes les 60 minutes par défaut, ou selon la configuration) sur chaque émulateur de contrôleur de domaine primaire (PDCE) de chaque domaine d'une forêt AD et recherche tous les objets privilégiés dans le domaine AD concerné. SDPROP ne se contente pas de vérifier l'appartenance aux groupes par défaut (tels que les administrateurs de domaine), mais continue à suivre tous les groupes imbriqués dans ces groupes privilégiés et à les marquer, ainsi que leurs membres, comme "privilégiés". Comme vous pouvez ajouter des utilisateurs, des groupes et même des objets informatiques à ces groupes privilégiés, tous ces objets sont pris en compte lors de l'analyse. Avertissement important : les objets doivent être locaux dans le même domaine que le groupe privilégié pour être pris en compte par SDPROP ; il ne faut donc pas s'attendre à la même protection pour des utilisateurs ajoutés à partir d'un autre domaine.
Pour chaque objet privilégié trouvé par SDPROP, le processus compare le nTSecurityDescriptor de l'objet à un modèle d'autorisation spécial réservé uniquement à la protection de ces objets privilégiés. Ce modèle accorde un certain nombre d'autorisations, mais il garantit surtout que seuls les administrateurs, les administrateurs de domaine et les administrateurs d'entreprise peuvent modifier le mot de passe des comptes privilégiés. Si le processus SDPROP constate un écart entre les autorisations des objets qu'il trouve et celles du modèle, il remplace le nTSecurityDescriptor de l'objet concerné par celui du modèle, puis met à jour l'attribut adminCount de l'objet avec un "1".
Dans les coulisses : AdminSDHolder
Le modèle de permission spéciale que SDPROP copie dans vos objets privilégiés est configurable. Il s'agit du nTSecurityDescriptor(permissions) de l'objet AdminSDHolder de votre domaine. Ce nom devrait vous rappeler quelque chose : il s'agit littéralement de l'objet "admin security descriptor holder", un objet conteneur situé dans le conteneur système de chaque domaine(CN=AdminSDHolder,CN=System,DC=myco mpany,DC=com). Les autorisations par défaut définies sur AdminSDHolder sont relativement restrictives en ce qui concerne les modifications apportées aux objets. C'est ce que l'on peut attendre des autorisations qui seront attribuées à tous les groupes et utilisateurs privilégiés de votre système d'archivage. L'exemple de liste d'autorisations de la figure 5 provient d'un déploiement récent d'un laboratoire de test sur Windows Server 2019 qui ne contient pas de serveurs Exchange. Si vous avez Exchange dans votre environnement, vous trouverez d'autres autorisations ajoutées à ce modèle. Après tout, les développeurs d'Exchange avaient envisagé de " posséder " l'AD pour leur application. Pour l'instant, gardez à l'esprit que les autorisations suivantes sont appliquées à tous vos objets privilégiés dans le domaine AD correspondant. Plus important encore, vous pouvez voir que cette liste de contrôle d'accès (ACL) n'a pas d'héritage activé. En d'autres termes, la liste de contrôle d'accès bloque l'héritage des autorisations définies sur un objet parent (OU), y compris les autorisations de réinitialisation du mot de passe du service d'assistance dont il a été question précédemment. Ainsi, la combinaison de SDPROP et AdminSDHolder protège vos comptes les plus privilégiés contre les permissions mal configurées dans votre AD.
Techniquement, il est possible de supprimer quelques groupes d'administrateurs par défaut dans AD et de les empêcher d'être considérés comme privilégiés par le processus SDPROP, en particulier les groupes des opérateurs de compte, des opérateurs de serveur, des opérateurs d'impression et des opérateurs de sauvegarde. Les membres ne seraient alors pas remplacés par les autorisations de l'objet AdminSDHolder. Toutefois, cette configuration n'est pas recommandée, car chaque groupe présente ses propres risques en matière d'élévation des privilèges dans AD. Ces groupes méritent d'être protégés ou, mieux encore, de ne pas être utilisés. Pour en savoir plus sur l'exclusion (ou la ré-inclusion) de ces groupes du processus SDPROP, voir l'article "Active Directory Security : Comprendre l'objet AdminSDHolder'.2
Le rôle de l'attribut AdminCount
L'attribut adminCount lui-même n'a pas d'importance en termes de sécurité. Il s'agit d'une simple fonction de support qui vous permet d'utiliser plus facilement une requête LDAP pour déterminer les autorisations des objets qui ont été remplacées par les autorisations définies sur ce modèle spécial, comme indiqué précédemment. Notez que lorsque vous supprimez un utilisateur, un groupe ou un ordinateur d'un groupe privilégié, il n'est plus privilégié. Le processus SDPROP écrit l'identifiant d'événement 4780 dans le journal des événements de sécurité du contrôleur de domaine primaire (PDC) lorsqu'il estampille les autorisations AdminSDHolder sur les objets privilégiés et met à jour ces objets avec l'attribut adminCount (défini sur 1). Cependant, il n'annule pas ces modifications lorsqu'un objet n'est plus privilégié et n'écrit pas d'événement dans le journal des événements pour vous informer qu'il n'est plus considéré comme privilégié. Par exemple, lorsque vous ajoutez temporairement quelqu'un au groupe des administrateurs du domaine et que le processus SDPROP s'exécute avant que vous ne supprimiez l'utilisateur, ce dernier aura toujours le paramètre nTSecurityDescriptor verrouillé et sera marqué par adminCount=1. Il en va de même pour tout objet. L'idéal est donc de ne pas ajouter temporairement un utilisateur à un groupe privilégié. Si vous l'avez fait, vous devez nettoyer les autorisations et l'attribut adminCount afin que l'utilisateur retrouve son état d'origine. Ce processus de nettoyage est décrit plus loin dans ce document.
Regarder de plus près les permissions du détenteur de l'administration (AdminSDHolder)
Après avoir compris ces concepts, êtes-vous satisfait des autorisations accordées par l'objet AdminSDHolder et SDPROP à tous vos comptes privilégiés ? Si vous examinez de plus près ces autorisations, même sans Exchange, vous remarquerez certaines autorisations douteuses, comme le montre la figure 6, tirée de la page des paramètres de sécurité avancés de l'objet AdminSDHolder, à laquelle vous accédez par le biais d'utilisateurs et d'ordinateurs AD ou de l'édition ADSI. Quel accès ces autres entrées marquées comme "spéciales" accordent-elles au principal de sécurité respectif dans cette liste de contrôle d'accès ? Malheureusement, l'éditeur de sécurité AD standard n'est pas très efficace pour convertir correctement la chaîne SDDL stockée dans l'attribut nTSecurityDescriptor . Même lorsque vous ouvrez l'entrée de contrôle d'accès (ACE) correspondante, ces autorisations spéciales ne sont souvent pas affichées. Vous devez donc les trouver directement via PowerShell, avec quelque chose comme (Get-Acl'AD:CN=AdminSDHolder,CN=System,D C=mydom,DC=local').access, ou en utilisant DSACLS.exe, qui ont tous deux une sortie difficile à déchiffrer. Un outil relativement simple, puissant et souvent négligé pour la gestion des ACL est LDP.exe, qui affiche parfaitement tous les ACE avec les informations pertinentes. Suivez les étapes suivantes pour afficher les autorisations appropriées de votre objet AdminSDHolder : Lancez LDP.exe ;
- Choisissez Connection > Bind (ou Ctrl + B) et Bind en tant qu'utilisateur actuellement connecté ;
- Choisissez Vue > Arbre (ou Ctrl + T) et sélectionnez votre domaine comme BaseDN ;
- Dans l'arborescence du domaine à gauche, naviguez jusqu'à Système > AdminSDHolder;
- Cliquez avec le bouton droit de la souris sur l'objet AdminSDHolder et sélectionnez Avancé > Descripteur de sécurité;
- Cliquez sur OK pour afficher le descripteur de sécurité ;
La fenêtre obtenue doit ressembler à celle de la figure 7. Si vous la comparez à la figure 6 de l'éditeur de sécurité standard, vous constaterez que même les ACE sont triés dans le même ordre. Si vous n'avez jamais mis à jour les autorisations de AdminSDHolder avec l'éditeur de sécurité par défaut (tel qu'il est utilisé dans AD users and computers et ADSIedit), l'éditeur de sécurité LDP.exe vous montre même les ACE d'accès d'origine compatibles avec Windows 2000, divisés pour de nombreux types d'objets. L'éditeur de sécurité par défaut ne peut même pas traiter correctement ces ACE et les remplace simplement par une autorisation de lecture générique sur toute autre mise à jour de l'ACL ; une fois mis à jour avec l'interface utilisateur (UI) de l'éditeur de sécurité par défaut, ces autres ACE pour ce groupe sont automatiquement supprimés. Cela ne se produit pas si l'autorisation AdminSDHolder (ou toute autre autorisation) est mise à jour avec l'éditeur de sécurité LDP.exe, de sorte qu'en général, LDP.exe est l'option la plus sûre pour mettre à jour les ACL critiques dans AD.
Vous pouvez maintenant facilement confirmer que les autorisations "everyone" et "self-permissions" ne posent aucun problème. L'autorisation de modifier le mot de passe peut sembler dangereuse mais n'indique rien d'autre que le droit de modifier le mot de passe d'un utilisateur lorsque vous connaissez l'ancien mot de passe de ce même utilisateur (contrairement à la réinitialisation du mot de passe, qui permet à un administrateur d'écraser n'importe quel mot de passe existant). Ceci dit, quel est le problème avec les ACE mis en évidence ? Le compte MSOL_5c0317387a29 (c'est-à-dire 'MSOL_' plus une chaîne aléatoire), surligné en orange dans la figure 7, est présent dans la plupart des environnements. Il s'agit d'un compte par défaut créé automatiquement lors de l'installation de l'outil Azure AD Connect, qui l'utilise pour synchroniser les objets entre Azure AD et AD sur site. Les versions antérieures d'Azure AD Connect, lors de l'utilisation de l'option d'installation express, ajoutaient automatiquement le compte à l'ACL AdminSDHolder pour permettre le contrôle des groupes et des utilisateurs privilégiés. Si vous avez configuré votre compte Azure AD Connect manuellement ou si vous utilisez une version plus récente de l'outil, il se peut que vous ne trouviez pas cette entrée.
Vous ne devez pas répliquer les comptes ou groupes AD privilégiés vers Azure AD, car cela pourrait conduire à des chemins d'attaque supplémentaires entre les deux répertoires. Si vous suivez cette règle, il n'est pas nécessaire de garder le compte de synchronisation autorisé de cette façon, vous pouvez donc supprimer l'entrée de AdminSDHolder. Le compte de synchronisation lui-même, cependant, doit être considéré comme hautement privilégié et sensible, de sorte que la suppression de l'ACL ici n'apporte pas beaucoup de réduction supplémentaire à la surface d'attaque AD. Il n'en va pas de même pour les deux entrées surlignées en rouge : les groupes access3 et authenticated users , compatibles avec les systèmes d'exploitation antérieurs à Windows 2000. Ces deux groupes bénéficient d'autorisations de lecture complètes sur tout objet privilégié dans AD. Ce n'est certainement pas l'idéal ; n'importe quel utilisateur (ou ordinateur) de votre forêt AD peut énumérer le contenu de n'importe quel groupe privilégié (par exemple Domain Admins) et dresser la liste des différentes appartenances à des groupes de n'importe quel utilisateur privilégié. C'est exactement ce qu'aiment les intrus : il est facile de déterminer à qui s'en prendre dans votre système AD et quel compte capturer et utiliser pour effectuer une attaque de type "pass-the-hash" ou autre afin de dominer le domaine et la forêt. Vos utilisateurs et vos applications professionnelles n'auront probablement jamais besoin de consulter ces informations, alors pourquoi les autoriser ?
La réponse est simple : vous ne devez pas le faire. Supprimez ces deux autorisations (y compris tous les autres ACE qui pourraient être attribués au groupe d'accès compatible pré-Windows 2000). Remplacez-les simplement par une autorisation pour un autre groupe ; par exemple, SVC-ADconfig- AdminSDHolder-READ. Faites de ce groupe un groupe local de domaine afin de pouvoir contrôler ses membres lorsque vous avez besoin d'un compte de service ou d'un objet informatique qui exécute un logiciel ayant le droit légitime de lire les données de vos objets privilégiés. L'utilisation du type de groupe local de domaine vous permet d'ajouter des utilisateurs, des groupes globaux ou universels ou des ordinateurs de n'importe quel domaine de votre forêt AD. Vous pouvez avoir besoin de cette capacité pour les logiciels ou les systèmes que vous utilisez pour surveiller ou administrer votre AD. Par exemple, si vous utilisez Semperis Directory Services Protector (DSP), vous voudrez ajouter le compte de l'ordinateur DSP à ce groupe. Mais tous les autres utilisateurs et ordinateurs ne peuvent rien lire sur vos objets privilégiés, ce qui constitue un moyen efficace de réduire la surface d'attaque de votre système d'archivage. Les intrus sont simplement empêchés d'énumérer les objets appropriés. Notez que cette action doit être répétée pour chaque domaine de votre forêt AD.
Un modèle AdminSDHolder mis à jour dans le domaine racine ressemblerait alors à la figure 8. Pour déterminer l'effet de ces changements sur votre posture de sécurité AD, vous devez utiliser les droits dont disposerait un intrus par l'intermédiaire d'un utilisateur de domaine normal avant et après la modification de l'autorisation sur l'objet AdminSDHolder dans votre environnement de production. Par souci de simplicité, cet exemple vérifie la sécurité du domaine racine d'une forêt AD, sans tenir compte des domaines enfants. En réalité, vous voudrez vérifier la sécurité de tous les domaines de la forêt.
Utilisation de puissants scanners de vulnérabilité AD
Vous pouvez facilement effectuer ces vérifications simples à l'aide d'outils gratuits : l'outil d'analyse des vulnérabilités AD Purple Knight 4, BloodHound5 et SharpHound (l'outil de collecte de données de BloodHound). Les intrus utilisent souvent une combinaison de SharpHound dans le réseau de la victime et de BloodHound sur une machine externe pour trouver le chemin d'attaque le plus court vers le groupe des administrateurs de domaine. Les deux analyses de vulnérabilité peuvent facilement être répétées dans un environnement AD, sans configuration particulière, bien que le fonctionnement de BloodHound et de ses dépendances (c'est-à-dire la base de données NEOj4, Java JDK) puisse nécessiter un effort substantiel. Purple Knight ne nécessite aucune installation au-delà du téléchargement et du décompactage du fichier .zip correspondant.
Avant d'ajuster AdminSDHolder
Cet exemple effectue les deux analyses en tant qu'utilisateur simple, JustArootUser. Cet utilisateur n'a pas de droits d'administration particuliers dans AD, mais il est un utilisateur authentifié dans la forêt AD. Ce scénario reproduit les actions d'un intrus dans votre environnement AD. La première analyse, effectuée à l'aide du site Purple Knight, révèle 29 indicateurs d'exposition (IOE), c'est-à-dire des vulnérabilités qu'un intrus pourrait utiliser pour attaquer AD (voir la figure 9). L'analyse BloodHound/SharpHound répertorie tous les comptes d'administrateurs de domaine (voir figure 10) auxquels l'utilisateur simple peut accéder, ainsi que le chemin le plus court vers le groupe des administrateurs de domaine (voir figure 11).
Après ajustement AdminSDHolder
Après avoir supprimé l'ACE pour les utilisateurs authentifiés et les groupes d'accès compatibles avec Windows 2000 de l'AdminSDHolder dans le domaine racine et ajouté l'ACE pour le groupe SVC-ADconfig- AdminSDHolder-READ, vous devez attendre que le processus SDPROP s'exécute et mettre à jour vos objets privilégiés afin que leurs attributs nTSecurityDescriptor soient mis à jour avec ceux du modèle AdminSDHolder. Ce processus prend environ une heure, mais vous pouvez déclencher manuellement la mise à jour, comme décrit plus loin dans le document. Après ces actions, une analyse de Purple Knight ne trouve que 18 IOE, soit 11 vulnérabilités de moins qu'auparavant (voir la figure 12). Maintenant que l'utilisateur simple ne peut plus énumérer le groupe des administrateurs de domaine ou ses membres, une analyse BloodHound/SharpHound montre qu'un intrus serait incapable de voir les membres du groupe ou de localiser les chemins d'attaque vers eux (voir les figures 13 et 14).
AD est-il maintenant en sécurité ?
Notez que les vulnérabilités contre les comptes privilégiés ne disparaissent pas complètement ; elles sont simplement moins visibles pour les attaquants. Mais il est devenu beaucoup plus difficile de trouver les points faibles appropriés pour attaquer votre système d'AD. Par exemple, les intrus ne peuvent plus voir quels utilisateurs privilégiés sont correctement protégés par le groupe des utilisateurs protégés - un groupe dont vous souhaitez que vos administrateurs de domaine et autres utilisateurs privilégiés soient membres, car ce groupe fait ce que son nom indique : protéger les comptes contre divers vecteurs d'attaque, tels que les attaques de type "pass-the-hash". Avec le verrouillage, les intrus ne peuvent plus planifier un chemin d'attaque détaillé vers vos comptes les plus privilégiés et doivent trouver d'autres moyens de compromettre votre AD. Ces moyens sont souvent plus complexes. Si vous avez mis en place une surveillance adéquate de votre système d'AD et de vos points d'extrémité, de telles attaques pourraient déclencher une alarme plus tôt pour l'équipe de votre centre d'opérations de sécurité (SOC). Une combinaison d'outils tels que Microsoft Defender for Identity, Semperis Directory Services Protector et SentinalOne XDR vous permettra d'aller assez loin dans ce domaine.
Ce verrouillage des autorisations ne signifie pas pour autant que vous pouvez renoncer à d'autres bonnes pratiques en matière de sécurité. Vous devez toujours prendre au sérieux la hiérarchisation de votre infrastructure AD. Au minimum, cela signifie que vos comptes à privilèges les plus élevés ne se connectent jamais à un système autre que les contrôleurs de domaine (ou d'autres systèmes de niveau 0 hautement fiables). Le masquage de l'accès à vos comptes privilégiés n'est qu'un aspect de ce type de hiérarchisation administrative et répond spécifiquement aux techniques de reconnaissance utilisées par les attaquants, telles qu'elles sont décrites dans le cadre ATT&CK de MITRE.6
Gardez également à l'esprit que l'analyse Purple Knight a encore détecté d'autres vulnérabilités potentielles, même après le verrouillage de l'AdminSDHolder. Des IOE telles que "Non-default principals with DC Sync rights on the domain" ou "Domain trust to a third-party domain without quarantine" ont encore été trouvées via les permissions standard pour les utilisateurs authentifiés sur d'autres objets du domaine - et pourraient encore être utilisées par des intrus pour planifier des attaques.
Vous n'avez pas encore terminé ...
Maintenant que vous avez créé le groupe SVC- ADconfig-AdminSDHolder-READ, vous devez encore ajouter les comptes appropriés au groupe, que vous voulez réactiver pour la lecture des objets privilégiés. Ces comptes comprennent les comptes de service à faible privilège pour les outils de sécurité et de gestion et, dans une forêt multidomaine, les administrateurs de domaine des autres domaines. Par exemple, la figure 15 montre la vue d'un administrateur de domaine d'un domaine enfant sur les objets de la racine de la forêt. Ce compte, qui s'appuyait sur les autorisations des utilisateurs authentifiés dans AdminSDHolder, n'a plus le droit de lire les groupes privilégiés du domaine racine.
Ce problème est facilement résolu en ajoutant le groupe d'administrateurs du domaine enfant (global) au groupe local SVC-ADconfig- AdminSDHolder-READ dans le domaine racine. Une fois que vous aurez verrouillé le domaine enfant, vous devrez répéter cette tâche pour ajouter le groupe d'administrateurs du domaine racine au groupe du domaine enfant - ou vous pouvez faire du groupe spécial AdminSDHolder un groupe universel dans votre domaine racine, l'utiliser sur tous les modèles AdminSDHolder dans cette forêt, et y ajouter tous les groupes d'administrateurs de domaine. C'est à vous de choisir. Il va sans dire qu'il ne faut pas activer l'héritage sur le modèle AdminSDHolder lui-même. Cela invaliderait l'ensemble de la fonctionnalité. Notez également que, tout comme vous pouvez utiliser AdminSDHolder pour verrouiller votre AD en supprimant les autorisations, les intrus peuvent également utiliser l'objet pour obtenir la persistance dans un AD compromis. Pour ce faire, un intrus crée d'abord un utilisateur discret et le cache quelque part dans la structure de votre OU. Il attribue ensuite à cet utilisateur l'autorisation de réinitialiser les mots de passe des utilisateurs dans le modèle AdminSDHolder. SDPROP fait le reste, permettant à l'intrus de garder le contrôle. Il est évident que vous devrez surveiller en permanence les modifications apportées à ce modèle. Enfin, comme nous l'avons déjà mentionné, vous devez nettoyer les administrateurs et les groupes d'administrateurs que vous avez pu générer au fil des ans.
Nettoyage des objets privilégiés : Recherche d'objets mal configurés
Les étapes suivantes vous permettent de localiser et de nettoyer les objets qui étaient auparavant considérés comme privilégiés par AD (et donc "estampillés" via SDPROP en mettant à jour leur ACL et en définissant l'attribut adminCount à "1"), mais qui ne sont plus membres d'aucun groupe privilégié :
- Mark all existing groups with admincount=1 via the telephoneNumber attribute (or some other unused attribute) so that you can more easily locate these groups again in a later stage of the clean-up: Get-ADObject-LDAPfilter “(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))”| Set-ADObject -Replace @ {telephoneNumber=“adminCount- Check-20220730”};
- Efface le paramètre actuel de l'attribut adminCount pour tous les groupes trouvés précédemment : Get- ADObject -LDAPfilter "(&(group Type:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))" | Set- ADObject -Clear "adminCount" ;
- Veillez à ce que le processus SDPROP restamplifie tous les objets pertinents : SDPROP n'effectuera une mise à jour que sur les objets pertinents lorsqu'un changement se produit dans l'ACL de la cible ou de l'AdminSDHolder. Le moyen le plus simple de s'assurer que SDPROP effectuera sa magie est d'ajouter manuellement un faux ACE (par exemple Allow 'Backup Operators' to 'List Object') dans AdminSDHolder, puis de supprimer l'ACE après votre vérification ;
- Force l'exécution de SDPROP.
Vous pouvez attendre jusqu'à 60 minutes pour que le processus SDPROP s'exécute (c'est-à-dire attendre que la planification par défaut déclenche l'opération). Vous pouvez également forcer le DC ayant le rôle PDCE FSMO à lancer le processus SDPROP à votre demande, en envoyant la commande RunProtectAdminGroupsTask au RootDSE de votre domaine. La méthode la plus simple consiste à utiliser LDP.exe en tant qu'utilisateur disposant des privilèges d'administrateur du domaine : en choisissant l'option 'run as administrator' lors du lancement, puis :
- Lancez LDP.exe en choisissant l'option Exécuter en tant qu'administrateur ;
- Sélectionnez Connexion > Connecter et entrez le DC avec le rôle d'émulateur PDC dans votre domaine ;
- Appuyez sur Ctrl + B ou sélectionnez Connection > Bind pour vous lier en tant qu'utilisateur actuellement connecté ;
- Appuyez sur Ctrl + M ou sélectionnez Parcourir > Modifier pour lancer une opération de modification ;
- Laissez DN : vide et entrez RunProtectAdminGroupsTask comme Attribut et 1 comme Valeur ;
- Choisissez Operation ADD et cliquez sur Enter ou appuyez sur Alt + E ;
- Lorsque l'entrée [Add] RunProtectAdminGroupsTask:1 apparaît dans la liste des entrées de la fenêtre Modifier (voir figure 16), cliquez sur le bouton Run pour lancer l'opération et exécuter le processus SDPROP.
- Attendez que le processus SDPROP se termine. Vous pouvez soit vérifier que
l'attribut adminCount=1 renvoie aux objets connus que vous attendez (par exemple les membres directs de votre groupe d'administrateurs de domaine), soit vérifier votre journal d'événements de sécurité sur le PDCE et valider que plus aucun événement avec l'ID 4780 (catégorie de tâche : gestion de compte d'utilisateur) n'est généré. Ces événements vous indiquent quels objets ont été réinitialisés via le processus SDPROP. - Vérifiez quels groupes n'ont pas été mis à jour en utilisant l'indicateur précédent et en ajoutant un filtre pour les groupes pour lesquels adminCount n'est pas égal à '1' : Get- ADObject-LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648)(telephoneNumber=adminCount-Check-20220730)(!(adminCount=1)))”;
- Les résultats du dernier filtre sont les objets que vous voudrez bientôt nettoyer. Ils contiennent toujours l'ACL du paramètre AdminSDHolder au moment où ils étaient un groupe privilégié, ce qui signifie également qu'ils n'héritent pas des autorisations que vous avez pu définir au niveau de l'OU ;
- Répétez la même procédure avec votre ordinateur et vos comptes utilisateurs. Il est probable que vous ne souhaitiez pas utiliser l'attribut telephoneNumber comme drapeau de contrôle AdminSDHolder temporaire sur les objets utilisateur ; peut-être que facsimileTelephoneNumber n'est plus utilisé. Le filtre LDAP approprié pour trouver les utilisateurs privilégiés serait : (&(objectClass=user) (objectCategory=person) (admincount=1)) ;
- Supprimez le faux ACE de l'objet AdminSDHolder après avoir déterminé vos objets de nettoyage.
Nettoyage des objets à privilèges : Réinitialisation des ACL sur les objets mal configurés
L'utilisation de PowerShell pour restaurer les ACL sur les objets concernés est un peu plus délicate. Il n'existe pas d'équivalent PowerShell simple à l'option "restore defaults" qui est disponible dans l'interface utilisateur des paramètres de sécurité avancés sur les objets AD. Ces valeurs par défaut sont stockées dans le schéma AD, en particulier dans l'attribut defaultSecurityDescriptor de la classe d'objet concernée. Lorsque vous cliquez sur l'option de restauration des valeurs par défaut dans l'interface utilisateur de sécurité, les autorisations de classe appropriées sont lues à partir du schéma, puis appliquées à l'objet. Si vous n'avez que quelques objets mal configurés, cette méthode peut être le moyen le plus simple de les corriger. Mais qu'en est-il si vous avez de nombreux objets de ce type à plusieurs endroits ?
Une option consiste à utiliser l'outil DSACLS avec l'option /resetDefaultDACL , qui rétablit la sécurité de l'objet à sa valeur par défaut telle qu'elle est définie dans le schéma ; cependant, il peut être difficile de mélanger les outils PowerShell et CLI. Bien que Microsoft n'ait pas créé d'équivalent PowerShell pour traiter une réinitialisation directe de l'ACL à sa valeur par défaut, vous pouvez utiliser la cmdlet Get-ACL pour récupérer l'ACL d'un autre objet de la même classe, puis appliquer cette ACL à des objets mal configurés via la cmdlet Set-ACL. En fait, vous pouvez copier et coller des ACL d'un objet à un autre via les commandes PowerShell Get-ACL et Set-ACL. Étant donné que le defaultSecurityDescriptor du schéma est également lu et utilisé lors de la création de tout nouvel objet d'une classe spécifique, vous pouvez simplement créer un objet factice dans le but de copier l'ACL. L'objet peut même être un objet désactivé puisque son état ne fait pas partie de l'ACL.
Malheureusement, vous ne pouvez pas vous contenter de canaliser la sortie de la cmdlet Get-ADObject dans la cmdlet Set-ACL, car cette dernière doit recevoir le chemin d'accès à l'objet dans un format spécifique : le nom distinctif (DN) de l'objet précédé de "AD :". Par conséquent, vous devez parcourir en boucle la liste des objets renvoyés par Get-ADObject, former le chemin d'accès approprié pour l'utiliser avec Set-ACL, puis exécuter la commande correspondante dans la boucle. Le script PowerShell suivant réinitialise les ACL des objets de classe utilisateur à celles d'un compte fictif nouvellement créé appelé DefaultUserACL (l'attribut facsimileTelephoneNumber a été précédemment signalé pour aider à localiser les comptes mal configurés).
#Set path for ACLing to AD
Set-Location AD:
#Grab ACL objects from a sample user- account (e.g. newly created account)
$DefaultAcl = (Get-Acl “AD:CN= DefaultUserACL,OU=MyOU,DC=mydo m,DC=local”)
#query for the old AdminCount objects that must get their permissions reset $OldAdminCountObjects =
Get-ADObject -LDAPfilter
“(&(objectClass=user)
(objectCategory=person)(facsimile TelephoneNumber=adminCount- Check-20220730)(!(adminCount=1)))”
#work through every object, grab the DN, create the proper ACL-DN-Path and set sample ACL on object
ForEach ($Object in $$OldAdminCountObjects){
$ACLpath = “AD:” + $Object. distinguishedName
write-host “Resetting permissions on”,
$ACLpath
Set-Acl -Path $ACLpath -AclObject
$DefaultAcl#update flag of object
Set-ADObject -Identity $Object.
distinguishedName -Replace
@{facsimileTelephoneNumber=“ACL was reset 20220730”}
}
Lorsque vous adaptez le script pour des groupes ou des ordinateurs, veillez à passer au filtre LDAP approprié avec l'attribut que vous avez choisi pour vous aider à localiser ces objets. Si vous préférez, vous pouvez ignorer la création de ces objets factices et utiliser la même logique de boucle pour exécuter les outils DSACLS, en utilisant le nom distinctif de l'objet et l'option /resetDefaultDACL . L'une ou l'autre méthode vous aidera à nettoyer correctement les anciens objets privilégiés dans votre AD.
La sécurité AD requiert une attention permanente
Ce document a pour but de vous aider à comprendre les avantages des fonctions de sécurité intégrées AdminSDHolder et SDPROP d'AD, qui protègent vos objets les plus privilégiés au sein d'AD, et comment vous pouvez verrouiller davantage ces objets pour améliorer la protection, dans le but de lutter contre la phase de reconnaissance d'une attaque. Plus il est difficile pour les intrus d'accéder à vos objets les plus privilégiés, mieux c'est. Comme indiqué, cette méthode de renforcement doit s'accompagner d'une hiérarchisation appropriée de vos comptes administratifs et d'une surveillance active de votre AD et de vos points finaux. Il a toujours été important de sécuriser votre système d'administration, et l'augmentation constante des attaques par ransomware souligne cette nécessité.
Ressources
1. Mueller, R. et Geelen, P. (septembre 2020 [novembre 2011]), 'Active Directory : LDAP Syntax Filters', Microsoft, disponible à l'adresse https://social.technet. microsoft.com/wiki/contents/articles/5392.active- directory-ldap-syntax-filters.aspx (consulté le 25 septembre 2022).
2. Smith, R. (janvier 2018), "Active Directory Security : Understanding the AdminSDHolder Object', Petri, disponible à l'adresse https://petri.com/ active-directory-security-understanding- AdminSDHolder-object (consulté le 25 septembre 2022).
3. Grillenmeier, G. (novembre 2021), "Understanding the Risks of Pre-Windows 2000 Compatibility Settings in Windows 2022", Semperis, disponible à l'adresse https://www.semperis.com/blog/security-risks- pre-windows-2000-compatibility-windows-2022/ (consulté le 25 septembre 2022).
4. Purple Knight, « Uncover Active Directory vulnerabilities before attackers do », disponible à l’https://www.semperis.com/purple-knight (consulté le 25 septembre 2022).
5. GitHub, "BloodHound 4.2.0 - Azure Refactor", disponible à l'adresse https://github.com/BloodHoundAD (consulté le 25 septembre 2022).
6. MITRE ATT&CK, "Reconnaissance", disponible à l'adresse https://attack.mitre.org/tactics/TA0043 (consulté le 25 septembre 2022).
