I log degli eventi di Windows e gli Event ID più usati da chi difende

#Cosa sono i log degli eventi di Windows

Windows tiene un registro continuo di quello che succede sulla macchina: servizi che partono, programmi che vanno in crash, persone che accedono. Ogni voce è un evento. Ogni evento ha un timestamp, un provider (il componente che l'ha scritto), un Event ID numerico, un livello e una serie di campi che dipendono dal tipo di evento. Gli eventi sono raggruppati in log, chiamati anche canali, e salvati come file .evtx in %SystemRoot%\System32\Winevt\Logs.

All'inizio contano soprattutto tre log:

• Application contiene gli eventi scritti dai programmi e da alcuni componenti di Windows. Un'app che va in crash o un aggiornamento fallito di solito finiscono qui.
• System contiene gli eventi di Windows stesso e dei driver: servizi che partono e si fermano, il servizio di log degli eventi che parte all'avvio (Event ID 6005), errori dei driver.
• Security contiene gli eventi di audit: logon, logoff, uso di privilegi sensibili, creazione di processi, modifiche ad account e policy. La maggior parte dell'articolo parla di questo log, ed è l'unico dei tre che un utente normale non può aprire.

La differenza di accesso si vede da PowerShell. Sulla macchina usata per questo articolo (Windows 11, Windows PowerShell 5.1), questo comando è stato eseguito in una shell senza diritti di amministratore:

Get-WinEvent -ListLog System,Application | Format-Table LogName,RecordCount,IsEnabled -Auto

LogName     RecordCount IsEnabled
-------     ----------- ---------
System            36196      True
Application       19965      True

Aggiungendo Security allo stesso comando è comparso un errore per quel log: Windows non è riuscito a recuperarne le informazioni perché l'operazione non era autorizzata. I tuoi conteggi saranno diversi.

#Perché conta

Molti rilevamenti su Windows si basano sul log Security. Una regola SIEM per i tentativi di indovinare le password conta gli eventi 4625. Una regola per una sessione amministrativa sospetta guarda insieme 4624 e 4672. Una regola per la manomissione dei log cerca gli eventi 1102. L'articolo sul SIEM del Manuale da campo ha spiegato come funzionano queste regole. Leggere gli eventi a mano su una macchina ti permette di controllare se le ipotesi di una regola valgono sui tuoi sistemi.

Il log Security contiene solo quello che la policy di audit dice a Windows di registrare. Se la policy non prevede l'audit dei logon falliti, Windows non scrive eventi 4625 e una regola che li conta non scatta mai. Dal SIEM non si distingue da una macchina tranquilla. Per questo si controlla la policy di audit prima di leggere il log.

#Come funziona l'audit

#La policy di audit decide cosa esiste

Windows raggruppa le impostazioni di audit in categorie, e ogni categoria in sottocategorie. Ogni sottocategoria può registrare i successi, i fallimenti, entrambi o niente. Le categorie sono Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use e System.

La categoria Logon/Logoff contiene le sottocategorie da cui nasce la maggior parte degli eventi di questo articolo: Logon (4624 e 4625), Logoff (4634), Account Lockout (che Microsoft elenca anche per 4625) e Special Logon (4672). La creazione di processi, evento 4688, appartiene alla sottocategoria Process Creation sotto Detailed Tracking.

auditpol è lo strumento integrato per leggere la policy. auditpol /list stampa i nomi di categorie e sottocategorie e funziona in una shell normale. auditpol /get legge le impostazioni reali. La documentazione di riferimento di Microsoft dice che serve il permesso Read sulla policy oppure il diritto "Manage auditing and security log" (SeSecurityPrivilege), e una shell normale senza privilegi elevati non ha né l'uno né l'altro.

auditpol /list /category /v

Sulla macchina usata per questo articolo, con Windows in portoghese, il comando è andato a buon fine senza privilegi elevati e ha stampato ogni categoria con un nome tradotto e un GUID. Logon/Logoff aveva il GUID {69979849-797A-11D9-BED3-505054503030}. Il nome inglese lì funzionava ancora con auditpol /list /subcategory:"Logon/Logoff", che ha elencato dodici sottocategorie. Se il tuo sistema rifiuta un nome, passa il GUID.

#Gli Event ID che userai di più

#4624 e 4625: i logon

Entrambi gli eventi vengono scritti sul computer dove è avvenuto il logon. Se qualcuno digita una password sbagliata sul tuo portatile, il 4625 finisce nel log Security del tuo portatile. I due eventi hanno quasi tutti i campi in comune:

• Subject è l'account che ha segnalato il logon, spesso il computer stesso o SYSTEM.
• Logon Type dice come è avvenuto il logon. I valori comuni sono 2 (Interactive, alla tastiera), 3 (Network, per esempio una condivisione di file), 4 (Batch), 5 (Service), 7 (Unlock), 10 (RemoteInteractive, Remote Desktop) e 11 (CachedInteractive, credenziali di dominio memorizzate sulla macchina).
• New Logon (in 4624) o Account For Which Logon Failed (in 4625) è l'account che sta accedendo, con Security ID, nome e dominio. In 4624 questa sezione riporta anche il Logon ID della nuova sessione.
• Failure Information (solo 4625) ha un codice Status e un codice Sub Status. La pagina di Microsoft elenca quelli da tenere d'occhio: 0xC000006A per una password errata, 0xC0000064 per un nome utente che non esiste, 0xC000006D per un nome utente errato o informazioni di autenticazione errate, 0xC0000072 per un account disabilitato. La stessa pagina indica 0xC0000234, "Account locked out", come stato tipico quando l'errore viene da un account bloccato. Diversi errori 0xC0000064 di seguito possono indicare che qualcuno sta enumerando i nomi utente.
• Process Information mostra il processo che ha tentato il logon, e Network Information riporta il nome della workstation, l'indirizzo di origine e la porta di origine. 127.0.0.1 o ::1 significano localhost, e la porta è 0 per i logon interattivi.

Da Windows 10 in poi, 4624 riporta anche Elevated Token, che dice se la sessione ha privilegi di amministratore.

#4634: il logoff, e perché conta il Logon ID

4634 dice che una sessione di logon è terminata. Da solo racconta poco. Il suo valore sta nel Logon ID: lo stesso valore esadecimale compare nel 4624 che ha aperto la sessione, in ogni 4672 di quella sessione, negli eventi 4688 dei processi avviati dalla sessione e nel 4634 che l'ha chiusa. Seguendo un Logon ID attraverso il log ricostruisci una sessione dall'inizio alla fine. Microsoft precisa che i Logon ID sono univoci solo tra un riavvio e l'altro sullo stesso computer, quindi abbina sempre l'ID a un intervallo di tempo.

#4672: privilegi speciali

Windows scrive 4672 quando un nuovo logon riceve uno dei privilegi sensibili di un elenco, come SeDebugPrivilege (debug dei programmi), SeBackupPrivilege (backup di file e directory) o SeTcbPrivilege (agire come parte del sistema operativo).

Ogni logon di SYSTEM genera un 4672, quindi il log ne contiene molti. Microsoft consiglia di guardare quelli in cui l'account non è LOCAL SYSTEM, NETWORK SERVICE o LOCAL SERVICE, e non è un amministratore che ti aspetti abbia quei privilegi.

#4688: creazione di processi

4688 viene scritto ogni volta che parte un nuovo processo, se la sottocategoria Process Creation è sotto audit. Registra il nome del nuovo processo, il nome del processo creatore (il padre), l'account, il Token Elevation Type (se il processo è stato eseguito con un token completo, elevato o limitato) e il livello di integrità.

Ha anche un campo Process Command Line, vuoto per impostazione predefinita. La pagina di Microsoft dice che viene riempito solo quando è attiva l'impostazione di Group Policy "Administrative Templates\System\Audit Process Creation\Include command line in process creation events". Senza, sai che powershell.exe è partito ma non cosa gli è stato chiesto di fare.

#1102: il log è stato cancellato

1102 significa che qualcuno ha cancellato il log Security. Lo scrive il provider Microsoft-Windows-Eventlog, e l'evento riporta l'account che l'ha cancellato. L'indicazione di Microsoft è breve: di norma questo evento non dovrebbe comparire, raramente c'è un motivo per cancellare a mano il log Security e ogni occorrenza merita un'indagine.

#Cosa aggiunge Sysmon

Sysmon (System Monitor) è uno strumento Sysinternals pubblicato da Microsoft. Si installa come servizio e driver, resta attivo anche dopo i riavvii e scrive i propri eventi in Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. Va scaricato a parte, non fa parte di un'installazione predefinita di Windows, e Microsoft indica come supportati Windows 11 e Windows Server 2019 o successivi.

Rispetto al log Security integrato, Sysmon dà più dettagli su attività che altrimenti vedresti solo in parte:

• L'Event ID 1, creazione di processi, include la riga di comando completa, gli hash del file (SHA1 per impostazione predefinita, con MD5, SHA256 e IMPHASH disponibili) e un ProcessGuid che resta univoco anche quando Windows riusa gli ID di processo.
• L'Event ID 3 registra le connessioni di rete con il processo dietro ciascuna. È disattivato per impostazione predefinita.
• Altri ID coprono la creazione di file (11), le query DNS (22), le modifiche al registro, le named pipe, le sottoscrizioni WMI e un processo che ne apre un altro, come lsass.exe (10).

Un file di configurazione XML decide quali eventi Sysmon include o esclude. Microsoft dichiara che Sysmon non analizza i propri eventi e non cerca di nascondersi agli attaccanti. A leggerli ci pensa un SIEM o un analista.

Installare Sysmon modifica il sistema, quindi il lab di questo articolo non lo fa.

#Prova pratica: trova il tuo logon fallito

Creerai un logon fallito sul tuo computer, con il tuo account, e lo troverai in tre modi. Non cambiare la policy di audit durante questo lab. Se risulta che la policy non registra i logon falliti, quel risultato è la lezione: annotalo e fermati lì.

#Passo 1: apri una PowerShell con privilegi elevati

Fai clic destro su Windows PowerShell o Terminal e scegli Run as administrator. Controlla che la shell abbia davvero i privilegi elevati:

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

True significa che puoi leggere il log Security. Sulla macchina usata per questo articolo, la shell disponibile ha restituito False. I comandi qui sotto sono stati eseguiti lì lo stesso e gli errori sono riportati così come sono comparsi, perché è utile conoscerli. Dove ci sarebbe l'output con privilegi elevati, l'articolo descrive i campi da cercare, in base alla documentazione di Microsoft.

#Passo 2: controlla la policy di audit

auditpol /get /category:"Logon/Logoff"

In una shell con privilegi elevati stampa ogni sottocategoria con la sua impostazione. Trova la riga Logon. Per questo lab deve includere Failure, quindi "Success and Failure" oppure "Failure". Se dice "No Auditing", Windows non scriverà 4625 e il resto del lab non troverà niente.

Senza privilegi elevati, sulla macchina usata per questo articolo, il comando ha stampato l'errore 0x00000522 con un messaggio secondo cui il client non possiede un privilegio richiesto, ed è uscito con codice 1314.

#Passo 3: genera l'evento

Premi Win+L per bloccare lo schermo. Digita una password sbagliata una volta, poi accedi con quella giusta. Annota l'ora.

Usa la password, non un PIN. Se di solito usi Windows Hello, scegli l'opzione password nella schermata di accesso. Questo articolo non ha provato cosa produce un PIN sbagliato.

#Passo 4: trova il logon fallito con Get-WinEvent

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

-FilterHashtable applica il filtro mentre gli eventi vengono letti, cosa che la documentazione di Microsoft descrive come più efficiente del passare tutto a Where-Object. -MaxEvents 5 tiene le cinque corrispondenze più recenti, perché Get-WinEvent restituisce prima le più nuove.

In una shell con privilegi elevati, il primo risultato dovrebbe riportare l'ora che hai annotato. Nel suo Message, controlla:

• Logon Type. L'esempio di 4625 di Microsoft è un logon interattivo, tipo 2, con il processo chiamante C:\Windows\System32\winlogon.exe.
• Account For Which Logon Failed, che dovrebbe essere il tuo account.
• Status e Sub Status. Per una password sbagliata, cerca 0xC000006A in uno dei due.
• Source Network Address e Source Port. Per un logon alla tua tastiera, aspettati un valore locale come 127.0.0.1 e la porta 0, come nell'esempio di Microsoft.

Senza privilegi elevati, questo stesso comando ti inganna. Sulla macchina usata per questo articolo non ha segnalato un problema di permessi. Ha stampato l'errore secondo cui nessun evento corrispondeva ai criteri di selezione. Un semplice Get-WinEvent -LogName Security -MaxEvents 1 nella stessa shell ha riportato la causa reale, un'operazione non autorizzata. Se da una shell senza privilegi elevati vedi "no events found", controlla i privilegi prima di concludere che il log è vuoto.

#Passo 5: trova il logon riuscito

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 | Select-Object TimeCreated, Id

Dovresti vedere un 4624 pochi secondi dopo il tuo 4625, con altri eventi 4624 attorno, perché i servizi e il sistema fanno logon di continuo. Apri il messaggio completo di quello più vicino alla tua ora e controlla il Logon Type e il nome dell'account. Aggiungendo StartTime=(Get-Date).AddMinutes(-15) alla hashtable limiti la ricerca agli ultimi quindici minuti.

Una password sbagliata seguita da quella giusta dallo stesso account, alla tastiera, a pochi secondi di distanza, è un errore di battitura. Lo stesso errore ripetuto su molti account da un solo indirizzo di rete fa pensare a tentativi di indovinare le password, e le regole di rilevamento sono scritte per distinguere questi due casi.

#Passo 6: la stessa ricerca con wevtutil

wevtutil qe Security /c:5 /rd:true /f:text /q:"*[System[(EventID=4625)]]"

wevtutil è il vecchio strumento a riga di comando per i log degli eventi. qe interroga gli eventi, /c:5 limita il numero, /rd:true legge prima i più recenti, /f:text stampa testo invece di XML e /q accetta un filtro XPath. Con privilegi elevati ottieni gli stessi eventi del passo 4. Togli /f:text per vedere l'XML grezzo, con i nomi dei campi usati dalle regole di rilevamento, come TargetUserName, Status e LogonType. Su Windows in un'altra lingua il testo del messaggio è tradotto, mentre i nomi dei campi nell'XML restano in inglese.

Senza privilegi elevati, sulla macchina usata per questo articolo, ha stampato che non è riuscito ad aprire la query sugli eventi perché l'accesso è stato negato, ed è uscito con codice 5.

#Passo 7: guardalo in Event Viewer

Esegui eventvwr.msc. Se ti viene chiesto, consenti l'esecuzione come amministratore. Vai in Windows Logs > Security, scegli Filter Current Log e inserisci 4625 nella casella degli Event ID. Apri l'evento. La scheda General mostra lo stesso messaggio che hai letto in PowerShell. La scheda Details, nella vista XML, mostra i nomi grezzi dei campi. Tieni aperto questo evento: l'articolo su Sigma lo confronta con una regola.

#Errori comuni

• Fidarsi di "no events found" da una shell normale. Come ha mostrato il passo 4, una query Get-WinEvent -FilterHashtable sul log Security senza privilegi elevati può riportare zero corrispondenze invece di accesso negato.
• Dare per scontato che un evento esista senza controllare la policy. Senza impostazione di audit non c'è evento. Lo stesso vale per i campi: la riga di comando di 4688 resta vuota finché una policy separata non la attiva.
• Leggere un evento isolato. Un singolo 4625 significa poco. Guarda il 4624 che segue, il Logon ID e l'intervallo di tempo.
• Cancellare il log dopo un lab per fare ordine. Distruggi le prove che hai appena creato e generi un 1102 su cui qualcuno potrebbe dover indagare.
• Dimenticare che i log si sovrascrivono. Sulla macchina usata per questo articolo, Get-WinEvent -ListLog Application ha mostrato una dimensione massima di 20971520 byte in modalità Circular: quando il log si riempie, gli eventi vecchi vengono sovrascritti. Controlla il log Security allo stesso modo, con privilegi elevati, prima di contare sugli eventi del mese scorso.

#Per andare oltre

• Leggi la pagina Microsoft di ogni evento di questo articolo. Ognuna si chiude con raccomandazioni per il monitoraggio della sicurezza che sono quasi idee di rilevamento già pronte.
• Prepara una macchina virtuale in un home lab legale, installaci Sysmon con un file di configurazione, esegui qualche comando e confronta l'evento 1 di Sysmon con il 4688 dello stesso processo.
• Trasforma l'evento che hai trovato in un rilevamento: l'articolo successivo, scrivere la tua prima regola Sigma, costruisce e prova una regola proprio per questo 4625.

#Fonti

• Microsoft Learn, 4625(F) An account failed to log on
• Microsoft Learn, 4624(S) An account was successfully logged on
• Microsoft Learn, 4634(S) An account was logged off
• Microsoft Learn, 4672(S) Special privileges assigned to new logon
• Microsoft Learn, 4688(S) A new process has been created
• Microsoft Learn, 1102(S) The audit log was cleared
• Microsoft Learn, Get-WinEvent
• Microsoft Learn, Sysmon
• Microsoft Learn, auditpol get
• Microsoft Learn, wevtutil