comptes communs AD : qualifier les preuves de connexion

Ce que doit établir l’attribution des comptes communs AD

L’attribution des comptes communs AD commence par une distinction : un compte d’annuaire est un principal de sécurité, tandis qu’un opérateur est la personne qui l’utilise. Un compte nommé shared-support peut mériter un examen, mais son nom ne prouve pas que plusieurs personnes connaissent ses identifiants. Une connexion sous ce compte peut établir son utilisation sans identifier la personne qui en est à l’origine.

Traitez une détection fondée sur le nom comme une file de dossiers à investiguer. Pour chaque compte sélectionné, établissez son propriétaire, sa finalité réelle, ses utilisateurs autorisés, les systèmes qui en dépendent et les preuves de connexion disponibles. Conservez l’observation dans l’annuaire, les preuves d’authentification et l’attribution à une personne comme des conclusions distinctes. Une dépendance de service légitime et une session humaine impossible à attribuer nécessitent des réponses différentes, même lorsqu’elles utilisent le même nom de compte.

Notre revue de la classification, du propriétaire et de l’expiration des comptes explique comment clarifier les noms génériques et la finalité des comptes. Ce guide ajoute les exigences de preuve pour attribuer une activité : quelle identité chaque événement Windows décrit, où effectuer les corrélations et ce qui reste inconnu avant le retrait du compte.

Comment fonctionne le processus de qualification

1. Constituer un dossier pour chaque compte

Consignez le domaine du compte, son nom SAM, son SID, son état d’activation actuel, l’heure de collecte, le propriétaire responsable et l’usage prévu. Listez les services, tâches planifiées, applications, procédures d’administration et exigences de reprise connus. Le propriétaire est responsable de la résolution du dossier ; sa responsabilité ne permet pas, à elle seule, d’établir qui a effectué une connexion donnée.

Demandez au propriétaire quelles personnes peuvent obtenir ou utiliser les identifiants, et par quelles voies d’accès. Distinguez l’autorisation documentée de l’utilisation observée. Si le propriétaire affirme qu’une seule personne utilise le compte, conservez cette déclaration comme une assertion à confronter aux preuves. Si personne ne peut identifier le propriétaire, gardez le dossier ouvert avec une personne nommément responsable de la prochaine étape d’investigation.

Examinez aussi les comptes désactivés. Le détecteur inclut les utilisateurs désactivés dont le nom correspond aux motifs ; son décompte ne représente donc pas le nombre de sessions partagées actives. Préservez les preuves historiques disponibles et vérifiez les dépendances avant de décider si un objet désactivé peut être retiré. L’état actuel de l’annuaire ne permet pas d’établir ce qui s’est produit pendant une période d’investigation antérieure.

2. Définir le périmètre des preuves avant de rechercher

Identifiez les postes de travail ou hôtes d’administration initiateurs, les serveurs de destination et l’intervalle de temps pertinent. Vérifiez lesquels de ces systèmes génèrent et transmettent les événements Security requis. Les deux pages de référence classent les événements sous Audit Logon. Une collecte limitée aux contrôleurs de domaine ne démontre pas la couverture de toutes les sessions de destination ou de tous les processus initiateurs.

Pour l’inventaire plus large des stratégies d’audit et des événements, consultez notre guide des événements et de la collecte pour la supervision d’Active Directory. Ici, la question opérationnelle est plus précise : l’équipe peut-elle récupérer les preuves concernant ce compte, sur ces hôtes, pendant cet intervalle, en préservant les champs d’identité ?

Documentez la rétention locale, les lacunes de transmission, le comportement de l’analyseur, les limites d’accès et la synchronisation des horloges avant de tirer une conclusion négative. Préservez le XML original de l’événement ou un enregistrement équivalent sans perte, en complément des champs normalisés. Une colonne SIEM nommée Account peut masquer le choix de Subject ou de Target par l’analyseur ; validez cette correspondance avec l’événement lui-même.

Détection : distinguer les identités de 4624 et 4648

3. Lire la session réussie sur la destination

La référence Microsoft de l’événement 4624 le définit comme la création d’une session de connexion sur l’ordinateur auquel on accède. Subject décrit le compte qui signale ou invoque la connexion ; New Logon décrit le compte pour lequel la session a été créée. N’attribuez pas la session à une personne en lisant uniquement Subject.

Conservez séparément ces champs d’événement dans le dossier :

Par exemple, Logon Type 3 décrit une connexion réseau, 4 une connexion par traitement par lots, 5 une connexion de service et 10 une connexion interactive à distance. Ces descriptions aident à vérifier si l’usage observé correspond à la finalité déclarée par le propriétaire. Ce ne sont pas des verdicts d’attribution à une personne : une session réseau peut être initiée par une automatisation, et une session de service n’identifie pas la personne qui l’a configurée.

La référence de 4624 explique aussi que la disponibilité de l’adresse, du port et du poste de travail dépend du contexte d’authentification et du protocole. Un champ de provenance vide doit rester vide dans le dossier de preuves ; ne le complétez pas à partir d’un autre événement simplement parce que le nom du compte correspond. Le SID du compte partagé identifie ce principal, sans préciser lequel de ses utilisateurs possibles a agi.

4. Lire les identifiants explicites sans inverser les identités

La référence Microsoft de l’événement 4648 décrit un processus qui tente une connexion avec des identifiants fournis explicitement. Cela se produit aussi lors d’activités courantes, notamment avec les tâches planifiées et RUNAS. Subject est le compte demandeur ; Account Whose Credentials Were Used est l’identité correspondant aux identifiants. Il peut s’agir de comptes différents.

Un enregistrement 4648 avec un Subject nominatif et un Target partagé fournit une preuve utile que ce contexte de sécurité nominatif demande l’utilisation des identifiants partagés. Il ne permet pas, à lui seul, d’établir quelle personne contrôle ce contexte. Il décrit aussi une tentative ; ne la transformez pas en connexion réussie sur la destination sans preuves complémentaires. Le XML de l’événement contient le nom, le domaine et le GUID de la cible ; ne supposez pas qu’il fournit un SID cible simplement parce qu’un schéma normalisé prévoit une colonne pour celui-ci.

5. Corréler sur le bon hôte et dans la bonne session

Partez de l’hôte, de l’horodatage et de la section d’identité pertinents. Les consignes Microsoft de corrélation de Logon ID limitent son unicité à un ordinateur entre deux redémarrages. Limitez les jointures sur Logon ID à cet hôte et à cet intervalle entre redémarrages, sans les étendre au domaine. Pour un 4648 initiateur, recherchez la session 4624 locale correspondante en utilisant le contexte de connexion Subject de 4648 et le contexte New Logon de 4624. Joindre systématiquement Subject à Subject répond à une autre question.

Préservez les deux GUID de 4648. Les références Microsoft décrivent une corrélation 4624/4648 sur le même ordinateur lorsque le GUID pertinent est disponible. Ni un GUID de Subject ni un GUID des identifiants ne doit être choisi automatiquement simplement parce qu’un analyseur les a renommés sous un même champ générique. Établissez quelle session la correspondance proposée représente et conservez le fondement de cette décision.

Un GUID composé uniquement de zéros est une preuve indisponible, et non une session commune à tous les enregistrements contenant des zéros. Entre les hôtes initiateurs et les hôtes de destination, construisez une chronologie à partir du compte et du domaine, de l’hôte cible, du contexte de provenance disponible et des horodatages. Qualifiez cette association de contextuelle lorsqu’aucun lien de session fiable n’existe. N’assimilez jamais des Logon ID hexadécimaux identiques sur deux machines.

6. Consigner le niveau de confiance et les explications concurrentes

Utilisez des catégories explicites de confiance comme convention de revue, et non comme système de notation Microsoft. L’utilisation du compte peut être confirmée alors que l’attribution à une personne reste indéterminée. Conservez des colonnes distinctes pour ces conclusions au lieu d’attribuer un score rassurant unique à tout le dossier.

Une preuve indépendante peut être un enregistrement de passerelle d’accès avec authentification individuelle ou de retrait d’identifiants, si l’organisation en dispose et si ses horodatages et identités peuvent être vérifiés. Une liste de personnes, une adresse IP ou les seuls souvenirs du propriétaire constituent des preuves plus faibles. Consignez les hypothèses alternatives, telles qu’une automatisation planifiée ou une autre personne contrôlant la session initiatrice ; documentez pourquoi l’explication retenue est mieux étayée.

Il s’agit d’une procédure d’investigation, et non d’une requête présentée comme exécutée. Aucun test sur un hôte ou dans un SIEM n’a été réalisé pour ce guide. Validez les correspondances de champs et les corrélations à l’aide d’une activité contrôlée et autorisée avant de vous y fier en exploitation.

Rétablir la responsabilité avant le retrait (Remediation)

7. Remplacer l’accès humain partagé par un accès nominatif

Pour les procédures humaines, prévoyez un accès avec des identités individuelles d’opérateurs et vérifiez que les enregistrements préservent l’identité individuelle jusqu’à l’action privilégiée. Renommer shared-support avec un nom d’apparence personnelle ne crée pas de traçabilité des responsabilités. Confirmez qui peut obtenir les identifiants, comment l’accès est approuvé et comment il peut être retiré lorsque le rôle d’une personne change.

Pour l’automatisation, documentez la charge de travail et son propriétaire séparément des opérateurs humains. Examinez les possibilités de migration avec l’équipe applicative au lieu d’imposer à un service une conception d’identité interactive. L’objectif est de supprimer le partage inutile d’identifiants tout en préservant les dépendances légitimes et une piste d’accès vérifiable.

Si un remplacement immédiat est impossible, documentez une exception temporaire avec un propriétaire, une finalité approuvée, des utilisateurs autorisés, des hôtes permis, des preuves compensatoires, une échéance et un jalon de migration. Une exception sans piste d’attribution exploitable doit l’indiquer explicitement. Une échéance future ne rend pas attribuable la session ambiguë d’aujourd’hui.

8. Désactiver uniquement une identité examinée

Avant le retrait, obtenez l’évaluation des dépendances par le propriétaire, vérifiez les dispositions de reprise, préservez les dossiers d’investigation et convenez des responsabilités de validation et de retour arrière. Décidez séparément si les preuves justifient une réponse à une compromission. Une détection fondée uniquement sur le nom ne démontre pas une compromission et ne justifie pas une opération sur les identifiants à l’échelle du parc.

Pour un compte ordinaire dont le retrait a été approuvé, l’exemple suivant adapte les paramètres documentés de Disable-ADAccount. Le DN et le contrôleur de domaine accessible en écriture sont illustratifs ; vérifiez les deux avant utilisation. Ces exemples nécessitent le module ActiveDirectory et des permissions dans l’annuaire ; ils n’ont pas été exécutés pour cet article.

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -WhatIf

-WhatIf prévisualise l’opération ; il ne teste pas si une application cessera de fonctionner. Après la revue des dépendances et pendant la fenêtre de changement approuvée, l’action ciblée correspondante est :

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Ne transmettez pas toutes les correspondances de nom à une opération de désactivation par pipeline. Vérifiez l’état résultant de l’annuaire et les procédures dépendantes après le changement approuvé. La suppression nécessite une décision distincte concernant la rétention et la reprise ; ni un faible décompte du détecteur ni un intervalle sans événements ne fournit cette autorisation.

9. Clore le dossier avec la décision étayée par les preuves

Répondez à trois questions pour chaque compte : quels hôtes et stratégies d’audit ont fourni les preuves requises ; existe-t-il une identité nominative indépendante d’opérateur ; et quelles dépendances nécessitent une exception temporaire avant le retrait ? Si une réponse manque, conservez la question non résolue, le propriétaire responsable et la prochaine date de revue.

Terminez par un résultat concret : accès humain remplacé, dépendance de charge de travail migrée, identité inutile désactivée ou exception temporaire maintenue. Joignez la justification du niveau de confiance et les lacunes de preuve. Une revue achevée doit expliquer à la fois la décision opérationnelle et les limites de toute affirmation d’attribution historique.

Comment EtcSec détecte ce cas

Le contrôle SHARED_ACCOUNT d’etc-collector est une détection de sévérité moyenne dans la catégorie Accounts. Au commit du collecteur 0423094759d50002457031317098417993e19510, Detect() dans public/internal/audit/detectors/ad/accounts/patterns/shared-account.go:45 compare le SAMAccountName des utilisateurs collectés à quatre préfixes insensibles à la casse :

(?i)^shared
(?i)^common
(?i)^generic
(?i)^guest-

Il s’agit d’heuristiques du produit fondées sur les noms. shared-support et CommonDesk correspondent ; my-shared-support ne correspond pas à ^shared, car le préfixe est ancré au début. Le contrôle n’inclut pas les préfixes service/svc, n’examine pas qui connaît le mot de passe et ne détermine pas combien de personnes utilisent un compte.

Chaque utilisateur correspondant est ajouté une fois, puis la boucle interne sur les motifs s’arrête. Count est le nombre d’utilisateurs collectés correspondants, y compris les comptes désactivés : aucun filtre n’est appliqué sur l’état d’activation. Lorsque les détails sont demandés et que des correspondances existent, la détection inclut les entités utilisateur concernées. La fonction renvoie une détection même lorsque Count vaut zéro.

Le fournisseur LDAP fournit les utilisateurs et attributs de l’annuaire, sans l’historique des événements 4624/4648 ni une identité d’opérateur. Ce Detect ne corrèle pas les sessions, ne prouve pas le partage d’identifiants, n’évalue pas les enregistrements indépendants d’attribution et ne vérifie pas un retrait approuvé. Un résultat positif ouvre le processus de qualification décrit ci-dessus ; un décompte nul établit uniquement qu’aucun nom collecté ne correspondait à ces expressions, sans démontrer que toute utilisation de compte est attribuable.