Triage AD badPwdCount: qualificare i contatori prima di un verdetto di attacco

Cosa può stabilire il triage AD badPwdCount

Il triage AD badPwdCount parte da una domanda sulle evidenze: quale controller di dominio ha fornito il contatore di questo account, in quale momento e la raccolta è effettivamente riuscita? Un'istantanea della directory può identificare gli account da approfondire. Da sola, non può dimostrare un attacco a dizionario, identificare l'origine degli errori o indicare che una password è debole.

Il risultato pratico è un fascicolo di analisi che collega lo stato della directory all'attività di autenticazione. Conservare il rilievo originale, raccogliere viste confrontabili dai controller di dominio pertinenti, verificare lo stato di blocco calcolato e analizzare i log del percorso di autenticazione coinvolto. Quindi documentare se le evidenze sostengono un errore dell'utente, un'applicazione che riprova con un segreto obsoleto, un'attività sospetta o un caso irrisolto.

Questa guida usa letture difensive della directory e un esempio documentato di sblocco mirato. I comandi sono adattamenti illustrativi per un amministratore autorizzato con il modulo PowerShell ActiveDirectory e le autorizzazioni appropriate. Non sono stati eseguiti su un dominio. Non è stato effettuato alcun test di password spraying o di blocco deliberato.

Cosa misura realmente il contatore LDAP

Il riferimento Microsoft sugli attributi di sicurezza dell'utente descrive badPwdCount come un attributo non replicato, mantenuto separatamente su ciascun controller di dominio. Conta i tentativi di accesso con password errata nella vista di quel controller; il riferimento indica inoltre che zero può significare un valore sconosciuto. Raccomanda di interrogare ogni DC per ottenere una vista dell'intero dominio, anziché trattare una singola lettura come il totale del dominio.

Il riferimento dello schema Bad-Pwd-Count aggiunge che l'attributo viene azzerato su un determinato DC quando l'utente accede correttamente a quel DC. Un contatore non è quindi una cronologia permanente. Un valore inferiore in un'istantanea successiva non dimostra che tutti gli errori precedenti siano stati analizzati.

Per il triage, conservare le osservazioni separate dei DC prima di creare un riepilogo. Un numero senza il server e l'ora di raccolta perde il contesto necessario per confrontarlo con un'altra osservazione. Un riepilogo dei contatori non identifica neppure tentativi distinti in un intervallo scelto; usare gli eventi per costruire quella sequenza temporale.

Il blocco è una questione separata. Microsoft documenta UF_LOCKOUT, valore 0x0010, in msDS-User-Account-Control-Computed. Richiedere esplicitamente questo attributo calcolato quando si esamina lo stato attuale di AD DS. Non presumere che un booleano del collector chiamato LockedOut provenga necessariamente da esso.

Rilevamento: raccogliere viste confrontabili da ciascun DC

Identificare l'account e l'ambito della raccolta

Partire dall'identificativo dell'account del rilievo e dall'endpoint originale del collector. Registrare il dominio, il DN o GUID dell'account, la versione del collector, l'ora di raccolta, gli attributi richiesti e gli eventuali errori di raccolta. Confermare l'elenco dei DC rispetto all'inventario del dominio; l'esempio seguente con due server non indica di omettere gli altri DC.

La documentazione di Get-ADUser permette di selezionare un utente tramite DN, richiedere proprietà aggiuntive e specificare un server di directory. Queste letture adattate usano un nome host di DC esplicito invece di affidarsi alla selezione automatica del server:

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc02.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Sostituire il DN e i nomi host illustrativi con valori verificati. Richiedere lockoutTime conserva un altro attributo grezzo per l'analisi; non usare un valore diverso da zero da solo come verdetto sul blocco attuale. Interpretare il bit di blocco calcolato solo quando il suo valore è stato restituito correttamente. Un valore mancante è sconosciuto, non falso.

Per un inventario più ampio e autorizzato, Get-ADUser accetta anche un filtro LDAP. Questo esempio recupera gli oggetti utente abilitati e gli attributi pertinenti da un server selezionato esplicitamente. Non limita deliberatamente la popolazione agli account già sopra la soglia del prodotto:

Get-ADUser -LDAPFilter '(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Ripetere la lettura sugli altri DC verificati nell'ambito approvato. Evitare di costruire un filtro LDAP concatenando un nome di account senza escape. Per un singolo caso, le letture basate sull'identità evitano completamente questa interpolazione.

Conservare la qualità della raccolta insieme ai valori

Usare un registro con una riga per account e DC. I campi seguenti sono una raccomandazione operativa, non dati forniti automaticamente dal rilevatore:

Se un DC non è disponibile, segnalare la lacuna e conservare le letture riuscite. Non sostituire la riga mancante con zero e non ridurre silenziosamente l'ambito dichiarato. Se le osservazioni differiscono, conservarle entrambe e analizzarne tempi e provenienza prima di scegliere un riepilogo. L'obiettivo è un confronto verificabile, non rendere identiche tutte le celle.

Rilevamento: associare gli eventi al percorso di autenticazione

L'istantanea LDAP seleziona un obiettivo d'indagine; la sequenza temporale degli eventi fornisce il contesto dell'attività. Verificare la copertura di audit, l'inoltro, la conservazione e i sistemi esaminati prima di interpretare un risultato vuoto. Scegliere l'intervallo di analisi dalla cronologia del caso e dalle evidenze disponibili. Il contatore stesso non fornisce quell'intervallo.

Microsoft associa questi eventi rispettivamente ad Audit Logon/Account Lockout, Audit Kerberos Authentication Service e Audit Credential Validation. Una ricerca limitata ai DC non copre tutte le ubicazioni di 4625. L'evento 4771 è assente per gli account configurati senza obbligo di preautenticazione Kerberos. L'evento 4776 copre sia le convalide riuscite sia quelle fallite e identifica la workstation di origine, anziché il server di destinazione o un indirizzo IP.

Leggere la nomenclatura dei codici appropriata a ciascun evento. Per 4625, conservare entrambi i campi di stato invece di ridurli a un'etichetta generica di errore. In 4771, 0x18 significa informazioni di preautenticazione non valide, con una password errata come causa documentata. In 4776, 0xC000006A indica una password errata o digitata male, 0xC0000064 un nome utente sconosciuto e 0xC0000234 un account bloccato. Un errore causato dal blocco è un'evidenza diversa dall'attività con password errate che lo ha preceduto.

Costruire una sequenza temporale raggruppata per account, origine, percorso di autenticazione e sistema emittente. Conservare riferimenti ai record originali affinché un altro analista possa esaminare la conclusione. Non sommare tutte le righe di tipi di evento diversi per dichiarare un numero di tentativi indipendenti: determinare prima quali record descrivono lo stesso flusso di autenticazione.

Estendere l'analisi oltre l'account selezionato quando le origini o i tempi lo giustificano. Il contesto di correlazione tra più account e a bassa frequenza nella nostra guida al password spraying spiega questa indagine più ampia. Qui, il primo compito resta qualificare l'osservazione della directory che ha aperto il caso.

Correzione: risolvere la causa prima di chiudere il rilievo (Remediation)

Preservare le evidenze e verificare le spiegazioni alternative

Conservare i valori LDAP iniziali e gli eventi pertinenti prima di modificare le credenziali o lo stato dell'account. Identificare il proprietario dell'account e le applicazioni che lo usano. Chiedere informazioni su cambi recenti di password, modifiche alla configurazione dei servizi, attività pianificate, accesso remoto ed esperienza riferita dall'utente. Usare queste risposte per selezionare i sistemi da ispezionare, non come sostituto dei loro log.

La matrice decisionale seguente è un metodo di triage proposto. Nessuna di queste spiegazioni viene calcolata dal solo badPwdCount:

Per un carico di lavoro che usa una credenziale obsoleta, coordinare la modifica della credenziale con tutti i componenti utilizzatori noti. Aggiornare una sola attività pianificata lasciando irrisolto un altro client che riprova non è una correzione completa. Verificare la configurazione del carico di lavoro e i successivi record di autenticazione prima di attribuirgli definitivamente gli errori.

Trattare i nomi insoliti come un segnale diverso. La nostra analisi dei nomi degli account distingue un indicatore statico di denominazione dall'attività di accesso. Un nome di account generico non dimostra quale password sia stata tentata, chi l'abbia inviata o se questo caso sia malevolo.

Sbloccare soltanto l'account esaminato quando appropriato

Se lo stato calcolato conferma il blocco e l'amministratore responsabile ha approvato il ripristino dell'accesso dopo aver esaminato la causa, usare un'operazione mirata. Questo esempio adatta i parametri di identità e server documentati per Unlock-ADAccount:

Unlock-ADAccount -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Questo è un esempio che modifica lo stato, non un comando eseguito per questo articolo. Confermare l'identità e il server prima dell'uso. Non inviare l'intero inventario tramite pipeline a uno sblocco massivo. Uno sblocco non corregge un segreto applicativo obsoleto e non risolve un'attività sospetta; usare le evidenze per scegliere la risposta appropriata.

Quando l'indagine stabilisce una compromissione o una minaccia persistente, seguire la procedura di risposta agli incidenti dell'organizzazione per contenimento, modifiche alle credenziali e sistemi interessati. Un contatore di directory non basta per selezionare automaticamente tali azioni. Allo stesso modo, non allentare i controlli di blocco solo per ridurre i rilievi senza esaminarne le conseguenze sulla sicurezza e sulla disponibilità.

Verificare la correzione e documentare la conclusione

Ripetere le stesse letture della directory con la stessa identità di account e gli stessi DC espliciti dopo la modifica approvata. Conservare nuovamente i timestamp e la qualità della raccolta. Esaminare i log pertinenti durante un periodo di osservazione dichiarato e chiedere al proprietario di confermare che l'applicazione o il flusso di lavoro dell'utente interessato funziona come previsto.

Chiudere il caso con un'affermazione supportata: un'applicazione identificata che riprovava è stata corretta; un problema di accesso dell'utente è stato risolto; un'attività è stata segnalata come sospetta; oppure la copertura resta incompleta. Registrare i riferimenti agli eventi a supporto, le spiegazioni escluse, le evidenze mancanti, le azioni, il responsabile e la data di follow-up. Il rientro sotto la soglia del prodotto è un contesto utile, ma la chiusura deve spiegare la causa e le evidenze alla base della decisione.

Come EtcSec rileva questo caso

Il controllo di etc-collector è PASSWORD_DICT_ATTACK_RISK, categoria Password, gravità Medium. Il Detect() esaminato si trova in public/internal/audit/detectors/ad/password/dict-attack-risk.go:24. Esclude gli utenti con Disabled=true e seleziona ogni utente rimanente quando BadPasswordCount > 3 oppure LockedOut=true.

Count è il numero di utenti selezionati, non la somma dei tentativi falliti, il numero di sistemi di origine o il numero di attacchi. Ogni utente contribuisce una sola volta anche quando entrambe le condizioni corrispondono. L'implementazione restituisce il rilievo anche a zero; le entità interessate sono incluse quando vengono richiesti i dettagli e viene selezionato almeno un utente.

Il provider determina ciò che il controllo può effettivamente vedere:

• parser.go:164 legge badPwdCount tramite getIntAttr; questa funzione ausiliaria, alla riga 290, restituisce zero per un valore assente e ignora gli errori di strconv.Atoi.
• client.go:460 recupera gli utenti dal contesto LDAP scelto. Questo percorso non aggrega le osservazioni di tutti i DC.
• parser.go:189 ricava LockedOut dal bit 0x0010 di userAccountControl. L'elenco predefinito degli attributi utente non richiede msDS-User-Account-Control-Computed. Sebbene lockoutTime venga raccolto, non viene usato per calcolare questo booleano.

Questo ramo relativo al blocco non deve quindi essere presentato come una valutazione calcolata affidabile del blocco attuale per AD DS moderno. Richiedere indipendentemente l'attributo calcolato durante il triage del rilievo. Conservare una discrepanza tra il booleano del collector e tale lettura invece di considerare autorevole l'etichetta del collector.

Il controllo non ha una finestra temporale, un'origine di autenticazione, una correlazione di eventi, una valutazione della policy effettiva di blocco o una misura della qualità della password. La soglia è un predicato del prodotto, non un valore di policy AD DS. Tre o meno errori registrati non dimostrano sicurezza e un conteggio positivo non dimostra un attacco.

Esiste un motivo concreto per analizzare i contatori senza presumerne la causa. Il repository pubblico SafeSpray e il suo codice sorgente main.go usano un filtro LDAP contenente badPwdCount=0 per selezionare gli utenti prima dei tentativi di autenticazione SMB. Questo mostra come uno strumento pubblico usa i contatori, non dimostra che sia stato eseguito nel proprio ambiente o che la sua dichiarazione di evitare i blocchi sia affidabile. Il codice è stato letto; lo strumento non è stato eseguito.