L'annuaire Active Directory, centre névralgique de la sécurité des systèmes d'information Microsoft, est un élément critique permettant la gestion centralisée de comptes, de ressources et de permissions. L'obtention de privilèges élevés sur cet annuaire entraîne une prise de contrôle instantanée et complète de toutes les ressources ainsi administrées.
L'analyse des modes opératoires des attaques récentes met en évidence une recrudescence du ciblage des annuaires Active Directory, compte tenu de leur rôle de pierre angulaire de la plupart des systèmes d'information. En effet, l'attaquant ayant obtenu des droits élevés sur l'annuaire peut alors déployer une charge malveillante sur l'ensemble du système d'information, notamment par GPO ou en utilisant des connexions directes (psexec, wmiexec). Par conséquent, le faible niveau de sécurité des annuaires met en danger les systèmes d'information dans leur globalité et fait porter un risque systémique aux organisations.
Les observations de l'ANSSI font apparaître un manque de maturité critique et récurrent sur la sécurité des annuaires Active Directory. Le niveau de sécurité décroît ainsi de manière importante en fonction du temps et au rythme de la manipulation de ses objets ou des actions d'administration.
En réponse à ce risque croissant, l'ANSSI a développé et met à disposition un recueil de points de contrôle, afin d'accompagner les chaines DSI et SSI dans le suivi du niveau de sécurité des annuaires Active Directory. Ce recueil a vocation à être enrichi régulièrement en fonction des travaux de recherche, des pratiques constatées en audit, et de l'analyse des modes opératoires adverses.
Chaque point de contrôle vise à vérifier l'absence d'une pratique susceptible d'affaiblir le niveau de sécurité et qui pourrait le cas échéant être utilisée dans le cadre d'une attaque. En fonction des faiblesses trouvées, l'annuaire Active Directory se voit affecté un niveau :
Pour obtenir un niveau, un annuaire Active Directory doit passer avec succès tous les points de contrôles des niveaux inférieurs. Un annuaire de niveau 5 a passé avec succès tous les points de contrôle.
Chaque point de contrôle détaillé présente les caractéristiques suivantes:
Lorsqu'elles sont applicables, les documentations officielles sont proposées pour approfondissement.
Développé par l'ANSSI, le service ADS (Active Directory Security) met à disposition des opérateurs règlementés et de la sphère publique une capacité d'audit des annuaires Active Directory visant à leur donner de la visibilité sur le niveau de sécurité de leur annuaire et à les accompagner dans son durcissement par l'application progressive de mesures adéquates, avec un suivi dans le temps. Le service ADS implémente l'ensemble des points de contrôle présentés dans ce recueil.
Un point de contrôle peut apparaître pour plusieurs niveaux de sécurité d'un Active directory. Plus le niveau visé est élevé, plus ses critères deviennent stricts. À ce jour, seuls les points permettant la validation des niveaux de sécurité 1 à 3 sont publiés. Les points de contrôle de niveaux supérieurs seront publiés lors de mises à jour futures de ce document.
La liste suivante permet de naviguer dans les points de contrôle et de consulter les recommandations associées.
L'historique des modifications est disponible ici.
Not implemented: | ||||
Not implemented: |
Niveau | titre | ID | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Chemins de contrôle dangereux vers les conteneurs de certificats | vuln_adcs_control | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les conteneurs de certificats. Ces chemins de contrôle permettent d'ajouter une autorité de certification malveillante et donc notamment d'usurper des utilisateurs ou des services. LégendeContrôle fort et immédiatContrôle indirectContrôle indirect faible | ||||||||||||||||||||||||||||||||||
recommandationLors de l'installation d'un serveur de PKI Microsoft, l'utilisateur réalisant l'installation se voit automatiquement déléguer des droits sur ces conteneurs. Il est recommandé d'enlever les permissions dangereuses sur ces conteneurs de certificats afin de revenir à un état par défaut. La correction est généralement effectuée à l'aide des consoles adsiedit.msc ou de l'utilitaire ldp. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers les modèles de certificats | vuln_adcs_template_control | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les modèles de certificats (certificate templates). Le contrôle d'un modèle de certificat permet de faire générer par l'autorité de certification un certificat arbitraire. Il est par exemple possible d'obtenir un certificat d'authentification par carte à puce pour n'importe quel utilisateur, et ainsi d'usurper son identité. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationIl est recommandé d'enlever les permissions dangereuses sur ces modèles de certificats afin de restaurer l'état par défaut. La correction est généralement effectuée à l'aide de la console adsiedit.msc, pkiview.msc ou de l'utilitaire ldp. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
1 | Permissions d'enrôlement dangereuses sur des modèles de certificats permettant l'authentification | vuln_adcs_template_auth_enroll_with_name | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes permissions d'enrôlement dangereuses existent vers des modèles de certificats utilisables pour l'authentification Windows et dont les informations de nom peuvent être arbitrairement fournies par le demandeur. Ces permissions permettent de faire générer par l'autorité de certification un certificat avec un sujet arbitraire. Il est par exemple possible d'obtenir un certificat d'authentification par carte à puce pour n'importe quel utilisateur, et ainsi d'usurper son identité. Sont listés ci-dessous les délégations accordées à des « principals » non privilégiés permettant de demander ces certificats approuvés pour de l’authentification Windows et dont le modèle de certificat permet au demandeur de spécifier un sujet arbitraire. Il est à noter que si la délégation est accordée à un principal de type Utilisateurs authentifiésAuthenticated Users, Utilisateurs du domaineDomain Users ou Ordinateurs du domaineDomain Computers la forêt peut être instantanément compromise. | ||||||||||||||||||||||||||||||||||
recommandationPlusieurs actions peuvent être entreprises pour corriger ce défaut de configuration. Celles-ci sont listées ci-dessous par ordre d’importance. Cas 1 : la CA associée n'est pas utilisée pour de l'authentification Windows par carte à puce ou RadiusLes CA approuvées pour émettre des certifications réalisant de l’authentification Windows par certificats ou PEAP/EAP-TLS avec le service Microsoft Radius IAS (Internet Authentication Service) doivent être inscrites dans le conteneur NTAuthCertificates ( https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store) Si ce n’est pas le cas, il est recommandé de supprimer la CA du conteneur NTAuthCertificates à l'aide de pkiview.msc ou certutil.exe. Notes :
Cas 2 : le demandeur ne doit pas fournir le sujet du certificatS’il
est accordé au demandeur de pouvoir fournir un sujet arbitraire,
l’autorité de certification n’effectuera aucune validation sur
l’identité du sujet spécifié. Il est recommandé de ne pas permettre au demandeur de fournir un sujet arbitraire. Cette option peut être modifiée dans les propriétés des modèles de certificat qui peuvent être édités à l'aide de la console certtmpl.msc. Cas 3: la délégation des droits est trop largeSi le modèle de certificat doit autoriser le demandeur à spécifier un sujet arbitraire et que la CA doit être approuvée pour de l’authentification Windows, une éventuelle délégation ne doit être effectuée que pour un principal privilégié. Supprimer les droits d'enrôlement dangereux sur les modèles de certificat à l'aide de la console pkiview.msc, adsiedit.msc ou de l'utilitaire ldp.exe. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. | ||||||||||||||||||||||||||||||||||
123 | Certificats faibles ou vulnérables | vuln_certificates_vuln | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéCertains certificats possèdent des problèmes et ne doivent plus être utilisés. Cette vulnérabilité peut apparaître aux niveaux 1, 2 et 3 selon le problème rencontré :
Un individu malveillant pourrait tenter d'exploiter l'une de ces vulnérabilités pour générer un certificat malveillant avec une signature valide, lui permettant d'usurper l'identité de n'importe quel utilisateur. | ||||||||||||||||||||||||||||||||||
recommandationLes conteneurs de certificats d'une forêt peuvent être édités via l'outil pkiview.msc. Cas des autorités de certifications validesIl est recommandé de révoquer les certificats problématiques et de les générer à nouveau. Les certificats enfants doivent aussi être générés à nouveau. Enfin, les certificats expirés doivent être purgés des conteneurs de confiance. Lors de la génération d'un nouveau certificat, il convient de s'assurer que :
Cas des autorités de certifications expiréesSi le certificat est expiré, il est recommandé de le supprimer de la liste des autorités reconnues de l'Active Directory. Dans le cas d'une utilisation de signature de code, l'autorité de certification peut être redéployée par GPO. | ||||||||||||||||||||||||||||||||||
1 | Objets critiques non disponibles | vuln_critical_objects | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéCertaines informations nécessaires à la génération de ce rapport ne sont pas disponibles. Pour pouvoir traiter correctement les annuaires Active Directory, le service ADS a besoin d'informations sur certains objets, en particulier :
Des modifications de droits ont été effectuées sur l'annuaire, ce qui a empêché l'utilisateur ayant effectué le relevé de voir les objets susmentionnés. Note : ce point de contrôle ne révèle pas de problème de configuration ou de vulnérabilité, mais peut fausser l'analyse. | ||||||||||||||||||||||||||||||||||
recommandationIl est recommandé d'effectuer un nouveau relevé en utilisant un compte avec un plus haut niveau de privilèges et depuis un poste d'administration s'il s'agit d'un compte d'administration. | ||||||||||||||||||||||||||||||||||
1 | Contrôleurs de domaine incohérents | vuln_dc_inconsistent_uac | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéCertains contrôleurs de domaine de la forêt possèdent des attributs dans un état incohérent. Ces incohérences peuvent être symptomatiques d'une erreur de configuration (manuelle ou par un logiciel) ou de traces de malveillance. | ||||||||||||||||||||||||||||||||||
recommandationChaque contrôleur de domaine doit posséder les caractéristiques suivantes :
La correction est généralement effectuée à l'aide de l'utilitaire ldp. Note : certains éditeurs créent pour leurs produits des configurations de ce type. C'est notamment le cas pour l'éditeur Riverbed. | ||||||||||||||||||||||||||||||||||
1 | Délégation d'authentification contrainte vers un service d'un contrôleur de domaine | vuln_delegation_a2d2 | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes possèdent des délégations d'authentification contraintes vers un service d'un contrôleur de domaine. Elles permettent au compte d'élever ses privilèges auprès du contrôleur de domaine. | ||||||||||||||||||||||||||||||||||
recommandationLa délégation d'authentification contrainte permet à un compte de s'authentifier auprès d'un service Kerberos avec l'identité d'un autre utilisateur (s'étant préalablement authentifié auprès de ce compte). Si cette délégation est autorisée vers une ressource privilégiée (notamment un service présent sur un contrôleur de domaine), elle permet au compte d'élever ses privilèges et de compromettre la forêt. La délégation d'authentification contrainte vers un service d'un contrôleur de domaine ne doit pas être utilisée. Pour les comptes concernés, il faut supprimer dans l'attribut msDS-AllowedToDelegateTo tous les Service Principal Name (SPN) référençant les contrôleurs de domaine. Cette opération peut être effectuée directement à partir de l'onglet « Délégation » de la console de gestion des utilisateurs et ordinateurs. | ||||||||||||||||||||||||||||||||||
1 | Délégation contrainte basée sur les ressources, sur des contrôleurs de domaine | vuln_delegation_sourcedeleg | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéSur les contrôleurs de domaine, la délégation contrainte basée sur les ressources (resource-based constrained delegation) est configurée. Cette configuration accorde à des comptes une délégation complète vers les contrôleurs de domaine. | ||||||||||||||||||||||||||||||||||
recommandationLa délégation vers des ressources privilégiées (par exemple un service d'un contrôleur de domaine) ne doit pas être utilisée. Contrairement aux autres types de délégations reposant sur un Service Principal Name (SPN), la délégation contrainte basée sur les ressources est implémentée avec un descripteur de sécurité sur la ressource cible. Ce descripteur de sécurité est stocké dans l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity sur l'ordinateur cible. Pour retirer cette délégation, il est nécessaire de supprimer l'attribut. Cette modification peut être réalisée en PowerShell. Par exemple, la commande Set-ADComputer MACHINE -PrincipalsAllowedToDelegateToAccount $Null permet de retirer cette délégation autorisée sur une machine appelée MACHINE. | ||||||||||||||||||||||||||||||||||
1 | Délégation d'authentification contrainte avec transition de protocole vers un service privilégié | vuln_delegation_t2a4d | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes possèdent des délégations d'authentification contraintes avec transition de protocole vers un service privilégié. Elles permettent au compte d'élever ses privilèges. Les services privilégiés considérés sont :
| ||||||||||||||||||||||||||||||||||
recommandationLa délégation d'authentification contrainte avec transition de protocole permet à un compte de s'authentifier auprès d'un service Kerberos avec l'identité d'un autre utilisateur. Si cette délégation est autorisée vers une ressource privilégiée (notamment un service présent sur un contrôleur de domaine), elle permet au compte d'élever ses privilèges et de compromettre la forêt. La délégation d'authentification contrainte vers un service d'un contrôleur de domaine ne doit pas être utilisée. Pour les comptes concernés, il faut supprimer dans l'attribut msDS-AllowedToDelegateTo tous les Service Principal Name (SPN) référençant les contrôleurs de domaine. Cette opération peut être effectuée directement à partir de l'onglet « Délégation » de la console de gestion des utilisateurs et ordinateurs. | ||||||||||||||||||||||||||||||||||
1 | Présence de Display Specifiers dangereux | vuln_display_specifier | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLes objets Display Specifiers permettent de modifier les menus de la console d'administration dsa.msc et d'exécuter des objets COM ou des scripts. La forêt contient des objets Display Specifiers pointant sur des scripts situés sur des serveurs de fichiers (hors du sysvol) : | ||||||||||||||||||||||||||||||||||
recommandationLes scripts présents dans les objets Display Specifiers doivent être supprimés ou déplacés sur le partage sysvol d'un contrôleur de domaine. | ||||||||||||||||||||||||||||||||||
1 | Permissions dangereuses sur le groupe DnsAdmins | vuln_dnsadmins | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéPlusieurs comptes non privilégiés sont membres du groupe DnsAdmins ou possèdent des droits dangereux sur celui-ci. Les membres du groupe DnsAdmins disposent de nombreux droits pour gérer le service DNS Microsoft, qui est généralement hébergé par un contrôleur de domaine. Parmi ces droits, il est possible de gérer l'intégralité des enregistrements des zones DNS ayant une portée domaine, d'employer des fonctionnalités de debug du serveur, voire non documentées, comme par exemple la possibilité de faire redémarrer instantanément ou d'arrêter le service DNS. Enfin, selon le niveau de mise à jour du système d'exploitation de l'intégralité des serveurs DNS en production, ou de la configuration locale du service DNS, il peut toujours être possible de faire exécuter du code arbitraire via la fonctionnalité serverlevelplugindll. Malgré la disponibilité d'un correctif auprès de Microsoft, ces fonctionnalités dangereuses peuvent toujours être réactivées. Il est donc impossible d'évaluer l'innocuité du paramétrage uniquement par l'étude de la configuration dans l'Active Directory, tout comme il est impossible de vérifier avec certitude que l'ensemble des serveurs DNS Microsoft soient à jour. L'ensemble de ces possibilités donne des capacités de nuisance significatives, voire facilite des attaques réseau, et justifient donc de considérer ce groupe comme étant privilégié. | ||||||||||||||||||||||||||||||||||
recommandationIl est recommandé de ne pas utiliser le groupe DNSAdmin. Une délégation doit être créée pour la gestion du DNS (création/suppression de zones, gestion des enregistrements, etc.), généralement effectuée à l'aide de l'utilitaire ldp. Cette délégation peut être effectuée en deux étapes. Étape 1: autoriser l'accès aux RPC nécessaires à l'utilisation des composants enfichables de gestion DNSDans la partition du domaine, dans le conteneur CN=System, déléguer les droits suivants sur le conteneur CN=MicrosoftDNS : Étape 2: autoriser la modification de la zone DNSDans la partition DC=DomainDnsZones, sur chaque zone ayant besoin d'être administrée, déléguer les droits suivants avec héritage sur le conteneur CN=MicrosoftDNS : Attention à ne pas oublier également de déléguer les zones inverses (reverse DNS). Note : pour changer de naming context (partition) dans ldp, il faut utiliser le menu affichage, arborescence et utiliser le menu déroulant pour sélectionner DomainDnsZones. De plus, les opérations suivantes sont à réaliser sur le groupe DnsAdmins :
Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Cas particulier de Microsoft Exchange ServerCertains chemins de contrôle qui apparaissent peuvent être liés à des groupes Exchange bénéficiant de permissions dangereuses. Deux cas particuliers peuvent se présenter :
Les contrôles suivants, uniquement s'ils sont mentionnés pour un groupe lié à Exchange, ont fait l'objet d'un correctif de Microsoft :
Attention : certaines des propriétés LDAP concernées par ces écritures (servicePrincipalName et altSecurityIdentities) font partie du property-set Public-Information. Ainsi, les permissions d'écritures peuvent être attribuées pour chaque attribut unitairement ou le property-set entier, auquel cas seul ce dernier sera visible dans la DACL de l'objet concerné. Pour appliquer ce correctif, il est nécessaire d'effectuer les actions suivantes :
Pour tout autre chemin de contrôle, une qualification manuelle doit être effectuée pour caractériser le problème. À titre d'information, la liste des derniers correctifs publiés pour Exchange Server est disponible ici. Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
13 | Zones DNS mal configurées | vuln_dnszone_bad_prop | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes zones DNS présentent des problèmes de configuration. Par exemple, la valeur ZONE_UPDATE_UNSECURE (propriété DSPROPERTY_ZONE_ALLOW_UPDATE) permet la mise à jour d'un enregistrement DNS sans authentification. Un individu malveillant peut utiliser cette vulnérabilité pour :
Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationSi la propriété DSPROPERTY_ZONE_ALLOW_UPDATE vaut ZONE_UPDATE_UNSECURE, il est recommandé de reconfigurer les zones DNS pour n'autoriser que les mises à jour sécurisées avec la commande suivante: dnscmd <servername> /Config <zone> /AllowUpdate 2 | ||||||||||||||||||||||||||||||||||
1 | Comptes privilégiés dont le mot de passe n'expire jamais | vuln_dont_expire_priv | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéCertains comptes privilégiés possèdent des mots de passe n'expirant pas. Si aucun mécanisme de sécurité ne force le changement de ces mots de passe, la récupération d'un compte privilégié permet à un individu malveillant de conserver ces droits d'accès au domaine sur le long terme. | ||||||||||||||||||||||||||||||||||
recommandationCas généralIl est recommandé de changer régulièrement les mots de passe des membres des groupes privilégiés (au maximum tous les 3 ans). Afin que la politique de mot de passe du domaine soit imposée sur ces comptes, la propriété DONT_EXPIRE ne doit pas être positionnée. Il convient donc de supprimer cette propriété pour ces comptes et de renouveler régulièrement leur mot de passe dès la suppression de la propriété. Cette action peut être effectuée en décochant la case « Le mot de passe n'expire jamais » dans les propriétés du compte de l'utilisateur (onglet compte). Note importante : il est déconseillé de forcer ce renouvellement trop fréquemment (quelques mois). Une demande de renouvellement trop fréquente induit statistiquement un nouveau choix de mot de passe plus faible, ce qui en fait une mesure de sécurité contre-productive. La fréquence de changement doit être adaptée en fonction du contexte d'emploi du compte. La politique de mot de passe imposée par le domaine peut être soit globale, soit affinée via le mécanisme des Password Settings Object (PSO). Cas particuliersSi la propriété DONT_EXPIRE a été positionnée car le changement de mot de passe de ces comptes n'est pas possible facilement, cela peut signifier que ces comptes ne sont pas utilisés pour des opérations d'administration (par exemple, des comptes de service). Ces comptes ne doivent en aucun cas être membres d'un groupe privilégié. Il convient de :
Cas des comptes non utilisésIl est nécessaire de neutraliser les comptes qui ne sont plus utilisés. La méthode suivante de neutralisation apporte les mêmes avantages que la suppression tout en conservant la traçabilité offerte par la simple désactivation. Pour neutraliser un compte, il faut :
Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
123 | Paramètres dSHeuristics dangereux | vuln_dsheuristics_bad | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes paramètres dangereux sont configurés dans l'attribut dSHeuristics. Cette vulnérabilité peut apparaître aux niveaux 1 et 2 selon le problème rencontré :
| ||||||||||||||||||||||||||||||||||
recommandationL'attribut dSHeuristics permet de définir des heuristiques qui sont utilisées pour déterminer le fonctionnement de certains mécanismes de l'Active Directory. Par exemple :
Les paramètres dangereux configurés dans la propriété dSHeuristics doivent être modifiés et réinitialisés à leur valeur par défaut :
La correction est généralement effectuée à l'aide des consoles adsiedit.msc ou de l'utilitaire ldp. | ||||||||||||||||||||||||||||||||||
134 | Niveaux fonctionnels de la forêt et des domaines insuffisants | vuln_functional_level | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLe niveau fonctionnel de la forêt ou des domaines est insuffisant. L'utilisation d'un niveau fonctionnel Active Directory faible prive la forêt de fonctionnalités de sécurité importantes. Seuils de toléranceCe point de contrôle apparaît selon des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationDans les environnements Active Directory, certains mécanismes sont liés aux niveaux fonctionnels qui peuvent être au niveau forêt ou domaine. Les niveaux fonctionnels sont caractérisés par un chiffre allant de 0 (Windows 2000) à 7 (Windows 2016 / 2019 / 2022). Afin de bénéficier des dernières fonctionnalités de sécurité, il est important d'augmenter les niveaux fonctionnels des domaines ainsi que de la forêt. Chaque niveau fonctionnel apporte des fonctionnalités de sécurité :
Pour augmenter le niveau fonctionnel d'un domaine, il est nécessaire de mettre à niveau l'ensemble des contrôleurs de domaine vers un système d'exploitation supportant le niveau désiré et de réaliser une migration au niveau fonctionnel supérieur. De même, pour augmenter le niveau fonctionnel d'une forêt, il est nécessaire que l'ensemble des domaines soient dans un niveau fonctionnel équivalent ou supérieur. Note : il est nécessaire de vérifier la compatibilité du niveau fonctionnel avec les logiciels tiers installés. Par exemple, pour Microsoft Exchange : matrice de compatibilité. | ||||||||||||||||||||||||||||||||||
1 | Comptes privilégiés sans préauthentification Kerberos | vuln_kerberos_properties_preauth_priv | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes privilégiés n'imposent pas la préauthentification Kerberos. | ||||||||||||||||||||||||||||||||||
recommandationLa préauthentification permet de s'assurer que l'utilisateur connaît un de ses secrets d'authentification lors d'une demande de TGT (ticket Kerberos obtenu auprès d'un contrôleur de domaine). Sans préauthentification il est possible d'obtenir un ticket chiffré avec un des secrets associés au compte correspondant. Il est ensuite possible de lancer une attaque afin de retrouver le mot de passe de l'utilisateur, ce qui peut être facilité s'il n'est pas assez robuste. La propriété DONT_REQUIRE_PREAUTH doit être supprimée pour ces comptes et le mot de passe doit être changé. Par défaut, tous les comptes utilisateur imposent la préauthentification car la propriété DONT_REQUIRE_PREAUTH n'est pas positionnée. Cette propriété ne doit jamais être positionnée pour les comptes privilégiés du domaine. En cas d'incompatibilité avec une application, celle-ci doit faire l'objet d'une évolution applicative. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
1 | Contrôleurs de domaine dont le mot de passe de compte d'ordinateur est inchangé depuis plus de 45 jours | vuln_password_change_dc_no_change | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes contrôleurs de domaine n'ont pas changé le mot de passe de leur compte d'ordinateur depuis plus de 45 jours, ce qui indique que leurs secrets ne sont pas renouvelés. | ||||||||||||||||||||||||||||||||||
recommandationDans leur fonctionnement par défaut, les contrôleurs de domaine changent automatiquement le mot de passe de leur compte d'ordinateur périodiquement (30 jours par défaut). Il convient d'investiguer la raison qui empêche le contrôleur de domaine de changer son mot de passe. Une première vérification consiste à vérifier la valeur des entrées de Registre suivantes :
Si ces valeurs sont incorrectes, il convient de les remettre aux valeurs par défaut et de s'assurer qu'elles ne sont pas positionnées par une GPO. Si ces valeurs sont correctes, vérifier si le service NETLOGON est démarré avec sc.exe query netlogon. | ||||||||||||||||||||||||||||||||||
1 | Contrôleurs de domaines inactifs | vuln_password_change_inactive_dc | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes contrôleurs de domaine ne se sont pas authentifiés depuis plus de 45 jours. | ||||||||||||||||||||||||||||||||||
recommandationDans leur fonctionnement par défaut, les contrôleurs de domaine doivent s'authentifier et changer automatiquement leur mot de passe sur le domaine tous les 30 jours. L'absence d'authentification au domaine est symptomatique d'une machine désynchronisée. Les contrôleurs de domaine désynchronisés du domaine doivent être réinstallés ou supprimés. Dans le cas d'une réinstallation, afin d'éviter le chemin de contrôle de type OWNER du compte d'ordinateur, il est recommandé d'effectuer une jonction de domaine hors connexion à l'aide de l'utilitaire Djoin. | ||||||||||||||||||||||||||||||||||
1 | Comptes privilégiés dont le mot de passe est inchangé depuis plus de 3 ans | vuln_password_change_priv | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa date de dernier changement du mot de passe de comptes privilégiés est supérieure à 3 ans. | ||||||||||||||||||||||||||||||||||
recommandationCas généralAfin de limiter l'impact en cas de vol d'un mot de passe, il est nécessaire de mettre en œuvre une politique de renouvellement des mots de passe pour les comptes privilégiés. La durée de ce renouvellement doit être inférieure à 3 ans. Le compte « Administrateur intégré » (RID 500, utilisé en tant que compte bris de glace ne devant jamais être utilisé sauf en de rares exceptions) doit également faire l'objet d'un changement de mot de passe tous les 3 ans. En effet il est important de s'assurer régulièrement que celui-ci est toujours accessible et que les procédures associées à son utilisation sont toujours correctes. Note importante : il est déconseillé de forcer ce renouvellement trop fréquemment (quelques mois). Une demande de renouvellement trop fréquente induit statistiquement un nouveau choix de mot de passe plus faible, ce qui en fait une mesure de sécurité contre-productive. Cas des comptes de serviceS'il s'agit d'un compte de service où le changement de mot de passe n'est pas possible, il convient de :
Cas des comptes non utilisésIl est nécessaire de neutraliser les comptes qui ne sont plus utilisés. Cette méthode de neutralisation apporte les mêmes avantages que la suppression tout en conservant la traçabilité offerte par la simple désactivation. Pour neutraliser un compte, il faut :
Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
12 | Permissions dangereuses sur l'objet adminSDHolder | vuln_permissions_adminsdholder | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes permissions dangereuses existent sur l'objet adminSDHolder. Ces permissions permettent aux comptes concernés de prendre le contrôle complet de l'Active Directory. Dans un modèle d'administration en niveaux (tiered administrative model), ces permissions cassent l'étanchéité du Tier 0. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationCas généralLes permissions de l'objet adminSDHolder sont régulièrement appliquées sur l'ensemble des objets protégés (membres des groupes administratifs et opératifs) de l'Active Directory. Par défaut, seuls les objets privilégiés possèdent des droits sur l'objet adminSDHolder. Ainsi, ce mécanisme permet de protéger les utilisateurs et les groupes les plus privilégiés de l'Active Directory. Il est fortement déconseillé de changer les permissions par défaut de cet objet. Ainsi il est recommandé d'enlever les permissions dangereuses sur l'objet adminSDHolder afin de revenir à un état par défaut. La correction est généralement effectuée à l'aide du composant logiciel enfichable ADSI Edit ou de l'utilitaire ldp. Cas particuliersDans le cadre de la mise en œuvre de forêts d'administration, il est toléré d'ajouter des droits à un groupe sur l'adminSDHolder aux conditions suivantes :
Si une permission est liée à Exchange (par exemple WRITE_SPN), il est nécessaire d'appliquer les mises à jour Exchange ad hoc. La documentation relative aux permissions Exchange positionnées sur l'objet adminSDHolder est accessible à cette URL :
Si les permissions concernent un compte Azure ADConnect (MSOL), il est nécessaire de reconfigurer les droits dans l'AD relatifs au compte MSOL spécifié. La documentation relative aux comptes Azure ADConnect (MSOL) est accessible à cette URL :
Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Cas particulier de Microsoft Exchange ServerCertains chemins de contrôle qui apparaissent peuvent être liés à des groupes Exchange bénéficiant de permissions dangereuses. Deux cas particuliers peuvent se présenter :
Les contrôles suivants, uniquement s'ils sont mentionnés pour un groupe lié à Exchange, ont fait l'objet d'un correctif de Microsoft :
Attention : certaines des propriétés LDAP concernées par ces écritures (servicePrincipalName et altSecurityIdentities) font partie du property-set Public-Information. Ainsi, les permissions d'écritures peuvent être attribuées pour chaque attribut unitairement ou le property-set entier, auquel cas seul ce dernier sera visible dans la DACL de l'objet concerné. Pour appliquer ce correctif, il est nécessaire d'effectuer les actions suivantes :
Pour tout autre chemin de contrôle, une qualification manuelle doit être effectuée pour caractériser le problème. À titre d'information, la liste des derniers correctifs publiés pour Exchange Server est disponible ici. Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers les contrôleurs de domaine | vuln_permissions_dc | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéCas généralDes chemins de contrôle dangereux existent vers les contrôleurs de domaine. Cela permet aux comptes concernés de prendre le contrôle complet de l'Active Directory. Un attaquant peut, par exemple, répliquer l'ensemble des secrets (dont ceux des Administrateurs du domaineDomain Admins), les réutiliser et ainsi prendre le contrôle complet du domaine. Cas des contrôleurs de domaine en lecture seuleDans le cas particulier des contrôleurs de domaine en lecture seule (RODC), un attaquant peut répliquer l'ensemble des secrets autorisés sur ce RODC et en devenir administrateur local. Le contrôle MANAGED_BY permet d'être administrateur local du RODC. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationIl convient de considérer les comptes ayant des permissions sur les contrôleurs de domaine comme étant privilégiés. Il est alors nécessaire de les protéger avec le mécanisme de l'adminSDHolder. Pour cela, ces comptes doivent appartenir au groupe Administrateurs de l'entrepriseEnterprise Admins ou Administrateurs du domaineDomain Admins. Dans le cadre de la mise en place de forêts d'administration, il est toléré d'ajouter des droits sur les contrôleurs de domaine aux conditions suivantes :
Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Cas particulier de Microsoft Exchange ServerCertains chemins de contrôle qui apparaissent peuvent être liés à des groupes Exchange bénéficiant de permissions dangereuses. Deux cas particuliers peuvent se présenter :
Les contrôles suivants, uniquement s'ils sont mentionnés pour un groupe lié à Exchange, ont fait l'objet d'un correctif de Microsoft :
Attention : certaines des propriétés LDAP concernées par ces écritures (servicePrincipalName et altSecurityIdentities) font partie du property-set Public-Information. Ainsi, les permissions d'écritures peuvent être attribuées pour chaque attribut unitairement ou le property-set entier, auquel cas seul ce dernier sera visible dans la DACL de l'objet concerné. Pour appliquer ce correctif, il est nécessaire d'effectuer les actions suivantes :
Pour tout autre chemin de contrôle, une qualification manuelle doit être effectuée pour caractériser le problème. À titre d'information, la liste des derniers correctifs publiés pour Exchange Server est disponible ici. Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers les paramètres DFSR du SYSVOL | vuln_permissions_dfsr_sysvol | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les paramètres du moteur de réplication de fichiers de Microsoft (DFSR) du volume système (SYSVOL). Un attaquant peut enregistrer un nouveau réplica DFS du SYSVOL, modifier son contenu et enfin forcer une synchronisation de celui-ci. Les modèles de stratégie de groupe et / ou les scripts ainsi modifiés seront appliqués (par exemple, sur les contrôleurs de domaine) par les GPO ad hoc, ce qui permet de prendre le contrôle total du domaine. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationIl est fortement déconseillé de changer les permissions par défaut de cet objet. Ainsi il est recommandé d'enlever les permissions dangereuses sur les paramètres DFSR du SYSVOL afin de revenir à un état par défaut. La correction est généralement effectuée à l'aide du composant logiciel enfichable ADSI Edit ou de l'utilitaire ldp. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers les clés DPAPI | vuln_permissions_dpapi | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les clés DPAPI. Si un attaquant obtient la clé DPAPI du domaine, il est en mesure de déchiffrer l'ensemble des secrets protégés par DPAPI, moyennant un accès préalable à cette donnée chiffrée. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationMicrosoft Windows fournit un mécanisme de protection des données (DPAPI) dont l'objectif est de protéger des données (souvent des fichiers ou des mots de passe) d'un utilisateur ou d'un processus système. DPAPI est, par exemple, utilisée par le gestionnaire de mots de passe de Windows, plusieurs navigateurs web, plusieurs messageries de discussion instantanées, le stockage des clés Wi-Fi et les certificats. Les données protégées sont chiffrées par une clé appelée master key, qui elle-même est protégée par le mot de passe de l'utilisateur ou une clé du domaine (backup key). Note : le mécanisme DPAPI est réputé robuste et n'est pas remis en question par ce point. Il est fortement déconseillé de modifier les permissions par défaut des clés DPAPI. Ainsi il recommandé d'enlever les permissions dangereuses sur ces clés afin de revenir à un état par défaut. La correction est généralement effectuée à l'aide du composant logiciel enfichable ADSI Edit ou de l'utilitaire ldp. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers les clés gMSA | vuln_permissions_gmsa_keys | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les clés des group managed service accounts (gMSA). Un attaquant ayant un contrôle sur ces clés est en mesure de récupérer le mot de passe des gMSA associés à ces clés. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationLes comptes membres des gMSA héritent de certaines propriétés des classes utilisateurs et ordinateurs et permettent donc plus de souplesse au niveau de la gestion des comptes de services. Les gMSA utilisent le service de distribution de clés (KDS) pour créer et gérer les mots de passe des comptes. Les mots de passe de ces comptes sont dérivés d'une clé gérée par le KDS. Il est fortement déconseillé de modifier les permissions par défaut de ces objets. Ainsi il recommandé d'enlever les permissions dangereuses sur ceux-ci afin de retourner à un état par défaut. La correction peut être effectuée à l'aide de la commande Dsacls <DN> /S /T. Cette commande restaure les permissions par défaut à partir du schéma. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers la racine des naming contexts | vuln_permissions_naming_context | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les racines LDAP de l'Active Directory, appelées naming contexts. Selon le contrôle appliqué sur le naming context, un attaquant peut prendre le contrôle complet de l'Active Directory. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationUn annuaire Active Directory contient plusieurs partitions appelées naming contexts :
Il est fortement déconseillé de changer les permissions par défaut de la racine des naming contexts. Ainsi il est recommandé d'enlever ces permissions dangereuses. La correction est généralement effectuée à l'aide du composant logiciel enfichable ADSI Edit ou de l'utilitaire ldp. Certaines de ces permissions, notamment relatives au service Microsoft Exchange, peuvent faire l'objet de correctifs de sécurité qu'il est nécessaire d'appliquer. C'est notamment le cas lorsque les objets suivants sont concernés :
Documentation relative aux permissions Exchange positionnées sur la racine des domaines : Documentation relative aux comptes Azure ADConnect (MSOL) :
Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Cas particulier de Microsoft Exchange ServerCertains chemins de contrôle qui apparaissent peuvent être liés à des groupes Exchange bénéficiant de permissions dangereuses. Deux cas particuliers peuvent se présenter :
Les contrôles suivants, uniquement s'ils sont mentionnés pour un groupe lié à Exchange, ont fait l'objet d'un correctif de Microsoft :
Attention : certaines des propriétés LDAP concernées par ces écritures (servicePrincipalName et altSecurityIdentities) font partie du property-set Public-Information. Ainsi, les permissions d'écritures peuvent être attribuées pour chaque attribut unitairement ou le property-set entier, auquel cas seul ce dernier sera visible dans la DACL de l'objet concerné. Pour appliquer ce correctif, il est nécessaire d'effectuer les actions suivantes :
Pour tout autre chemin de contrôle, une qualification manuelle doit être effectuée pour caractériser le problème. À titre d'information, la liste des derniers correctifs publiés pour Exchange Server est disponible ici. Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers les objets du schéma | vuln_permissions_schema | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les objets du schéma. Un attaquant ayant un contrôle sur le schéma peut prendre le contrôle complet de l'Active Directory. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationLe schéma est l'une des trois partitions (appelées aussi naming context) de l'Active Directory. Il contient la définition de tous les objets de la forêt Active Directory. Il est fortement déconseillé de changer les permissions par défaut de ces objets sauf dans le cadre d'une préparation de forêt lors de la mise à jour du niveau fonctionnel de la forêt ou lors de l'installation d'un composant. Ainsi il est recommandé d'enlever les permissions dangereuses sur les objets du schéma afin de revenir à un état par défaut. La correction peut être effectuée à l'aide de la commande Dsacls <DN> /S /T. Cette commande restaure les permissions par défaut à partir du schéma. Descripteurs de sécurité par défaut :
Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
1 | Chemins de contrôle dangereux vers les serveurs MicrosoftDNS | vuln_permissions_msdns | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers les serveurs DNS Microsoft. Les comptes ayant le droit d'écrire les propriétés du conteneur CN=MicrosoftDNS,CN=System ont la possibilité de faire exécuter du code arbitraire par le service DNS, qui est généralement hébergé par un contrôleur de domaine. Par défaut, les membres du groupe DnsAdmins ont ce droit. LégendeContrôle fort et immédiatContrôle indirectContrôle indirect faible | ||||||||||||||||||||||||||||||||||
recommandationIl est recommandé de retirer la permission d'écriture sur les propriétés du conteneur CN=MicrosoftDNS,CN=System pour ces comptes. Si la mise en place d'une telle permission a été faite pour la gestion du DNS, il est possible de créer une délégation manuellement. Cette délégation est généralement effectuée à l'aide de l'utilitaire ldp et elle peut être effectuée en deux étapes. Étape 1: autoriser l'accès aux RPC nécessaires à l'utilisation des composants enfichables de gestion DNSDans la partition du domaine, dans le conteneur CN=System, déléguer les droits suivants sur le conteneur CN=MicrosoftDNS : Étape 2: autoriser la modification de la zone DNSDans la partition DC=DomainDnsZones, sur chaque zone ayant besoin d'être administrée, déléguer les droits suivants avec héritage sur le conteneur CN=MicrosoftDNS : Attention à ne pas oublier également de déléguer les zones inverses (reverse DNS). Note : pour changer de naming context (partition) dans ldp, il faut utiliser le menu affichage, arborescence et utiliser le menu déroulant pour sélectionner DomainDnsZones. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
1 | Chemins de contrôle dangereux vers les GPO s'appliquant aux membres des groupes privilégiés | vuln_permissions_gpo_priv | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers des GPO s'appliquant aux membres des groupes privilégiés. Un attaquant ayant le contrôle sur ces GPO peut exécuter du code sur les machines utilisées par ces membres et élever ses privilèges. LégendeContrôle fort et immédiatContrôle indirectContrôle indirect faible | ||||||||||||||||||||||||||||||||||
recommandationIl est recommandé de revoir les permissions positionnées sur les GPO. La correction doit être effectuée à l'aide du composant logiciel enfichable de gestion des GPO gpmc.msc afin de maintenir la synchronisation des permissions entre l'annuaire LDAP et le répertoire SYSVOL. La correction s'effectue dans l'onglet "Délégation", il est toutefois recommandé d'utiliser la vue "avancée" de cet éditeur. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
1 | Comptes avec un PrimaryGroupID inférieur à 1000 | vuln_primary_group_id_1000 | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéCertains utilisateurs ou ordinateurs ont un attribut primaryGroupId en dehors des valeurs par défaut recommandées. Les primaryGroupId inférieurs à 1000 sont souvent privilégiés. | ||||||||||||||||||||||||||||||||||
recommandationDans le fonctionnement d'un Active Directory, l'attribut primaryGroupId d'un compte utilisateur ou machine permet d'affecter implicitement ce compte à un groupe, même si ce groupe n'est pas répertorié par l'attribut memberOf de l'utilisateur. L'appartenance à un groupe via cet attribut n'apparaît pas dans la liste des membres du groupe dans certaines interfaces. Cet attribut peut permettre de dissimuler l'appartenance d'un compte à un groupe. Il est recommandé de repositionner les attributs primaryGroupId des utilisateurs ou ordinateurs concernés à leur valeur par défaut :
| ||||||||||||||||||||||||||||||||||
12 | Nombre important de membres des groupes privilégiés | vuln_privileged_members | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa forêt contient trop de comptes privilégiés (? comptes). Le seuil est fixé à 50 comptes ou à 3 fois le nombre de domaines de la forêt. La présence d'un nombre important de comptes privilégiés ne permet pas d'en assurer le contrôle : cela induit une mauvaise visibilité des comptes privilégiés réellement nécessaires, une augmentation du risque d'oubli de désactivation ou de suppression d'un compte non utilisé, etc. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationLes groupes privilégiés de l'Active Directory permettent aux utilisateurs qui en sont membres de posséder tous les droits et privilèges sur la forêt. L'utilisation de ces groupes, à l'exception des groupes « AdministrateursAdministrators » et « Administrateurs du domaineDomain Admins », procure donc un faux sentiment de sécurité. Il est nécessaire de mettre en place un modèle d'administration permettant de réduire le nombre de comptes privilégiés. Pour cela, il convient de référencer les besoins d'administration de chaque compte et de faire les délégations ad hoc. Par exemple, pour un administrateur ayant besoin de créer et de supprimer des utilisateurs, les délégations nécessaires seront :
Cette délégation est généralement effectuée à l'aide de l'utilitaire ldp. Note : l'« Assistant Délégation de contrôle » de l'Active Directory permet également de déléguer certaines actions d'administration. Bien que plus facile d'utilisation, cet assistant positionne trop de privilèges pour certaines délégations. Il est donc conseillé de privilégier l'utilitaire ldp. Enfin, les règles d'appartenance suivantes doivent être mises en œuvre :
Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
12 | Chemins de contrôle dangereux vers des membres de groupes privilégiés | vuln_privileged_members_perm | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers des membres de groupes privilégiés. Ces chemins de contrôle correspondent à des droits ou privilèges permettant à des utilisateurs non privilégiés de prendre le contrôle de comptes privilégiés. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationLa plupart des chemins de contrôle cités dans cette vulnérabilité sont également liés aux vulnérabilités « Permissions dangereuses sur l'objet adminSDHolder » et « Chemins de contrôle dangereux vers les contrôleurs de domaine ». L'application des recommandations associées à ces vulnérabilités corrigera une majorité de ces chemins. Pour les chemins restants, il est recommandé d'enlever ces permissions dangereuses. La correction est généralement effectuée à l'aide du composant logiciel enfichable ADSI Edit ou de l'utilitaire ldp. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Cas particulier de Microsoft Exchange ServerCertains chemins de contrôle qui apparaissent peuvent être liés à des groupes Exchange bénéficiant de permissions dangereuses. Deux cas particuliers peuvent se présenter :
Les contrôles suivants, uniquement s'ils sont mentionnés pour un groupe lié à Exchange, ont fait l'objet d'un correctif de Microsoft :
Attention : certaines des propriétés LDAP concernées par ces écritures (servicePrincipalName et altSecurityIdentities) font partie du property-set Public-Information. Ainsi, les permissions d'écritures peuvent être attribuées pour chaque attribut unitairement ou le property-set entier, auquel cas seul ce dernier sera visible dans la DACL de l'objet concerné. Pour appliquer ce correctif, il est nécessaire d'effectuer les actions suivantes :
Pour tout autre chemin de contrôle, une qualification manuelle doit être effectuée pour caractériser le problème. À titre d'information, la liste des derniers correctifs publiés pour Exchange Server est disponible ici. Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
1 | Comptes privilégiés avec SPN | vuln_spn_priv | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéL'attribut servicePrincipalName (SPN) est positionné pour plusieurs comptes privilégiés. Il est possible de lancer une attaque afin de retrouver le mot de passe de l'utilisateur, ce qui peut être facilité si celui-ci n'est pas assez robuste. | ||||||||||||||||||||||||||||||||||
recommandationLe SPN permet d'associer des noms de service Kerberos à des comptes. Lorsqu'un compte possède un nom de service Kerberos, n'importe quel utilisateur authentifié peut demander un ticket pour ce service. Dans ce cas, le ticket émis est chiffré avec une des clés Kerberos associées au compte correspondant, ce qui permet de faire une attaque par brute force. Par défaut seuls les comptes machine possèdent des SPN, cet attribut doit toujours être vide pour les comptes privilégiés du domaine. Cas général: supprimer le SPNSi les comptes ayant un SPN ont réellement besoin d'être privilégiés, il convient de supprimer leur attribut servicePrincipalName et de changer leur mot de passe. Note : il est toléré qu'un compte privilégié possède un SPN aux conditions suivantes :
Cas particulier: retirer le compte des groupes privilégiésSi les comptes ayant un SPN n'ont pas réellement besoin d'être membres d'un groupe privilégié de l'Active Directory, il est préférable de les retirer de ces groupes et de faire les délégations nécessaires. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
1 | Relations d'approbation sortante de type domaine non filtré | vuln_trusts_domain_notfiltered | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéUn ou plusieurs domaines de la forêt approuvent un domaine externe sans filtrage. Un attaquant ayant compromis le domaine externe peut usurper l'identité de n'importe quel utilisateur ou machine du domaine (sauf comptes ayant un RID inférieur à 1000, ce qui exclut les utilisateurs ou les groupes présents par défaut). Il est alors possible pour cet individu malveillant d'accéder à l'ensemble des données du domaine. Si un chemin de contrôle existe pour le compte usurpé, il peut également élever ses privilèges vers « Administrateurs du domaineDomain Admins » et ainsi compromettre l'ensemble de la forêt. | ||||||||||||||||||||||||||||||||||
recommandationDepuis Windows 2003, il est possible de filtrer un domaine externe approuvé. Ce mécanisme est appelé « quarantaine ». Ce filtrage empêche tout utilisateur du domaine approuvé d'usurper l'identité d'un utilisateur d'un autre domaine. Les relations d'approbation concernées doivent avoir ce mécanisme de quarantaine activé. Cette action peut être effectuée via la commande :netdom trust <domaine> /domain:<domaine_externe_approuvé> /Quarantine:oui. De plus, il est recommandé de ne pas établir de relation d'approbation sortante depuis une forêt de confiance vers un domaine de moindre confiance / sensibilité. Note : le type de relation d'approbation est vérifié par la présence ou l'absence de certains attributs ldap. La relation externe relevée dans cette vulnérabilité est déduite de l'absence de l'attribut WITHIN_FOREST. Dans certains cas, lorsque les forêts sont anciennes, les relations d'approbation internes ne sont pas correctement marquées WITHIN_FOREST. Dans ce cas, il est nécessaire d'effectuer une opération manuelle pour positionner les attributs corrects sur les relations. | ||||||||||||||||||||||||||||||||||
1 | Relations d'approbation sortantes de type forêt avec sID History activé | vuln_trusts_forest_sidhistory | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa forêt approuve une forêt externe, avec un filtrage affaibli. Un attaquant ayant compromis la forêt externe peut usurper l'identité de n'importe quel utilisateur ou machine de la forêt (sauf comptes ayant un RID inférieur à 1000, ce qui exclut les utilisateurs ou les groupes présents par défaut). Il est alors possible pour cet individu malveillant d'accéder à l'ensemble des données de la forêt. Si un chemin de contrôle existe pour le compte usurpé, il peut également élever ses privilèges vers « Administrateurs du domaineDomain Admins » et ainsi compromettre l'ensemble de la forêt. | ||||||||||||||||||||||||||||||||||
recommandationPar construction, les relations d'approbation de type forêt sont filtrées. Toutefois, ce filtrage a été affaibli pour permettre le fonctionnement d'un mécanisme appelé sIDHistory, utilisé notamment lors d'une migration de forêt. Il convient préalablement de justifier l'affaiblissement du filtrage entre ces forêts. Ceci peut être dû à une migration en cours nécessitant le mécanisme du sIDHistory. Si c'est le cas, il est alors nécessaire de terminer cette migration avant de réactiver le filtrage par défaut. Le retour à un état de filtrage par défaut peut être effectué avec la commande :netdom trust <forêt> /domain:<forêt_tierce_approuvée> /EnableSIDHistory:no. | ||||||||||||||||||||||||||||||||||
1 | Nombre important de comptes actifs inutilisés | vuln_user_accounts_dormant | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa forêt contient plus de 25% de comptes dormants. Les comptes dormants correspondent à des comptes utilisateur ou machine, non désactivés qui ne se sont pas authentifiés auprès de l'Active Directory depuis plus d'un an. Ces comptes dormants sont soit des comptes légitimes devant être rarement utilisés, soit des comptes obsolètes. Les comptes obsolètes peuvent donner accès à des personnes n'en ayant plus besoin (suite à un départ par exemple) ou être utilisés de manière furtive par un attaquant, ce qui est d'autant plus préjudiciable si ces comptes sont privilégiés. La présence de ces comptes augmente par ailleurs le travail de gestion des comptes (revue de droits, etc.). Comptes dormants / Comptes non désactivés | ||||||||||||||||||||||||||||||||||
recommandationL'absence de politique de gestion des comptes (ou sa mauvaise application) peut entraîner la persistance de comptes obsolètes sur le domaine. Cela peut s'expliquer, par exemple, par le départ ou le changement d'affectation d'un utilisateur, la suppression d'une application ou la mise au rebut d'une machine. Sont considérés comme dormants des comptes n'ayant plus d'activité auprès du domaine depuis plus d'un an. Sont considérés comme obsolètes des comptes dormants dont l'existence dans le domaine n'est plus justifiée. Deux critères peuvent être utilisés pour énumérer les comptes dormants dans un domaine :
Il convient de déterminer, parmi ces comptes dormants, les comptes obsolètes. En effet, une partie des comptes présentés en annexe peut concerner des comptes dormants légitimes (par exemple un compte de secours) ou encore des comptes utilisés pour créer des boîtes de messagerie Exchange consultées uniquement par délégation. Ces comptes fonctionnels Exchange doivent être désactivés et positionnés dans une OU adéquate. Il est nécessaire de neutraliser les comptes obsolètes. Cette méthode de neutralisation apporte les mêmes avantages que la suppression tout en conservant la traçabilité offerte par la simple désactivation. Pour neutraliser un compte, il faut :
| ||||||||||||||||||||||||||||||||||
2 | Mauvaises versions de l'Active Directory | vuln_adupdate_bad | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa préparation du domaine (Domain-wide update) est en version 15. Cette version crée un chemin de contrôle permettant le contrôle total de l'Active Directory par certains groupes. | ||||||||||||||||||||||||||||||||||
recommandationLa préparation du domaine en version 15 positionne des ACE trop permissives aux groupes Administrateurs de clésKey Admins et Administrateurs de clés de l'entrepriseEnterprise Key Admins. Il est donc recommandé d'appliquer la préparation de domaine au moins en version 16. La préparation d'un domaine est effectuée à l'aide de l'outil adprep.exe, présent dans le média d'installation Windows Server. La révision 16 est disponible depuis un média Windows Server, version 1709 ou ultérieur (par exemple Windows Server 2019). Les commandes permettant de réaliser cette action sont adprep /ForestPrep puis adprep /DomainPrep. https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/adprep/changes-made-by-adprep Note : l'opération de préparation d'un domaine est décorrélée de la version des systèmes d'exploitation des contrôleurs de domaine ou des niveaux fonctionnels (domaine et forêt). Il n'est donc pas nécessaire de mettre à jour les systèmes d'exploitation des contrôleurs de domaine ou d'augmenter les niveaux fonctionnels. | ||||||||||||||||||||||||||||||||||
2 | Le groupe "Pre-Windows 2000 Compatible Access" contient "Anonymous" | vuln_compatible_2000_anonymous | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLe mécanisme de compatibilité pré-Windows 2000 est activé. Cela se caractérise par la présence de l'identifiant de sécurité AnonymeAnonymous (S-1-5-7) dans les membres du groupe Builtin\Accès compatible pré-Windows 2000Builtin\Pre-Windows 2000 Compatible Access. Ce mécanisme permet une énumération anonyme de certains éléments auprès des contrôleurs de domaine. | ||||||||||||||||||||||||||||||||||
recommandationLe mécanisme de compatibilité pré-Windows 2000 permet d'assurer le support des systèmes antérieur à Windows 2000 (Windows NT 4.0). Historiquement utilisé pour des raisons de rétrocompatibilité, le groupe Builtin\Accès compatible pré-Windows 2000Builtin\Pre-Windows 2000 Compatible Access ne doit contenir que Utilisateurs authentifiésAuthenticated Users (S-1-5-11). | ||||||||||||||||||||||||||||||||||
234 | Algorithmes de chiffrement supportés par les DC/RODC | vuln_dc_crypto | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLes DC/RODC mettent en œuvre différents algorithmes de chiffrement pour les tickets Kerberos (DES, RC4, AES). Initialement, seul l'algorithme RC4 (RC4-HMAC) était supporté pour les systèmes Windows et les algorithmes basés sur DES pouvaient être activé pour améliorer la compatibilité avec les systèmes non Windows. Windows Server 2008 a apporté le support d'algorithmes reposant sur AES (AES128-CTS-HMAC-SHA1-96 et AES256-CTS-HMAC-SHA1-96) , ceux-ci ayant été normalisés et supportés par des systèmes non Windows. Actuellement, les algorithmes basés sur DES (DES-CBC-CRC et DES-CBC-MD5) sont considérés comme obsolètes et doivent êtes désactivés. De même, dans un objectif de durcissement, l'algorithme RC4 peut être désactivé ceci entrainant cependant la perte de compatibilité avec les systèmes antérieurs à Windows Vista et Windows Server 2008. Seuils de toléranceCe point de contrôle présente des seuils de tolérance différents en fonction du niveau de sécurité visé :
| ||||||||||||||||||||||||||||||||||
recommandationLa configuration des algorithmes supportés par un DC/RODC est définie dans les options de sécurité de la stratégie de sécurité locale (Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos). Ce paramètre ne doit pas être modifié dans chaque stratégie de sécurité locale des DC (risque de désynchronisation entre les DC). Il est recommandé de modifier ce paramètre dans la GPO "Default Domain Controller Policy" ou toute autre GPO appliquée aux DC. Au niveau 2, il est recommandé de définir cette stratégie et d'activer : RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 et "Futurs types de chiffrement". Au niveau 3, il est recommandé de définir cette stratégie et d'activer : AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96 et "Futurs types de chiffrement". Avant de modifier ce paramètre, il est nécessaire de s'assurer que les contrôleurs de domaine n'émettent que des TGT ou des tickets de service chiffrés avec AES128 ou AES256. Ceci peut être vérifié en regardant, sur chaque DC, les évènements 4768 (demande de TGT) et 4769 (demande de ticket de service) dans le journal Sécurité. Dans ces deux évènements, l'attribut TicketEncryptionTypeindique l'algorithme utilisé par le contrôle de domaine pour chiffrer le ticket. Il convient de s'assurer que seuls les types 0x11 (AES128-CTS-HMAC-SHA1-96) ou 0x12 (AES256-CTS-HMAC-SHA1-96) sont utilisés. | ||||||||||||||||||||||||||||||||||
2 | Délégation d'authentification non contrainte | vuln_delegation_t4d | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes de la forêt possèdent des délégations d'authentification non contraintes. Cette délégation permet d'usurper l'identité de tout utilisateur s'authentifiant auprès de ces comptes. | ||||||||||||||||||||||||||||||||||
recommandationLa délégation d'authentification non contrainte permet à un compte de s'authentifier auprès de n'importe quel service Kerberos avec l'identité d'un utilisateur (s'étant préalablement authentifié auprès de ce compte). Elle n'est donnée par défaut qu'aux contrôleurs de domaine et ne doit pas être accordée à d'autres comptes. Pour les comptes concernés, il convient de supprimer la propriété TRUSTED_FOR_DELEGATION présente dans l'attribut userAccountControl. Cette opération peut être effectuée directement à partir de l'onglet « Délégation » de la console de gestion des utilisateurs et ordinateurs. Si une délégation Kerberos doit être mise en œuvre, il faut utiliser la délégation contrainte. | ||||||||||||||||||||||||||||||||||
2 | Comptes dont le mot de passe n'expire jamais | vuln_dont_expire | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéPlus de 10% des comptes possèdent des mots de passe n'expirant pas. La récupération d'un compte permet à un individu malveillant de conserver ses droits d'accès au domaine sur le long terme. | ||||||||||||||||||||||||||||||||||
recommandationCas généralAfin qu'un renouvellement soit imposé techniquement par l'Active Directory, il est nécessaire que les comptes ne possèdent pas la propriété DONT_EXPIRE. Cette propriété doit être supprimée et le mot de passe être changé. S'il est contre-productif d'imposer un délai d'expiration trop court, il convient également d'éviter que des mots de passe ne soient jamais changés. En effet, il est parfois constaté la présence de comptes actifs dont le mot de passe n'a pas changé depuis parfois plus de 10 ans, augmentant la probabilité de son exposition, de sa réutilisation ou de sa faiblesse. Aussi, cette exception peut avoir pour effet de mettre l'organisme dans la situation de ne jamais pouvoir changer certains mots de passe. Enfin, les comptes utilisateurs d'un Active Directory ne sont techniquement pas distinguables de comptes de services non gérés (au sens gMSA/sMSA). La politique de mot de passe imposée par le domaine peut ainsi être soit globale, soit différenciée entre les types de comptes utilisateurs non privilégiés via le mécanisme des Password Settings Object (PSO). Si une durée de vie longue des mots de passe est tolérée par la politique de l'organisme, celle-ci doit être explicitement définie par la politique de mots de passe. La différenciation permet de maintenir une gestion suivie dans le temps de certaines catégories de comptes et impose la documentation des exceptions et de leurs procédures de changement de mots de passe. L'usage de la propriété DONT_EXPIRE a généralement pour conséquence l'oubli du renouvellement du mot de passe de certains comptes d'importance particulière, après un incident de sécurité ou non, voire légitime l'installation de produits ou l'usage de comptes fonctionnels ayant cette caractéristique et dont la procédure de renouvellement risque de ne pas être documentée. Cas des comptes de servicePour être en mesure de changer le mot de passe des comptes de service et de pouvoir tracer leur utilisation, il est nécessaire de documenter leur emploi. Un document doit ainsi recenser tous les comptes de service et leur utilisation. Il doit contenir pour chaque compte de service identifié :
| ||||||||||||||||||||||||||||||||||
2 | Compte Invité actif | vuln_guest | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLe compte InvitéGuest est activé. Le compte InvitéGuest permet aux utilisateurs réseau non authentifiés de se connecter en tant qu'InvitéGuest sans mot de passe. Ces utilisateurs non autorisés peuvent accéder à toutes les ressources accessibles au compte InvitéGuest sur le réseau. Cette fonctionnalité signifie que tous les objets ou dossiers partagés avec des autorisations qui autorisent l’accès au compte InvitéGuest, au groupe Invités du domaineDomain Guests, au groupe InvitésGuests, ou au groupe Tout le mondeEveryone sont accessibles sur le réseau, ce qui peut entraîner l’exposition ou l’altération des données. | ||||||||||||||||||||||||||||||||||
recommandationDésactiver le compte InvitéGuest. | ||||||||||||||||||||||||||||||||||
2 | Comptes utilisateurs avec un chiffrement Kerberos faible | vuln_kerberos_properties_deskey | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa propriété USE_DES_KEY_ONLY est positionnée pour plusieurs utilisateurs. Cette propriété autorise les contrôleurs de domaine à émettre des tickets chiffrés avec l'algorithme DES, afin d'assurer une compatibilité avec d'anciennes implémentations Kerberos. Cet algorithme est considéré comme obsolète et ne doit plus être utilisé. Il diminue grandement la robustesse des tickets Kerberos émis et simplifie les attaques par brute force. | ||||||||||||||||||||||||||||||||||
recommandationLe support des familles de chiffrement par les systèmes Windows est, dans une configuration par défaut, le suivant :
La propriété USE_DES_KEY_ONLY doit être retirée de l'attribut userAccountControl des comptes. Cette opération peut être effectuée directement à partir de l'onglet « Compte » de la console de gestion des utilisateurs et ordinateurs, en décochant la case « Utiliser uniquement les types de chiffrement DES via Kerberos pour ce compte ». En cas d'incompatibilité avec une application, celle-ci doit faire l'objet d'une évolution applicative. | ||||||||||||||||||||||||||||||||||
2 | Comptes sans préauthentification Kerberos | vuln_kerberos_properties_preauth | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes n'imposent pas la préauthentification Kerberos. Sans préauthentification il est possible d'obtenir un ticket chiffré avec un des secrets associés au compte correspondant. Il est ensuite possible de lancer une attaque afin de retrouver le mot de passe de l'utilisateur, ce qui peut être facilité s'il n'est pas assez robuste. | ||||||||||||||||||||||||||||||||||
recommandationLa préauthentification permet de s'assurer que l'utilisateur connaît un de ses secrets d'authentification lors d'une demande de TGT (ticket Kerberos obtenu auprès d'un contrôleur de domaine). Par défaut, les comptes utilisateur imposent la préauthentification. Cette propriété ne doit jamais être positionnée pour les comptes du domaine. Cas généralLa propriété DONT_REQUIRE_PREAUTH doit être supprimée pour ces comptes et le mot de passe doit être changé. Cas particuliersEn cas d'incompatibilité avec une application, celle-ci doit faire l'objet d'une évolution applicative. Ce problème peut être réduit via les contournements suivants:
| ||||||||||||||||||||||||||||||||||
2 | Mot de passe du compte krbtgt inchangé depuis plus d'un an | vuln_krbtgt | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLe mot de passe du compte krbtgt n'a pas été changé depuis plus d'un an. Le compte krbtgt est un compte d'infrastructure servant de support de stockage aux clés des centres de distribution des clés Kerberos. La compromission du compte krbtgt permet à un attaquant de forger des tickets Kerberos (souvent appelés golden tickets) et ainsi de pouvoir s'authentifier auprès de n'importe quelle ressource (serveur, poste de travail, etc.) du domaine Active Directory avec des droits d'administration, et ce, de manière relativement furtive. Le compte krbtgt ne changeant pas automatiquement de mot de passe, si la base des comptes de l'Active Directory a été extraite (par exemple par un ancien administrateur, lors d'un audit ou pour un test de robustesse des mots de passe), il est possible, tant que ce mot de passe n'a pas été changé, d'utiliser les informations contenues dans la base afin d'en extraire les secrets. Une personne malveillante peut ainsi s'authentifier sur l'ensemble des services du domaine Active Directory plusieurs années après. | ||||||||||||||||||||||||||||||||||
recommandationLe compte krbtgt est un compte d'infrastructure servant de support de stockage aux clés des centres de distribution des clés Kerberos. Afin de renouveler les clés Kerberos utilisées pour chiffrer les TGT, il est nécessaire de procéder annuellement à un changement manuel du mot de passe du compte krbtgt. Il est conseillé d'effectuer ce changement en utilisant le script mis à disposition par Microsoft. Le changement de mot de passe doit être effectué deux fois pour être efficace. Attention: toute opération de changement du mot de passe du compte krbtgt doit être effectuée uniquement dans un environnement Active Directory où la réplication entre contrôleurs de domaine est nominale. Ainsi il est indispensable d'attendre un délai avant le deuxième changement de mot de passe. Il est également possible de réinitialiser manuellement le mot de passe du compte krbtgt, de la même façon qu'un compte classique. Si le script mis à disposition n'est pas utilisé, il est recommandé un délai d'au minimum 24 heures entre les deux changements et de s'assurer de la réplication effective entre contrôleurs de domaine. Une stratégie peut être d'effectuer un unique changement de mot de passe tous les 6 mois, afin de garantir un changement effectif annuel. | ||||||||||||||||||||||||||||||||||
2 | Serveurs dont le mot de passe de compte d'ordinateur est inchangé depuis plus de 90 jours | vuln_password_change_server_no_change_90 | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes serveurs n'ont pas changé le mot de passe de leur compte d'ordinateur depuis plus de 90 jours, ce qui indique que leurs secrets ne sont pas renouvelés. | ||||||||||||||||||||||||||||||||||
recommandationDans leur fonctionnement par défaut, les serveurs changent automatiquement le mot de passe de leur compte d'ordinateur périodiquement (30 jours par défaut). Il convient d'investiguer la raison qui empêche les serveurs de changer leur mot de passe. Une première vérification consiste à vérifier la valeur des entrées de Registre suivantes :
Si ces valeurs sont incorrectes, il convient de les remettre aux valeurs par défaut et de s'assurer qu'elles ne sont pas positionnées par une GPO. Si ces valeurs sont correctes, vérifier si le service NETLOGON est démarré avec sc.exe query netlogon. | ||||||||||||||||||||||||||||||||||
2 | Comptes de service managés dont le mot de passe de compte est inchangé depuis plus de 90 jours | vuln_password_change_msa_no_change_90 | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes de service managés n'ont pas changé le mot de passe de leur compte depuis plus de 90 jours, ce qui indique que leurs secrets ne sont pas renouvelés. | ||||||||||||||||||||||||||||||||||
recommandationDans leur fonctionnement par défaut, les comptes de service managés changent automatiquement le mot de passe de leur compte périodiquement (30 jours par défaut). Il convient d'investiguer la raison qui empêche les serveurs de changer leur mot de passe. Une première vérification consiste à vérifier la valeur des entrées de Registre suivantes :
Si ces valeurs sont incorrectes, il convient de les remettre aux valeurs par défaut et de s'assurer qu'elles ne sont pas positionnées par une GPO. | ||||||||||||||||||||||||||||||||||
2 | Chemins de contrôle dangereux vers des conteneurs d'objets privilégiés | vuln_permissions_gpo_container_priv | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes chemins de contrôle dangereux existent vers des conteneurs (sites et OU) contenant des membres des groupes privilégiés. Un attaquant ayant le contrôle sur ces conteneurs pourrait lier une GPO à cet emplacement et ainsi exécuter du code sur les machines utilisées par ces membres et élever ses privilèges. LégendeContrôle fort et immédiatContrôle indirectContrôle indirect faible | ||||||||||||||||||||||||||||||||||
recommandationIl recommandé d'enlever les permissions dangereuses sur ces conteneurs afin de revenir à un état par défaut. La correction est généralement effectuée à l'aide du composant logiciel enfichable ADSI Edit ou de l'utilitaire ldp. Acceptation du risqueSi
des permissions spécifiques sont nécessaires, il convient de considérer
que les comptes ou les groupes délégués sont eux-mêmes privilégiés.
Ainsi, ils doivent être correctement protégés et leurs permissions
appliquées doivent être au moins aussi restrictives que celles
appliquées à l'adminSDHolder. Il est donc nécessaire de leur appliquer des permissions "sécurisées". Pour cela, il est recommandé d'utiliser la commande Set-ADSyncRestrictedPermissions Exemple d'utilisation de Set-ADSyncRestrictedPermissions
Import-Module .\AdSyncConfig.psm1 $credential = Get-Credential Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=ExampleUserAccount,CN=Users,DC=example,DC=ads" -Credential $credential Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d'installation d'Azure AD Connect à l'aide de l'utilitaire intégré msiexec : msiexec /a "AzureADConnect.msi" /qb TARGETDIR=c:\temp\ Le paquet d'installation peut être téléchargé à l'adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771. Contexte : chemins de contrôleUn chemin de contrôle est composé d'un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d'un objet sur un autre au travers d'une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d'atteindre des cibles, et permettent d'identifier des déviances dans la gestion du domaine, de valider l'application d'un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission. LimitesCertains chemins de contrôle peuvent disposer de correctifs qui les rendent non exploitables. Ces cas imposent généralement d'avoir l'ensemble des contrôleurs de domaine au même niveau de mise à jour. De plus, les fonctionnalités dangereuses peuvent parfois être réactivées par un paramètre de registre ou dsHeuristics. Il est donc toujours recommandé de nettoyer les permissions concernées de l'Active Directory pour prévenir une réapparition du problème. Liste des correctifs spécifiques connus :
Visualisation des chemins de contrôleIl est possible de visualiser les chemins de contrôle qui permettent la compromission totale de la forêt via l'onglet dédié de ce rapport. Pour accéder aux graphes de contrôle, cliquer ici. | ||||||||||||||||||||||||||||||||||
2 | Comptes membres de groupes privilégiés avec une mauvaise politique de mot de passe | vuln_privileged_members_password | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéUne politique de mot de passe faible est imposée à des comptes privilégiés. | ||||||||||||||||||||||||||||||||||
recommandationIl est recommandé d'appliquer une politique de mot de passe pour les comptes privilégiés avec :
Note importante : il est déconseillé de forcer un renouvellement trop fréquent (quelques mois). Une demande de renouvellement trop fréquente induit statistiquement un nouveau choix de mot de passe plus faible, ce qui en fait une mesure de sécurité contre-productive. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
2 | Comptes ou groupes privilégiés révélés par des RODC | vuln_rodc_priv_revealed | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes privilégiés ont été révélés sur des RODC, ce qui signifie que leurs secrets d'authentification y sont mis en cache. Une compromission de ces machines (généralement plus exposées que des contrôleurs de domaine classiques) permet de compromettre l'intégralité du domaine. | ||||||||||||||||||||||||||||||||||
recommandationLes RODC conservent, entre autres, une copie d'une partie des secrets du domaine. Par défaut, les comptes membres de groupes privilégiés ne sont pas révélés (c'est-à-dire copiés) sur les RODC. Cette mesure permet de limiter l'impact d'un accès malveillant aux seuls comptes révélés sur les RODC. Les utilisateurs privilégiés ne doivent donc pas être révélés sur les RODC. Pour cela, les contrôleurs de domaine en lecture seule (RODC) doivent comporter dans l'attribut msDS-NeverRevealGroup au minimum les valeurs suivantes :
Cette opération peut être effectuée directement à partir de l'onglet « Stratégie de réplication de mot de passe » de la console de gestion des utilisateurs et ordinateurs. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
2 | Comptes ou groupes ayant un historique de SID d'apparence non conforme | vuln_sidhistory_dangerous | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéPlusieurs comptes ou groupes de la forêt possèdent un attribut sIDHistory ayant la valeur d'un well-known SID (SID des utilisateurs et groupes génériques) ou d'un SID privilégié de domaine. Ce mécanisme peut être utilisé par des attaquants pour s'accorder illégitimement des droits d'accès. | ||||||||||||||||||||||||||||||||||
recommandationLa propriété sIDHistory permet de rajouter un identifiant de sécurité (SID) arbitraire dans la liste des groupes d'un compte utilisateur ou machine. Ce mécanisme est principalement utilisé lors de la migration de comptes d'un domaine à un autre pour perpétuer l'accès à d'anciennes ressources. Une investigation doit être menée pour expliquer la présence de ces SID non conformes. L'attribut sIDHistory doit être effacé pour tous les comptes et groupes concernés dès lors que les opérations de migration ont été effectuées. | ||||||||||||||||||||||||||||||||||
2 | Utilisation de NTFRS pour la réplication du SYSVOL | vuln_sysvol_ntfrs | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes contrôleurs de domaines sont configurés pour utiliser le protocole de réplication NTFRS (en particulier pour la réplication du SYSVOL). Ce protocole est obsolète et rajoute inutilement des interfaces d'administration aux contrôleurs de domaine. De plus, ce protocole n'est plus supporté par les dernières versions de Windows Server, ce qui empêche la migration vers les dernières versions. | ||||||||||||||||||||||||||||||||||
recommandationIl est recommandé d'utiliser uniquement le mécanisme Distributed File System Replication (DFSR) pour synchroniser des répertoires sur différents serveurs, en particulier pour la réplication du SYSVOL. Note : NTFRS n'est plus supporté dans les dernières versions de Windows Server. Le processus de migration vers DFSR est documenté par Microsoft : https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr. | ||||||||||||||||||||||||||||||||||
2 | Comptes de trust dont le mot de passe est inchangé depuis plus d'un an | vuln_trusts_accounts | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLes comptes de trust n'ont pas eu leur mot de passe changé depuis plus d'un an. Cela peut signifier que les relations d'approbation ont été supprimées, mais que les comptes associés sont toujours présents. | ||||||||||||||||||||||||||||||||||
recommandationCas d'une relation d'approbation suppriméeCertains comptes de trust restent présents alors que les relations associées ont été supprimées. Il faut donc supprimer ces comptes. Cas d'une relation d'approbation non suppriméeIl est recommandé de changer au moins annuellement les mots de passe des comptes de trust. Ce changement doit être automatique entre les environnements Microsoft. Il convient également d'investiguer la cause du non-renouvellement automatique de ce mot de passe. | ||||||||||||||||||||||||||||||||||
3 | Comptes ou groupes membres de "Pre-Windows 2000 Compatible Access" | vuln_compatible_2000_not_default | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLe mécanisme de compatibilité pré-Windows 2000 est activé pour certains comptes. Ce mécanisme permet l'accès à certaines RPC aux membres du groupe Builtin\Accès compatible pré-Windows 2000Builtin\Pre-Windows 2000 Compatible Access. Selon le paramétrage système, le groupe intégré Tout le mondeEveryone peut contenir les utilisateurs anonymes, ce qui peut augmenter le risque s'il est membre du groupe de rétrocompatibilité. | ||||||||||||||||||||||||||||||||||
recommandationLe mécanisme de compatibilité pré-Windows 2000 permet d'assurer le support des domaines de type Windows NT. Historiquement utilisé pour des raisons de rétrocompatibilité, le groupe Builtin\Accès compatible pré-Windows 2000Builtin\Pre-Windows 2000 Compatible Access ne doit contenir que Utilisateurs authentifiésAuthenticated Users (S-1-5-11). Note : les serveurs ADCS sont inscrits dans ce groupe lors de leur installation. Dans la plupart des cas, l'appartenance à ce groupe n'est pas nécessaire et peut être supprimée. Cette opération est facilement réversible. | ||||||||||||||||||||||||||||||||||
3 | Algorithmes de chiffrement supportés par les comptes de service | vuln_kerberos_properties_encryption | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLes comptes de service qui supportent l'authentification Kerberos (i.e. qui disposent d'un attribut servicePrincipalName) peuvent utiliser différents algorithmes (DES, RC4, AES128 et AES256) de chiffrement pour les tickets émis à destination des services s'exécutant sous l'identité de ces comptes. Pour un compte donné dans l'annuaire, l'attribut msDS-SupportedEncryptionTypes indique aux contrôleurs de domaine les algorithmes supportés pour le service s'exécutant pour l'identité de ce compte. Par défaut, cet attribut est vide et seul l'algorithme RC4 est utilisé. Si le compte de service est un "compte machine" s'exécutant sous Windows, celle-ci va mettre à jour automatiquement l'attribut en fonction de ses capacités. Depuis Windows Vista et Windows Server 2008, la machine indique généralement qu'elle supporte RC4, AES128 et AES256. | ||||||||||||||||||||||||||||||||||
recommandationPour les comptes de service qui ne sont pas de type "compte machine", il est nécessaire de spécifier explicitement le support d'AES128 ou AES256 dans les options du compte. Ceci peut être fait en spécifiant la valeur 28 (0x1C) dans l'attribut msDS-SupportedEncryptionTypes du compte utilisateur ou en activant l'option spécifique dans ses propriétés :
En cas d'incompatibilité avec une application, celle-ci doit faire l'objet d'une évolution applicative. | ||||||||||||||||||||||||||||||||||
3 | Objets ayant un propriétaire inadapté | vuln_owner | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes objets, créés il y a plus de 7 jours, ont des propriétaires non standard. | ||||||||||||||||||||||||||||||||||
recommandationTous les objets (utilisateurs, groupes, sMSA, gMSA, ordinateurs, OU et GPO) doivent avoir pour propriétaire l'un des objets suivants :
| ||||||||||||||||||||||||||||||||||
3 | Serveurs inactifs | vuln_password_change_inactive_servers | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes serveurs ne se sont pas authentifiés depuis plus de 90 jours. | ||||||||||||||||||||||||||||||||||
recommandationDans leur fonctionnement par défaut, les serveurs doivent s'authentifier et changer automatiquement leur mot de passe sur le domaine tous les 30 jours. Les serveurs non utilisés doivent être désactivés. L'absence d'authentification au domaine est symptomatique d'une machine désynchronisée. Les serveurs désynchronisés du domaine doivent réinstallés ou supprimés. Dans le cas d'une réinstallation, afin d'éviter le chemin de contrôle de type OWNER du compte machine, il est recommandé d'effectuer une jonction de domaine hors connexion à l'aide de l'utilitaire Djoin. | ||||||||||||||||||||||||||||||||||
3 | Serveurs dont le mot de passe de compte d'ordinateur est inchangé depuis plus de 45 jours | vuln_password_change_server_no_change_45 | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes serveurs n'ont pas changé le mot de passe de leur compte d'ordinateur depuis plus de 45 jours, ce qui indique que leurs secrets ne sont pas renouvelés. | ||||||||||||||||||||||||||||||||||
recommandationDans leur fonctionnement par défaut, les serveurs changent automatiquement le mot de passe de leur compte d'ordinateur périodiquement (30 jours par défaut). Il convient d'investiguer la raison qui empêche les serveurs de changer leur mot de passe. Une première vérification consiste à vérifier la valeur des entrées de Registre suivantes :
Si ces valeurs sont incorrectes, il convient de les remettre aux valeurs par défaut et de s'assurer qu'elles ne sont pas positionnées par une GPO. Si ces valeurs sont correctes, vérifier si le service NETLOGON est démarré avec sc.exe query netlogon. | ||||||||||||||||||||||||||||||||||
3 | Comptes avec un PrimaryGroupID modifié | vuln_primary_group_id_nochange | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéCertains utilisateurs ou ordinateurs ont un attribut primaryGroupId modifié. | ||||||||||||||||||||||||||||||||||
recommandationDans le fonctionnement d'un Active Directory, l'attribut primaryGroupId d'un compte utilisateur ou machine permet d'affecter implicitement ce compte à un groupe, même si ce groupe n'est pas répertorié par l'attribut memberOf de l'utilisateur. L'appartenance à un groupe via cet attribut n'apparaît pas dans la liste des membres du groupe dans certaines interfaces. Cet attribut dissimule l'appartenance d'un compte à un groupe privilégié. Il est recommandé de repositionner les attributs primaryGroupId des utilisateurs ou ordinateurs concernés à leur valeur par défaut :
| ||||||||||||||||||||||||||||||||||
3 | Comptes privilégiés non membres du groupe Protected Users | vuln_protected_users | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes privilégiés ne sont pas protégés par le groupe Protected usersProtected users. | ||||||||||||||||||||||||||||||||||
recommandationL'ensemble des comptes privilégiés doivent être ajoutés au groupe Protected usersProtected users afin de :
Attention : l'utilisation du groupe Protected usersProtected users a des impacts fonctionnels importants. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
3 | Comptes ayant leur mot de passe stocké de manière réversible | vuln_reversible_password | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes ont leur mot de passe stocké de manière réversible dans l'annuaire. Il est possible, en possédant des droits d'administrateur de récupérer en clair les mots de passe concernés. | ||||||||||||||||||||||||||||||||||
recommandationAfin d'éviter les faiblesses dans la gestion des mots de passe, il est nécessaire de retirer les propriétés dangereuses relatives aux mots de passe des comptes utilisateur. Cette action peut être effectuée à l'aide de la console « Utilisateurs et ordinateurs AD ». Il faut pour cela décocher la case « Enregistrer le mot de passe en utilisant un chiffrement réversible » dans l'onglet « Compte » des propriétés du compte en question. Cela a pour effet de retirer la propriété ENCRYPTED_TEXT_PASSWORD_ALLOWED de l'attribut userAccountControl. Si ces paramètres correspondent à un besoin métier légitime, il convient de le documenter, par exemple en l'indiquant dans le commentaire du compte. | ||||||||||||||||||||||||||||||||||
3 | Configuration dangereuse des contrôleurs de domaine en lecture seule (RODC) (neverReveal) | vuln_rodc_never_reveal | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa forêt possède des contrôleurs de domaine en lecture seule (RODC) avec des attributs de révélation dangereux. Des groupes par défaut sont manquants dans l'attribut msDS-NeverRevealGroup sur des RODC. | ||||||||||||||||||||||||||||||||||
recommandationL'attribut msDS-NeverRevealGroup permet d'interdire la révélation des secrets des objets qui y sont listés (et ce, de manière récursive). Les contrôleurs de domaine en lecture seule (RODC) doivent comporter dans l'attribut msDS-NeverRevealGroup au minimum les valeurs suivantes :
| ||||||||||||||||||||||||||||||||||
3 | Comptes ou groupes privilégiés présents dans les attributs de révélation des RODC | vuln_rodc_reveal | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLa forêt possède des contrôleurs de domaine en lecture seule (RODC) avec des attributs de révélation dangereux. En effet, certains utilisateurs ou groupes privilégiés (RID < 1000) sont présents dans l'attribut msDS-RevealOnDemandGroup. | ||||||||||||||||||||||||||||||||||
recommandationL'attribut msDS-RevealOnDemandGroup permet de définir les utilisateurs et groupes autorisés à être révélés sur un RODC. Les contrôleurs de domaine en lecture seule (RODC) ne doivent pas comporter dans cet attribut des groupes dont le RID est inférieur à 1000. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
3 | Configuration dangereuse des groupes de réplication pour les contrôleurs de domaine en lecture seule (RODC) (allow) | vuln_rodc_allowed_group | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLe groupe Groupe de réplication de mot de passe RODC autoriséeAllowed RODC Password Replication Group n'est pas vide. | ||||||||||||||||||||||||||||||||||
recommandationLes secrets des membres du groupe Groupe de réplication de mot de passe RODC autoriséeAllowed RODC Password Replication Group peuvent être révélés sur l'ensemble des RODC. Il est recommandé de vider ce groupe et d'utiliser des groupes spécifiques dans la PRP (Password Replication Policy) de chaque RODC. | ||||||||||||||||||||||||||||||||||
3 | Configuration dangereuse des groupes de réplication pour les contrôleurs de domaine en lecture seule (RODC) (denied) | vuln_rodc_denied_group | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéLe groupe Groupe de réplication de mot de passe RODC refuséeDenied RODC Password Replication Group ne possède pas l'ensemble de ses membres par défaut. | ||||||||||||||||||||||||||||||||||
recommandationLe groupe Groupe de réplication de mot de passe RODC refuséeDenied RODC Password Replication Group doit avoir au minimum les membres suivants (intégrés par défaut) :
| ||||||||||||||||||||||||||||||||||
3 | Comptes krbtgt de RODC orphelins | vuln_rodc_orphan_krbtgt | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes krbtgt sont présents mais ne sont plus associés à des RODC. | ||||||||||||||||||||||||||||||||||
recommandationLes comptes krbtgt inutilisés peuvent être supprimés. | ||||||||||||||||||||||||||||||||||
3 | Comptes ou groupes ayant un historique de SID | vuln_sidhistory_present | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes comptes ou groupes de la forêt possèdent un attribut sIDHistory non vide. La présence de sIDHistory entraine inutilement la génération d'évènements Windows 4665 et 4666, ce qui peut rendre plus difficile la supervision. De plus, leur utilisation légitime impose un affaiblissement de la sécurité des relations d'approbation. Note : seuls les 10000 premiers objets sont affichés. | ||||||||||||||||||||||||||||||||||
recommandationLa propriété sIDHistory permet de rajouter un identifiant de sécurité (SID) arbitraire dans la liste des groupes d'un compte utilisateur ou machine. Ce mécanisme est principalement utilisé lors de la migration de comptes d'un domaine à un autre pour perpétuer l'accès à d'anciennes ressources. Il peut également être utilisé par des attaquants pour s'accorder illégitimement des droits d'accès. L'attribut sIDHistory doit être effacé pour tous les comptes et groupes concernés dès lors que les opérations de migration ont été effectuées. | ||||||||||||||||||||||||||||||||||
3 | Relations d'approbation entrante avec délégation | vuln_trusts_tgt_deleg | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes relations d'approbation autorisent explicitement la délégation Kerberos. Par construction, ces relations permettent aux ressources externes approuvées de pouvoir s'authentifier avec l'identité des comptes qui s'y connectent (comptes membres de la forêt analysée). Cela permet à un attaquant ayant compromis le domaine externe approuvé d'élever ses privilèges vers le domaine local approbateur. | ||||||||||||||||||||||||||||||||||
recommandationUne relation d'approbation entrante permet d'être approuvé par un domaine externe ou une forêt tierce. Cela permet aux comptes de se connecter à des ressources externes à la forêt. Une relation d'approbation entrante doit interdire la délégation Kerberos vers la ressource approbatrice. À partir de Windows 2012 il est possible de désactiver la délégation de TGT à l'aide de la commande :netdom trust <domaine> /domain:<domaine_externe_approuvé> /EnableTGTDelegation:no | ||||||||||||||||||||||||||||||||||
4 | Membres des groupes privilégiés hors silo d'authentification | vuln_silo_priv | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes membres de groupes privilégiés ne sont pas membres d'un silo d'authentification, ou celui-ci n'est pas correctement configuré. | ||||||||||||||||||||||||||||||||||
recommandationTous les utilisateurs privilégiés doivent être membres d'un silo d'authentification correctement configuré. Contexte : groupes privilégiésLes groupes privilégiés sont les groupes d'administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre. | ||||||||||||||||||||||||||||||||||
4 | Comptes utilisateurs de carte à puce sans expiration de mot de passe | vuln_smartcard_expire_passwords | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéDes domaines ne positionnent pas l'attribut msDS-ExpirePasswordsOnSmartCardOnlyAccounts. | ||||||||||||||||||||||||||||||||||
recommandationDans le cadre de l'authentification par carte à puce sur les domaines Windows, il est possible de configurer l'annuaire Active Directory pour permettre au mot de passe de changer automatiquement en respectant la politique mise en place. Ce changement automatique est effectué si l'attribut msDS-ExpirePasswordsOnSmartCardOnlyAccounts de la racine des domaines est positionné. Cet attribut n'est présent et actif que lorsque le niveau fonctionnel du domaine est Windows 2016 / 2019 / 2022 ou supérieur. Il est recommandé de positionner l'attribut msDS-ExpirePasswordsOnSmartCardOnlyAccounts à la racine des domaines, même si les cartes à puce ne sont pas actuellement utilisées. | ||||||||||||||||||||||||||||||||||
4 | Ajout de machines au domaine non limité | vuln_user_accounts_machineaccountquota | ||||||||||||||||||||||||||||||||
description de la vulnérabilitéPar défaut les utilisateurs authentifiés peuvent joindre 10 machines au domaine. Cette valeur est contrôlée par l'attribut ms-DS-MachineAccountQuota de l'objet racine. Les comptes machine ajoutés ont alors pour propriétaire le compte utilisé, lui offrant un contrôle total dessus. La vulnérabilité CVE-2021-42287 utilisait des machines jointes pour réaliser une élévation de privilèges. | ||||||||||||||||||||||||||||||||||
recommandationPositionner l'attribut ms-DS-MachineAccountQuota à 0 à la racine des domaines. La correction est généralement effectuée à l'aide des consoles adsiedit.msc ou de l'utilitaire ldp. |
Le tableau ci-dessous présente l'historique des changements majeurs de l'analyse.
2023-03-30
Ajout d'une fonctionnalité de filtrage du contenu du rapport basée sur les DN d'objets
2023-03-27
Ajout du groupe "Domain Controllers" dans l'encart de description des objets privilégiés. Le groupe était déjà pris en compte lors de l'analyse.
2023-03-26
Ajout de l'outil d'édition des conteneurs de certificats dans la recommandation
2023-03-26
Ajout des security descriptors par défaut pour divers objets et de cas légitimes de modification
2022-11-10
Clarification des recommandations.
2022-10-28
Clarification des recommandations.
2022-10-26
Ajout de précisions sur les vulnérabilités liées à l'appartenance au groupe "DNSAdmins".
2022-10-26
Ajout des correctifs officiels des permissions excessives Exchange Server.
2022-10-26
Ajout des correctifs officiels des permissions excessives Exchange Server.
2022-10-26
Ajout des correctifs officiels des permissions excessives Exchange Server.