La postazione di lavoro dell'utente è il punto più vulnerabile dell'infrastruttura in termini di sicurezza delle informazioni. Gli utenti potrebbero ricevere una lettera al proprio indirizzo e-mail di lavoro che sembra provenire da una fonte sicura, ma con un collegamento a un sito infetto. Forse qualcuno scaricherà un'utilità utile per lavorare da una posizione sconosciuta. Sì, puoi inventare decine di casi in cui il malware può infiltrarsi nelle risorse aziendali interne attraverso gli utenti. Le postazioni di lavoro richiedono quindi maggiore attenzione, e in questo articolo vi diremo dove e quali eventi intraprendere per monitorare gli attacchi.
Per rilevare un attacco nella fase più precoce possibile, Windows dispone di tre utili origini eventi: il registro eventi di sicurezza, il registro di monitoraggio del sistema e i registri di Power Shell.
Registro eventi di sicurezza
Questa è la posizione di archiviazione principale per i registri di sicurezza del sistema. Ciò include eventi di accesso/disconnessione dell'utente, accesso agli oggetti, modifiche alle policy e altre attività relative alla sicurezza. Naturalmente, se è configurata la politica appropriata.
Enumerazione di utenti e gruppi (eventi 4798 e 4799). All'inizio di un attacco, il malware spesso cerca negli account utente locali e nei gruppi locali su una workstation per trovare le credenziali per i suoi loschi affari. Questi eventi aiuteranno a rilevare il codice dannoso prima che si diffonda e, utilizzando i dati raccolti, si diffonda ad altri sistemi.
Creazione di un account locale e cambiamenti nei gruppi locali (eventi 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 e 5377). L'attacco può anche iniziare, ad esempio, aggiungendo un nuovo utente al gruppo degli amministratori locali.
Tentativi di accesso con un account locale (evento 4624). Gli utenti rispettabili accedono con un account di dominio e identificare un accesso con un account locale può significare l'inizio di un attacco. L'evento 4624 include anche gli accessi con un account di dominio, pertanto durante l'elaborazione degli eventi è necessario filtrare gli eventi in cui il dominio è diverso dal nome della workstation.
Un tentativo di accesso con l'account specificato (evento 4648). Ciò accade quando il processo viene eseguito in modalità "esegui come". Ciò non dovrebbe accadere durante il normale funzionamento dei sistemi, quindi tali eventi devono essere controllati.
Blocco/sblocco della workstation (eventi 4800-4803). La categoria degli eventi sospetti comprende qualsiasi azione avvenuta su una postazione di lavoro bloccata.
Modifiche alla configurazione del firewall (eventi 4944-4958). Ovviamente, quando si installa un nuovo software, le impostazioni di configurazione del firewall potrebbero cambiare, causando falsi positivi. Nella maggior parte dei casi, non è necessario controllare tali cambiamenti, ma sicuramente non farà male conoscerli.
Collegamento di dispositivi Plug'n'play (evento 6416 e solo per Windows 10). È importante tenerlo d’occhio se gli utenti solitamente non collegano nuovi dispositivi alla workstation, ma all’improvviso lo fanno.
Windows include 9 categorie di controllo e 50 sottocategorie per la messa a punto. L'insieme minimo di sottocategorie che dovrebbero essere abilitate nelle impostazioni:
Accesso / Fine sessione
- Accedere;
- Disconnettersi;
- Blocco dell'account;
- Altri eventi di accesso/disconnessione.
Gestione account
- Gestione dell'account utente;
- Gestione del gruppo di sicurezza.
Modifica della politica
- Modifica della politica di audit;
- Modifica della politica di autenticazione;
- Modifica della politica di autorizzazione.
Monitor di sistema (Sysmon)
Sysmon è un'utilità integrata in Windows in grado di registrare eventi nel registro di sistema. Di solito è necessario installarlo separatamente.
Questi stessi eventi possono, in linea di principio, essere trovati nel registro di sicurezza (abilitando la politica di controllo desiderata), ma Sysmon fornisce maggiori dettagli. Quali eventi possono essere prelevati da Sysmon?
Creazione del processo (ID evento 1). Il registro eventi di sicurezza del sistema può anche dirti quando è stato avviato un file *.exe e persino mostrarne il nome e il percorso di avvio. Ma a differenza di Sysmon, non sarà in grado di mostrare l'hash dell'applicazione. Il software dannoso può anche essere chiamato innocuo notepad.exe, ma è l'hash che lo porterà alla luce.
Connessioni di rete (ID evento 3). Ovviamente le connessioni di rete sono tantissime ed è impossibile tenerne traccia tutte. Ma è importante considerare che Sysmon, a differenza di Security Log, può associare una connessione di rete ai campi ProcessID e ProcessGUID e mostra la porta e gli indirizzi IP di origine e destinazione.
Modifiche nel registro di sistema (ID evento 12-14). Il modo più semplice per aggiungerti all'esecuzione automatica è registrarti nel registro. Security Log può farlo, ma Sysmon mostra chi ha apportato le modifiche, quando, da dove, l'ID del processo e il valore della chiave precedente.
Creazione del file (ID evento 11). Sysmon, a differenza di Security Log, mostrerà non solo la posizione del file, ma anche il suo nome. È chiaro che non puoi tenere traccia di tutto, ma puoi controllare determinate directory.
E ora cosa non è nelle policy del Security Log, ma è in Sysmon:
Modifica dell'ora di creazione del file (ID evento 2). Alcuni malware possono falsificare la data di creazione di un file per nasconderlo dai rapporti sui file creati di recente.
Caricamento di driver e librerie dinamiche (ID evento 6-7). Monitoraggio del caricamento di DLL e driver di dispositivo in memoria, verificando la firma digitale e la sua validità.
Creare un thread in un processo in esecuzione (ID evento 8). Un tipo di attacco che deve essere monitorato.
Eventi RawAccessRead (ID evento 9). Operazioni di lettura del disco utilizzando “.”. Nella stragrande maggioranza dei casi, tale attività dovrebbe essere considerata anormale.
Crea un flusso di file denominato (ID evento 15). Viene registrato un evento quando viene creato un flusso di file denominato che emette eventi con un hash del contenuto del file.
Creazione di una pipe e di una connessione denominata (ID evento 17-18). Tracciamento del codice dannoso che comunica con altri componenti tramite la pipe denominata.
Attività WMI (ID evento 19). Registrazione degli eventi che vengono generati quando si accede al sistema tramite il protocollo WMI.
Per proteggere Sysmon stesso, è necessario monitorare gli eventi con ID 4 (arresto e avvio di Sysmon) e ID 16 (modifiche alla configurazione di Sysmon).
Registri di Power Shell
Power Shell è un potente strumento per la gestione dell'infrastruttura Windows, quindi è molto probabile che un utente malintenzionato lo scelga. Sono disponibili due origini che è possibile utilizzare per ottenere i dati sugli eventi di Power Shell: registro di Windows PowerShell e registro Microsoft-WindowsPowerShell/operativo.
Registro di Windows PowerShell
Fornitore di dati caricato (ID evento 600). I provider di PowerShell sono programmi che forniscono un'origine dati che PowerShell può visualizzare e gestire. Ad esempio, i provider integrati potrebbero essere variabili di ambiente Windows o il registro di sistema. L'emergere di nuovi fornitori deve essere monitorato per individuare in tempo eventuali attività dannose. Ad esempio, se vedi WSMan apparire tra i provider, significa che è stata avviata una sessione remota di PowerShell.
Registro Microsoft-WindowsPowerShell/Operativo (o MicrosoftWindows-PowerShellCore/Operativo in PowerShell 6)
Registrazione del modulo (ID evento 4103). Gli eventi memorizzano informazioni su ciascun comando eseguito e i parametri con cui è stato chiamato.
Registrazione del blocco degli script (ID evento 4104). La registrazione del blocco degli script mostra ogni blocco di codice PowerShell eseguito. Anche se un utente malintenzionato tenta di nascondere il comando, questo tipo di evento mostrerà il comando di PowerShell che è stato effettivamente eseguito. Questo tipo di evento può anche registrare alcune chiamate API di basso livello effettuate; questi eventi vengono generalmente registrati come Verbose, ma se un comando o uno script sospetto viene utilizzato in un blocco di codice, verrà registrato come gravità di avviso.
Tieni presente che una volta configurato lo strumento per raccogliere e analizzare questi eventi, sarà necessario ulteriore tempo di debug per ridurre il numero di falsi positivi.
Raccontaci nei commenti quali registri raccogli per gli audit sulla sicurezza delle informazioni e quali strumenti utilizzi a tale scopo. Una delle nostre aree di interesse sono le soluzioni per il controllo degli eventi di sicurezza delle informazioni. Per risolvere il problema della raccolta e dell'analisi dei log, possiamo suggerire di dare un'occhiata più da vicino , che può comprimere i dati archiviati con un rapporto di 20:1 e una sua istanza installata è in grado di elaborare fino a 60000 eventi al secondo da 10000 origini.
Fonte: habr.com