Verifica computer AD whenChanged: provenienza della disabilitazione

Che cos'è una verifica whenChanged di un computer AD disabilitato?

Una verifica whenChanged di un computer AD disabilitato parte da un account computer attualmente disabilitato e da un vecchio timestamp di modifica della directory. Chiede se l'account debba rimanere in Active Directory, chi sia responsabile di questa decisione e quali evidenze ne giustifichino il ritiro. Il timestamp aiuta a dare priorità all'indagine; non stabilisce quando l'account è stato disabilitato.

Questa distinzione conta quando un elenco di pulizia diventa una coda di eliminazione. Un account disabilitato può appartenere a una workstation ritirata, una macchina temporaneamente isolata, un'identità di servizio o un'infrastruttura in attesa di una procedura di dismissione separata. Un rilievo di audit non fornisce nessuna di queste decisioni aziendali. Mantieni separate le evidenze dello stato attuale dell'account, della provenienza della disabilitazione e dell'approvazione del ritiro.

La verifica descritta qui segue il rilievo COMPUTER_DISABLED_NOT_DELETED di etc-collector. Non introduce una pianificazione universale dell'eliminazione e non deduce un attacco da un vecchio timestamp. Il risultato è una decisione documentata per un oggetto identificato: conservarlo con una motivazione di cui un responsabile risponda, indagare sulle evidenze mancanti o ritirarlo attraverso una procedura approvata dopo aver risolto le sue dipendenze.

Funzionamento: l'ultima modifica non dimostra la provenienza della disabilitazione

Il riferimento Microsoft dell'attributo whenChanged definisce il valore come la data dell'ultima modifica dell'oggetto. Il sistema lo aggiorna ogni volta che l'oggetto cambia. Il valore non viene replicato: registra quindi quale controller di dominio ha fornito l'osservazione e quando lo hai letto.

Impostare lo stato disabilitato modifica l'oggetto, ma il valore attuale di whenChanged non identifica tale operazione. Una modifica successiva può sostituire il timestamp precedente anche se l'account rimane disabilitato. Leggere un valore recente non dimostra quindi una disabilitazione recente; leggere un valore vecchio non ne fornisce l'autore, il motivo o l'approvazione. Tratta l'attributo come un'osservazione di modifica proveniente dal DC scelto, anziché come un campo dedicato alla data di disabilitazione.

Mantieni queste distinzioni nel registro della verifica:

La nostra guida all'igiene degli oggetti computer Active Directory fornisce il contesto più ampio del ciclo di vita, inclusi controller di dominio, LAPS e oggetti computer obsoleti. Le sue cadenze illustrative di pulizia non dimostrano una data di disabilitazione e non vengono adottate come soglie per questa verifica. Un'osservazione dell'ultimo accesso o della password della macchina risponderebbe a un'altra domanda; nessuna viene usata qui al posto delle evidenze di disabilitazione dell'account.

Rilevamento: accertare lo stato attuale e indagare sulla transizione

Passaggio 1: leggere l'oggetto esatto da un DC specificato

Usa il modulo ActiveDirectory su una workstation di amministrazione autorizzata. Il riferimento Microsoft di Get-ADComputer documenta -Identity, -Properties e -Server. Richiedi esplicitamente gli attributi LDAP e specifica un server di directory anziché affidarti a una selezione implicita:

$computer = Get-ADComputer -Identity 'PC01' -Server 'dc01.contoso.com' -Properties whenChanged,userAccountControl,objectClass -ErrorAction Stop
$computer | Select-Object DistinguishedName,ObjectGUID,SID,Enabled,whenChanged,userAccountControl,objectClass

La proiezione usa la sintassi documentata di Select-Object di Microsoft. Conserva l'identità del computer, il DC scelto, l'ora di lettura e l'esito della raccolta insieme ai campi visualizzati. Una query fallita costituisce un'evidenza incompleta. Un attributo non disponibile non è un risultato negativo affidabile solo perché il processo di raccolta ha restituito un oggetto.

Il parser LDAP esaminato ricava Disabled dal bit ACCOUNTDISABLE, 0x0002, di userAccountControl nella directory. La proprietà Enabled visualizzata e l'attributo grezzo forniscono osservazioni dello stato attuale da riconciliare. Non registrano da quanto tempo l'account è disabilitato. Se la lettura attuale è in conflitto con l'audit, indaga sull'ora di raccolta, sull'identità di destinazione e sulle osservazioni dei DC prima di agire sul rilievo precedente.

Passaggio 2: usare l'evento 4742 solo dove le sue evidenze sono applicabili

Microsoft documenta l'evento 4742, modifica di un account computer, nella sottocategoria Audit Computer Account Management. Viene generato sui controller di dominio. Esamina i registri Security dei DC pertinenti o le loro copie raccolte, con una configurazione di audit e una conservazione sufficienti a coprire la transizione sospettata.

In un SIEM, limita l'indagine all'evento 4742 e al TargetSid dell'account modificato. Esamina l'evento grezzo, non soltanto un riepilogo normalizzato. Conserva l'ora dell'evento, il DC emittente, l'identificatore del record, l'identità di destinazione, l'identità del soggetto, OldUacValue, NewUacValue e le informazioni modificate di controllo dell'account. Confronta qualsiasi presunta transizione di disabilitazione con il registro approvato della modifica o dell'incidente e con la lettura attuale della directory. La sola corrispondenza del nome account fornisce un contesto meno solido del SID di destinazione verificato.

La documentazione dell'evento afferma esplicitamente che alcune modifiche non generano 4742. Altri eventi possono contenere trattini per tutti gli attributi modificati visualizzati, lasciando non identificato l'attributo cambiato. Una voce 4742 per l'oggetto non è quindi automaticamente una prova della sua disabilitazione. Potrebbe documentare un'altra modifica dell'account, e una ricerca nei registri potrebbe non coprire il DC o il periodo pertinenti.

I campi UAC precedente e nuovo di 4742 usano l'implementazione SAM dei flag dell'account, le cui definizioni differiscono da quelle di userAccountControl LDAP. Non applicare la maschera LDAP 0x0002 a questi campi dell'evento per affermare una transizione di disabilitazione. Interpreta la transizione registrata usando le definizioni dei flag dell'account documentate per l'evento e conserva i valori grezzi per la verifica.

Passaggio 3: correlare le evidenze con la responsabilità

Chiedi al responsabile se la macchina sia ancora necessaria, temporaneamente isolata, sostituita o formalmente dismessa. Collega la risposta all'identità esatta della directory. Conserva separatamente il motivo della disabilitazione, le evidenze disponibili della transizione e la decisione di ritiro. Quando mancano evidenze storiche, descrivi direttamente questa lacuna anziché costruire una data a partire dall'ultima modifica dell'oggetto.

Una modifica inspiegata che coinvolge un'identità critica richiede un'indagine prima della pulizia del ciclo di vita. Viceversa, una decisione di conservazione approvata può essere legittima anche se il rilevatore continua a segnalare l'oggetto. Registra chi riesaminerà quella decisione e quale condizione giustificherebbe il ritiro. Eliminare il rilievo non è di per sé un requisito aziendale per eliminare l'account.

Correzione: verificare le dipendenze prima della rimozione approvata (Remediation)

Passaggio 1: classificare l'oggetto e risolvere le incognite

Conferma la classe dell'oggetto e il suo ruolo operativo prima di scegliere una procedura di ritiro. Il rilevatore non esclude esplicitamente controller di dominio o account di servizio gestiti di gruppo. Un controller di dominio richiede la propria procedura appropriata di dismissione; un'identità di servizio richiede la verifica delle sue dipendenze di servizio. Un esempio generico di rimozione di una workstation non autorizza ad applicare la stessa azione a ogni oggetto restituito dal raccoglitore.

Riconcilia lo stato attuale dell'account, la risposta del responsabile e i registri di dismissione. Mantieni in sospeso i casi irrisolti con una prossima azione assegnata a un responsabile. Questo processo non stabilisce un nuovo periodo generico di invecchiamento: il tempo trascorso non può dimostrare che le esigenze di servizi, registri o ripristino siano terminate.

Passaggio 2: inventariare gli oggetti figlio e le dipendenze di ripristino

Leggi i figli immediati dell'oggetto computer verificato usando i parametri di ricerca documentati di Get-ADObject di Microsoft. Questo esempio usa il $computer restituito sopra e richiede identificatori e classi degli oggetti, anziché segreti di ripristino:

Get-ADObject -LDAPFilter '(objectClass=*)' -SearchBase $computer.DistinguishedName -SearchScope OneLevel -Server 'dc01.contoso.com' -ErrorAction Stop |
    Select-Object DistinguishedName,ObjectGUID,ObjectClass

OneLevel cerca solo i figli immediati. Se un figlio ha propri discendenti o l'inventario è incompleto, indaga sulla struttura e sul suo scopo prima di procedere. Un risultato vuoto con visibilità non verificata non dimostra che non esistano oggetti dipendenti. Registra gli errori di accesso e l'incertezza sull'ambito come voci di inventario irrisolte.

Includi le informazioni di ripristino BitLocker nella verifica delle dipendenze. La nostra guida alla verifica del ripristino BitLocker in AD: associare il record della directory al protettore attuale del volume spiega perché un oggetto di ripristino deve corrispondere al protettore di ripristino effettivamente presente sul volume. La sua sola presenza non dimostra che il ripristino sia utilizzabile, e la sua data non stabilisce quando l'account computer è stato disabilitato.

Concorda come le informazioni di ripristino necessarie e gli altri dati degli oggetti figlio rimarranno disponibili secondo il processo approvato di ripristino e conservazione dell'organizzazione prima della rimozione del computer. Mantieni i segreti fuori dai ticket di pulizia e dai registri SIEM. Registra la decisione sulle dipendenze e il responsabile, anziché copiare le password di ripristino nelle evidenze. Questa è una verifica delle dipendenze del ritiro; la guida collegata fornisce la procedura separata di verifica del volume e del protettore.

Passaggio 3: visualizzare l'anteprima ed eseguire solo la rimozione approvata di un singolo oggetto

Dopo aver completato le verifiche di responsabilità, dismissione, dipendenze e ripristino, usa la sintassi Microsoft di Remove-ADComputer per l'oggetto verificato. La documentazione supporta l'identità GUID, un server esplicito e -WhatIf. L'anteprima seguente non esegue la rimozione:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -WhatIf

Confronta la destinazione e l'anteprima con il registro di ritiro approvato. Un'anteprima non verifica che la macchina sia inutilizzata, che i dati di ripristino siano conservati o che l'azione sia stata approvata. Rileggi l'oggetto attuale prima dell'operazione autorizzata se le evidenze possono essere cambiate.

Solo dopo tale validazione, il comando sul singolo oggetto mantiene una richiesta esplicita di conferma:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -Confirm

Se figli, protezione o un altro errore impediscono la rimozione, fermati e risolvi la causa specifica attraverso la procedura approvata. Non trasformare un errore in un'eliminazione ricorsiva del computer e dei suoi discendenti. Conserva l'esito effettivo del comando; un'operazione tentata non dimostra che l'account sia stato rimosso.

Passaggio 4: chiudere la verifica con evidenze

Registra la decisione finale, l'approvatore, le decisioni sulle dipendenze e l'esito dell'operazione. Verifica il risultato nella directory attraverso una lettura autorizzata dell'identità esatta sul DC registrato, conservando qualsiasi errore e il suo significato. Conferma che le informazioni di ripristino necessarie rimangano disponibili attraverso il processo concordato. Per un oggetto conservato, documenta il motivo della conservazione e l'indagine restante anziché dichiarare completata la correzione.

Come EtcSec rileva questo caso

Al commit esaminato del raccoglitore 20268a321609c193b79c5da6764f3f56950449cb, COMPUTER_DISABLED_NOT_DELETED è un rilievo di gravità Low. Il suo Detect() esamina i computer raccolti e include un oggetto solo quando Disabled è true, WhenChanged è diverso da zero e WhenChanged.Before(Now.AddDate(0, 0, -30)) è true. Il confronto è stretto: un timestamp uguale alla soglia è escluso.

La soglia sottrae 30 giorni di calendario al Now dell'audit. È un riferimento di igiene operativa di etc-collector, non una scadenza di eliminazione richiesta da Microsoft o da un altro standard identificato. Una modifica successiva dell'oggetto sposta in avanti whenChanged e può rinviare questo segnale mentre l'account rimane disabilitato.

Nel provider LDAP esaminato, un whenChanged mancante o non valido diventa un tempo zero, che questo rilevatore salta. Un userAccountControl mancante o sintatticamente non valido diventa zero, quindi il parser non contrassegna quell'oggetto come disabilitato. Il filtro computer predefinito è (objectClass=computer). Sebbene il parser possa identificare una classe gMSA, questo Detect() non esclude esplicitamente controller di dominio o gMSA.

Il rilevatore non stabilisce la data di disabilitazione, il responsabile, l'approvazione della dismissione, gli oggetti figlio, le dipendenze di ripristino o una cronologia degli eventi a supporto. Un rilievo positivo avvia la verifica delle evidenze descritta sopra. Un conteggio pari a zero non può chiudere queste domande indipendenti, soprattutto quando la raccolta o la disponibilità degli attributi sono incerte.