La workstation per utenti è il punto più vulnerabile dell'infrastruttura in termini di sicurezza informatica. Gli utenti potrebbero ricevere nella loro email di lavoro un messaggio apparentemente proveniente da una fonte sicura, ma con un link a un sito infetto. È possibile immaginare decine di casi in cui, attraverso gli utenti, il malware possa infiltrarsi nelle risorse interne. Pertanto, le workstation richiedono una maggiore attenzione e in questo articolo parleremo di quali eventi e da dove monitorare per rilevare gli attacchi.
Per identificare un attacco nella fase più precoce, in Windows ci sono tre utili fonti di evento: il registro degli eventi di sicurezza, il registro di monitoraggio del sistema e i registri di Power Shell.
Registro degli eventi di sicurezza (Security Log)
Questo è il principale luogo di archiviazione dei log di sicurezza di sistema. Qui vengono archiviati gli eventi di accesso/uscita degli utenti, gli accessi agli oggetti, le modifiche alle politiche e altre attività legate alla sicurezza. Naturalmente, se è stata configurata la relativa politica.
Enumerazione di utenti e gruppi (eventi 4798 e 4799). Il malware, all'inizio di un attacco, spesso esamina le credenziali delle locali e dei gruppi sul workstation per trovare le credenziali necessarie per le sue attività illecite. Questi eventi possono aiutare a rilevare il codice dannoso prima che possa progredire e diffondersi ad altri sistemi utilizzando i dati raccolti.
Creazione di un account locale e modifiche nei gruppi locali (eventi 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 e 5377). Un attacco può iniziare, ad esempio, con l'aggiunta di un nuovo utente al gruppo degli amministratori locali.
Tentativi di accesso con un account locale (evento 4624). Gli utenti corretti accedono con un account di dominio e l'individuazione di un accesso con un account locale può indicare l'inizio di un attacco. L'evento 4624 include anche accessi con un account di dominio, quindi durante l'elaborazione degli eventi è necessario filtrare quelli in cui il dominio differisce dal nome della workstation.
Tentativo di accesso con un account specifico (evento 4648). Questo accade quando il processo viene eseguito in modalità 'Esegui come' (run as). In modalità di funzionamento normale del sistema, ciò non dovrebbe verificarsi, quindi tali eventi devono essere tenuti sotto controllo.
Blocco/sblocco della stazione di lavoro (eventi 4800-4803). A qualsiasi azione verificatasi su una stazione di lavoro bloccata può essere attribuita la categoria di eventi sospetti.
Modifiche alla configurazione del firewall (eventi 4944-4958). È chiaro che durante l'installazione di nuovo software le impostazioni di configurazione del firewall possono variare, il che porterà a falsi allarmi. In molti casi non è necessario controllare tali modifiche, ma sapere di esse non è mai superfluo.
Collegamento di dispositivi Plug’n’play (evento 6416 e solo per Windows 10). È importante monitorare questo se gli utenti di solito non collegano nuovi dispositivi alla stazione di lavoro, e poi all'improvviso - collegano.
Windows include 9 categorie di audit e 50 sottocategorie per una configurazione fine. Il set minimo di sottocategorie che è consigliato attivare nelle impostazioni è:
Accesso/Disconnessione
- Accesso;
- Disconnessione;
- Blocco dell’account;
- Altri eventi di accesso/disconnessione.
Gestione degli account
- Gestione degli account utente;
- Gestione dei gruppi di sicurezza.
Modifica della politica
- Modifica della politica di audit;
- Modifica della politica di autenticazione;
- Modifica della politica di autorizzazione.
Monitoraggio di sistema (Sysmon)
Sysmon è uno strumento integrato in Windows che può registrare eventi nel registro di sistema. Di solito è necessario installarlo separatamente.
Questi eventi possono in effetti essere trovati nel registro di sicurezza (attivando la politica di audit appropriata), ma Sysmon fornisce più dettagli. Quali eventi possono essere estratti da Sysmon?
Creazione di processo (ID evento 1). Il registro di sistema degli eventi di sicurezza può anche dire quando è stato avviato qualche *.exe e anche mostrare il suo nome e il percorso di avvio. Ma a differenza di Sysmon, non potrà mostrare l'hash dell'applicazione. Il malware può chiamarsi anche il ben noto notepad.exe, ma proprio l'hash lo svelerà.
Connessioni di rete (ID evento 3). È evidente che ci sono molte connessioni di rete e non è possibile monitorarle tutte. Ma è importante tenere a mente che Sysmon, a differenza del Security Log, sa collegare la connessione di rete ai campi ProcessID e ProcessGUID, mostrando la porta e Indirizzi IP l'origine e il destinatario.
Modifiche nel registro di sistema (ID evento 12-14). Il modo più semplice per aggiungere se stessi all'avvio automatico è registrarsi nel registro. Security Log può farlo, ma Sysmon mostra chi ha apportato modifiche, quando, da dove, ID processo e il valore precedente della chiave.
Creazione di un file (ID evento 11). Sysmon, a differenza di Security Log, mostra non solo la posizione del file, ma anche il suo nome. È chiaro che non si può tenere traccia di tutto, ma è possibile condurre audit su directory specifiche.
E ora, ciò che non si trova nelle politiche di Security Log, ma è presente in Sysmon:
Modifica della data di creazione del file (ID evento 2). Alcuni malware possono alterare la data di creazione del file per nasconderlo dai rapporti sui file di recente creazione.
Caricamento di driver e librerie dinamiche (ID eventi 6-7). Monitoraggio del caricamento in memoria di DLL e driver di dispositivo, verifica della firma digitale e della sua validità.
Creazione di un thread in un processo in esecuzione (ID evento 8). Uno dei tipi di attacco che è necessario monitorare.
Eventi RawAccessRead (ID evento 9). Operazioni di lettura dal disco tramite '`.`'. Nella stragrande maggioranza dei casi, tale attività deve essere considerata anomala.
Creazione di uno stream di file nominato (ID evento 15). L'evento viene registrato quando viene creato uno stream di file nominato, che genera eventi con l'hash del contenuto del file.
Creazione di una named pipe e collegamenti (ID eventi 17-18). Monitoraggio di codice dannoso che comunica con altri componenti tramite named pipe.
Attività WMI (ID evento 19). Registrazione di eventi generati durante l'accesso 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 (modifica della configurazione di Sysmon).
Registri di Power Shell
Power Shell è uno strumento potente per la gestione dell'infrastruttura Windows, quindi è molto probabile che l'attaccante scelga proprio questo. Per ottenere dati sugli eventi di Power Shell, si possono utilizzare due fonti: Windows PowerShell log e Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Fornitore di dati caricato (ID evento 600). I provider PowerShell sono programmi che fungono da sorgente di dati per PowerShell, consentendo di visualizzarli e gestirli. Ad esempio, i fornitori integrati possono essere le variabili d'ambiente di Windows o il registro di sistema. È necessario monitorare l'emergere di nuovi fornitori per identificare tempestivamente attività malevole. Ad esempio, se si nota che tra i fornitori è apparso WSMan, significa che è iniziata una sessione remota di PowerShell.
Registro di Microsoft-WindowsPowerShell / Operativo (o MicrosoftWindows-PowerShellCore / Operativo in PowerShell 6)
Registrazione dei moduli (ID evento 4103). Negli eventi è memorizzata l'informazione su ogni comando eseguito e sui parametri con cui è stato invocato.
Registrazione del blocco degli script (ID evento 4104). La registrazione del blocco degli script mostra ogni blocco di codice PowerShell eseguito. Anche se un malintenzionato cerca di nascondere il comando, questo tipo di evento mostrerà effettivamente il comando PowerShell eseguito. Inoltre, in questo tipo di evento possono essere registrate alcune chiamate API di basso livello eseguite; questi eventi sono di solito registrati come Verbose, ma se viene utilizzato un comando o uno script sospetto in un blocco di codice, sarà registrato con una severità di Warning.
Si noti che dopo aver configurato lo strumento di raccolta e analisi di questi eventi sarà necessario un ulteriore tempo per il debug al fine di ridurre il numero di falsi positivi.
Raccontate nei commenti quali log raccogliete per l'audit della sicurezza informatica e quali strumenti utilizzate per farlo. Una delle nostre aree di lavoro è la fornitura di soluzioni per l'audit degli eventi di sicurezza informatica. Per affrontare la questione della raccolta e analisi dei log, possiamo suggerire di considerare , che è in grado di comprimere i dati memorizzati con un rapporto di 20:1, e un suo esemplare installato può gestire fino a 60.000 eventi al secondo provenienti da 10.000 fonti.
Fonte: habr.com
