Guide pratiche
Event ID di Windows da monitorare: la lista corta di un SOC
Microsoft classifica a bassa criticità gli eventi da cui nasce quasi tutto il lavoro di un SOC. La lista corta che raccogliamo, con il valore predefinito di ogni criterio di audit verificato sulla documentazione, e il rumore che copre l'unica riga che conta.
In breve
Contano una ventina di Event ID del registro Sicurezza di Windows, letti in correlazione. Accessi (4624, 4625, 4648, 4672), Kerberos sui domain controller (4768, 4769, 4771), account e gruppi (4720, 4726, 4740, 4728, 4732, 4756), esecuzione (4688, 4697, 4698, 4104), manomissione (1102, 4719, 4616). Alcuni, tra cui il 4688 e il 4769, dipendono da sottocategorie di audit che nascono non configurate.
Il registro Sicurezza di Windows è la fonte più ricca che un SIEM riceve da una rete aziendale. In ogni onboarding fatto finora, abbiamo trovato la stessa situazione: acceso quello che Windows accende da solo, spento tutto il resto. Di hardening, nessuna traccia.
Il punto di partenza per decidere cosa raccogliere è la documentazione di chi ha scritto il sistema operativo. Microsoft pubblica l'elenco degli eventi da monitorare in un'appendice della guida alla sicurezza di Active Directory, Appendix L, aggiornata a maggio 2025, con tre livelli di criticità. Alta significa che una sola occorrenza va investigata. Media e bassa significano che l'evento conta soltanto se compare in numero anomalo oppure correlato ad altri.
La tabella Microsoft e la lettura che ne facciamo
Nella colonna della criticità alta stanno eventi come il 4765 e il 4766, che registrano l'aggiunta di SID History a un account, il 4794, che segnala un tentativo di impostare la modalità di ripristino della directory, il 4964, che scatta all'accesso di un membro di un gruppo speciale. Sono i segni di una compromissione del dominio già avanzata. In una rete di cinquanta postazioni possono passare anni prima che ne compaia uno.
Nella colonna della criticità bassa stanno il 4624, il 4625, il 4648, il 4672, il 4688, il 4720, il 4732 e il 4769. Presi uno per uno valgono poco e per questo stanno in basso. Presi insieme, sulla stessa macchina e nella stessa mezz'ora, raccontano quasi tutte le intrusioni che abbiamo gestito. Un accesso di tipo 10 da un indirizzo mai visto, i privilegi speciali assegnati a quella sessione, un processo avviato con una riga di comando codificata in base64, un'attività pianificata creata un minuto dopo. Quattro righe a criticità bassa, che lette in sequenza descrivono un'intrusione in corso.
La tabella Microsoft dice la stessa cosa, quando definisce la criticità bassa come rilevante soltanto in correlazione. La differenza sta in quale correlazione si cerca. La documentazione suggerisce di legare gli eventi bassi a quelli medi e alti. Nelle reti delle PMI quelle due colonne restano quasi sempre vuote per mesi, quindi la correlazione che paga è tra eventi bassi, letta sulla stessa macchina in una finestra di pochi minuti. La colonna alta resta in allarme immediato, con il 4719 e il 1102 accanto, perché quando uno di quegli eventi compare la correlazione non serve più.
Gli eventi che raccogliamo
Ogni evento è verificato sulla pagina di documentazione Microsoft che lo descrive. Il campo che conta è quello che guardiamo per primo, perché separa una riga da tenere da una da scartare. La colonna Audit predefinito dice se quell'evento viene scritto da un Windows appena installato, secondo la stessa documentazione.
| Event ID | Ambito | Cosa registra | Il campo che conta | Audit predefinito |
|---|---|---|---|---|
| 4624 | Accessi | Accesso riuscito | Logon Type (2 console, 3 rete, 10 desktop remoto, 11 credenziali in cache) con l'indirizzo di origine | Sì |
| 4625 | Accessi | Accesso fallito | Codice di stato e origine, contati per finestra di tempo | Sì, sui client dalla versione 1809 di Windows 10 |
| 4648 | Accessi | Accesso con credenziali esplicite | Account usato e processo chiamante, tipico del runas e dei movimenti laterali | Sì |
| 4672 | Accessi | Privilegi speciali assegnati alla sessione | Chi entra con diritti amministrativi e da dove | Sì |
| 4776 | Accessi | Convalida di credenziali NTLM | NTLM dove ci si aspetterebbe Kerberos | Solo server |
| 4768 | Kerberos, solo domain controller | Richiesta di TGT | Account e indirizzo del client | Sì sui server |
| 4769 | Kerberos, solo domain controller | Richiesta di ticket di servizio | Tipo di cifratura 0x17 (RC4) su un account di servizio, dove ci si aspetta 0x11 oppure 0x12 (AES) | No |
| 4771 | Kerberos, solo domain controller | Pre-autenticazione fallita | Raffiche sullo stesso account | Sì sui server |
| 4720, 4726 | Account e gruppi | Account creato, account eliminato | Orario e account che esegue l'operazione | Sì |
| 4740 | Account e gruppi | Account bloccato | Postazione da cui arriva il blocco | Sì |
| 4728, 4732, 4756 | Account e gruppi | Membro aggiunto a un gruppo di sicurezza globale, locale oppure universale | I gruppi amministrativi in particolare | Sì |
| 4688 | Esecuzione e persistenza | Processo creato | Riga di comando (se il criterio è acceso) e processo padre | No |
| 4697 | Esecuzione e persistenza | Servizio installato | Percorso del binario e account di esecuzione | No |
| 4698 | Esecuzione e persistenza | Attività pianificata creata | Comando e account | - |
| 4104 | Esecuzione e persistenza | Blocco di script PowerShell, registro Microsoft-Windows-PowerShell/Operational | Testo dello script e presenza di codifica base64 | - |
| 1102 | Manomissione della traccia | Registro di audit svuotato | Ogni occorrenza | Sempre |
| 4719 | Manomissione della traccia | Criterio di audit modificato | Ogni occorrenza | Sempre |
| 4616 | Manomissione della traccia | Ora di sistema modificata | Salti superiori a pochi secondi | Sempre |
| 6416 | Periferiche | Periferica collegata o rimossa | Chiavette e dischi esterni sulle postazioni | - |
| 4663 | Periferiche | Accesso ai file di un supporto rimovibile | Chiavette e dischi esterni sulle postazioni | - |
Nella colonna Audit predefinito, Sì significa che la sottocategoria da cui l'evento dipende è attiva nell'installazione standard, No che nasce non configurata e l'evento non viene scritto finché non si accende, Solo server che è attiva sulle edizioni server e spenta sulle client, Sempre che l'evento viene scritto a prescindere dal criterio. Il trattino segnala che la documentazione consultata non dichiara il valore predefinito; per i supporti rimovibili dichiara soltanto che, finché il criterio non è configurato, nessun evento viene scritto.
Il 4769 merita una nota, perché è l'evento con più falsi allarmi della lista. La documentazione stessa avverte che i fallimenti con codice 0x20 indicano un ticket scaduto e hanno rilevanza quasi nulla. Il segnale sta nel tipo di cifratura richiesto; Microsoft indica di monitorare tutto ciò che si discosta da 0x11 e 0x12.
Il doppio criterio del 4688
È il caso che in onboarding pesa di più, perché l'evento dipende da due criteri distinti. Audit Process Creation, che lo genera, è "Not configured". Il campo della riga di comando dipende da un secondo criterio, "Include command line in process creation events", anch'esso non configurato. Servono entrambi. Con il primo acceso e il secondo spento, il 4688 arriva, ma con il campo del comando vuoto.
La documentazione della riga di comando riporta anche un avvertimento. Con quel criterio acceso, gli argomenti di ogni processo finiscono nel registro Sicurezza in testo leggibile, password comprese, se qualcuno le passa da riga di comando. Chi ha accesso in lettura al registro le legge. È un motivo in più per tenere quei registri in un archivio con accessi tracciati.
Fuori tabella resta una sottocategoria che nasce senza audit e che conosciamo bene, Audit Other Logon/Logoff Events, con il 4800 e il 4801 del blocco e dello sblocco della postazione. Sono gli eventi con cui abbiamo ricostruito la sequenza nel caso della frode via email e su una postazione appena installata mancano.
Il rumore e la riga sepolta
L'evento più frequente che riceviamo dalle postazioni viene dai moduli di protezione avanzata degli antivirus. Terminano un processo, scrivono un errore, lo terminano di nuovo un minuto dopo e scrivono un altro errore, per giorni. Righe lunghe, dettagliate, ripetute, che dopo la prima aggiungono zero informazione.
Il registro Sicurezza che gira su se stesso lo vediamo di rado. Quando succede, il registro si è riempito di righe come quelle sopra fino a raggiungere la dimensione massima; l'unica riga che conta, magari un 4698 con un comando dentro, sta in mezzo a migliaia di righe identiche. Su quella macchina la riga resta per qualche ora, poi la rotazione la cancella. Un sistema che indicizza i campi e conserva una copia fuori dalla macchina la ritrova anche in mezzo al rumore. È il motivo per cui il nostro agente per Windows spedisce gli eventi appena scritti, prima che il registro locale abbia il tempo di girare.
Cosa chiede la norma e cosa scegliamo noi
Il provvedimento del Garante del 27 novembre 2008 chiede di registrare gli accessi degli amministratori di sistema e di conservarli con completezza, inalterabilità e possibilità di verifica dell'integrità. Nessun Event ID compare nel testo. Il provvedimento indica il risultato e lascia aperta la strada per arrivarci. La lista è la strada che abbiamo scelto. La ragione pratica è che copre apertura di sessione, uso dei privilegi, esecuzione e manomissione della traccia con eventi nativi del sistema operativo.
C'è un secondo confine e riguarda i lavoratori. L'audit acceso per la sicurezza della rete non deve diventare un controllo dell'attività lavorativa. Per questo ci fermiamo prima delle sottocategorie che registrerebbero ogni documento aperto da ogni utente. Il confine tra le due cose, con quello che l'articolo 4 dello Statuto dei lavoratori chiede all'azienda, merita un articolo a sé.
Un pomeriggio di lavoro e nessun acquisto
Tutti i criteri elencati qui si accendono con un oggetto Criteri di gruppo. Un sistemista attento lo fa in un pomeriggio. Con il registro configurato così trova la riga anche a mano, finché il volume glielo permette.
Ci è capitato più volte di dover leggere il comando lanciato su una macchina e di trovare un 4688 con il campo della riga di comando vuoto. Il criterio era spento e l'evento, scritto senza quel campo, resta così per sempre. Il caso che vediamo più spesso è un altro. Server consegnati chiavi in mano con il sistema operativo com'è uscito dall'installazione e domain controller dove l'audit Kerberos non è mai stato acceso, spesso da anni, perché l'hardening non stava nel preventivo di nessuno.
Da fare entro oggi
Apri un prompt amministrativo su un domain controller e su una postazione qualunque e lancia auditpol /get /category:*. Confronta il risultato con la colonna Audit predefinito. Poi, con un oggetto Criteri di gruppo:
- Accendi Audit Process Creation e il criterio "Include command line in process creation events", entrambi.
- Sui domain controller accendi Audit Kerberos Service Ticket Operations, con successo e fallimento. Il volume è alto e va misurato prima di alzare allarmi.
- Accendi Audit Security System Extension per i servizi installati e Audit Other Object Access Events per le attività pianificate.
- Attiva "Turn on PowerShell Script Block Logging".
- Se ti servono blocco e sblocco della postazione, accendi Audit Other Logon/Logoff Events.
- Configura Audit Removable Storage sulle postazioni dove le chiavette sono un rischio.
- Porta gli eventi fuori dalle macchine appena scritti. Allargare il registro Sicurezza rimanda la rotazione di qualche ora e lascia il rumore dov'è.
- Avvisa il titolare che l'audit è cambiato, perché l'informativa ai lavoratori potrebbe doverlo recepire.
Se dopo una settimana il registro Sicurezza delle postazioni è pieno di righe degli stessi due o tre moduli di protezione, hai trovato il rumore. Il filtro si costruisce da lì, un modulo alla volta.