Guide de Détection des Comptes Obsolètes et Sur-Privilégiés

Les comptes obsolètes et sur-privilégiés ne sont pas un simple bruit d'hygiène de l'annuaire. Dans Active Directory, un compte dormant qui appartient encore à un groupe privilégié, qui conserve un mot de passe ancien, ou qui possède encore une dépendance de service peut devenir un chemin de retour vers le domaine, peu visible.

Que sont les comptes obsolètes et sur-privilégiés ?

Les comptes obsolètes et sur-privilégiés sont des identités anciennes ou peu visibles qui donnent encore accès à des droits d'administration significatifs dans Active Directory. Un compte devient obsolète quand plus personne ne le surveille ; il devient sur-privilégié quand il conserve plus d'accès que ne l'exige son rôle actuel. Les deux problèmes se recoupent souvent.

Les environnements Active Directory accumulent des comptes au fil du temps. Les employés partent, les prestataires terminent leurs missions, les comptes de service survivent aux projets, et les identités d'administration d'urgence restent activées bien après la disparition de leur raison d'être.

Du point de vue d'un attaquant, ces deux conditions se renforcent mutuellement. La meilleure cible n'est pas seulement un compte ancien. C'est un compte ancien qui se trouve encore sur un chemin privilégié, qui est faiblement surveillé, et qui n'a aucun propriétaire clair susceptible de remarquer une activité inhabituelle.

Comment ça fonctionne

Les comptes AD restent actifs jusqu'à ce que quelqu'un les désactive ou les supprime. Si la revue d'offboarding, la revue des comptes de service ou la revue des privilèges est ignorée, l'environnement se remplit de comptes qui :

ne se sont pas authentifiés depuis des mois, voire des années
appartiennent encore à des groupes privilégiés
ont des mots de passe définis il y a longtemps et jamais révisés
échappent à toute revue de cycle de vie rigoureuse

Un compte privilégié obsolète est intéressant car il combine une forte valeur avec une faible surveillance. Le compte peut ne jamais apparaître dans le travail d'administration quotidien, mais il donne toujours accès aux mêmes permissions dès lors que le mot de passe est présenté.

Les recommandations de Microsoft sur la remédiation des comptes obsolètes désignent explicitement les comptes inactifs comme un risque de sécurité et recommandent des vérifications régulières. Ces mêmes recommandations avertissent aussi que les comptes de service peuvent ne pas se connecter pendant de longues périodes, ce qui impose des garde-fous plutôt qu'une suppression aveugle.

Comptes obsolètes et sur-privilégiés : les limites du périmètre quand vous les recherchez

Une revue de comptes obsolètes doit être précise sur ce que signifient réellement les horodatages.

LastLogonDate et les données de connexion répliquées sous-jacentes sont utiles pour identifier des candidats au nettoyage, mais elles ne constituent pas une preuve forensique exacte de la dernière utilisation sur chaque contrôleur de domaine. Elles suffisent à identifier des comptes nécessitant une revue humaine. Elles ne doivent pas être le seul signal avant de supprimer une identité de service sensible.

C'est pourquoi une revue mature distingue au moins trois cas :

les comptes utilisateurs qui auraient clairement dû être désactivés après un départ
les identités de service ou de tâche planifiée potentiellement encore utilisées de façon non interactive
les identités d'urgence ou partagées privilégiées qui ont survécu parce que personne n'a voulu tester les dépendances

L'objectif n'est pas de conserver tout compte ancien au motif qu'une application pourrait cesser de fonctionner. L'objectif est d'arrêter de traiter une propriété floue comme une raison de préserver indéfiniment un privilège dormant.

Une distinction opérationnelle utile est celle entre inactivité et non-pertinence. Un compte peut être silencieux parce qu'il est abandonné, ou silencieux parce qu'il n'est déclenché que mensuellement par une sauvegarde, une tâche planifiée ou un processus de reprise rarement utilisé. La revue doit distinguer explicitement ces cas.

Les limites des horodatages qui comptent

Pour le tri des comptes obsolètes, utilisez plusieurs signaux. Microsoft indique que PasswordLastSet est répliqué et que lastLogonTimeStamp existe pour aider à identifier les comptes potentiellement obsolètes. Cela rend ces attributs utiles pour un nettoyage à l'échelle du domaine. Cela ne prouve pas qu'un compte est sans dépendance.

Une revue fiable combine :

les données d'inactivité répliquées, comme l'ancienneté du mot de passe ou lastLogonTimeStamp
les données d'événements des contrôleurs de domaine pour l'authentification récente
l'analyse de l'appartenance aux groupes et des droits délégués
les vérifications de dépendances liées aux services, tâches planifiées et applications
l'attestation du propriétaire pour les comptes devant rester activés

Plus le privilège est élevé, moins il est acceptable de se fier à un seul horodatage. Un membre dormant de Domain Admins et un utilisateur dormant à faible privilège ne représentent pas le même risque.

La chaîne d'attaque

Étape 1 - Recenser les comptes obsolètes et à forte valeur

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -Properties LastLogonDate, PasswordLastSet, MemberOf |
  Select-Object SamAccountName, LastLogonDate, PasswordLastSet |
  Sort-Object LastLogonDate

$groups = @('Domain Admins','Enterprise Admins','Schema Admins','Backup Operators','Account Operators')
foreach ($group in $groups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Get-ADUser -Properties LastLogonDate, PasswordLastSet |
    Select-Object @{N='Group';E={$group}}, SamAccountName, LastLogonDate, PasswordLastSet
}

Microsoft documente aussi Search-ADAccount -AccountInactive -UsersOnly comme un moyen pratique de trouver les comptes utilisateurs inactifs. Utilisez-le comme outil de découverte, puis ajoutez le contexte de privilège et de dépendance avant d'agir.

Étape 2 - Prioriser les comptes à mot de passe ancien et privilège élevé

Les comptes avec un mot de passe très ancien, une appartenance à un groupe stable et aucun propriétaire actuel sont les premiers qu'un attaquant tentera de valider, de pulvériser (spray) ou de réutiliser.

Priorisez les comptes qui cumulent plusieurs conditions :

données de connexion obsolètes
PasswordLastSet ancien
appartenance à un groupe privilégié
appartenance via des groupes imbriqués
indicateurs de compte comme « le mot de passe n'expire jamais »
absence de propriétaire métier ou technique nommé

Étape 3 - Transformer un accès dormant en accès privilégié

Un compte obsolète qui donne toujours accès à Domain Admins, à des droits d'administration délégués, à des privilèges de sauvegarde ou à un accès serveur étendu n'a besoin d'aucun exploit inédit. Le privilège existe déjà.

Étape 4 - Persister via des identités à faible visibilité

Les comptes dormants sont souvent absents des flux de travail quotidiens, ce qui permet à une activité inhabituelle de passer inaperçue plus longtemps qu'elle ne le devrait. C'est particulièrement vrai pour les comptes d'administration partagés et les identités de service que personne n'a revus récemment.

Détection

Event IDs Windows

Event ID	Source	Ce qu'il faut surveiller
4624	DC ou poste de travail	Connexion réussie depuis un compte sans activité récente attendue
4768	DC	Demandes de TGT pour des comptes qui auraient dû rester dormants
4728 / 4732 / 4756	DC	Changements de groupes privilégiés impliquant des identités obsolètes ou peu claires
4720	DC	Création de compte évoquant un chemin d'administration recyclé ou de remplacement

Microsoft documente « Audit Security Group Management » comme la sous-catégorie d'audit qui génère les événements liés aux changements d'appartenance aux groupes de sécurité, y compris les groupes globaux, locaux et universels. Cette distinction compte quand le chemin privilégié utilise des groupes imbriqués ou non globaux.

Indices comportementaux

première utilisation réussie d'un compte après une longue période de dormance
appartenance à un groupe privilégié combinée à un mot de passe très ancien
comptes de service se connectant de façon interactive ou depuis des hôtes inattendus
comptes partagés utilisés depuis plusieurs systèmes sans raison opérationnelle claire

Requête SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.TargetUserName: (* AND NOT '*$')

Cette requête a besoin d'être enrichie avec l'ancienneté du compte, le contexte de privilège et la propriété attendue. La dormance sans contexte n'est qu'une liste. La dormance combinée au privilège est la véritable découverte.

L'enrichissement de détection qui rend l'alerte utile

Une alerte sur un compte obsolète doit porter suffisamment de contexte pour que le répondant décide de désactiver, d'investiguer ou d'escalader :

état actuel activé/désactivé
date de dernière définition du mot de passe
contexte des dernières connexions interactives et réseau connues
groupes privilégiés directs et imbriqués
indication si le compte est marqué comme sensible ou protégé
indication si le compte possède des services, tâches planifiées ou identifiants applicatifs
présence d'activité Kerberos ou NTLM récente

Sans cet enrichissement, les équipes créent généralement un tableur et reportent les décisions difficiles.

Remédiation

Action rapide : désactivez d'abord les comptes utilisateurs manifestement obsolètes, puis traitez les identités de service et partagées via une revue basée sur le propriétaire plutôt que de les laisser en l'état indéfiniment.

1. Désactiver les comptes obsolètes

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -SearchBase 'OU=Users,DC=corp,DC=local' `
  -Properties LastLogonDate | ForEach-Object {
    Disable-ADAccount -Identity $_
    Write-Host "Disabled: $($_.SamAccountName) - Last login: $($_.LastLogonDate)"
  }

Pour les comptes utilisateurs qui ne devraient manifestement plus exister, désactivez-les d'abord, surveillez l'impact, puis supprimez-les après la période de rétention acceptée par vos équipes opérationnelles. Ne supprimez pas d'objets privilégiés ou liés à un service en première action, sauf si l'absence de dépendance est déjà prouvée.

2. Réduire l'appartenance aux groupes privilégiés

$groups = @('Domain Admins','Enterprise Admins','Schema Admins')
$groups | ForEach-Object {
  Get-ADGroupMember -Identity $_ -Recursive |
    Select-Object @{N='Group';E={$_}}, SamAccountName, distinguishedName
} | Export-Csv privileged_members.csv -NoTypeInformation

Supprimez le privilège permanent avant de débattre de la suppression du compte. Un compte obsolète sans appartenance à Domain Admins ou à des droits délégués équivalents reste un travail de nettoyage, mais ce n'est plus la même exposition Tier-0 immédiate.

3. Appliquer une politique plus stricte aux identités privilégiées

New-ADFineGrainedPasswordPolicy -Name 'PrivilegedAccountsPSO' `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -ComplexityEnabled $true `
  -PasswordHistoryCount 24 `
  -MaxPasswordAge (New-TimeSpan -Days 60) `
  -LockoutThreshold 3

Add-ADFineGrainedPasswordPolicySubject -Identity 'PrivilegedAccountsPSO' `
  -Subjects 'Domain Admins'

Microsoft documente les politiques de mots de passe affinées comme un moyen d'appliquer des paramètres de mot de passe et de verrouillage différents à différents ensembles d'utilisateurs, y compris des paramètres plus stricts pour les comptes privilégiés. C'est utile quand des comptes privilégiés existent encore, mais cela ne remplace pas la suppression des appartenances superflues.

4. Corriger le processus de cycle de vie, pas seulement les comptes

Les causes récurrentes sont généralement opérationnelles :

l'offboarding qui désactive l'accès e-mail mais oublie les groupes AD
les comptes de service sans propriétaire après un changement d'équipe
les comptes d'administration d'urgence jamais remis sous revue
les comptes partagés maintenus en vie parce que personne ne veut tester la dépendance

Une remédiation crédible referme ces lacunes de processus pendant que le nettoyage des comptes est en cours.

5. Mettre en quarantaine les exceptions plutôt que de les oublier

Si un compte à faible activité doit rester activé, documentez-le comme une exception avec une date de revue et un propriétaire nommé. L'exception doit inclure :

pourquoi le compte doit rester activé
quels systèmes en dépendent
quels groupes ou droits délégués il possède
ce qui casserait s'il était désactivé
quelle surveillance prouve qu'il n'est utilisé que comme prévu

Les exceptions sans date d'expiration sont la façon dont les comptes obsolètes et sur-privilégiés reviennent.

Valider avant de clôturer le constat

Un nettoyage de comptes obsolètes n'est pas terminé quand le tableur paraît plus court. Validez le résultat réel du contrôle.

relancez l'export des comptes inactifs et confirmez que les mêmes identités à haut risque ne sont plus activées
confirmez que l'appartenance aux groupes privilégiés a bien été supprimée, et pas seulement laissée en place sur un objet désactivé qui pourrait être réactivé sans changement
passez en revue l'activité récente des événements 4624 et 4768 pour repérer les comptes réutilisés après la décision de nettoyage
documentez le propriétaire, la dépendance et la prochaine date de revue pour tout compte devant rester activé malgré une faible activité
vérifiez le périmètre des politiques de mot de passe affinées pour les comptes privilégiés restants
revoyez les chemins de groupes imbriqués pour vérifier que le privilège n'a pas été préservé indirectement

Pour les comptes de service, la vérification finale doit aussi confirmer que la dépendance est réelle et toujours d'actualité. Si personne ne peut prouver la raison d'être du compte, c'est un argument pour le retirer, pas pour une nouvelle exception.

Comment EtcSec détecte cela

EtcSec rend ce constat plus exploitable en corrélant l'inactivité, le niveau de privilège, l'ancienneté du mot de passe et l'absence de couverture par une politique. C'est important car un compte dormant à faible valeur et un compte dormant privilégié ne posent pas le même problème opérationnel.

Comptes Obsolètes et Sur-Privilégiés : Le Risque Caché dans Active Directory