Data/Locales/checks/fr/ADTradecraftChecks.json
|
{ "_family": "ADTradecraftChecks.json", "ADTRADE-001": { "name": { "value": "Résidus cpassword de préférences de stratégie de groupe dans SYSVOL", "status": "machine-draft" }, "description": { "value": "De 2008 à mai 2014, les préférences de stratégie de groupe permettaient aux administrateurs de pousser des tâches planifiées, des mots de passe d'utilisateurs locaux, des lecteurs mappés et des services à l'aide d'un champ « cpassword » — chiffré avec une clé AES-256 que Microsoft a publiquement documentée. Le correctif MS14-025 a désactivé le champ cpassword dans les NOUVELLES préférences mais a laissé intactes celles déjà présentes dans SYSVOL. Chaque engagement de red team en trouve encore. Tout utilisateur de domaine authentifié peut lire SYSVOL, récupérer le cpassword et le déchiffrer hors connexion. Si vous trouvez quoi que ce soit ici, considérez chaque information d'identification exposée comme compromise et renouvelez-la.", "status": "machine-draft" }, "recommendedValue": { "value": "Aucun attribut cpassword où que ce soit sous \\\\domain\\SYSVOL\\domain\\Policies\\**\\*.xml.", "status": "machine-draft" }, "remediationSteps": { "value": "Analysez SYSVOL : Get-ChildItem -Path \\\\<domain>\\SYSVOL\\<domain>\\Policies -Recurse -Include *.xml | Select-String 'cpassword'. Pour chaque correspondance : (1) renouvelez le mot de passe du compte dont l'information d'identification est exposée (le nom d'utilisateur figure dans le même fichier XML), (2) auditez les journaux à la recherche d'une utilisation de cette information d'identification depuis la création de la préférence, (3) supprimez la préférence de GPP une fois la nouvelle information d'identification en place. L'article KB2962486 de Microsoft fournit les instructions de nettoyage.", "status": "machine-draft" } }, "ADTRADE-002": { "name": { "value": "Indicateur DCShadow (serveurs malveillants dans la partition de configuration)", "status": "machine-draft" }, "description": { "value": "DCShadow (Vincent LE TOUX / Benjamin Delpy, BlueHat IL 2018) enregistre un hôte contrôlé par l'attaquant en tant que contrôleur de domaine en écrivant des objets nTDSDSA + server sous CN=Sites,CN=Configuration. Le faux DC est ensuite utilisé pour injecter des données de réplication malveillantes (SID history, hachages de mots de passe) sans jamais être un véritable DC. REMARQUE : sur les domaines de longue durée, un objet server sans correspondance est bien plus souvent des MÉTADONNÉES DE DC RÉSIDUELLES (un DC supprimé sans « ntdsutil metadata cleanup ») qu'une véritable attaque DCShadow ; c'est pourquoi il est classé High plutôt que Critical — examinez l'horodatage whenCreated pour distinguer un objet récemment créé (suspect) de vieilles métadonnées obsolètes.", "status": "machine-draft" }, "recommendedValue": { "value": "Tous les objets server sous CN=Sites,CN=Configuration correspondent à des contrôleurs de domaine réels et inventoriés. Aucun objet server récemment créé ne correspondant pas à un DC connu.", "status": "machine-draft" }, "remediationSteps": { "value": "Énumérez : Get-ADObject -Filter {objectClass -eq 'server'} -SearchBase \"CN=Sites,$((Get-ADRootDSE).configurationNamingContext)\" -Properties whenCreated, dNSHostName | Sort whenCreated. Recoupez avec votre inventaire de DC (Get-ADDomainController -Filter *). Tout objet server ne correspondant pas à un DC réel, en particulier récemment créé, exige une réponse à incident immédiate — DCShadow est un primitif de niveau prise de contrôle du domaine. Surveillez les événements 5137 / 5141 sur le conteneur de schéma comme signal de détection.", "status": "machine-draft" } }, "ADTRADE-003": { "name": { "value": "Clés de récupération BitLocker obsolètes", "status": "machine-draft" }, "description": { "value": "Les clés de récupération BitLocker sont stockées dans AD en tant qu'objets enfants msFVE-RecoveryInformation de l'ordinateur qui les a sauvegardées. Lorsqu'un ordinateur est déclassé mais que l'objet AD reste en suspens, les clés de récupération demeurent interrogeables par quiconque dispose de droits de récupération BitLocker — généralement un groupe plus large que « Tier Zero ». Des clés obsolètes signifient que les disques mis au rebut sont déchiffrables s'ils sont récupérés chez un reconditionneur ou dans une poubelle.", "status": "machine-draft" }, "recommendedValue": { "value": "Tous les objets msFVE-RecoveryInformation appartiennent à des ordinateurs actifs au cours des 90 derniers jours. Aucune clé orpheline liée à des comptes d'ordinateur désactivés ou récemment modifiés puis devenus obsolètes.", "status": "machine-draft" }, "remediationSteps": { "value": "Énumérez les informations de récupération : Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} -Properties whenCreated. Pour chacune, remontez jusqu'à l'objet ordinateur parent et vérifiez son lastLogonTimestamp / Enabled. Pour les ordinateurs inactifs depuis plus de 90 jours : confirmez que le disque a été effacé ou détruit, puis supprimez l'objet ordinateur AD (ce qui supprime en cascade les informations de récupération). Pour les ordinateurs activement utilisés mais avec des clés de récupération très anciennes : renouvelez-les via Backup-BitLockerKeyProtector. Vérifiez que le groupe de récupération BitLocker a une composition restreinte.", "status": "machine-draft" } }, "ADTRADE-004": { "name": { "value": "Hygiène de la stratégie de réplication de mot de passe RODC", "status": "machine-draft" }, "description": { "value": "Les contrôleurs de domaine en lecture seule (RODC) mettent en cache les mots de passe des principaux listés dans leur stratégie de réplication de mot de passe (PRP). Si un compte Tier Zero (Domain Admin, Enterprise Admin, krbtgt) est atteignable par la PRP d'un RODC — directement ou via imbrication de groupes — la compromission du RODC compromet ces comptes. Le groupe par défaut « Denied RODC Password Replication Group » devrait explicitement contenir DA / EA / SA / Schema Admins / krbtgt ; certains environnements personnalisent la stratégie et suppriment accidentellement ces refus.", "status": "machine-draft" }, "recommendedValue": { "value": "Tous les RODC du domaine ont une stratégie de réplication de mot de passe où Domain Admins, Enterprise Admins, Schema Admins, krbtgt et Account Operators figurent du côté Refuser. Aucun compte à privilèges élevés ne figure du côté Autoriser.", "status": "machine-draft" }, "remediationSteps": { "value": "Pour chaque RODC : Get-ADDomainController -Filter {IsReadOnly -eq $true} | ForEach-Object { Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Allowed; Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Denied }. Vérifiez que la liste Refusée contient le groupe intégré « Denied RODC Password Replication Group ». Si votre environnement ne comporte pas de RODC, cette vérification est sans objet — PASS. Le guide de planification RODC de Microsoft fournit le modèle de PRP canonique.", "status": "machine-draft" } }, "ADTRADE-005": { "name": { "value": "Rotation de clé du compte d'ordinateur Entra Seamless SSO (AZUREADSSOACC$)", "status": "machine-draft" }, "description": { "value": "Lorsque l'authentification unique fluide (Seamless SSO) Entra (Azure AD) est activée pour l'identité hybride, AD crée un compte d'ordinateur nommé AZUREADSSOACC$. Son mot de passe est la clé Kerberos partagée qu'Entra utilise pour valider les tickets SSO. Microsoft indique que cette clé n'est PAS renouvelée automatiquement — les administrateurs doivent la faire tourner. Si un attaquant extrait la clé AZUREADSSOACC$ (il s'agit d'un hachage NT normal, lisible via DCSync ou depuis un DC), il peut forger des Silver Tickets Kerberos pour le service Azure AD et s'authentifier en tant que N'IMPORTE QUEL utilisateur hybride synchronisé, sans autre interaction, tant que la clé reste valide. Une clé non renouvelée depuis plus de 90 jours élargit considérablement cette fenêtre.", "status": "machine-draft" }, "recommendedValue": { "value": "Clé Kerberos AZUREADSSOACC$ renouvelée au moins tous les 90 jours (faites-la tourner deux fois par rotation pour invalider la clé précédente).", "status": "machine-draft" }, "remediationSteps": { "value": "Renouvelez la clé Seamless SSO sur une machine disposant du module Entra Connect / Azure AD : Import-Module 'C:\\Program Files\\Microsoft Azure Active Directory Connect\\AzureADSSO.psd1'; New-AzureADSSOAuthenticationContext; Update-AzureADSSOForest. Effectuez la rotation deux fois (le compte stocke la clé actuelle + la précédente) et planifiez-la de façon récurrente. Si Seamless SSO n'est plus utilisé, désactivez-le et supprimez l'objet AZUREADSSOACC$.", "status": "machine-draft" } }, "ADTRADE-006": { "name": { "value": "Shadow Credentials (msDS-KeyCredentialLink) sur les principaux privilégiés", "status": "machine-draft" }, "description": { "value": "L'attribut msDS-KeyCredentialLink contient les clés publiques utilisées pour l'ouverture de session PKINIT sans mot de passe / Windows Hello Entreprise. Un attaquant disposant d'un accès en écriture à cet attribut sur une cible peut ajouter SA PROPRE paire de clés (Whisker / pyWhisker) puis demander un TGT Kerberos en tant que ce compte à l'aide de la clé privée correspondante — une technique de persistance et d'usurpation furtive appelée « shadow credentials ». Toute clé de credential inattendue sur un objet Tier Zero (un administrateur de domaine, un contrôleur de domaine ou tout compte adminCount=1) devrait être traitée comme une porte dérobée potentielle jusqu'à preuve qu'il s'agit d'une inscription WHfB légitime.", "status": "machine-draft" }, "recommendedValue": { "value": "Aucune valeur msDS-KeyCredentialLink non reconnue sur les principaux privilégiés/Tier Zero ; chaque clé correspond à une inscription WHfB/sans mot de passe connue.", "status": "machine-draft" }, "remediationSteps": { "value": "Pour chaque principal signalé, inspectez les credentials de clé (Get-ADObject -Properties msDS-KeyCredentialLink, ou la cmdlet Get-ADKeyCredential de DSInternals) et corrélez chaque clé d'appareil avec une inscription Windows Hello Entreprise légitime. Supprimez toute entrée que vous ne pouvez pas attribuer à une inscription sanctionnée. Restreignez qui peut écrire msDS-KeyCredentialLink (auditez Key Admins / Enterprise Key Admins et les DACL d'OU/d'objet accordant ce droit d'écriture). Réinitialisez les comptes concernés en cas de suspicion de compromission.", "status": "machine-draft" } }, "ADTRADE-007": { "name": { "value": "Surface d'élévation par migration dMSA BadSuccessor", "status": "machine-draft" }, "description": { "value": "Windows Server 2025 a introduit les comptes de service administrés délégués (dMSA, classe d'objet msDS-DelegatedManagedServiceAccount) avec une fonctionnalité de migration : un dMSA peut être marqué comme remplaçant un compte existant, après quoi il hérite des privilèges et des clés Kerberos de ce compte. La technique « BadSuccessor » divulguée en 2024 en abuse : un principal qui peut simplement CRÉER un dMSA dans une OU (CreateChild sur la classe dMSA, ou droits larges d'écriture/GenericAll sur l'OU) peut en créer un, le pointer vers un compte privilégié et hériter de ses clés — s'élevant vers ce compte sans jamais détenir de droits directs sur lui. Cette vérification inventorie les OU où un principal non-Tier Zero détient cette capacité.", "status": "machine-draft" }, "recommendedValue": { "value": "Aucun principal non-Tier Zero ne peut créer ou écrire un MSA délégué (msDS-DelegatedManagedServiceAccount) dans une OU.", "status": "machine-draft" }, "remediationSteps": { "value": "Sur chaque OU signalée, retirez CreateChild (pour la classe msDS-DelegatedManagedServiceAccount), GenericAll, WriteDacl et WriteOwner des principaux non administratifs. Auditez largement les autorisations déléguées des OU — les mêmes ACE qui permettent BadSuccessor permettent aussi d'autres abus de création d'objets. En attendant un correctif/une mitigation, surveillez la création d'objets msDS-DelegatedManagedServiceAccount (événements 4662/5137). Cette vérification est ignorée (SKIP) sur les forêts dont le schéma est antérieur à Server 2025.", "status": "machine-draft" } }, "ADTRADE-008": { "name": { "value": "Appartenance aux groupes Key Admins / Enterprise Key Admins", "status": "machine-draft" }, "description": { "value": "Les groupes Key Admins (RID de domaine 526) et Enterprise Key Admins (RID 527) se voient accorder le droit d'écrire l'attribut msDS-KeyCredentialLink dans l'ensemble du domaine/de la forêt. Cela fait de tout membre un primitif de shadow credentials à l'échelle du domaine : un membre peut implanter des credentials de clé sur n'importe quel compte et s'authentifier en tant que ce compte via PKINIT. Ces groupes sont livrés VIDES et devraient le rester, sauf si un flux de provisionnement de clés Windows Hello Entreprise spécifique l'exige de manière démontrable. Tout membre constitue un chemin d'élévation qui doit être justifié.", "status": "machine-draft" }, "recommendedValue": { "value": "Les groupes Key Admins et Enterprise Key Admins sont vides (aucun membre permanent).", "status": "machine-draft" }, "remediationSteps": { "value": "Examinez chaque membre de Key Admins et Enterprise Key Admins. Retirez tout compte qui n'a pas un besoin documenté et continu de provisionner des clés Windows Hello Entreprise. Si le provisionnement de clés WHfB nécessite des droits délégués, limitez-les à un compte de service dédié doté des autorisations les plus restreintes possibles plutôt qu'à l'appartenance à ces groupes à l'échelle du domaine. Traitez les membres inattendus comme un mécanisme de persistance potentiel.", "status": "machine-draft" } }, "ADTRADE-009": { "name": { "value": "Appartenance au groupe Cert Publishers", "status": "machine-draft" }, "description": { "value": "Les membres du groupe Cert Publishers (RID de domaine 517) sont autorisés à publier des certificats dans le magasin NTAuth et sur les objets utilisateur/ordinateur. Par défaut, le groupe ne contient que le ou les comptes d'ordinateur des autorités de certification d'entreprise. Un compte utilisateur ou de service placé dans ce groupe acquiert la capacité d'influencer quels certificats sont approuvés pour l'authentification, ce qui constitue un tremplin dans plusieurs chemins d'élévation AD CS (attaques de classe ESC) et peut permettre une usurpation basée sur les certificats. L'appartenance de comptes d'ordinateur (les hôtes d'AC eux-mêmes) est attendue ; tout membre non-ordinateur constitue une anomalie.", "status": "machine-draft" }, "recommendedValue": { "value": "Cert Publishers ne contient que le ou les comptes d'ordinateur des autorités de certification d'entreprise — aucun compte utilisateur ou de service.", "status": "machine-draft" }, "remediationSteps": { "value": "Retirez tout compte utilisateur ou de service du groupe Cert Publishers ; seuls les comptes d'ordinateur des autorités de certification d'entreprise y ont leur place. Examinez le contenu du magasin NTAuth (certutil -viewstore -enterprise NTAuth) à la recherche de certificats d'AC inattendus. Durcissez AD CS de façon large : auditez les autorisations d'inscription des modèles de certificat et la surface de mauvaise configuration ESC1-ESC8.", "status": "machine-draft" } }, "ADTRADE-010": { "name": { "value": "Posture des comptes de service administrés de groupe (gMSA) et exposition des mots de passe", "status": "machine-draft" }, "description": { "value": "Les comptes de service administrés de groupe (gMSA) détiennent des mots de passe de 240 bits qu'AD génère et renouvelle automatiquement, éliminant le Kerberoasting des mots de passe faibles de comptes de service et la corvée de rotation manuelle. Deux préoccupations de posture : (1) l'utilisation effective de gMSA pour les identités de service, et (2) qui est autorisé à récupérer le mot de passe géré, contrôlé par le descripteur de sécurité msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword). Si ce descripteur accorde l'accès à un principal large (Tout le monde, Utilisateurs authentifiés, Domain Users) ou à un principal non privilégié, ce principal peut récupérer le mot de passe gMSA en clair (par exemple GMSAPasswordReader) et usurper pleinement l'identité du service.", "status": "machine-draft" }, "recommendedValue": { "value": "Les identités de service s'exécutent en tant que gMSA ; msDS-GroupMSAMembership est limité aux seuls hôtes spécifiques qui doivent exécuter le service (aucun principal large ou non privilégié).", "status": "machine-draft" }, "remediationSteps": { "value": "Pour chaque gMSA, définissez PrincipalsAllowedToRetrieveManagedPassword sur les comptes d'ordinateur exacts (ou un groupe strictement délimité) qui exécutent le service : Set-ADServiceAccount -Identity <gmsa> -PrincipalsAllowedToRetrieveManagedPassword <hosts>. Retirez Tout le monde / Utilisateurs authentifiés / Domain Users de cette liste. Lorsque des comptes de service utilisent encore des mots de passe statiques de comptes utilisateur, migrez-les vers des gMSA pour bénéficier de la rotation automatique et de la résistance au Kerberoasting.", "status": "machine-draft" } } } |