Data/Locales/checks/fr/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Audit du compte de synchronisation Azure AD Connect (MSOL_)", "status": "machine-draft" }, "description": { "value": "Lorsqu'Azure AD Connect s'installe en mode Express, il crée un compte de domaine nommé MSOL_<hexadécimal-aléatoire> et lui accorde les droits Replicating Directory Changes + Replicating Directory Changes All sur le contexte de nommage du domaine — c'est-à-dire des droits DCSync. Le compte est de fait Tier Zero mais il réside par défaut dans le conteneur Users, possède une expiration de mot de passe de 10 ans et apparaît rarement dans les outils d'énumération des groupes privilégiés, car il tire son pouvoir d'une ACL directe plutôt que d'une appartenance à un groupe. La compromission de ce compte équivaut fonctionnellement à une prise de contrôle du domaine.", "status": "machine-draft" }, "recommendedValue": { "value": "Tous les comptes MSOL_ sont inventoriés, leur mot de passe est renouvelé au cours des 180 derniers jours, ils sont placés dans une OU Tier Zero avec des droits d'ouverture de session restreints, et le serveur AAD Connect lui-même est durci en tant que système Tier Zero.", "status": "machine-draft" }, "remediationSteps": { "value": "Localisez le compte MSOL_ : Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}. Confirmez qu'il dispose de droits DCSync : dsacls 'DC=domain,DC=com' | findstr MSOL_. Déplacez-le vers une OU d'administration Tier Zero. Renouvelez le mot de passe à l'aide de l'outillage AAD Connect (ne réinitialisez PAS via l'outillage standard — utilisez Add-ADSyncADDSConnectorAccount dans le module PowerShell ADSync sur le serveur AAD Connect). Appliquez une GPO de restriction d'ouverture de session afin que le compte ne puisse se connecter localement qu'au serveur AAD Connect lui-même. Traitez l'hôte AAD Connect comme Tier Zero — restreignez qui peut y accéder en RDP/administration.", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "Comptes de service de logiciels de sauvegarde dans des groupes privilégiés", "status": "machine-draft" }, "description": { "value": "Les logiciels de sauvegarde (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) demandent généralement un compte de service doté d'autorisations très élevées. La documentation suggère souvent Domain Admin pour faciliter la configuration, et de nombreux administrateurs s'y conforment. Une fois que l'attaquant compromet le serveur de sauvegarde (un vecteur d'accès initial fréquent pour les rançongiciels), il hérite de Domain Admin via le compte de service. Il s'agit du chemin d'élévation par rançongiciel n°1 dans les données de réponse à incident de 2023-2025.", "status": "machine-draft" }, "recommendedValue": { "value": "Aucun compte de service de logiciel de sauvegarde n'est membre de Domain Admins, Enterprise Admins, Schema Admins ou Backup Operators. Utilisez des comptes à moindre privilège documentés par l'éditeur et des informations d'identification de sauvegarde isolées.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifiez le produit de sauvegarde utilisé et suivez son guide de moindre privilège (Veeam : administrateur local du serveur de sauvegarde uniquement + compte AD avec lecture d'objets ; Rubrik : principal de service dédié dans un rôle cloud-only ; etc.). Retirez le compte de sauvegarde de Domain Admins. Migrez vers un gMSA lorsque c'est pris en charge. Placez le serveur de sauvegarde dans une OU Tier 1 avec des droits d'ouverture de session restreints. Si un DA complet est réellement requis pour une charge de travail spécifique, documentez-le et isolez cette partie de la sauvegarde dans son propre compte, distinct du principal.", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "Comptes de service d'hyperviseur / de virtualisation dans des groupes privilégiés", "status": "machine-draft" }, "description": { "value": "Les intégrations vCenter / Hyper-V / SCVMM / Citrix / Nutanix avec AD utilisent souvent un compte de service configuré lors de l'installation. Si ce compte est un Domain Admin, la compromission du plan de gestion de l'hyperviseur (ou de la base de données SSO de l'hôte) se propage en cascade vers AD. L'hyperviseur est déjà conceptuellement Tier Zero ; son identité AD devrait correspondre.", "status": "machine-draft" }, "recommendedValue": { "value": "Les comptes de service d'hyperviseur n'ont que les droits documentés par l'éditeur (généralement lecture pour l'inventaire + écritures spécifiques sur des OU si l'intégration VM-AD est utilisée). Pas dans Domain Admins.", "status": "machine-draft" }, "remediationSteps": { "value": "Examinez le compte de service AD de chaque produit d'hyperviseur. Appliquez les recommandations de moindre privilège de l'éditeur. Pour vCenter : utilisez le modèle de source d'identité SSO documenté plutôt que de mapper un Domain Admin. Pour Hyper-V/SCVMM : limitez les droits du compte de service aux OU hébergeant les comptes d'ordinateur des VM. Traitez l'hôte de gestion de l'hyperviseur comme Tier Zero dans votre modèle d'administration.", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "Comptes de service de gestion de configuration dans des groupes privilégiés", "status": "machine-draft" }, "description": { "value": "Les plateformes de gestion de configuration (SCCM/MECM, Intune Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) poussent par définition des logiciels vers chaque poste — elles constituent déjà une plateforme privilégiée de déplacement latéral. SCCM en particulier présente des primitifs d'abus bien connus (exposition du Network Access Account, coercition NTLM vers le serveur de site, client push). Un compte de service de gestion de configuration dans Domain Admins donne à un attaquant qui atterrit sur n'importe quel poste géré les clés du domaine.", "status": "machine-draft" }, "recommendedValue": { "value": "Les comptes de service de gestion de configuration sont limités à leurs droits minimaux documentés et ne figurent jamais dans Domain Admins / Enterprise Admins. Le Network Access Account de SCCM est une identité dédiée non privilégiée.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifiez le produit de gestion de configuration et examinez les droits du compte de service. Pour SCCM : assurez-vous que le Network Access Account est non privilégié (PAS un Domain Admin) ; assurez-vous que le compte machine du serveur de site n'est pas un Domain Admin ; examinez les comptes de service de la hiérarchie pour le moindre privilège. Déplacez les serveurs de site et les points de gestion vers une OU Tier Zero avec des ouvertures de session restreintes.", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "Comptes de service SQL / de base de données dans des groupes privilégiés", "status": "machine-draft" }, "description": { "value": "Les comptes de service SQL Server / MySQL / PostgreSQL dans Domain Admins sont courants dans les environnements où l'équipe DBA a installé SQL avec la recommandation par défaut « Utiliser un compte AD existant » et a choisi un compte administrateur par commodité. Une fois le serveur de base de données atteignable sur le réseau, une compromission d'identifiant SQL ou une vulnérabilité de SQL Server donne directement à l'attaquant un accès Domain Admin.", "status": "machine-draft" }, "recommendedValue": { "value": "Les comptes de service de base de données s'exécutent en tant que gMSA ou identités de service dédiées sans appartenance à un groupe privilégié.", "status": "machine-draft" }, "remediationSteps": { "value": "Migrez les comptes de service SQL vers un gMSA lorsque c'est pris en charge. Pour les comptes qui doivent rester basés sur un compte utilisateur, retirez l'appartenance aux groupes privilégiés et n'accordez que les droits locaux requis par le moteur de base de données (Ouvrir une session en tant que service, Contourner la vérification de parcours, Ajuster les quotas de mémoire pour un processus — voir la documentation Microsoft pour les droits spécifiques).", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "Comptes d'administration Tier Zero hors d'une OU Tier Zero dédiée", "status": "machine-draft" }, "description": { "value": "Si vos Domain Admins résident dans la même OU que les utilisateurs ordinaires, chaque GPO ciblant les utilisateurs (scripts d'ouverture de session, stratégie de navigateur, lecteurs mappés, etc.) s'applique aussi à vos Domain Admins — ce qui signifie que quiconque peut modifier ces GPO peut exécuter du code en tant que Domain Admin à la prochaine ouverture de session. Le modèle en niveaux de Microsoft recommande une OU d'administration Tier Zero dédiée, avec une écriture de GPO restreinte et des droits d'ouverture de session restreints.", "status": "machine-draft" }, "recommendedValue": { "value": "Tous les membres de Domain Admins, Enterprise Admins et Schema Admins se trouvent dans une OU Tier Zero dédiée (généralement OU=Tier-0,OU=Admin) avec une écriture de GPO restreinte.", "status": "machine-draft" }, "remediationSteps": { "value": "Créez OU=Tier-0,OU=Admin si elle n'existe pas. Déplacez-y tous les membres de Domain/Enterprise/Schema Admins. Restreignez l'écriture de GPO sur cette OU (aux seuls administrateurs Tier Zero eux-mêmes). Appliquez une GPO de restriction d'ouverture de session dédiée afin que les comptes Tier Zero ne puissent se connecter qu'aux hôtes Tier Zero. Bloquez l'héritage sur l'OU.", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "Comptes de service avec droits d'ouverture de session interactive via un groupe privilégié", "status": "machine-draft" }, "description": { "value": "Les comptes de service membres de Domain Admins (ou de tout groupe se voyant accorder « Ouvrir une session localement » via l'appartenance par défaut à un groupe privilégié) peuvent être utilisés de manière interactive. Les attaquants adorent cela — récupérer un mot de passe de compte de service (Kerberoasting, registre, scripts dans SYSVOL), l'utiliser de manière interactive sur un poste de travail, vider LSASS et pivoter. Les comptes de service ne devraient pas pouvoir ouvrir une session interactive sur autre chose que l'hôte qu'ils desservent.", "status": "machine-draft" }, "recommendedValue": { "value": "Les comptes de service (heuristique : sAMAccountName commençant par svc/sa/service, ou possédant un SPN + sans ouverture de session interactive récente) se voient explicitement refuser « Ouvrir une session localement » et « Ouvrir une session via les services Bureau à distance » via la stratégie Default Domain Controllers Policy et une GPO dédiée de restriction d'ouverture de session Tier 1/Tier 2.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifiez les comptes de service (porteurs de SPN, convention de nommage ou inventaire métier). Appliquez une GPO Default Domain Policy : Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur > « Interdire l'ouverture de session locale » = <groupe-comptes-de-service>. Ajoutez les mêmes comptes à « Interdire l'ouverture de session via les services Bureau à distance ». Ajoutez-les au groupe Protected Users lorsque c'est pris en charge (Server 2012 R2+).", "status": "machine-draft" } } } |