Revue creation objets AD whenCreated : provisionnement approuvé

Qu’est-ce qu’une revue des créations d’objets AD ?

Une revue creation objets AD whenCreated relie les objets récemment créés dans l’annuaire à un provisionnement approuvé. Le résultat utile est un relevé daté indiquant quels utilisateurs, ordinateurs et groupes ont été examinés, qui en est responsable, quelle demande justifiait leur création et quelles preuves restent à obtenir. Le total des objets récents est un point de départ pour ce travail ; il ne démontre pas que les créations étaient malveillantes ou approuvées.

Microsoft décrit whenCreated comme un horodatage de création défini par le système, répliqué et disponible dans le catalogue global. Il fournit une date, sans identifier le demandeur ni donner de justification métier. Gardez ces types de preuves distincts pendant toute la revue. Microsoft Learn : attribut When-Created.

La question pratique est de savoir si chaque création observée relève d’un processus de provisionnement documenté. Un nouvel ordinateur peut correspondre à un déploiement prévu, un groupe à une application approuvée et un utilisateur à une arrivée légitime. Ces possibilités exigent des pièces justificatives et un responsable identifié. Les noms, descriptions et une OU familière peuvent orienter l’enquête, mais ne doivent pas remplacer une preuve d’approbation.

Fonctionnement : constituer un registre d’objets daté

Commencez par consigner le domaine, la base de recherche, le contrôleur de domaine interrogé, l’heure de collecte et l’intervalle de revue. Conservez les paramètres de collecte et les éventuelles erreurs avec les lignes d’objets. Vous pourrez ainsi distinguer une observation de l’annuaire d’une hypothèse sur le périmètre couvert par la collecte.

Conservez une ligne de revue par identifiant d’objet stable, avec le nom distinctif actuel comme repère lisible. Préservez séparément l’appartenance aux populations : un objet présent dans les populations utilisateurs et ordinateurs doit garder les deux étiquettes tout en ne contribuant qu’une fois au registre des objets uniques. Cela concerne les comptes de service administrés de groupe, que les filtres LDAP du collecteur peuvent inclure dans les deux populations.

Utilisez des collections distinctes pour les objets dans l’intervalle, ceux hors intervalle, ceux dont la date est indisponible et les populations ou emplacements illisibles. Une requête en échec constitue une observation en échec. Elle ne peut produire un résultat vide fiable. De même, un objet exclu par un filtre de date n’a pas été classé comme approuvé.

La revue hebdomadaire des créations récentes du processus d’audit AD récurrent fournit la cadence opérationnelle. Ce registre apporte les preuves relatives aux objets et au provisionnement nécessaires à cette revue. Conservez explicitement l’intervalle de revue plutôt que de considérer la fenêtre rétrospective de dix jours d’un produit comme une politique de l’organisation.

Détection : lire whenCreated avec un périmètre explicite

Utilisez un hôte équipé du module PowerShell Active Directory et un compte autorisé à lire l’annuaire. Les exemples ci-dessous sont des requêtes de revue fondées sur la documentation, pas des commandes exécutées sur l’annuaire d’un client. Remplacez le domaine et le DC d’exemple avant utilisation.

Get-ADObject documente -Filter, les -Properties supplémentaires, -SearchBase, -SearchScope et -Server. Les exemples définissent -SearchScope Subtree pour inclure la base de recherche et ses descendants. Les filtres ci-dessous combinent ces paramètres avec les trois définitions de populations du collecteur et une borne inférieure sur whenCreated. Microsoft Learn : Get-ADObject.

$reviewEnd = [DateTime]::UtcNow
$reviewStart = $reviewEnd.AddDays(-10)
$base = 'DC=contoso,DC=local'
$dc = 'dc01.contoso.local'
$properties = 'whenCreated','objectGUID','objectSid','objectClass'

$users = Get-ADObject -Filter {objectClass -eq 'user' -and (objectCategory -eq 'person' -or objectClass -eq 'msDS-GroupManagedServiceAccount') -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$computers = Get-ADObject -Filter {objectClass -eq 'computer' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$groups = Get-ADObject -Filter {objectClass -eq 'group' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

Les requêtes à borne inférieure omettent les dates plus anciennes et indisponibles. Pour une observation distincte sur le périmètre, effectuez une lecture sans prédicat de date :

$scopeObjects = Get-ADObject -Filter * -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

Cette lecture plus large n’est pas équivalente aux trois requêtes par population. Classez ses objets avant toute comparaison. Par défaut, la cmdlet exclut les objets supprimés ; aucune des deux lectures ne reconstitue un historique complet de l’annuaire.

Étape 1 : préserver l’observation

Enregistrez les définitions des requêtes et leurs résultats, réussis ou en échec, avant d’interpréter les lignes. Si une requête s’arrête sur une erreur, consignez l’erreur et le périmètre concerné, puis recherchez la cause de l’échec de collecte. Ne remplacez pas le résultat par un tableau vide en poursuivant comme si la population avait été examinée.

Pour les dates retournées, conservez la valeur d’origine et normalisez l’affichage du registre en UTC. Évaluez la borne inférieure de façon cohérente : le collecteur utilise une comparaison stricte après son heure de référence moins dix jours. Un horodatage exactement sur cette borne est exclu. Son code ne fixe aucune borne supérieure à l’heure de référence ; signalez donc séparément toute date retournée après la fin de revue consignée, sans l’intégrer silencieusement à l’intervalle normal.

Étape 2 : rapprocher les objets uniques

Regroupez les observations par GUID d’objet, conservez toutes les étiquettes de populations et comparez le registre obtenu aux comptes par population du collecteur. Expliquez les différences par le périmètre, les limites, le traitement des dates et les classes qui se chevauchent avant de les considérer comme des créations inexpliquées. Un compte dédupliqué peut légitimement différer de la somme des observations d’utilisateurs, d’ordinateurs et de groupes.

Gardez les comptes désactivés dans la revue. Leur état ne répond pas à la question du motif de création ni de l’approbation de leur demande de provisionnement. Le détecteur d’objets récents lui-même n’exclut pas les utilisateurs ou ordinateurs désactivés.

Étape 3 : rattacher chaque ligne au provisionnement

Demandez au responsable identifié de fournir la demande et les preuves d’approbation propres à l’objet. Faites correspondre les identifiants, la classe prévue, l’emplacement et la finalité, plutôt que d’accepter un ticket de déploiement générique pouvant concerner plusieurs objets sans rapport. Consignez tout désaccord entre la demande et l’objet observé comme un point de suivi.

Une réponse du responsable sans pièce justificative reste une déclaration à évaluer. À l’inverse, l’absence de réponse correspond à une provenance non résolue, sans prouver une activité d’attaquant. Distinguez ces résultats pour que la remédiation traite le manque réel de preuves.

Détection : corréler l’événement 5137 uniquement avec une couverture prouvée

L’événement 5137 consigne la création d’un objet d’annuaire sur un contrôleur de domaine où l’audit des réussites est activé sous Audit Directory Service Changes. Microsoft précise que la SACL de l’objet parent doit auditer l’action Create pertinente pour la classe d’objet. Les deux contrôles doivent avoir été appliqués avant la création ; les enregistrements locaux ou centraux conservés doivent couvrir cette période. Microsoft Learn : événement 5137.

Faites correspondre ObjectGUID, étayé par ObjectDN et ObjectClass, au registre. Conservez l’heure UTC de l’événement, le DC émetteur et l’identifiant d’enregistrement. SubjectUserSid, SubjectUserName et SubjectDomainName identifient le compte demandeur. SubjectLogonId peut aider à corréler une session ; il n’identifie pas la personne derrière une automatisation et ne prouve pas l’approbation.

Le guide de configuration de la politique d’audit explique pourquoi les événements doivent d’abord être générés. Pour 5137, ajoutez les preuves de la SACL Create du parent et de la conservation ; le compteur de créations ne prouve aucun de ces éléments.

Résoudre les créations non approuvées et les lacunes de preuve (Remediation)

La remédiation commence par la décision relative à chaque objet, pas par la réduction d’un compte de créations récentes. Un provisionnement approuvé doit rester documenté même tant que l’objet se trouve dans la fenêtre rétrospective. Une création non résolue exige un responsable et une voie d’investigation.

1. Compléter le dossier de provisionnement. Joignez l’identifiant de l’objet, la demande, l’approbation et la réponse du responsable à la ligne de revue. Confirmez que la finalité et l’emplacement observés concordent avec la demande approuvée. Consignez toute exception justifiée et la personne responsable de sa résolution.
2. Faire remonter les créations inexpliquées ou incohérentes. Préservez les observations de l’annuaire et les enregistrements événementiels disponibles. Demandez aux responsables des identités et des services d’évaluer l’usage prévu de l’objet et son exposition actuelle. Traitez les objets dont l’absence d’autorisation est confirmée dans les processus d’incident et de changement de l’organisation, avec une décision explicite de confinement.
3. Corriger les lacunes de collecte. Examinez les bases de recherche, les limites de populations configurées et les échecs de requêtes. Répétez les lectures sur le périmètre après correction de la cause et conservez la nouvelle heure d’observation. Gardez les observations antérieures en échec dans le registre pour que le dossier final ne suggère pas une couverture ininterrompue.
4. Corriger la couverture événementielle future. Faites vérifier par des administrateurs autorisés l’audit effectif des réussites de Directory Service Changes et les SACL Create pertinentes des parents. Vérifiez que les archives conservées sont réellement consultables. Validez la génération et la collecte futures par une création de test approuvée, puis conservez les preuves obtenues.
5. Vérifier la clôture à partir du registre. Rapprochez le registre actualisé des objets uniques du provisionnement approuvé et des exceptions documentées. Ne clôturez que les décisions étayées par des preuves ; maintenez ouverts les éléments de provenance inconnue et de périmètre incomplet.

Évitez toute suppression ou désactivation automatique fondée uniquement sur l’âge, un nom inconnu ou l’absence d’événement de création. Ces signaux justifient une enquête, tandis que la décision de remédiation exige des preuves sur l’objet et ses dépendances. Les exemples de cet article lisent l’annuaire ; ils n’autorisent aucun changement de l’annuaire.

Comment EtcSec détecte ce signal

Au commit du collecteur 9f698083354a1cb7f625df5cb490a515823c3257, RECENT_OBJECTS_CREATED est un constat Info. Sa méthode Detect() additionne les entrées utilisateurs, ordinateurs et groupes dont la valeur Created est non nulle et strictement postérieure à DetectorData.Now - 10 × 24 hours. Dix jours est une heuristique du produit. La comparaison n’a aucune borne supérieure à Now, et le détecteur n’exclut pas les comptes désactivés.

Le constat fournit un total et les compteurs agrégés newUsers, newComputers et newGroups. Il ne fournit aucune liste AffectedEntities par objet et ne détermine ni demandeur, ni intention, ni autorisation. Les analyseurs LDAP obtiennent Created depuis whenCreated ; les valeurs absentes ou les formats que parseADTime ne comprend pas deviennent zéro et sont exclus de ce calcul.

La collecte dépend de BaseDN, de MaxUsers, de MaxGroups et de MaxComputers. Une erreur lors de la récupération de l’une des trois populations arrête la collecte. Les populations peuvent se chevaucher : le filtre utilisateurs inclut les gMSA et le filtre ordinateurs peut retourner les mêmes objets. Le compte additionné ne constitue donc pas un inventaire unique de tous les objets AD.

Utilisez ce constat pour lancer le registre indépendant et la revue de provisionnement décrits ci-dessus. Un compte inférieur lors d’un audit ultérieur peut simplement refléter le vieillissement des objets au-delà de la fenêtre rétrospective, un changement de périmètre ou une différence de collecte. Vérifiez directement les décisions de revue et les preuves avant de clôturer le travail.