Ajout à un groupe privilégié : établir les droits et les usages réels
Enquêtez sur un ajout à un groupe Windows ou Active Directory : acteur, membre, imbrications, tokens et accès observés avant un confinement ciblé.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Une alerte annonce qu’un compte a été ajouté à un groupe sensible. Le changement mérite une investigation, mais il reste plusieurs questions : qui l’a demandé, quel membre a été ajouté, quels droits ce groupe ouvre-t-il réellement et ces droits ont-ils été utilisés ? Supprimer l’appartenance ne répond pas à toutes ces questions.
MITRE ATT&CK décrit l’ajout à des groupes locaux ou de domaine sous T1098.007 comme une méthode possible de persistance et d’élévation de privilèges. Ce repère décrit un abus possible d’une fonction légitime ; il ne rend pas malveillante toute opération d’administration. Source : MITRE ATT&CK, Additional Local or Domain Groups
Ce guide propose une méthode indépendante du SIEM, avec des exemples Windows et Active Directory. Les faits documentés sont séparés de nos recommandations. Il ne décrit aucun incident client ni aucune intégration Seculogik disponible.
1. Séparer l’acteur, le membre et le groupe
La documentation Microsoft de l’événement 4732 distingue le sujet qui demande l’ajout, le membre ajouté et le groupe destinataire. Elle fournit leurs identifiants et indique que le nom du membre peut être absent pour un groupe local. Un nom vide ne suffit donc pas à conclure que le membre est inconnu si son SID est présent. Source : Microsoft, événement 4732
Notre recommandation : conserver l’événement d’origine et construire trois fiches distinctes. Pour chacune, relevez le SID, le nom observé et le domaine ou l’ordinateur pertinent. Ajoutez l’hôte émetteur, les heures d’origine et de réception, ainsi que la référence de collecte. Ne réduisez pas l’opération à une ligne « utilisateur devenu administrateur ».
L’identité technique enregistrée comme acteur n’identifie pas nécessairement la personne qui contrôlait l’accès. Vérifiez le contexte d’administration et l’autorisation auprès du responsable concerné. Une demande approuvée doit correspondre au membre, au groupe, au périmètre et à la période observés, pas seulement à une opération vaguement similaire.
L’identifiant de session du sujet concerne l’acteur de la modification. Gardez-le séparé des sessions du membre ajouté : elles serviront à étudier l’usage éventuel des nouveaux accès, qui est une autre question.
2. Lire le type de groupe avant de qualifier la portée
Microsoft regroupe ces événements dans l’audit de gestion des groupes de sécurité :
- 4728 : ajout à un groupe global de sécurité du domaine.
- 4732 : ajout à un groupe local de sécurité ; l’événement peut apparaître sur un contrôleur de domaine, un serveur membre ou un poste.
- 4756 : ajout à un groupe universel de sécurité du domaine.
Les définitions de 4728 et 4756 renvoient aux champs de 4732, avec une différence de type de groupe. Source : Microsoft, Audit Security Group Management
Nous recommandons de confirmer l’emplacement et la portée du groupe dans l’annuaire ou sur le système concerné. « Local » ne signifie pas automatiquement « limité au poste qui affiche l’alerte » : le contexte d’un groupe local de domaine doit être distingué de celui d’un groupe propre à une machine.
Ces numéros signalent une modification d’appartenance à un groupe de sécurité, pas une classification universelle de privilège. Un groupe métier peut donner un accès très sensible ; un nom inquiétant peut ne plus correspondre à des permissions actives. Vérifiez la fonction réelle avant de fixer la priorité.
Si les résultats sont incomplets, examinez la politique d’audit, les systèmes couverts et la conservation. L’absence d’un événement dans la recherche ne suffit pas à reconstituer l’historique des appartenances.
3. Suivre les imbrications jusqu’aux ressources
Microsoft décrit les groupes de sécurité comme des ensembles pouvant contenir des comptes et d’autres groupes. Leur portée encadre les appartenances et l’attribution des permissions. La documentation distingue également droits utilisateur et permissions sur les ressources. Source : Microsoft, groupes de sécurité Active Directory
Notre recommandation : reconstruire le chemin pertinent entre le membre ajouté et les ressources accessibles. Si un groupe est ajouté à un autre, examinez les membres indirectement concernés ; ne limitez pas l’enquête au nom présent dans l’alerte. Conservez les étapes de cette relation et les restrictions de portée rencontrées.
Vérifiez ensuite ce que le groupe permet sur les systèmes cibles : administration locale, droits particuliers, accès à des partages ou délégation sur des objets, selon la configuration réelle. Un intitulé ne remplace pas l’examen des permissions et des restrictions applicables.
Présentez ce relevé comme un état daté. Les appartenances et permissions actuelles ne décrivent pas nécessairement celles de la période de l’ajout. Recherchez l’historique disponible avant de conclure qu’un chemin aujourd’hui visible existait déjà, ou qu’un chemin absent n’a jamais existé.
4. Examiner le contexte de sécurité, pas seulement la liste actuelle
Microsoft définit le token d’accès Windows comme le contexte de sécurité d’un processus ou d’un thread. Il contient notamment l’identité, des SID de groupes et des privilèges ; le système produit un token lors de la connexion. Source : Microsoft, tokens d’accès
Notre recommandation : distinguer l’appartenance enregistrée dans l’annuaire, le contexte des sessions existantes et celui d’une nouvelle connexion contrôlée. Ne déduisez pas qu’un ajout est déjà utilisable partout, ni qu’un retrait a coupé toutes les possibilités d’accès, sur la seule lecture de la liste des membres.
Faites vérifier les sessions et processus pertinents par une personne habilitée. Le traitement dépend du système, du service et du mécanisme d’autorisation. Évitez une promesse de délai universel de propagation ou de révocation ; indiquez les contrôles réalisés et ce qui reste à vérifier.
N’utilisez pas le compte suspect pour effectuer des opérations privilégiées en production afin de « prouver » son accès. Si un test est nécessaire, définissez une identité et une ressource contrôlées, une action bénigne, une autorisation et un résultat attendu. Un test doit réduire l’incertitude sans agrandir l’incident.
5. Rechercher les usages sans confondre capacité et action
L’événement 4624 documente une session créée sur le système auquel l’accès a eu lieu. Il apporte du contexte de connexion, sans démontrer à lui seul l’exécution d’une opération privilégiée. Source : Microsoft, événement 4624
De même, 4672 signale l’attribution de certains privilèges sensibles à une nouvelle session. Il ne décrit pas leur exercice et peut correspondre à une activité système habituelle. Source : Microsoft, événement 4672
Nous recommandons donc deux recherches distinctes : les activités de l’acteur qui a modifié le groupe et celles du membre ajouté. Pour chaque rapprochement, gardez l’identité, l’hôte, la session pertinente et la période. Un identifiant de session identique sur deux ordinateurs ne constitue pas, à lui seul, une relation prouvée.
Cherchez ensuite les effets sur les ressources concernées : changement de configuration, lancement d’un traitement administratif, accès à un objet ou action enregistrée par l’application, selon les données réellement disponibles. Distinguez accès possible, connexion observée, action réussie et tentative refusée.
Documentez les périodes et catégories sans couverture. « Aucun usage retrouvé dans les sources examinées » est une conclusion différente de « aucun usage n’a eu lieu ». L’étendue de la recherche doit accompagner le résultat.
6. Vérifier une réponse ciblée et son effet
Préservez les appartenances, les permissions pertinentes et les événements utiles avant le changement, dans la mesure compatible avec l’urgence. Faites autoriser le retrait ou les restrictions nécessaires, avec un responsable et une prise en compte des usages légitimes. Traitez également l’accès qui a permis l’ajout si les indices le justifient.
Après intervention, nous recommandons de vérifier séparément la disparition du chemin non autorisé, le traitement des sessions pertinentes et le résultat sur la ressource cible. La réussite d’une commande de retrait ne clôt pas ces trois contrôles. Conservez aussi une surveillance de réapparition adaptée au risque.
Exemple entièrement fictif : l’ajout d’un groupe de support est approuvé, mais l’examen révèle une imbrication lui ouvrant une ressource hors périmètre. L’autorisation de l’ajout n’efface pas l’écart de droits ; cet écart ne prouve pas pour autant une compromission. Documentez le changement légitime et le chemin excessif séparément.
Le dossier final doit préciser l’opération, son autorisation, les droits établis, les usages retrouvés, les inconnues et les mesures vérifiées. Nos ressources gratuites d’investigation peuvent aider à organiser ces éléments sans confondre appartenance, privilège, usage et attribution.