> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/cyber-best-practices/fr/guides-de-remediation-des-vulnerabilites/ad-scan-vulnerability-remediation-guide/privileged-accounts.md). # Comptes à privilèges ## P-Kerberoasting #### Ce que cela signifie Dans Active Directory, certains comptes sont enregistrés pour exécuter des services tels qu’un serveur SQL ou une application web. Ces comptes ont un **Nom de principal de service (SPN)**, ce qui est essentiellement une étiquette qui dit « ce compte exécute un service réseau. » Le risque de sécurité est : **tout utilisateur authentifié** dans le domaine peut demander un ticket Kerberos pour n’importe quel compte doté d’un SPN. Ce ticket est chiffré avec le mot de passe du compte, et l’attaquant peut ensuite tenter de le craquer hors ligne, sans déclencher la moindre alerte. C’est ce qu’on appelle une **attaque Kerberoasting** . C’est particulièrement dangereux lorsque le compte avec le SPN est aussi un **Administrateur du domaine**, car casser ce mot de passe signifie un contrôle total du domaine. #### Ce que l'analyse vérifie Le scan AD signale les comptes qui remplissent **les trois** conditions : 1. Le compte est membre d’un **groupe privilégié** (Administrateurs du domaine, Administrateurs d’entreprise, etc.) 2. Le compte a un **Nom de principal de service (SPN)** 3. mot de passe du compte **n’a pas été modifié depuis plus de 40 jours** (ce qui laisse plus de temps aux attaquants pour le craquer) #### Pourquoi l’alerte peut persister Vous devez traiter **les trois** les conditions. Corrections incomplètes courantes : * **Mot de passe modifié mais SPN conservé :** L’alerte disparaît temporairement, mais revient après 40 jours. * **SPN supprimé mais le compte est toujours dans Administrateurs du domaine :** L’alerte disparaît, mais le risque sous-jacent demeure. #### Comment diagnostiquer ```powershell $privilegedGroups = @("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators") $threshold = (Get-Date).AddDays(-40) foreach ($group in $privilegedGroups) { Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.objectClass -eq "user" } | ForEach-Object { Get-ADUser $_ -Properties ServicePrincipalName, PasswordLastSet } | Where-Object { $_.ServicePrincipalName.Count -gt 0 -and $_.PasswordLastSet -lt $threshold } | Select-Object SamAccountName, @{N="Âge du mot de passe (jours)"; E={[math]::Round(((Get-Date) - $_.PasswordLastSet).TotalDays)}}, @{N="SPNs"; E={$_.ServicePrincipalName -join "; "}} } ``` #### Comment corriger **Meilleure option : supprimer le compte des groupes privilégiés.** Les comptes de service ont rarement besoin d’être Administrateurs du domaine. Créez un compte dédié, non privilégié, avec uniquement les autorisations dont le service a réellement besoin : ```powershell Remove-ADGroupMember -Identity "Domain Admins" -Members "svc_account" -Confirm:$false ``` **Si vous ne pouvez pas le retirer du groupe d’administration :** Au minimum, réinitialisez régulièrement le mot de passe (tous les 30 jours ou moins) : ```powershell Set-ADAccountPassword -Identity "svc_account" ` -NewPassword (ConvertTo-SecureString "YourNewStr0ngP@ssw0rd!" -AsPlainText -Force) -Reset ``` **Meilleure solution à long terme :** Passer à un **compte de service géré de groupe (gMSA)**, qui fait tourner automatiquement son mot de passe tous les 30 jours : ```powershell New-ADServiceAccount -Name "gMSA_SQLService" ` -DNSHostName "gmsa_sqlservice.yourdomain.com" ` -PrincipalsAllowedToRetrieveManagedPassword "SQLServersGroup" ``` ## P-AdminLogin #### Ce que cela signifie Chaque domaine Active Directory possède un **compte Administrateur intégré** créé automatiquement lors de la configuration du domaine. Ce compte a un contrôle total sur l’ensemble du domaine et ne peut pas être verrouillé. En raison de sa puissance et de sa prévisibilité (les attaquants savent qu’il existe toujours), il devrait être réservé **aux situations d’urgence uniquement**, comme la reprise après sinistre. L’administration quotidienne devrait utiliser des comptes d’administration personnels (p. ex., `adm_john`) afin que les actions puissent être attribuées à des personnes. #### Ce que l'analyse vérifie Le scan AD vérifie si le compte Administrateur intégré s’est connecté à un Contrôleur de domaine quelconque au cours des **35 derniers jours**. Si c’est le cas, l’alerte se déclenche, indiquant que le compte est utilisé pour des tâches courantes au lieu d’être conservé pour les urgences. #### Pourquoi l’alerte peut persister * **Renommer le compte n’aide pas.** Le scan identifie l’Administrateur intégré par son identifiant interne (RID-500), pas par son nom. * **Modifier le mot de passe n’aide pas.** Le scan vérifie l’activité de connexion, pas l’ancienneté du mot de passe. * **Des scripts automatisés ou des tâches planifiées** s’exécutant sous l’Administrateur intégré continueront de déclencher l’alerte. * **Il vous suffit d’attendre.** Après l’arrêt de l’utilisation du compte, l’alerte disparaît automatiquement après 35 jours. #### Comment diagnostiquer ```powershell # Vérifier quand l’Administrateur intégré s’est connecté pour la dernière fois sur chaque DC $domainSID = (Get-ADDomain).DomainSID $adminSID = "$domainSID-500" Get-ADDomainController -Filter * | ForEach-Object { $dc = $_ $admin = Get-ADUser -Identity $adminSID -Server $dc.HostName -Properties LastLogon $lastLogon = [DateTime]::FromFileTime($admin.LastLogon) $daysAgo = [math]::Round(((Get-Date) - $lastLogon).TotalDays, 1) [PSCustomObject]@{ DC = $dc.HostName LastLogon = $lastLogon DaysAgo = $daysAgo Status = if ($daysAgo -le 35) { "ALERTE - Utilisé récemment" } else { "OK" } } } | Format-Table -AutoSize ``` Vérifiez également s’il existe des tâches planifiées qui pourraient utiliser l’Administrateur intégré : ```powershell Get-ADDomainController -Filter * | ForEach-Object { Invoke-Command -ComputerName $_.HostName -ScriptBlock { Get-ScheduledTask | Where-Object { $_.Principal.UserId -match "Administrator" } | Select-Object TaskName, @{N="RunAs"; E={$_.Principal.UserId}} } } ``` #### Comment corriger 1. **Créer des comptes d’administration personnels** pour chaque administrateur (p. ex., `adm_john`, `adm_jane`) 2. **Mettre à jour toutes les tâches planifiées** pour utiliser un compte de service dédié au lieu de l’Administrateur intégré 3. **Cesser de se connecter** avec l’Administrateur intégré pour les tâches courantes 4. L’alerte disparaîtra automatiquement **35 jours** après la dernière connexion ## P-AdminNum #### Ce que cela signifie Plus vous avez de comptes disposant de privilèges administrateur dans votre domaine, plus la surface d’attaque est grande. Chaque compte admin est un point d’entrée potentiel pour un attaquant. Au fil du temps, de nombreuses organisations se retrouvent avec un excès de comptes admin : accès temporaires jamais révoqués, comptes de service ajoutés aux Administrateurs du domaine par commodité, etc. #### Ce que l'analyse vérifie Le scan AD compte le nombre total de **utilisateurs uniques** dans tous les groupes privilégiés (Administrateurs du domaine, Administrateurs d’entreprise, Administrateurs, Opérateurs de compte, Opérateurs de serveur, Opérateurs de sauvegarde, etc.). Si le même utilisateur est dans plusieurs groupes, il n’est compté qu’une seule fois. L’alerte se déclenche si : * Plus de **10%** des utilisateurs actifs sont privilégiés, OU * Plus de **50** des comptes privilégiés existent > Cette vérification est ignorée pour les petites organisations comptant moins de 100 utilisateurs actifs. #### Comment diagnostiquer ```powershell $privilegedGroups = @( "Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators", \"Account Operators\", \"Server Operators\", \"Backup Operators\", \"Print Operators\" ) $uniqueMembers = @{} foreach ($group in $privilegedGroups) { try { Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.objectClass -eq "user" } | ForEach-Object { $uniqueMembers[$_.DistinguishedName] = $_.SamAccountName } } catch {} } $activeUsers = (Get-ADUser -Filter "Enabled -eq `$true" | Measure-Object).Count $pct = [math]::Round(($uniqueMembers.Count / $activeUsers) * 100, 1) Write-Host "Comptes privilégiés : $($uniqueMembers.Count)" Write-Host "Utilisateurs actifs : $activeUsers" Write-Host "Ratio : $pct% (alerte si >10 % ou >50 comptes)" Write-Host "" $uniqueMembers.Values | Sort-Object | ForEach-Object { Write-Host " - $_" } ``` #### Comment corriger Passez la liste en revue et supprimez les comptes qui n’ont pas réellement besoin d’un accès administrateur : ```powershell Remove-ADGroupMember -Identity "Domain Admins" -Members "username" -Confirm:$false ``` Bonnes pratiques : * Utilisez **comptes d’administration séparés** (`adm_john`) différents des comptes utilisés au quotidien * **Supprimer les comptes de service** des groupes d’administration, en leur accordant uniquement les autorisations spécifiques dont ils ont besoin * **Vérifier l’appartenance aux groupes privilégiés** régulièrement ## P-ProtectedUsers #### Ce que cela signifie Le **Utilisateurs protégés** est un groupe de sécurité spécial introduit dans Windows Server 2012 R2. Les membres de ce groupe bénéficient de protections supplémentaires : * Ils peuvent **s’authentifier uniquement avec Kerberos** (le protocole le plus sûr), et non avec l’ancien protocole NTLM * Leurs **identifiants ne sont pas mis en cache** sur les machines sur lesquelles ils se connectent : un attaquant qui compromet un poste de travail ne peut pas voler leurs identifiants depuis la mémoire * **La délégation est désactivée :** leur compte ne peut pas être usurpé par des services Ces protections sont essentielles pour les comptes d’administration, qui sont les principales cibles de la plupart des attaques. #### Ce que l'analyse vérifie Le scan AD vérifie que tous les **comptes d’administration activés** (membres de Domain Admins, Enterprise Admins, etc.) sont aussi membres du groupe **Utilisateurs protégés** . #### Pourquoi l’alerte peut persister * **Les utilisateurs ajoutés via des groupes imbriqués** peuvent ne pas être détectés. Ajoutez les utilisateurs **directement** au groupe Utilisateurs protégés. * **Les délais de réplication** entre les Contrôleurs de domaine peuvent provoquer des incohérences temporaires. * **Les comptes de service gérés (gMSA)** sont exclus de cette vérification : ils n’ont pas besoin de figurer dans Utilisateurs protégés. #### Comment diagnostiquer ```powershell $protectedUsers = (Get-ADGroupMember -Identity "Protected Users").DistinguishedName $privilegedGroups = @("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators") $notProtected = foreach ($group in $privilegedGroups) { Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.objectClass -eq "user" } | ForEach-Object { Get-ADUser $_ -Properties Enabled } | Where-Object { $_.Enabled -and $_.DistinguishedName -notin $protectedUsers } } $notProtected | Select-Object -Unique SamAccountName, Name | Format-Table -AutoSize ``` #### Comment corriger ```powershell Add-ADGroupMember -Identity "Protected Users" -Members "adm_john", "adm_jane" ``` > **Important :** Ajouter des comptes à Protected Users impose **l’authentification Kerberos uniquement**. Certaines applications héritées qui nécessitent NTLM peuvent cesser de fonctionner pour ces comptes. **Testez d’abord avec un seul compte** avant d’ajouter tous les administrateurs. > > Bonne pratique : les comptes d’administration doivent être utilisés **uniquement pour les tâches d’administration** (pas pour les e-mails, la navigation web ou l’exécution d’applications métier), donc la compatibilité NTLM est rarement un problème. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/cyber-best-practices/fr/guides-de-remediation-des-vulnerabilites/ad-scan-vulnerability-remediation-guide/privileged-accounts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.