Schemi di nomi account Active Directory

Che cosa indicano realmente i nomi account comuni

L’espressione schemi di nomi account active directory descrive un’euristica di denominazione, non un test delle password. Un account abilitato chiamato admin, test o temp merita una verifica del proprietario e dell’esposizione. Il nome non rivela la password, non dimostra che sia debole e non stabilisce che qualcuno abbia attaccato l’account. Questa distinzione deriva direttamente dall’implementazione di PASSWORD_COMMON_PATTERNS in public/internal/audit/detectors/ad/password/common-patterns.go:26.

Un nome generico può rendere più facile includere un’identità in un elenco ipotizzato di bersagli. È un’inferenza sulla selezione dei candidati, non una classifica misurata delle prime scelte degli attaccanti. La precedente documentazione Microsoft sulla rinomina di Administrator descrive un beneficio modesto nel cambiare questo nome noto, insieme al limite del suo SID noto. Non convalida una classifica universale di admin, test e temp né i quindici schemi del collector.

La domanda utile è quindi: che cosa fa questa identità, chi ne è responsabile e quali controlli proteggono i suoi effettivi percorsi di autenticazione? Trattate il risultato come una coda di revisione. Un nome di servizio descrittivo può supportare operazioni legittime; un nome dall’aspetto personale può comunque nascondere una gestione scadente delle credenziali. Il rilevatore non distingue questi casi perché esamina i nomi invece dei segreti o dell’attività.

Come funziona il password spraying

La guida Microsoft alla classificazione del password spraying descrive un piccolo insieme di password comuni provato su molti account. Questo differisce dai tentativi ripetuti con numerose password contro una sola identità. La denominazione degli account riguarda l’elenco dei bersagli; il password spraying riguarda i tentativi di autenticazione. Un inventario di nomi corrispondenti dimostra il primo elemento, non il secondo.

Il manuale operativo di indagine sul password spraying distingue inoltre la compromissione della password dalla compromissione dell’account. Un attaccante può scoprire una password corretta mentre la MFA impedisce l’accesso. Chi indaga deve esaminare le autenticazioni riuscite e interrotte, gli esiti della MFA e l’attività successiva, anziché interpretare ogni accesso finale fallito come prova che la password sia rimasta sconosciuta.

La catena d’attacco da indagare

Un’indagine difendibile segue la progressione documentata in quei manuali Microsoft: identificare account candidati e percorsi di autenticazione, correlare tentativi sospetti, determinare se una password sia stata accettata ed esaminare gli accessi risultanti. I nomi generici possono orientare il primo passaggio. Non forniscono prove per i successivi. Un’attività lenta e poco intensa può restare sotto le soglie di blocco, quindi l’assenza di un blocco non permette di escluderla automaticamente.

Per il meccanismo generale, l’enumerazione dei nomi utente, il rilevamento e i controlli nei due ambienti, consultate la nostra guida al password spraying in Active Directory ed Entra ID. Questo articolo si concentra sull’esatto predicato di denominazione, sulle ipotesi errate e sulle prove necessarie per risolvere un risultato relativo ai nomi.

Nessun elenco di nomi è un elenco completo dei bersagli di spraying. Esaminate identità esterne a questi schemi quando la telemetria di autenticazione lo giustifica. Viceversa, non etichettate ogni account corrispondente come violato: il processo di classificazione Microsoft richiede esplicitamente di separare l’attività dannosa dai falsi positivi.

Misurare gli account e i loro criteri effettivi

1. Creare un inventario senza raccogliere segreti

I comandi seguenti sono esempi documentati o adattamenti di parametri per un amministratore autorizzato. Non sono stati eseguiti contro un dominio per questo articolo. Usate il modulo ActiveDirectory, le autorizzazioni di directory appropriate e il contesto di dominio o server previsto. contoso.com e i nomi account sono illustrativi; verificate il bersaglio prima di usare un comando di modifica.

Get-ADUser documenta i filtri, il recupero degli account abilitati e la richiesta di proprietà aggiuntive. Questo filtro difensivo adatta tali capacità ai tredici nomi completi, a una sottostringa e a un suffisso del collector. L’elenco proviene dal rilevatore, non da un esempio Microsoft che consideri questi nomi una prova di password deboli.

Get-ADUser -Filter 'Enabled -eq $true -and (SamAccountName -eq "admin" -or SamAccountName -eq "administrator" -or SamAccountName -eq "test" -or SamAccountName -eq "user" -or SamAccountName -eq "guest" -or SamAccountName -eq "temp" -or SamAccountName -eq "default" -or SamAccountName -eq "support" -or SamAccountName -eq "service" -or SamAccountName -eq "backup" -or SamAccountName -eq "demo" -or SamAccountName -eq "sa" -or SamAccountName -eq "dba" -or SamAccountName -like "*password*" -or SamAccountName -like "*123")' -Properties DisplayName,Enabled

DisplayName supporta qui la revisione umana. Non partecipa al rilevatore. Un account il cui nome visualizzato è Test ma il cui sAMAccountName è alex.smith non viene selezionato dallo schema test. Viceversa, User123 corrisponde al suffisso anche se non corrisponde all’espressione di nome completo user. Questi esempi seguono le regole di corrispondenza del codice.

Registrate proprietario, finalità dell’account, dipendenze e decisione di revisione insieme all’inventario. Prima di confrontare un conteggio locale con un risultato del collector, riconciliate ambito della directory, momento della raccolta, stato abilitato e comportamento di corrispondenza. Non presumete che il breve elenco di nomi in un risultato sia la popolazione completa.

2. Leggere i criteri del dominio

Questo comando adatta l’esempio 3 di Get-ADDefaultDomainPasswordPolicy a un dominio illustrativo:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com

Esaminate MinPasswordLength, ComplexityEnabled, PasswordHistoryCount, LockoutThreshold, LockoutDuration e LockoutObservationWindow. Sono prove dei criteri. Il nome account non fornisce alcun valore per queste impostazioni. La lettura dei criteri di dominio non stabilisce neppure se un utente selezionato abbia un Password Settings Object risultante diverso.

3. Inventariare i criteri granulari

Usate il filtro documentato da Get-ADFineGrainedPasswordPolicy per recuperare gli oggetti dei criteri:

Get-ADFineGrainedPasswordPolicy -Filter *

Controllate AppliesTo e Precedence oltre alle impostazioni effettive. La guida Microsoft ai criteri password granulari indica che questi criteri si applicano a oggetti utente e gruppi di sicurezza globali. Non si applicano direttamente a una OU. Collocare un account generico in una OU amministrativa non stabilisce quindi, da solo, criteri password effettivi più forti.

4. Controllare i criteri risultanti dell’utente selezionato

Questo comando adatta l’esempio di identità in Get-ADUserResultantPasswordPolicy:

Get-ADUserResultantPasswordPolicy -Identity test

Il cmdlet recupera il PSO risultante dell’utente. Un PSO assegnato direttamente all’utente ha priorità sui PSO ereditati tramite gruppi di sicurezza globali. Se più PSO si applicano direttamente, tra questi prevale quello con il valore di precedenza più basso; i PSO collegati ai gruppi vengono confrontati solo quando nessuno si applica direttamente. Se non si applica alcun PSO, valutate i criteri predefiniti del dominio. Un risultato PSO vuoto non è una misura della robustezza della password.

La nostra guida alla sicurezza delle password di Active Directory esamina altre sei dimensioni: flag di scadenza, debolezza dei criteri, flag di password non richiesta, segreti esposti nelle descrizioni, WDigest e NTLMv1, insieme a FGPP e gestione degli account di servizio. Sono aspetti distinti da questo predicato di denominazione. Non sostituite la revisione di tali controlli con la scomparsa di un risultato sui nomi e non copiate valori dimostrativi dei criteri come riferimento di sicurezza.

Rilevamento: correlare 4625, 4740 e 4771

Raccogliere i sistemi e i campi corretti

Costruite le prove intorno al percorso di autenticazione. L’evento 4625 viene registrato sul computer in cui avviene l’accesso fallito; può trattarsi di un controller di dominio, un server membro o una workstation. Raccogliere solo un DC non garantisce la copertura di tutti gli accessi falliti. Verificate la copertura di Audit Logon e Audit Account Lockout secondo le sottocategorie documentate dell’evento.

Per gli account di dominio, includete i log Security dei DC per l’evento 4740, in Audit User Account Management, e l’evento 4771, in Audit Kerberos Authentication Service. Microsoft documenta 4771 come esclusivo dei DC e assente quando l’account non richiede la preautenticazione Kerberos.

Interpretare con precisione i codici di errore

La documentazione di monitoraggio di 4625 identifica 0xC000006A come password errata o digitata male, 0xC0000064 come nome account errato o scritto male e 0xC000006D come nome utente o informazioni di autenticazione non corretti. La documentazione dell’evento identifica 0xC0000234 come account bloccato. Conservate Status e SubStatus; non riducete l’indagine a una sola etichetta generica di errore.

Per 4771, 0x18 è KDC_ERR_PREAUTH_FAILED: informazioni di preautenticazione non valide, con una password errata documentata come causa. 0x6 è KDC_ERR_C_PRINCIPAL_UNKNOWN, cioè il client non è stato trovato nel database Kerberos. 0x12 è KDC_ERR_CLIENT_REVOKED, cioè le credenziali del client sono state revocate. Non equiparate automaticamente 0x12 al solo blocco e non trattate questi codici come intercambiabili con i campi di stato di 4625.

Queste distinzioni aiutano a separare i tentativi con nomi sconosciuti da quelli con password errate e dalle conseguenze di un blocco. Continuano a non rivelare la password candidata. Una regola di correlazione costruita su questi eventi non può dimostrare che uno stesso segreto sia stato inviato a tutti gli account.

Correlare il comportamento, poi verificare la spiegazione

Una proposta editoriale di rilevamento consiste nel raggruppare i fallimenti per finestra temporale e origine, contare gli account bersaglio distinti e collegare queste identità all’inventario dei nomi. Stabilite un riferimento locale prima di scegliere una finestra o una soglia di allerta. È un progetto da implementare e convalidare, non una query Microsoft copiata né una soglia misurata per il vostro ambiente.

Confrontate lo schema con gli errori utente attesi e i servizi che ritentano una vecchia credenziale. Ampliate la ricerca quando le origini variano, poi esaminate gli accessi riusciti o interrotti e le attività successive insolite. I manuali Microsoft sullo spraying supportano la correlazione di cronologia, origine, account e attività successive. Una campagna può restare sotto la soglia di blocco, quindi richiedere 4740 lascerebbe una lacuna di rilevamento.

In un ambiente ibrido, includete i registri di accesso e MFA di Entra e i log del provider di identità federato, quando pertinente. Il manuale di indagine spiega che la posizione dei log dipende dall’autenticazione gestita o federata. Una password accettata seguita da MFA fallita merita un’indagine anche senza accesso finale all’applicazione. Un rapporto sui nomi account senza risultati non può risolvere tale incidente.

Correzione: risolvere finalità, esposizione e controlli (Remediation)

1. Esaminare ogni identità con il responsabile

Usate un registro di revisione per distinguere identità umane, condivise, di test, di servizio, integrate e di ripristino. Questa classificazione è una raccomandazione operativa, non qualcosa che la regex calcola. Chiedete che cosa richieda ancora l’account, chi possa usarlo, quali percorsi di autenticazione lo accettino e che cosa dipenda dal nome o dalle credenziali attuali.

Preferite accessi umani attribuibili e documentate eccezioni, responsabili e date di scadenza per le esigenze temporanee. Esaminate i privilegi separatamente: support non stabilisce le autorizzazioni dell’help desk e backup non stabilisce a quali risorse l’account possa accedere. Il codice di denominazione non ha alcun predicato di appartenenza ai gruppi o di privilegio.

Per i test, le indicazioni Microsoft sugli ambienti di test Entra trattano tenant dedicati oppure risorse e registrazioni di applicazioni correttamente isolate. È una procedura per applicazioni Entra, non una ricetta di distribuzione AD nativa. Applicarne il principio di isolamento alle identità di test AD è una raccomandazione di governance: definite un confine di test e un ciclo di vita appropriati per il dominio.

2. Ritirare gli account inutili dopo la revisione delle dipendenze

Per un account ordinario confermato come inutile, verificate prima con il responsabile servizi dipendenti, attività pianificate, applicazioni e misure di ripristino. Pianificate poi una disabilitazione mirata. Questo comando adatta l’esempio 1 di Disable-ADAccount a un’identità di test illustrativa già esaminata:

Disable-ADAccount -Identity test

Non immettete l’inventario dei nomi in un’operazione di disabilitazione massiva. Il filtro non permette di sapere se un’identità sia essenziale per le operazioni. Una rinomina pianificata è un’altra possibile azione amministrativa, dopo aver controllato chi utilizza il nome corrente. Il comando seguente usa i parametri di identità e SamAccountName documentati da Set-ADUser:

Set-ADUser -Identity test -SamAccountName app-validation

Questo modifica il nome account SAM. Non modifica la password, non riduce le autorizzazioni, non impone la MFA e non dimostra che l’account non sia più individuabile. Scegliete i nomi per chiarezza operativa e responsabilità; ridurre il conteggio delle regex non giustifica sufficientemente una rinomina.

3. Preservare il ruolo di ripristino dell’Administrator integrato

Un Administrator abilitato corrisponde al rilevatore perché non esiste un’eccezione per SID o account integrato. Determinate quale account state esaminando prima di decidere di ritirarlo. Non disabilitate alla cieca l’Administrator integrato del dominio perché compare nell’elenco dei nomi.

Le indicazioni Microsoft sull’Administrator integrato ne riservano l’uso alla costruzione iniziale e al possibile ripristino di emergenza. La pagina ha esplicitamente rimosso la precedente raccomandazione di disabilitazione perché il ripristino della foresta usa questo account, incluso l’accesso senza server di catalogo globale. Descrive invece restrizioni e audit dell’uso, reimpostazioni della password e modifiche dell’account.

Applicate le restrizioni tramite un piano di ripristino esaminato e nell’ambito documentato. La pagina sconsiglia di collegare la GPO di restrizione a livello di dominio perché può rendere Administrator inutilizzabile durante il ripristino. Non estendete le affermazioni storiche sul blocco della vecchia pagina di rinomina di Administrator a un’affermazione non verificata su ogni versione e configurazione di Windows.

4. Usare gMSA per i servizi AD e identità gestite per Azure

Per i servizi Windows che usano normali utenti di dominio, valutate una migrazione a gMSA dove supportata. La documentazione Microsoft sugli account di servizio Windows Server descrive la gestione automatica delle password e un’identità di servizio condivisa fra più server. Esaminate compatibilità del servizio, host autorizzati a recuperare credenziali, autorizzazioni delle risorse e SPN prima della migrazione. Questa raccomandazione riguarda la gestione delle credenziali di servizio, non ogni account umano con un nome corrispondente.

Per i carichi di lavoro Azure, le indicazioni Microsoft sugli account di servizio cloud privilegiano le identità gestite quando possibile e le entità servizio quando necessario, rispetto agli account di servizio Entra basati su utenti. Tenete distinta questa scelta d’identità cloud dalla distribuzione di un gMSA AD.

Quando un’applicazione richiede davvero credenziali condivise, le indicazioni Entra sulla condivisione degli account descrivono un SSO basato su password che intermedia l’accesso tramite identità individuali. Gli utenti non devono ricevere la password condivisa; gli amministratori possono revocare l’accesso, richiedere MFA ed esaminare i registri di accesso. La rotazione della password dipende dal supporto dell’applicazione. È un’opzione specifica di accesso applicativo, non un rimedio universale per gli accessi AD condivisi.

5. Verificare FGPP, blocco e MFA sui percorsi reali

Scegliete le impostazioni di password e blocco in funzione della popolazione di account e del rischio, poi verificate i criteri risultanti con i comandi di inventario precedenti. FGPP può differenziare i criteri per utenti e gruppi di sicurezza globali. Non distribuite l’esempio Microsoft LockoutThreshold=0 soltanto perché compare in una dimostrazione: sintassi dei criteri e raccomandazioni di sicurezza hanno finalità diverse.

La documentazione sulla soglia di blocco account descrive il compromesso fra resistenza ai tentativi di indovinare le password e denial of service tramite blocchi deliberati. La discussione sulla baseline Windows usa dieci tentativi non validi come possibile punto di partenza, esplicitamente senza una soglia universale. Esaminate insieme soglia, durata, finestra di reimpostazione, operazioni di sblocco e monitoraggio.

Il blocco intelligente Entra è un controllo separato dal blocco AD DS. Distingue posizioni note e sconosciute e tiene traccia degli hash recenti delle password errate; il tracciamento degli hash non è disponibile con autenticazione pass-through. Per PTA, Microsoft prescrive una soglia Entra inferiore, una soglia AD DS almeno due o tre volte superiore e una durata Entra maggiore. Verificate modalità di autenticazione e impostazioni effettive invece di copiare un esempio come regola universale.

Imponete la MFA sui percorsi esposti compatibili ed esaminate l’autenticazione legacy come raccomanda il manuale di indagine sullo spraying. Un criterio MFA Entra non rende automaticamente obbligatoria la MFA sui percorsi tradizionali di autenticazione AD. Quando la telemetria dimostra una compromissione di password o account, seguite la risposta agli incidenti, incluse modifiche delle credenziali e opportune revoche di sessioni/token, anziché chiudere il caso dopo aver rinominato un account.

Come EtcSec rileva questo problema

Il controllo di etc-collector è PASSWORD_COMMON_PATTERNS, categoria Password, gravità High. Il suo Detect() inizia in public/internal/audit/detectors/ad/password/common-patterns.go:26; le quindici espressioni esatte sono dichiarate alle righe 28–44:

(?i)^admin$
(?i)^administrator$
(?i)^test$
(?i)^user$
(?i)^guest$
(?i)^temp$
(?i)^default$
(?i)^support$
(?i)^service$
(?i)^backup$
(?i)^demo$
(?i)password
123$
(?i)^sa$
(?i)^dba$

L’implementazione scorre gli utenti raccolti ed esclude soltanto gli account Disabled. Converte SAMAccountName in minuscolo e verifica queste espressioni. Tredici corrispondono al nome completo; password corrisponde ovunque e 123$ alla terminazione. Quindi admin01, test1, temp-user e svc-sql non vengono selezionati da questi soli nomi; resetPasswordHelp e User123 vengono selezionati.

Aggiunge un account alla prima espressione corrispondente e interrompe il ciclo interno. Un account che corrisponde a più espressioni contribuisce soltanto una volta. In questa implementazione non esiste alcuna esenzione basata su SID/RID, OU, gruppo privilegiato, finalità di servizio o elenco consentito.

Count comprende tutti gli utenti abilitati corrispondenti. Details.affectedAccountNames contiene al massimo dieci nomi, anche senza IncludeDetails. Dieci nomi visualizzati non significano quindi che esistano soltanto dieci account corrispondenti. AffectedEntities viene aggiunto quando i dettagli sono richiesti e il conteggio è positivo; il risultato stesso viene restituito anche a zero.

Il rilevatore non legge displayName, alcuna password o alcun hash di password. Non misura l’entropia delle password, non esegue autenticazioni, non valuta criteri di blocco o MFA e non esamina l’attività per provare un tentativo o un successo di spraying. Il testo descrittivo suggerisce un rischio di password predefinite, ma tali suggerimenti non sono predicati del codice.

Convalidare il risultato

Ripetete lo stesso inventario e le letture dei criteri effettivi dopo le modifiche approvate. Documentate le eccezioni mantenute e i requisiti di ripristino e confermate con i responsabili che servizi e applicazioni funzionino ancora. Esaminate i registri di autenticazione pertinenti per individuare attività sospette residue seguendo le indicazioni Microsoft per l’indagine.

Chiudete ogni revisione con il risultato che stabilisce realmente: identità inutile ritirata, dipendenza migrata, criteri effettivi verificati oppure eccezione mantenuta con giustificazione. Denominazione, criteri password, applicazione degli accessi e prove d’attacco rispondono a domande diverse. Una revisione dei nomi completata dovrebbe chiarire queste risposte senza affermare che una regex abbia testato un segreto.