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

$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 :

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) :

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 :

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

# 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é :

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

$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 :

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

$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

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.