KomuraSoft LLC
Contatti
Menu

Criteri di controllo di sicurezza Windows e indagine pratica sul registro eventi — Diventare un team IT capace di leggere l'evento 4625

· · Windows, Sicurezza, Registro eventi, Criteri di controllo, Progettazione dei log, PowerShell, Sistemi informativi

«Da ieri sera un account continua a bloccarsi. Per favore, scoprite perché.» «Voglio verificare se qualcuno sta tentando di accedere con l’account di un dipendente uscito.» «Potete dirmi chi ha fatto cosa, e quando, su questo server?» — sono le richieste che il personale IT delle piccole e medie imprese, o gli sviluppatori che hanno consegnato un sistema a un cliente, si trovano all’improvviso. E la cosa a cui finiscono per affidarsi è il registro eventi Security di Windows.

Ma quando aprite davvero il Visualizzatore eventi, vi aspettano due realtà. L’evento che volete vedere non è mai stato registrato (i criteri di controllo non erano abilitati), oppure è sepolto sotto una montagna di eventi illeggibili (annegato nel rumore e nel gonfiaggio). Il controllo di sicurezza è qualcosa che si può catturare «se lo si abilita», ma se non progettate cosa catturare e fino a dove, non vi aiuta quando vi serve davvero.

Due realtà che attendono nel Visualizzatore eventiAprendo il Visualizzatore eventi si trovano due realtà, o i criteri di controllo non sono abilitati e l'evento cercato non è registrato, o il registro è gonfiato di rumore e l'evento è sepolto tra troppi eventi, quindi occorre progettare cosa registrare e fino a doveNon registratoSepoltoAprire il Visualizzatore eventiQuale realtà ci aspetta?L'evento cercato non è registratoIleggibile tra troppi eventiCriteri di controllo disabilitatiGonfiato di rumoreProgettare cosa registrare e fino a dove

Figura 1: «Non è registrato» o «è sepolto e non si legge». In entrambi i casi, la causa è non aver progettato l’ambito di registrazione.

Questo articolo organizza il funzionamento dei criteri di controllo (i due sistemi, di base e avanzati), le sottocategorie da abilitare almeno in un ambiente di piccola o media dimensione, come leggere gli ID evento di riferimento — 4624/4625/4740/4688 e altri —, il dimensionamento del registro Security e come indagare con PowerShell, tutto sulla base di fonti primarie ad agosto 2026. Se gli articoli di questo sito su controllo NTLM, firma SMB, BitLocker e firewall riguardano tutti «irrobustire le difese», questo articolo riguarda «rendere possibile confermare dopo cosa è successo» — un seguito che li tiene insieme.

1. Prima di tutto, la conclusione

  • I criteri di controllo hanno due sistemi — «di base» e «avanzati (Advanced Audit Policy)» — e non vanno mescolati. Microsoft dichiara esplicitamente che usarli entrambi lascia i risultati di controllo in uno stato imprevedibile. Unificate sul lato avanzato (oltre 40 sottocategorie).1
  • Lo stato attuale si verifica con auditpol /get /category:*. Elenca ciò che è davvero in vigore in questo momento, indipendentemente dal fatto che provenga da una GPO o da un’impostazione locale.2
  • «Abilitare tutto» è qualcosa che non dovete mai fare. Abilitare sottocategorie che generano volumi enormi di eventi seppellisce sotto il rumore gli eventi che contano davvero, e influisce anche sulle prestazioni. Partite dalle raccomandazioni di baseline di Microsoft e aggiungete solo ciò che serve.34
  • Un accesso riuscito è 4624; uno non riuscito è 4625. Per il 4624, leggete «che tipo di accesso è stato» dal tipo di accesso (2 = Interactive, 3 = Network, 10 = RemoteInteractive, e così via).5
  • Per il 4625, il codice Status/Sub Status vi dice il motivo del fallimento. I classici sono 0xC0000064 = nome utente inesistente, 0xC000006A = password errata, 0xC0000072 = account disabilitato e 0xC0000234 = account bloccato.6
  • Dove viene registrato un evento è fisso. 4624/4625 vengono registrati sulla macchina a cui si accede; la convalida delle credenziali (4776) e il fallimento della pre-autenticazione Kerberos (4771) vengono registrati sul controller di dominio. Guardate la macchina sbagliata e concluderete per errore «non c’è log».678
  • Metà della progettazione del registro Security è il contenitore stesso — dimensione massima e conservazione. Se la conservazione è impostata sulla sovrascrittura, gli eventi vecchi spariscono per primi. Controllate dimensione massima e numero di record con Get-WinEvent -ListLog Security, e ampliatela ragionando a ritroso dai giorni che vi serve davvero tenere.910
  • La registrazione della riga di comando per la creazione di processi (4688) è potente, ma il prezzo è che i segreti finiscono in chiaro nel log. Controllate gli script prima di abilitarla.1112

2. Basi dei criteri di controllo — Non mescolare «di base» e «avanzati»

I criteri di controllo di Windows esistono in due sistemi.1

  • Criteri di controllo di base: le nove impostazioni di categoria sotto «Criteri locali > Criteri di controllo». È il sistema più vecchio, precedente a Windows Vista.
  • Configurazione criteri di controllo avanzati (Advanced Audit Policy Configuration): le oltre 40 impostazioni di sottocategoria sotto «Impostazioni di sicurezza > Configurazione criteri di controllo avanzati». Scompone ogni categoria di base in più sottocategorie — per esempio, l’unica categoria di base «Controlla eventi di accesso all’account» corrisponde a quattro sottocategorie sul lato avanzato. Abilitare una categoria di base ha lo stesso effetto di abilitare tutte le sottocategorie corrispondenti, il che registra un grande volume di eventi che magari non vi interessano.1

Il punto importante è che questi due sistemi non sono compatibili tra loro. Microsoft lo dice chiaro: «Non usate insieme i criteri di base e quelli avanzati: i risultati di controllo possono finire in uno stato imprevisto.» Quando i criteri di controllo avanzati vengono applicati via Criteri di gruppo, le impostazioni di controllo esistenti di quel computer vengono prima azzerate e poi vengono applicate le impostazioni avanzate; da quel momento, solo il lato avanzato può controllare in modo affidabile il controllo. Negli ambienti che usano il lato avanzato, abilitate l’opzione di sicurezza «Controllo: Forza le impostazioni di sottocategoria dei criteri di controllo in modo che prevalgano sulle impostazioni di categoria» così che le impostazioni di base non possano sovrascriverla (su macchine autonome è abilitata per default).14

Rapporto tra criteri di controllo di base e avanzatiI criteri di controllo di base e quelli avanzati non sono compatibili e usarli insieme lascia i risultati di controllo in uno stato imprevedibile, quindi si unifica sul lato avanzato e si abilita il forzare le impostazioni di sottocategoria per impedire la sovrascrittura dal lato di baseSìNoCriteri di controllo di base（9 categorie）Si usano entrambi?Criteri di controllo avanzati（oltre 40 sottocategorie）Risultati di controllo imprevedibiliUnificare sul lato avanzatoAbilitare Forza impostazioni di sottocategoriaImpedisce la sovrascrittura dal lato di base

Figura 2: I due sistemi non sono compatibili. Unificate sul lato avanzato e, con l’impostazione «Forza», impedite la sovrascrittura dal lato di base.

Verificare lo stato attuale è un solo comando, da un prompt dei comandi con privilegi di amministratore.2

rem elenca le impostazioni di audit attualmente in vigore, per sottocategoria
auditpol /get /category:*

rem backup delle impostazioni in CSV prima delle modifiche, e ripristino
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

L’output di auditpol è «il criterio che è davvero in vigore come risultato», indipendentemente dal fatto che origini da una GPO o da un’impostazione locale. Serve anche per il confronto quando un’impostazione che dovrebbe essere stata distribuita via GPO non sembra essersi applicata. Notate che un cambio delle impostazioni di controllo stesse viene registrato come evento 4719, quindi anche «il controllo è stato spento senza che nessuno se ne accorgesse» si può rintracciare dopo.12

auditpol mostra il criterio risultanteL'output di auditpol è il criterio di controllo in vigore come risultato, indipendentemente dal fatto che origini da GPO o da un'impostazione locale, serve al confronto quando la GPO non si riflette, e il cambio delle impostazioni di controllo stesse si può rintracciare dopo con l'evento 4719Impostazione distribuita via GPOCriterio in vigore come risultatoImpostazione localeElenco con auditpol /getServe al confronto se la GPO non si rifletteCambio delle impostazioni di controlloSi registra 4719 e si può rintracciare dopo

Figura 3: auditpol restituisce «l’impostazione in vigore» a prescindere dall’origine. Il cambio delle impostazioni di controllo stesse resta nel 4719.

3. Una tabella di decisione per le sottocategorie minime da abilitare

Il motivo per cui «abilitare tutto, per sicurezza» è una mossa sbagliata è chiaro. Per esempio, Microsoft avverte che controllare anche i successi delle sottocategorie di uso dei privilegi genera un volume di eventi così enorme da rendere difficile trovare altre voci nel registro di sicurezza, e può influire in modo significativo sulle prestazioni.4 Il contenitore del registro (sezione 5) è finito, quindi più rumore registrate, più erodete i giorni di conservazione degli eventi che vi servono davvero. La progettazione del controllo consiste nel decidere cosa non registrare.

Perché abilitare tutto è una mossa sbagliataAbilitare tutte le sottocategorie genera un volume enorme di eventi, seppellisce sotto il rumore gli eventi che contano, influisce sulle prestazioni e, con un contenitore di log finito, erode anche i giorni di conservazione degli eventi necessariAbilitare tutte le sottocategorieSi genera un volume enorme di eventiGli eventi che contano restano sepoltiImpatto sulle prestazioniSi erodono i giorni di conservazioneDecidere cosa non registrare è progettare il controllo

Figura 4: «Abilitare tutto» seppellisce gli eventi che contano. Decidere cosa non registrare è la progettazione del controllo.

Microsoft pubblica raccomandazioni di baseline e raccomandazioni rafforzate suddivise per workstation e server, ed è da lì che si parte.3 Da lì, la tabella sotto è organizzata intorno al punto di vista di un ambiente di piccola o media dimensione: «cosa vogliamo poter leggere almeno durante un incidente».

Sottocategoria (categoria) ID evento principali Cosa rivela Raccomandazione per un ambiente piccolo/medio
Accesso (Accesso/Disconnessione) 4624 / 4625 Successo/fallimento dell’accesso, tipo di accesso, origine Successo + fallimento. Da Windows 10 1809 successo e fallimento sono già abilitati per default3
Accesso speciale (stessa) 4672 / 4964 Occorrenza di un accesso con privilegi di amministratore Successo
Blocco account (stessa) 4625 Tentativo di accesso non riuscito contro un account attualmente bloccato Fallimento (4625 è un evento di fallimento; questa sottocategoria non ha eventi di successo)13
Gestione account utente (Gestione account) 4720 / 4726 / 4738 / 4740 Creazione, eliminazione, modifica, blocco di account Successo + fallimento
Gestione gruppi di sicurezza (stessa) 4728 / 4732 / 4756 (aggiunta), 4729 / 4733 / 4757 (rimozione) Membri aggiunti o rimossi da gruppi amministrativi e altri (globale/locale/universale) Successo (questa sottocategoria non ha eventi di fallimento)14
Convalida delle credenziali (Accesso all’account) 4776 Successo o fallimento dell’autenticazione NTLM. Registrato sul DC per gli account di dominio7 Successo + fallimento
Servizio di autenticazione Kerberos (stessa, solo DC) 4768 / 4771 Emissione di TGT e fallimento della pre-autenticazione (password errata, ecc.)8 Successo + fallimento, sui DC
Creazione processi (Tracciamento dettagliato) 4688 Chi ha eseguito cosa, da quale processo padre Successo. Leggete la cautela della sezione 7 prima di abilitare la registrazione della riga di comando
Altri eventi di accesso agli oggetti (Accesso agli oggetti) 4698 Creazione di un’attività pianificata (una tecnica comune di persistenza)15 Valutare di abilitare il successo
Modifica criteri di controllo (Modifica criteri) 4719 Cambi alle impostazioni di controllo stesse Successo + fallimento

Viceversa, in genere è più prudente non toccare per default il controllo di accesso agli oggetti su file system o Registro, l’uso dei privilegi o le sottocategorie di filtro pacchetti (5152 e simili). Servono quando le delimitate a una configurazione SACL mirata o a un’indagine a tempo limitato, non come qualcosa lasciato sempre acceso su tutta la linea — farlo vi mangia il registro.4

Come trattare le sottocategorie ad alto volume di eventiIl controllo di accesso agli oggetti su file system o Registro, l'uso dei privilegi e le sottocategorie di filtro pacchetti, se lasciati sempre al massimo, divorano il registro, e sono utili solo con una SACL mirata o per un periodo limitato di isolamentoSempre al massimoSACL mirata a un oggettoPeriodo limitato di isolamentoSottocategorie ad alto volume di eventiCome abilitarle?Controllo di accesso agli oggettiUso dei privilegi e filtro pacchettiDivorano il registroUtileUtile

Figura 5: Non tenete sempre al massimo l’accesso agli oggetti né l’uso dei privilegi. Servono solo se delimitate oggetto e periodo.

4. Come leggere gli ID evento di riferimento

4.1. 4624 — Gli accessi riusciti si distinguono per tipo di accesso

4624, «Un account ha eseguito l’accesso correttamente», viene registrato sulla macchina in cui è stata creata la sessione di accesso (la macchina a cui si accede).5 Poiché è un evento ad alto volume, il primo passo per leggerlo è classificarlo per tipo di accesso.5

Tipo di accesso Nome Cosa significa in pratica
2 Interactive Un accesso alla console di quel PC
3 Network Accesso in rete (cartelle condivise, strumenti di amministrazione, ecc.). Il più frequente, perché scatta una volta per macchina
4 Batch Esecuzione batch (attività pianificate, ecc.)
5 Service Avvio di un servizio (tramite Service Control Manager)
7 Unlock Sblocco dello schermo
8 NetworkCleartext Un accesso di rete in cui la password è stata passata in chiaro al pacchetto di autenticazione
9 NewCredentials Duplicazione di un token esistente con credenziali alternative (equivalente a runas /netonly)
10 RemoteInteractive Desktop remoto
11 CachedInteractive Un accesso con credenziali in cache (quando il DC non era raggiungibile)

Altri campi da controllare insieme sono il nome account sotto «Nuovo accesso», l’indirizzo di origine sotto «Informazioni di rete», il «Pacchetto di autenticazione» (NTLM o Kerberos) e il «Token con privilegi elevati» (se la sessione ha privilegi di amministratore). Se volete tracciare solo gli accessi con privilegi di amministratore, è utile anche l’evento 4672 (privilegi speciali assegnati al nuovo accesso), registrato con lo stesso ID di accesso.5

Procedura per leggere il 4624Il 4624, registrato in grande volume, si classifica prima per tipo di accesso, poi si controllano nome account e origine, pacchetto di autenticazione e token con privilegi elevati, e l'accesso con privilegi di amministratore si confronta con il 4672 dello stesso ID di accesso4624 Accesso riuscitoClassificare per tipo di accessoControllare i campi principaliNome account e originePacchetto di autenticazioneToken con privilegi elevatiTracciare i privilegi di amministratore4672 con lo stesso ID di accesso

Figura 6: Il 4624 si classifica per tipo di accesso prima di leggere i campi. L’accesso privilegiato si correla con il 4672.

4.2. 4625 — Il motivo del fallimento si fissa con il codice Status/Sub Status

4625, «Un account non è riuscito ad accedere», viene registrato sulla macchina in cui è stato tentato l’accesso.6 Piuttosto che fidarsi del testo del campo «Motivo dell’errore», il modo affidabile di leggerlo è il codice esadecimale Status/Sub Status. I classici sono i seguenti.6

  • 0xC0000064: Nome utente inesistente. Una rapida successione in una finestra breve può indicare un attacco di enumerazione degli account
  • 0xC000006A: Password errata. Fallimenti ripetuti contro un account specifico possono indicare un attacco di indovinamento della password
  • 0xC000006D: Nome utente o informazioni di autenticazione non validi
  • 0xC000006F: Fuori dall’orario di accesso consentito
  • 0xC0000070: Da una workstation non consentita
  • 0xC0000072: Account disabilitato da un amministratore (i tentativi sull’account di un dipendente uscito compaiono qui)
  • 0xC000015B: Il tipo di accesso richiesto non è consentito su questa macchina
  • 0xC0000193: Account scaduto
  • 0xC0000234: Bloccato

«Chi, da dove e perché è fallito» si fissa con il terzetto di account di destinazione, origine (nome workstation / indirizzo IP) e questo codice. La sezione 6 include PowerShell che estrae tutti e tre insieme in un colpo solo.

Flusso per fissare il motivo del fallimento del 4625Il motivo del fallimento del 4625 si fissa con il codice esadecimale Status/Sub Status, si legge l'indizio di attacco dalla tendenza del codice e si identifica con il terzetto di account di destinazione e origine0xC0000064 ripetuto0xC000006A ripetuto0xC00000724625 Accesso non riuscitoControllare il codice Sub StatusQual è la tendenza del codice?Indizio di enumerazione degli accountIndizio di indovinamento della passwordTentativo su account di un dipendente uscitoSi fissa con il terzettoAccount di destinazione+origine+codice

Figura 7: Il motivo del fallimento si fissa dal codice e si legge insieme ad account di destinazione e origine, come un terzetto.

4.3. 4740 — L’origine di un blocco è il «Nome computer chiamante»

4740, «Un account utente è stato bloccato» (sottocategoria: Gestione account utente). Il campo chiave di questo evento è «Nome computer chiamante (Caller Computer Name)», che registra il computer da cui è partito il tentativo di accesso che ha innescato il blocco.16 La procedura standard è identificare da questo campo la macchina di origine, e poi cercare le credenziali vecchie ancora conservate su quella macchina. Nella maggior parte dei casi la causa è qualcosa che continua a usare credenziali vecchie dopo un cambio password — credenziali salvate, una sessione RDP disconnessa e lasciata appesa, o un servizio o un’attività pianificata configurati con la password vecchia.

Procedura standard per indagare un blocco accountIl nome computer chiamante del 4740 identifica la macchina di origine, e su quella macchina si cercano credenziali salvate, sessioni RDP disconnesse e lasciate appese, e servizi o attività con password vecchie4740 Blocco accountControllare il nome computer chiamanteIdentificare la macchina di origineCercare le credenziali vecchieCredenziali salvateSessioni RDP disconnesse e lasciate appeseServizi o attività con password vecchie

Figura 8: Identificate l’origine dal «Nome computer chiamante» del 4740 e cercate le credenziali vecchie di quella macchina.

C’è un punto da tenere d’occhio. 4625 viene registrato sul computer che ha ricevuto il tentativo di accesso. Se la causa è un accesso di rete dalla macchina di origine verso, per esempio, un file server, sul registro Security della macchina di origine non resta nessun 4625; la traccia resta invece nel 4625 del server di destinazione o, per un account di dominio, nel 4776 (NTLM) o nel 4771 (fallimento della pre-autenticazione Kerberos) sul DC.78 Quando «non c’è nulla nel log della macchina di origine», andate a guardare il lato che ha ricevuto il tentativo.

Su quale macchina resta la traccia del fallimentoIl fallimento di un accesso di rete non resta sulla macchina di origine stessa, ma viene registrato nel 4625 del server di destinazione che ha ricevuto il tentativo, e per un account di dominio la traccia resta anche nel 4776 o nel 4771 del DCAccesso di reteAutenticazione di un account di dominioMacchina di origine（il 4625 non resta su di sé）Server di destinazioneViene registrato il 4625Controller di dominio4776（NTLM）/4771（Kerberos）

Figura 9: Il 4625 resta sul lato che ha ricevuto il tentativo. Se sulla macchina di origine non c’è nulla, guardate il server di destinazione e il DC.

4.4. La famiglia 4720 — Creazione e modifica di account, e aggiunte ai gruppi

Gli eventi di gestione account formano una sequenza di numeri adiacenti: 4720 (account utente creato)17, 4726 (eliminato), 4738 (modificato) e, sul lato gruppi, membro aggiunto/rimosso. Notate che quale ID evento scatta per un cambio di appartenenza a un gruppo dipende dal tipo di gruppo. È 4732/4733 per i gruppi locali, 4728/4729 per i gruppi globali e 4756/4757 per i gruppi universali.14 Domain Admins è un gruppo globale, quindi un’aggiunta a esso compare come 4728 — se allertate solo sul 4732, vi perdete proprio l’evento che più volete catturare. Nel quotidiano è soprattutto un registro del lavoro dell’help desk, ma «un utente standard è stato improvvisamente aggiunto a un gruppo amministrativo» o «è stato appena creato un account che nessuno riconosce» merita un’indagine anche come occorrenza singola. Microsoft stessa indica le aggiunte inattese di membri a gruppi privilegiati come esempio di evento su cui allertare singolarmente.3

Tipo di gruppo e evento di aggiunta di un membroL'aggiunta di un membro a un gruppo si registra con un ID evento diverso a seconda del tipo di gruppo, 4732 per locale, 4728 per globale e 4756 per universale, quindi l'aggiunta al gruppo globale Domain Admins si registra in 4728LocaleGlobaleUniversaleAggiunta di un membro a un gruppoQual è il tipo di gruppo?Si registra in 4732Si registra in 4728Si registra in 4756Qui resta l'aggiunta a Domain AdminsVigilare solo sul 4732 fa perdere casi

Figura 10: L’ID evento dell’aggiunta di un membro dipende dal tipo di gruppo. L’aggiunta a Domain Admins si registra nel 4728.

4.5. 4688 — Creazione di processi. La registrazione della riga di comando è un interruttore a parte

4688, «È stato creato un nuovo processo», registra l’account che lo ha creato, il percorso dell’eseguibile del nuovo processo, il processo padre e il tipo di elevazione del token ogni volta che viene creato un processo.11 È un evento di alto valore investigativo, che può rispondere a «chi ha eseguito cosa su questo server».

Per default, però, gli argomenti della riga di comando non vengono registrati. Solo quando abilitate separatamente l’impostazione Criteri di gruppo «Includi riga di comando negli eventi di creazione processi» (Modelli amministrativi > Sistema > Controllo creazione processi) il campo «Riga di comando del processo» del 4688 si popola con gli argomenti.1112 È di fatto essenziale per tracciare avvii sospetti come powershell -EncodedCommand ..., ma abilitatela solo dopo aver capito il rischio di esposizione di segreti descritto nella sezione 7.

Rapporto tra 4688 e registrazione della riga di comandoAbilitare il controllo della creazione di processi registra nel 4688 account, percorso dell'eseguibile e processo padre, ma gli argomenti della riga di comando si registrano solo abilitando un altro criterio di gruppo, con il rischio che i segreti finiscano in chiaroDefaultAbilitare anche la GPOAbilitare il controllo della creazione di processiViene registrato il 4688Account, percorso e processo padreVolete anche gli argomenti?La riga di comando resta vuotaVengono registrati gli argomentiRischio di segreti in chiaro

Figura 11: La registrazione della riga di comando del 4688 è un interruttore a parte. Prima di abilitarla, verificate il rischio di esposizione di segreti.

4.6. 4698 — Creazione di attività pianificate

4698, «È stata creata un’attività pianificata», registra il nome dell’attività e l’XML completo della definizione dell’attività (incluso il comando che esegue). Poiché registrare un’attività pianificata è una tecnica comune con cui il malware sopravvive a un riavvio, Microsoft raccomanda di monitorare gli eventi di creazione di attività.15 Anche in ambienti che usano intensamente le attività pianificate per il lavoro, la creazione in sé non è qualcosa che accade ogni giorno, quindi il livello di rumore resta relativamente basso.

Persistenza tramite attività pianificate e 4698Il malware usa la registrazione di un'attività pianificata come tecnica abituale per sopravvivere a un riavvio, quindi monitorando il 4698 registrato alla creazione di un'attività si può tracciare fino alla definizione XML completa, incluso il comando eseguitoPersistenza del malwareRegistra un'attività per sopravvivereViene registrato il 4698XML completo con il comando eseguitoSi rileva monitorando la creazione di attivitàLa creazione non è quotidiana, poco rumore

Figura 12: La registrazione di attività, tecnica abituale di persistenza, resta nel 4698. Dall’XML completo della definizione si arriva fino al comando eseguito.

Un altro da ricordare è 1102, «Il registro di controllo è stato cancellato.» Svuotare il registro Security lascia sempre questo evento, quindi se trovate «il log è vuoto» vi permette di distinguere un incidente da un’operazione di routine.18

Distinguere la cancellazione del log con il 1102Lo svuotamento del registro Security lascia sempre il 1102, quindi quando il log è vuoto, controllare se esiste il 1102 permette di distinguere se è stata un'operazione di cancellazione o un incidenteC'èNon c'èIl log è vuotoLo svuotamento lascia sempre il 1102C'è il 1102?C'è stata un'operazione di cancellazioneSospettare un incidente

Figura 13: Lo svuotamento del registro Security lascia sempre il 1102. Un log vuoto si distingue in incidente o operazione in base alla presenza del 1102.

5. Progettare il contenitore del log — Dimensione massima e conservazione

Prima di aggiungere altri criteri di controllo, controllate il recipiente che li riceve. Il registro Security ha una dimensione massima e una modalità di conservazione: in modalità sovrascrittura (la configurazione tipica), una volta raggiunta la dimensione massima, i nuovi eventi sovrascrivono i più vecchi. Viceversa, in modalità di conservazione (non sovrascrivere), una volta che il log è pieno, sono i nuovi eventi a essere scartati.10 Entrambi i comportamenti possono lasciarvi con «il log che mi serviva non c’è», quindi capire lo stato attuale viene prima.

# Controllare il contenitore del registro Security: modalità di ritenzione, dimensione massima, numero di record attuale
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# Quanti giorni sono davvero conservati adesso (timestamp dell'evento più vecchio)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog restituisce insieme la configurazione del log e il numero di record.9 La differenza tra «la data dell’evento più antico» e l’ora attuale è il periodo reale di conservazione; se non arriva al vostro requisito (quanti giorni indietro volete poter indagare), ampliate la dimensione massima. Potete configurarla con wevtutil sl Security /ms:<numero di byte>, o distribuirla via Criteri di gruppo.10

Dimensionamento calcolato a ritroso dai giorni di conservazioneSi controllano configurazione e numero di record con ListLog di Get-WinEvent, si calcola il numero reale di giorni di conservazione dalla data dell'evento più antico, e se non arriva ai giorni che si vogliono consultare in un'indagine di incidente si amplia la dimensione massimaArrivaNon arrivaControllare configurazione e numero con ListLogControllare la data dell'evento più anticoCalcolare i giorni reali di conservazioneArriva al requisito?Mantenere la dimensione attualeAmpliare la dimensione massimaImpostare con wevtutil sl o via GPO

Figura 14: Verificate quanti giorni restano davvero conservati e determinate la dimensione massima ragionando a ritroso dai giorni che volete poter consultare.

C’è anche un’opzione di sicurezza chiamata «Controllo: Arresta il sistema immediatamente se non è possibile registrare i controlli di sicurezza» (comunemente nota come CrashOnAuditFail). Quando è abilitata, se il sistema non riesce più a registrare un evento di controllo, si ferma con l’errore STOP C0000244. Esiste per requisiti di autenticazione che non possono assolutamente perdere una traccia di controllo, ed è disabilitata per default. Microsoft stessa avverte che può essere trasformata in un DoS, con un attaccante che genera deliberatamente un diluvio di eventi per fermare un server — quindi non è qualcosa da abilitare alla leggera in un ambiente tipico di piccola o media dimensione.19

Comportamento quando il log è pienoLa configurazione di conservazione ha due forme, modalità sovrascrittura e non sovrascrivere, e quando in modalità non sovrascrivere non si può più registrare il controllo, se è abilitata anche l'impostazione a parte CrashOnAuditFail il sistema si ferma con l'errore STOP C0000244Modalità sovrascritturaNon sovrascrivereSìIl registro Security raggiunge la dimensione massimaQual è la configurazione di conservazione?Viene sovrascritto l'evento più vecchioViene scartato l'evento nuovoEntrambi possono lasciare il log senza ciò che si cercaÈ abilitato anche CrashOnAuditFail?Si ferma con l'errore STOP C0000244

Figura 15: La configurazione di conservazione sovrascrive o scarta. CrashOnAuditFail è un’impostazione a parte che ferma il sistema quando non si può più registrare.

6. Indagine pratica — Filtri, Get-WinEvent ed esportazione

6.1. Restringere nel Visualizzatore eventi

Per un’indagine occasionale, il Visualizzatore eventi basta. Aprite il registro Security e specificate un ID evento (per esempio, 4625) e un intervallo di tempo con «Filtra registro corrente». Salvate le condizioni che controllate ripetutamente come «Visualizzazione personalizzata», così la volta dopo sono a un clic. Se volete restringere per un account specifico e non solo per ID evento, potete modificare direttamente la query XPath nella scheda XML della finestra di filtro.

6.2. Estrazione con Get-WinEvent

Per indagini con molti record, condizioni multiple o esecuzioni pianificate, passate a Get-WinEvent di PowerShell. Il punto chiave è usare -FilterHashtable, che applica il filtro sul lato server.9

Come scegliere lo strumento di indagineUn'indagine occasionale basta con il filtro del Visualizzatore eventi, le condizioni che si consultano ripetutamente si salvano in una visualizzazione personalizzata, e le indagini con molti record, condizioni multiple o esecuzione pianificata passano a Get-WinEventOccasionaleCondizione che si ripeteAlto volume, condizioni multiple, pianificataChe tipo di indagine?Filtrare nel Visualizzatore eventiSalvare in una visualizzazione personalizzataPassare a Get-WinEventFiltrare con FilterHashtable

Figura 16: Occasionale, il Visualizzatore eventi; se si ripete, una visualizzazione personalizzata; con alto volume, Get-WinEvent.

# Ottenere gli accessi falliti (4625) delle ultime 24 ore
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Dare forma tabellare a «chi, da dove e perché»
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Una volta che avete questo schema per estrarre EventData dalla rappresentazione XML di un evento, potete riusarlo così com’è per 4624 o 4688. La progettazione del filtro di Get-WinEvent — quando usare FilterHashtable rispetto a XPath, e come correggere una query lenta — è trattata in dettaglio in «Investigating Event Logs in Practice with Get-WinEvent — Filtering Speed Decides How Long the Investigation Takes».

Schema per estrarre EventDataGli eventi ottenuti con Get-WinEvent si convertono in rappresentazione XML, si estraggono i campi di EventData e si danno forma di tabella, e questo stesso schema si riusa sia per il 4624 sia per il 4688Ottenere con Get-WinEventConvertire l'evento in rappresentazione XMLEstrarre EventDataDare forma di tabella e aggregareSi riusa allo stesso modo per 4624 o 4688

Figura 17: Lo schema di estrarre EventData dalla rappresentazione XML e dargli forma di tabella si può riusare anche se cambia l’ID evento.

6.3. Esportazione con wevtutil

La regola per i log sulla macchina sotto indagine è esportarli e metterne al sicuro una copia prima, prima che vengano sovrascritti.10

rem conservare l'intero registro Security come evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem esportare solo gli eventi 4625, ristretti con XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Un .evtx esportato si può analizzare su un’altra macchina esattamente allo stesso modo, con Get-WinEvent -Path C:\logs\security-20260801.evtx.9 L’abitudine di preservare prima di analizzare è la stessa idea di «mettere al sicuro prima il dump» nell’indagine di un crash (vedere «Introduzione alla raccolta di crash dump Windows - WER/ProcDump/WinDbg»).

Flusso di preservazione e poi analisiIl registro Security della macchina sotto indagine si mette al sicuro esportandolo in un file evtx con wevtutil epl, si porta su un'altra macchina e si analizza allo stesso modo con il Path di Get-WinEventMacchina sotto indaginePreservare come evtx con wevtutil eplPortarlo su un'altra macchinaAnalizzare con Get-WinEvent -PathMetterlo al sicuro prima che la sovrascrittura lo elimini

Figura 18: Prima preservare, poi analizzare. Una volta messo al sicuro in evtx, si può indagare allo stesso modo su un’altra macchina.

7. Insidie — Quattro facili da calpestare sul campo

(1) I segreti finiscono nella riga di comando del 4688. Abilitare la registrazione della riga di comando mette gli argomenti di ogni processo nel registro Security in chiaro. Microsoft dichiara esplicitamente che «qualsiasi utente con accesso in lettura agli eventi di sicurezza sarebbe in grado di leggere gli argomenti della riga di comando di ogni processo creato con successo. Gli argomenti della riga di comando possono contenere informazioni sensibili o private come le password.»12 Se anche una sola applicazione aziendale o uno script avvia qualcosa come myapp.exe /user:admin /password:P@ssw0rd, è un segreto divulgato a chiunque possa consultare il log. Prima di abilitare, cercate i punti che passano segreti come argomenti della riga di comando e correggeteli. Anche dove esportate o inoltrate il log va trattato allo stesso livello di riservatezza.

Ordine per abilitare la registrazione della riga di comandoLa registrazione della riga di comando del 4688 va abilitata solo dopo aver individuato le applicazioni aziendali o gli script che passano segreti come argomenti, corretto quei punti, e chiesto lo stesso livello di trattamento anche alla destinazione di preservazione e inoltro del logCi sonoNon ci sonoIndividuare il passaggio di segreti come argomentiCi sono casi?Correggere i punti che li passanoAbilitare la registrazione della riga di comandoPreservazione e inoltro allo stesso livello di trattamento

Figura 19: La registrazione della riga di comando si abilita «dopo aver individuato e corretto». Invertire l’ordine equivale a divulgare i segreti.

(2) Operare senza sapere cosa succede quando il log si riempie. In modalità sovrascrittura, le prove vecchie spariscono in silenzio; in modalità non sovrascrivere, i nuovi eventi vengono scartati; e con CrashOnAuditFail abilitato, si ferma l’intero sistema (sezione 5).1019 L’approccio corretto è sapere quale comportamento avete scelto, e mettere in piedi un meccanismo — esportazioni pianificate, o una piattaforma di raccolta log — che raccoglie i dati prima che vengano sovrascritti.

(3) Controller di dominio e postazioni richiedono di guardare log diversi. 4624/4625 vengono registrati sulla macchina a cui si è acceduto.56 La convalida delle credenziali di un account di dominio (il 4776 di NTLM), invece, viene registrata sulla macchina che ha autorità su quella credenziale — per un account di dominio, è il DC7 — e il fallimento della pre-autenticazione Kerberos (4771) viene registrato solo su un DC.8 «Nessun 4625 sul file server» non significa «non c’è stato un attacco»; ottenete il quadro completo solo quando confrontate anche 4776/4771 sul DC. Vedere «NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM» per come scorre davvero ciascun protocollo di autenticazione.

(4) Lo sfasamento dell’orologio rompe la correlazione. Allineare i log di più macchine per tracciare «su quale postazione è uscito un 4625 subito prima di questo 4740» funziona solo se l’orologio di ogni macchina è d’accordo. In un ambiente di dominio, Kerberos stesso impone un limite superiore allo sfasamento dell’orologio (5 minuti per default), oltre il quale l’autenticazione stessa inizia a fallire.20 Dal punto di vista dell’indagine, uno sfasamento anche di pochi secondi — figuriamoci cinque minuti — può farvi leggere male l’ordine degli eventi, quindi controllare lo stato di sincronizzazione di w32time dovrebbe essere il primissimo passo della procedura di indagine. Tenete anche presente che i timestamp degli eventi sono salvati in UTC e visualizzati secondo il fuso orario della macchina da cui si consulta, quindi ricordatevi di convertire i fusi quando leggete un .evtx portato da una sede estera o da un server configurato in UTC.

Sincronizzazione dell'orologio come premessa della correlazioneConfrontare in ordine di tempo i log di più macchine presuppone che gli orologi di ciascuna coincidano, uno sfasamento di pochi secondi già fa leggere male l'ordine degli eventi, e uno sfasamento oltre i 5 minuti di default fa fallire l'autenticazione Kerberos stessa, quindi conviene mettere il controllo di w32time all'inizio della proceduraCoincidonoSfasamento di pochi secondiOltre i 5 minuti di defaultConfrontare i log di più macchinePresuppone che gli orologi coincidanoQuanto è lo sfasamento dell'orologio?Si può seguire in ordine di tempoSi legge male l'ordine degli eventiFallisce l'autenticazione KerberosControllare w32time all'inizio della procedura

Figura 20: Confrontare più macchine presuppone orologi allineati. Anche uno sfasamento di pochi secondi può far leggere male l’ordine degli eventi.

8. Riassunto

  • I criteri di controllo hanno due sistemi, «di base» e «avanzati», e mescolarli produce risultati imprevedibili. Unificate sul lato avanzato, verificate lo stato attuale con auditpol /get /category:*, e progettate da lì.
  • «Abilitare tutto» uccide l’indagine con rumore e gonfiaggio. Partite dalle raccomandazioni di baseline di Microsoft e lavorate sulla tabella di decisione della sezione 3, costruita intorno ad accesso, gestione account e creazione di processi.
  • Il 4624 si legge per tipo di accesso, il 4625 per codice Status/Sub Status, il 4740 per Nome computer chiamante e il 4688 per processo padre e riga di comando — ogni evento ha un campo specifico da controllare.
  • Il contenitore del log (dimensione massima e modalità di conservazione) è metà della progettazione del controllo. Verificate quanti giorni restano davvero conservati, dimensionatelo ragionando a ritroso dal requisito, ed esportatelo o aggregatelo prima che venga sovrascritto.
  • Verificate il rischio di esposizione di segreti prima di abilitare la registrazione della riga di comando per il 4688. Dove viene registrato ciascun evento, e la sincronizzazione dell’orologio, sono premesse della correlazione tra macchine.
  • Iniziate un’indagine con i filtri del Visualizzatore eventi; passate a Get-WinEvent -FilterHashtable per ciò che si ripete; preservate con wevtutil epl. Non rompete l’ordine «prima preservare, poi analizzare».

Articoli correlati

Aree di consulenza correlate

KomuraSoft LLC si occupa di consulenza sui criteri di controllo e sulla progettazione dei log in ambienti Windows, di indagini su «quando, chi e cosa» basate sul registro eventi, e di analisi della causa radice dei problemi di autenticazione e controllo in cui incorrono le applicazioni aziendali. Si può partire anche dallo stadio «mi hanno detto di guardare i log, ma non so da dove cominciare».

Riferimenti

  1. Microsoft Learn, Advanced security auditing FAQ. Sulla differenza tra i criteri di controllo di base (le nove impostazioni sotto Criteri locali) e i criteri di controllo avanzati; sul fatto che abilitare una categoria di base equivale ad abilitare tutte le sottocategorie corrispondenti; sul fatto che i due sistemi sono incompatibili, e usarli insieme lascia i risultati di controllo in uno stato imprevedibile, quindi non vanno mescolati; sul fatto che applicare il lato avanzato via Criteri di gruppo azzera le impostazioni di controllo esistenti; sul bisogno di abilitare «Controllo: Forza le impostazioni di sottocategoria dei criteri di controllo in modo che prevalgano sulle impostazioni di categoria»; e sulla convenienza di minimizzare il volume di eventi individuando e delimitando risorse, attività e utenti che contano. ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, auditpol. Sul fatto che il comando auditpol può visualizzare (/get), impostare (/set), fare backup in CSV (/backup), ripristinare (/restore) e azzerare (/clear) i criteri di controllo di sistema. ↩ ↩2

  3. Microsoft Learn, System Audit Policy recommendations. Sulla tabella di valori default di Windows, raccomandazioni di baseline e raccomandazioni rafforzate suddivise per workstation e server; sul fatto che le raccomandazioni sono solo un punto di partenza, da rivedere e testare rispetto alle minacce e alla tolleranza al rischio di ciascuna organizzazione; sul fatto che la sottocategoria Accesso ha sia successo sia fallimento abilitati per default da Windows 10 1809 in poi; sull’importanza di monitorare le workstation tanto quanto i server; su esempi di eventi su cui allertare singolarmente, come aggiunte inattese di membri a gruppi privilegiati; e sul rilevare picchi di accessi non riusciti per confronto con una baseline. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Sul fatto che si può gestire il controllo in modo preciso su oltre 40 sottocategorie; sul fatto che lasciare questa impostazione abilitata è una best practice, con il valore default Enabled per client, server membri e DC; e sull’avvertenza che impostazioni che generano volumi enormi di eventi, come abilitare il controllo dei successi per l’intera sottocategoria di uso dei privilegi, rendono difficile trovare altre voci nel registro di sicurezza e possono influire in modo significativo sulle prestazioni. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, 4624(S): An account was successfully logged on. Sul fatto che 4624 viene registrato sulla macchina a cui si è acceduto al momento della creazione della sessione di accesso; sull’elenco dei tipi di accesso (2 = Interactive, 3 = Network, 4 = Batch, 5 = Service, 7 = Unlock, 8 = NetworkCleartext, 9 = NewCredentials, 10 = RemoteInteractive, 11 = CachedInteractive); sul flag Elevated Token; sul pacchetto di autenticazione (NTLM/Kerberos/Negotiate) e sul Package Name di NTLM (NTLM V1/V2/LM); e sulla correlazione via Logon ID con eventi come 4672. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, 4625(F): An account failed to log on. Sul fatto che 4625 viene registrato sul computer in cui è avvenuto il tentativo di accesso (per un tentativo sulla postazione di un utente, quella postazione); sul fatto che le sue sottocategorie sono Blocco account e Accesso; sul significato dei codici Status/Sub Status (0xC0000064 = nome utente errato, 0xC000006A = password errata, 0xC000006D = nome utente o informazioni di autenticazione errati, 0xC000006F = fuori dall’orario di accesso consentito, 0xC0000070 = workstation non consentita, 0xC0000072 = account disabilitato, 0xC000015B = tipo di accesso non consentito, 0xC0000193 = account scaduto, 0xC0000234 = bloccato); e sul fatto che occorrenze ripetute di 0xC0000064 possono indicare un attacco di enumerazione degli account. ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. Sul fatto che 4776 viene registrato per ogni convalida di credenziali eseguita per l’autenticazione NTLM; sul fatto che viene registrato solo sul computer che ha autorità sulla credenziale — il controller di dominio per un account di dominio, o il computer locale per un account locale; e sul fatto che vengono registrati sia il successo sia il fallimento. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, 4771(F): Kerberos pre-authentication failed. Sul fatto che 4771 viene registrato per ogni fallimento del KDC nell’emettere un TGT Kerberos (password errata, scadenza, ecc.); e sul fatto che questo evento viene generato solo sui controller di dominio. ↩ ↩2 ↩3 ↩4

  9. Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). Sul recuperare la configurazione del log (LogMode, MaximumSizeInBytes, RecordCount) via -ListLog; sul filtraggio efficiente via -FilterHashtable specificato come hashtable di LogName, Id, StartTime e così via; sulla lettura di un file .evtx salvato via -Path; e sul recuperare eventi dal più antico e per conteggio via -Oldest / -MaxEvents. ↩ ↩2 ↩3 ↩4

  10. Microsoft Learn, wevtutil. Sull’impostare dimensione massima (/ms) e modalità di conservazione (/rt) via set-log (sl); sul fatto che la modalità di conservazione true significa che gli eventi esistenti vengono conservati e i nuovi eventi vengono scartati una volta che il log è pieno, mentre false significa che i nuovi eventi sovrascrivono i più vecchi esistenti; sull’esportare un registro eventi in un file via export-log (epl), con l’opzione /q per restringere con una query XPath; e sull’eseguire una query via query-events (qe). ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4688(S): A new process has been created. Sul fatto che 4688 viene registrato per ogni avvio di un nuovo processo; sul fatto che include l’account creatore, il percorso dell’eseguibile del nuovo processo, il nome del processo creatore (padre) e il tipo di elevazione del token; e sul fatto che il campo Process Command Line è vuoto per default, e si popola solo una volta abilitata l’impostazione Criteri di gruppo «Includi riga di comando negli eventi di creazione processi». ↩ ↩2 ↩3

  12. Microsoft Learn, Command line process auditing. Sul fatto che la registrazione della riga di comando richiede sia il controllo della creazione di processi dei criteri di controllo avanzati sia «Includi riga di comando negli eventi di creazione processi» (Modelli amministrativi > Sistema > Controllo creazione processi, non configurata per default); sulla cautela che, una volta abilitata, le informazioni di riga di comando di ogni processo vengono registrate in chiaro nel registro eventi di sicurezza, e qualsiasi utente con accesso in lettura agli eventi di sicurezza sarebbe in grado di leggere gli argomenti della riga di comando di ogni processo creato con successo, che possono contenere informazioni sensibili come le password; e sul fatto che i criteri di controllo avanzati sovrascritti da impostazioni di base generano l’evento 4719, che l’impostazione «Forza» previene. ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Audit Account Lockout. Sul fatto che la sottocategoria Blocco account controlla i tentativi di accesso non riusciti contro un account attualmente bloccato; sul fatto che l’evento generato è 4625(F); sul fatto che questa sottocategoria non ha eventi di successo, quindi abilitare il controllo dei successi non serve; e sul fatto che il controllo dei fallimenti è raccomandato su tutti i tipi di computer. ↩

  14. Microsoft Learn, Audit Security Group Management. Sul fatto che questa sottocategoria controlla creazione, modifica ed eliminazione dei gruppi di sicurezza, e aggiunte e rimozioni di membri; sul fatto che gli ID evento di aggiunta/rimozione di membri differiscono per tipo di gruppo — 4732/4733 per i gruppi locali, 4728/4729 per i gruppi globali e 4756/4757 per i gruppi universali; sul fatto che esistono eventi dedicati ai gruppi di dominio come 4728; e sul fatto che questa sottocategoria non ha eventi di fallimento, quindi il controllo dei successi è raccomandato su tutti i tipi di computer. ↩ ↩2

  15. Microsoft Learn, 4698(S): A scheduled task was created. Sul fatto che 4698 viene registrato per ogni attività pianificata creata; sul fatto che la sua sottocategoria è Altri eventi di accesso agli oggetti; sul fatto che registra il nome dell’attività e l’XML completo della definizione dell’attività, incluso il comando da eseguire; e sul fatto che si raccomanda di monitorare gli eventi di creazione di attività, specialmente sulle macchine importanti, perché il malware usa di frequente le attività pianificate per persistere attraverso i riavvii. ↩ ↩2

  16. Microsoft Learn, 4740(S): A user account was locked out. Sul fatto che 4740 viene registrato per ogni blocco di un account utente; sul fatto che la sua sottocategoria è Gestione account utente; e sul fatto che il campo Caller Computer Name registra il nome del computer da cui è partito il tentativo di accesso che ha causato il blocco. ↩

  17. Microsoft Learn, 4720(S): A user account was created. Sul fatto che 4720 viene registrato su controller di dominio, server membri e workstation per ogni nuovo oggetto utente creato; e sul fatto che la sua sottocategoria è Gestione account utente. ↩

  18. Microsoft Learn, 1102(S): The audit log was cleared. Sul fatto che l’evento 1102 viene registrato per ogni svuotamento del registro di controllo di sicurezza di Windows. ↩

  19. Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. Sul fatto che, se questa impostazione è abilitata e i controlli di sicurezza non possono essere registrati, il sistema si ferma con il messaggio STOP C0000244 {Audit Failed}; sul fatto che il valore default è Disabled; sul fatto che può essere trasformata in un DoS attraverso la generazione deliberata di un grande volume di eventi di sicurezza per forzare un arresto; e sul rischio che i dati delle applicazioni diventino inutilizzabili a causa di un arresto improvviso. ↩ ↩2

  20. Microsoft Learn, Maximum tolerance for computer clock synchronization. Sul fatto che Kerberos v5 usa i timestamp come difesa contro gli attacchi di replay, ed è per questo che è impostata una tolleranza massima (5 minuti sia per default sia come raccomandazione) per lo sfasamento dell’orologio tra un client e un controller di dominio, oltre la quale un timestamp non è più considerato autentico. ↩

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Non abbiamo configurato nessun criterio di controllo, perché nel registro Security compaiono già 4624 e 4625?
Perché Windows ha sottocategorie di controllo abilitate per default. La sottocategoria «Accesso», per esempio, ha sia il controllo dei successi sia quello dei fallimenti abilitato per default da Windows 10 versione 1809, quindi 4624 (successo) e 4625 (fallimento) vengono registrati anche se non avete configurato nulla. Lasciando i default, però, molti degli eventi che servono davvero in un'indagine — la convalida delle credenziali (4776) o la creazione di processi (4688), per esempio — non vengono registrati. Potete verificare cosa è abilitato nel vostro ambiente con `auditpol /get /category:*`. Da lì, la prassi è abilitare esplicitamente le sottocategorie mancanti dal lato dei criteri di controllo avanzati.
Voglio indagare un accesso non riuscito, ma non trovo l'evento 4625 nel registro Security del server interessato. Dove devo guardare?
Confermate prima il principio di base: 4625 viene registrato sul «computer in cui è stato tentato l'accesso». Per un accesso non riuscito sulla postazione di un utente, è quella postazione; per un tentativo di accesso a un file server, è il file server. Poi, con `auditpol /get /category:*`, verificate se il controllo dei fallimenti è abilitato per la sottocategoria «Accesso». Per gli account di dominio, la traccia compare spesso invece nella convalida delle credenziali (4776) o nel fallimento della pre-autenticazione Kerberos (4771) sul controller di dominio, e quando non riuscite a individuare la postazione è spesso più rapido partire dal lato DC. Se ancora non trovate nulla, controllate se gli eventi più vecchi sono già stati sovrascritti (confrontate la dimensione massima del registro con la data dell'evento più antico).
Dovremmo abilitare la registrazione della riga di comando per la creazione di processi (4688)?
Ha un valore investigativo molto alto, ma è un'impostazione da abilitare solo dopo aver capito il rischio. Una volta abilitata, gli argomenti della riga di comando di ogni processo vengono registrati in chiaro nel registro Security. Se anche un solo script o un'applicazione aziendale passa una password o una chiave API come argomento, quel segreto diventa visibile a chiunque possa leggere il registro Security. Microsoft stessa documenta esplicitamente questa cautela. L'ordine consigliato è verificare prima se i vostri script passano segreti come argomenti della riga di comando, correggere quelli che lo fanno, e solo allora abilitare l'impostazione.
Quanto grande dovrebbe essere la dimensione massima del registro Security?
L'approccio corretto è ragionare a ritroso da «quanti giorni vogliamo tenere a disposizione», non scegliere un numero valido per tutti. Potete controllare l'impostazione attuale e come si sta comportando in pratica con `Get-WinEvent -ListLog Security`; la differenza tra la data dell'evento più antico e l'ora attuale è «quanti giorni vengono davvero conservati adesso». Aggiungere sottocategorie di controllo aumenta il volume di eventi, quindi ricontrollate sempre questo intervallo reale di conservazione dopo un cambio di impostazioni. Nella risposta agli incidenti non è raro aver bisogno di log di settimane o mesi prima, quindi è rassicurante o esportare il registro periodicamente prima che venga sovrascritto, o aggregarlo su un'altra macchina con un meccanismo di raccolta.
Come si indaga la causa di un blocco account (4740)?
Il primo indizio è il campo «Nome computer chiamante (Caller Computer Name)» dell'evento 4740. Registra il computer da cui è partito il tentativo di accesso non riuscito che ha innescato il blocco. Attenzione, però: il record del fallimento in sé (4625) resta sul lato che ha ricevuto il tentativo di accesso, non sulla macchina di origine. Se proviene da un accesso di rete, seguitelo in ordine cronologico nel 4625 del server di destinazione o, per un account di dominio, nel 4776/4771 del controller di dominio. Una volta identificata la macchina di origine, cercatevi tutto ciò che tiene ancora credenziali vecchie da prima del cambio password: credenziali salvate, una sessione Desktop remoto disconnessa e lasciata appesa, o un servizio o un'attività pianificata configurati con la password vecchia. Se i blocchi si ripetono, controllate anche se la sincronizzazione dell'orologio è andata fuori fase.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Contattaci
Torna al blog