La stazione di lavoro degli utenti rappresenta il punto più vulnerabile dell'infrastruttura in termini di sicurezza informatica. Gli utenti possono ricevere nella loro email di lavoro un messaggio apparentemente proveniente da una fonte sicura, ma che contiene un link a un sito compromesso. È possibile che qualcuno scarichi un'utilità utile per il lavoro da una fonte sconosciuta. Potremmo inventare una dozzina di casi in cui il malware possa penetrare nelle risorse aziendali attraverso gli utenti. Per questo motivo, le stazioni di lavoro richiedono attenzione speciale, e in questo articolo parleremo di quali eventi monitorare per rilevare attacchi.
Per identificare un attacco nella sua fase iniziale, nel sistema operativo Windows esistono tre fonti di eventi utili: il registro eventi di sicurezza, il registro di monitoraggio del sistema e i registri di PowerShell.
Registro eventi di sicurezza (Security Log)
Questo è il principale archivio dei log di sicurezza del sistema. Qui vengono archiviati gli eventi di accesso/uscita degli utenti, l'accesso agli oggetti, le modifiche delle politiche e altre attività legate alla sicurezza. Ovviamente, se è stata impostata la politica corrispondente.
Enumerazione degli utenti e dei gruppi (eventi 4798 e 4799). All'inizio di un attacco, il malware spesso esamina le credenziali degli account utente locali e dei gruppi locali sulla stazione di lavoro per trovare dati per le sue malefatte. Questi eventi possono aiutare a rilevare il codice dannoso prima che progredisca ulteriormente e si diffonda su 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ò anche 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 legittimi accedono con un'account di dominio, e la rilevazione di un accesso con un'account locale potrebbe indicare l'inizio di un attacco. L'evento 4624 include anche gli accessi con l'account di dominio, quindi durante l'elaborazione degli eventi è necessario filtrare quelli in cui il dominio è diverso dal nome della stazione di lavoro.
Tentativo di accesso con un'account specificata (evento 4648). Ciò avviene quando un processo viene eseguito in modalità "Esegui come". In condizioni operative normali, non dovrebbe avvenire, quindi questi eventi devono essere monitorati.
Blocco/sblocco della stazione di lavoro (eventi 4800-4803). Appartengono alla categoria degli eventi sospetti tutte le azioni che si sono verificate su una stazione di lavoro bloccata.
Modifiche alla configurazione del firewall (eventi 4944-4958). È evidente che durante l'installazione di nuovi software, le impostazioni del firewall possono essere modificate, il che potrebbe causare falsi allarmi. In molti casi, non è necessario monitorare tali cambiamenti, ma sapere che esistono non è mai superfluo.
Collegamento di dispositivi Plug’n’play (evento 6416 e solo per Windows 10). È importante monitorare questo se gli utenti solitamente non collegano nuovi dispositivi alla stazione di lavoro e all'improvviso lo fanno.
Windows include 9 categorie di auditing e 50 sotto-categorie per la configurazione fine. Il set minimo di sotto-categorie raccomandato è:
Accesso/Disconnessione
- Accesso;
- Disconnessione;
- Blocco dell'account;
- Altri eventi di accesso/disconnessione.
Gestione dell'account
- Gestione dell'account utente;
- Gestione dei gruppi di sicurezza.
Modifica della politica
- Modifica della politica di auditing;
- Modifica della politica di autenticazione;
- Modifica della politica di autorizzazione.
Monitor di sistema (Sysmon)
Sysmon è un'utilità integrata in Windows che registra eventi nel registro di sistema. Di solito è necessario installarlo separatamente.
Questi eventi possono essere trovati anche nel registro di sicurezza (attivando la politica di auditing appropriata), ma Sysmon fornisce maggiori dettagli. Quali eventi possono essere estratti da Sysmon?
Creazione di un processo (ID evento 1). Il registro eventi di sicurezza può indicare quando è stato avviato un *.exe e può mostrare il suo nome e il percorso di avvio. Ma a differenza di Sysmon, non può mostrare l'hash dell'applicazione. Il malware può presentarsi come un innocuo notepad.exe, ma è proprio l'hash che lo smaschererà.
Connessioni di rete (ID evento 3). È chiaro che ci sono molte connessioni di rete, e non è possibile tenerle tutte sotto controllo. Ma è importante considerare che Sysmon, a differenza del Security Log, può collegare una connessione di rete ai campi ProcessID e ProcessGUID, mostrando la porta e Indirizzi IP sia la sorgente che il destinatario.
Modifiche nel registro di sistema (ID evento 12-14). Il metodo più semplice per aggiungersi all'avvio automatico è iscriversi nel registro. Il Security Log lo può fare, ma Sysmon mostra chi ha effettuato le modifiche, quando, da dove, ID processo e il valore precedente della chiave.
Creazione di un file (ID evento 11). Sysmon, a differenza del Security Log, mostrerà non solo la posizione del file, ma anche il suo nome. È chiaro che non si può seguire tutto, ma è possibile condurre un audit di determinate directory.
E ora cosa c'è in Sysmon che non è presente nelle politiche del Security Log:
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 creati di recente.
Caricamento di driver e librerie dinamiche (ID eventi 6-7). Monitoraggio del caricamento in memoria delle DLL e dei driver, 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 da monitorare.
Eventi RawAccessRead (ID evento 9). Operazioni di lettura dal disco utilizzando “.”. Nella stragrande maggioranza dei casi, tale attività dovrebbe essere considerata anomala.
Creazione di un flusso di file denominato (ID evento 15). L'evento viene registrato quando viene creato un flusso di file denominato, che genera eventi con l'hash del contenuto del file.
Creazione di named pipe e connessioni (ID eventi 17-18). Monitoraggio di codice maligno che comunica con altri componenti attraverso named pipe.
Attività WMI (ID evento 19). Registrazione degli eventi 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 (modifica della configurazione di Sysmon).
Log di Power Shell
Power Shell è uno strumento potente per la gestione dell'infrastruttura Windows, quindi è probabile che un attaccante opti per usarlo. Per ottenere informazioni sugli eventi di Power Shell, è possibile utilizzare due fonti: il log di Windows PowerShell e il log Microsoft-WindowsPowerShell / Operational.
Log di Windows PowerShell
Fornitore di dati caricato (ID evento 600). I fornitori di PowerShell sono programmi che fungono da fonte di dati per PowerShell per la visualizzazione e gestione. Ad esempio, i fornitori integrati possono includere variabili di ambiente Windows o il registro di sistema. È necessario prestare attenzione all'emergere di nuovi fornitori per rilevare tempestivamente attività dannose. Ad esempio, se si vede che tra i fornitori appare WSMan, significa che è stata avviata una sessione remota di PowerShell.
Microsoft-WindowsPowerShell / Operational log (o MicrosoftWindows-PowerShellCore / Operational in PowerShell 6)
Log di registrazione dei moduli (ID evento 4103). Negli eventi è memorizzata informazioni su ogni comando eseguito e sui parametri con cui è stato invocato.
Log di registrazione dell'esecuzione di script (ID evento 4104). Il log di registrazione dell'esecuzione di script mostra ogni blocco di codice PowerShell eseguito. Anche se un attaccante cerca di nascondere un comando, questo tipo di evento mostrerà effettivamente il comando PowerShell eseguito. Inoltre, in questo tipo di evento possono essere registrate alcune chiamate API a basso livello, di solito questi eventi sono registrati come Verbose, ma se un comando o uno script sospetto è utilizzato in un blocco di codice, sarà registrato con criticità Warning.
Si noti che dopo aver configurato lo strumento di raccolta e analisi di questi eventi sarà necessario ulteriore tempo per il debug al fine di ridurre il numero di falsi positivi.
Facci sapere nei commenti quali log raccogli per l'audit della sicurezza informatica e quali strumenti utilizzi per farlo. Una delle nostre specializzazioni sono le soluzioni per l'audit degli eventi di sicurezza informatica. Per risolvere il compito di raccolta e analisi dei log, possiamo consigliarti di dare un'occhiata a , che è in grado di comprimere i dati memorizzati con un fattore di 20:1, e un suo singolo campione installato può elaborare fino a 60000 eventi al secondo da 10000 fonti.
Fonte: habr.com
