Revisione creazione oggetti AD whenCreated: provisioning approvato

Che cos’è una revisione della creazione di oggetti AD?

Una revisione creazione oggetti AD whenCreated collega gli oggetti di directory creati di recente a un provisioning approvato. Il risultato utile è un registro datato che indica quali utenti, computer e gruppi sono stati esaminati, chi ne è responsabile, quale richiesta ne giustificava la creazione e quali prove restano da chiarire. Il totale degli oggetti recenti è un punto di partenza per questo lavoro; non dimostra che le creazioni fossero malevole o approvate.

Microsoft descrive whenCreated come un timestamp di creazione impostato dal sistema, replicato e disponibile nel catalogo globale. Fornisce una data, non l’identità del richiedente né una giustificazione aziendale. Tenete distinti questi tipi di prove durante tutta la revisione. Microsoft Learn: attributo When-Created.

La domanda pratica è se ogni creazione osservata appartenga a un processo di provisioning documentato. Un nuovo computer può corrispondere a una distribuzione prevista, un gruppo può supportare un’applicazione approvata e un utente può essere un nuovo ingresso legittimo. Queste possibilità richiedono documentazione e un responsabile identificato. Nomi, descrizioni e una OU familiare possono orientare l’indagine, ma non devono sostituire una prova di approvazione.

Funzionamento: costruire un registro degli oggetti datato

Iniziate registrando il dominio, la base di ricerca, il controller di dominio interrogato, l’ora della raccolta e l’intervallo di revisione. Conservate le impostazioni di raccolta e gli eventuali errori insieme alle righe degli oggetti. Questo permette di distinguere un’osservazione della directory da un’ipotesi su ciò che la raccolta ha coperto.

Mantenete una riga di revisione per ogni identificatore stabile di oggetto, con il nome distinto attuale come riferimento leggibile. Conservate separatamente l’appartenenza alle popolazioni: un oggetto restituito sia nella popolazione utenti sia in quella computer deve mantenere entrambe le etichette, contribuendo una sola volta al registro degli oggetti unici. Questo è rilevante per gli account di servizio gestiti di gruppo, che i filtri LDAP del collector possono includere in entrambe le popolazioni.

Usate raccolte distinte per gli oggetti nell’intervallo, quelli esterni, quelli con data non disponibile e le popolazioni o posizioni che non è stato possibile leggere. Una query fallita è un’osservazione fallita. Non può produrre un risultato vuoto attendibile. Analogamente, un oggetto escluso da un filtro sulla data non è stato classificato come approvato.

La revisione settimanale delle creazioni recenti nel flusso di audit AD ricorrente fornisce la cadenza operativa. Questo registro fornisce le prove sugli oggetti e sul provisioning per tale revisione. Conservate esplicitamente l’intervallo di revisione invece di trattare la finestra retrospettiva di dieci giorni di un prodotto come una politica organizzativa.

Rilevamento: leggere whenCreated con un ambito esplicito

Usate un host con il modulo PowerShell Active Directory e un account autorizzato a leggere la directory. Gli esempi seguenti sono query di revisione basate sulla documentazione, non comandi eseguiti sulla directory di un cliente. Sostituite il dominio e il DC di esempio prima dell’uso.

Get-ADObject documenta -Filter, le -Properties aggiuntive, -SearchBase, -SearchScope e -Server. Gli esempi impostano -SearchScope Subtree per includere la base di ricerca e i suoi discendenti. I filtri seguenti combinano questi parametri con le tre definizioni di popolazione del collector e un limite inferiore di 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

Le query con limite inferiore omettono le date precedenti e quelle non disponibili. Per un’osservazione separata dell’ambito, eseguite una lettura senza un predicato sulla data:

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

Questa lettura più ampia non equivale alle tre query per popolazione. Classificate i suoi oggetti prima del confronto. Per impostazione predefinita, il cmdlet esclude gli oggetti eliminati; nessuna delle letture ricostruisce una cronologia completa della directory.

Passaggio 1: conservare l’osservazione

Salvate le definizioni delle query e i loro esiti, riusciti o falliti, prima di interpretare le righe. Se una query si interrompe con un errore, registrate l’errore e l’ambito interessato e indagate sul fallimento della raccolta. Non sostituite il risultato con un array vuoto proseguendo come se la popolazione fosse stata esaminata.

Per le date restituite, conservate il valore originale e normalizzate la visualizzazione del registro in UTC. Valutate il limite inferiore in modo coerente: il collector usa un confronto stretto successivo alla propria ora di riferimento meno dieci giorni. Un timestamp esattamente su quel limite è escluso. Il suo codice non ha un limite superiore all’ora di riferimento; segnalate quindi separatamente qualsiasi data restituita successiva alla fine della revisione registrata, senza incorporarla silenziosamente nell’intervallo normale.

Passaggio 2: riconciliare gli oggetti unici

Combinate le osservazioni per GUID dell’oggetto, mantenete tutte le etichette delle popolazioni e confrontate il registro risultante con i conteggi per popolazione del collector. Spiegate le differenze attraverso ambito, limiti, gestione delle date e classi sovrapposte prima di considerarle creazioni inspiegate. Un conteggio deduplicato può legittimamente differire dalla somma delle osservazioni di utenti, computer e gruppi.

Mantenete gli account disabilitati nella revisione. Lo stato disabilitato non chiarisce perché un oggetto sia stato creato né se la sua richiesta di provisioning fosse approvata. Il rilevatore degli oggetti recenti stesso non esclude utenti o computer disabilitati.

Passaggio 3: collegare ogni riga al provisioning

Chiedete al responsabile identificato di fornire la richiesta e le prove di approvazione per lo specifico oggetto. Fate corrispondere identificatori, classe prevista, posizione e finalità, invece di accettare un ticket di distribuzione generico che potrebbe riferirsi a più oggetti non correlati. Registrate le discrepanze tra richiesta e oggetto osservato come elementi da seguire.

Una risposta del responsabile senza prove a supporto resta una dichiarazione da valutare. Viceversa, una risposta mancante indica una provenienza irrisolta, non una prova di attività di un attaccante. Tenete distinti questi esiti affinché la correzione affronti l’effettiva carenza di prove.

Rilevamento: correlare l’evento 5137 solo con copertura dimostrata

L’evento 5137 registra la creazione di oggetti di directory su un controller di dominio con l’audit delle operazioni riuscite abilitato in Audit Directory Service Changes. Microsoft specifica che la SACL dell’oggetto padre deve controllare l’azione Create pertinente per la classe dell’oggetto. Entrambi i controlli devono essere stati applicati prima della creazione; i record locali o centrali conservati devono coprire quel momento. Microsoft Learn: evento 5137.

Associate ObjectGUID, supportato da ObjectDN e ObjectClass, al registro. Conservate l’ora UTC dell’evento, il DC emittente e l’identificatore del record. SubjectUserSid, SubjectUserName e SubjectDomainName identificano l’account richiedente. SubjectLogonId può supportare la correlazione della sessione; non identifica la persona dietro l’automazione né dimostra l’approvazione.

La guida alla configurazione dei criteri di controllo spiega perché gli eventi devono prima essere generati. Per 5137, aggiungete le prove della SACL Create del padre e della conservazione; il contatore delle creazioni non dimostra nessuno di questi elementi.

Risolvere le creazioni non approvate e le carenze di prove (Remediation)

La correzione inizia dall’esito di ogni oggetto, non dalla riduzione di un conteggio di creazioni recenti. Il provisioning approvato deve restare documentato anche mentre l’oggetto rimane nella finestra retrospettiva. Una creazione irrisolta richiede un responsabile e un percorso di indagine.

1. Completare il registro di provisioning. Allegate l’identificatore dell’oggetto, la richiesta, l’approvazione e la risposta del responsabile alla riga di revisione. Confermate che finalità e posizione osservate concordino con la richiesta approvata. Registrate ogni eccezione giustificata e la persona responsabile della sua risoluzione.
2. Segnalare le creazioni inspiegate o incoerenti. Conservate le osservazioni della directory e i record degli eventi disponibili. Chiedete ai responsabili delle identità e dei servizi di valutare l’uso previsto dell’oggetto e la sua esposizione attuale. Gestite gli oggetti confermati come non autorizzati attraverso i processi organizzativi di incidente e cambiamento, con una decisione esplicita di contenimento.
3. Correggere le lacune nella raccolta. Esaminate le basi di ricerca, i limiti configurati delle popolazioni e gli errori delle query. Ripetete le letture nell’ambito dopo aver risolto la causa e conservate la nuova ora di osservazione. Mantenete nel registro le precedenti osservazioni fallite, affinché il record finale non suggerisca una copertura ininterrotta.
4. Correggere la copertura futura degli eventi. Fate verificare ad amministratori autorizzati l’audit effettivo delle operazioni riuscite di Directory Service Changes e le SACL Create pertinenti dei padri. Verificate che gli archivi conservati siano realmente consultabili. Convalidate la generazione e la raccolta future attraverso una creazione di test approvata, poi conservate le prove risultanti.
5. Verificare la chiusura rispetto al registro. Riconciliate il registro aggiornato degli oggetti unici con il provisioning approvato e le eccezioni documentate. Chiudete solo le decisioni supportate da prove; mantenete aperti gli elementi con provenienza sconosciuta e ambito incompleto.

Evitate eliminazioni o disabilitazioni automatiche basate soltanto sull’età, un nome sconosciuto o un evento di creazione mancante. Questi segnali giustificano un’indagine, mentre la decisione di correzione richiede prove sull’oggetto e sulle sue dipendenze. Gli esempi di questo articolo leggono la directory; non autorizzano una modifica della directory.

Come EtcSec rileva questo segnale

Al commit del collector 9f698083354a1cb7f625df5cb490a515823c3257, RECENT_OBJECTS_CREATED è un rilievo Info. Il suo metodo Detect() somma le voci di utenti, computer e gruppi il cui valore Created è diverso da zero e strettamente successivo a DetectorData.Now - 10 × 24 hours. Dieci giorni è un’euristica del prodotto. Il confronto non ha un limite superiore a Now e il rilevatore non esclude gli account disabilitati.

Il rilievo fornisce un totale e i contatori aggregati newUsers, newComputers e newGroups. Non fornisce una lista AffectedEntities per oggetto e non determina richiedente, intento o autorizzazione. I parser LDAP ottengono Created da whenCreated; i valori assenti o i formati non compresi da parseADTime diventano zero e sono esclusi dal calcolo.

La raccolta dipende da BaseDN, MaxUsers, MaxGroups e MaxComputers. Un errore nel recupero di una qualsiasi delle tre popolazioni interrompe la raccolta. Le popolazioni possono sovrapporsi: il filtro utenti include i gMSA e il filtro computer può restituire gli stessi oggetti. Di conseguenza, il conteggio sommato non è un inventario unico di tutti gli oggetti AD.

Usate questo rilievo per avviare il registro indipendente e la revisione del provisioning descritti sopra. Un conteggio inferiore in un audit successivo può semplicemente riflettere oggetti invecchiati oltre la finestra retrospettiva, un ambito cambiato o una differenza nella raccolta. Verificate direttamente le decisioni della revisione e le prove prima di chiudere il lavoro.