• Cloud, Guide, Sicurezza, Sistemi Operativi
• 3 Novembre 2024

All’interno della Community troverete diversi articoli inerenti al SIEM e SOAR di casa Redmond e di come esso vi può aiutare ad estendere la retention dei log, ma soprattutto di come poter rispondere in modo rapido ad incident di sicurezza.

A titolo informativo vi lascio la guida scritta da Nicola Ferrini per capire cosa è nel dettaglio Microsoft Sentinel Introduzione a Microsoft Sentinel – ICT Power

In questo articolo invece vorrei parlarvi delle Anlytics Rule (Regole di Analitica) e di come struttura una KQL (Kusto Query) per avere evidenza di tentativi di brute force per il collegamento RDP su un Domain Controllers.

Cosa sono le Analytics Rule?

Le regole di Analitica sono della “ricerche” scritte in linguaggio KQL (Kusto Query), linguaggio case sensitive che permette di leggere i dati raccolti in Microsoft Sentinel. Queste regole permettono di ricercare in modo ciclico i dati, quindi l’esecuzione della ricerca può essere effettuato con una schedulazione precisa come ad esempio ogni 5 minuti, ogni ora.

Con la creazione di queste regole potete creare delle regole di ricerca complesse e creare regole di correlazione degli eventi provenienti da diverse tabelle di Microsoft Sentinel. In questo articolo vi darò evidenza della regola di Analitica per ricercare tentativi di Brute Force.

Quando viene creata una regola, all’interno della creazione della stessa è possibile anche eseguire il “Mapping” delle entità, ovvero eseguire il parsing dei log provenienti dai vari connettori. Questo perché se volete generare un alert quando la query trova dei risultati è di fondamentale importanza avere a disposizione delle entità utili ad identificare cosa è “successo” come ad esempio:

• Utente che ha eseguito l’attività
• Indirizzo IP della macchina coinvolta
• Attività svolta

Vi riporto inoltre le severity che possono essere configurate alla generazione di un alert proveniente da una regola di Analitica:

Sono quindi uno strumento fondamentale per l’analisi Cyber.

Se volete approfondire le Analytics Rule vi riporto il link ufficiale Microsoft Regole di analisi pianificate in Microsoft Sentinel | Microsoft Learn

Esistono dei Prerequisiti?

Si esistono dei prerequisiti da dover rispettare che per comodità vi riporto di seguito:

• Subscription Microsoft Azure, nel mio caso ne utilizzerò una a consumo
• Workspace di Microsoft Sentinel, utile a raccogliere i dati provenienti dal Domain Controller
• Domain Controller con abilito gli Audit log delle login Success e Failed

Svolgimento

Per darvi evidenza di come poter procedere a creare una regola di Analitica che vi permetta di ricercare tentivi di Brute Force utilizzerò un workspace di Microsoft Sentinel ed un Domain Controller in Hosting presso Microsoft Azure.

Figura 1: Workspace di Microsoft Sentinel Utile a collezionare i log provenienti dal domain controller

Figura 2: Caratteristiche Domain Controller che invierà i log a Microsoft Sentinel

La prima operazione che dovrete eseguire sarà abilitare gli Audit log di Login Success e Login Failed.

Figura 4: Apertura Group Policy Management

Figura 5: Aprire in modalità configurazione la Group Policy applicata ai Domain Controllers

Figura 6: Apertura Policy Computer Configuration – Policies -Windows Settings – Security Settings – Local Policies – Audit Policy

Figura 7: Abilitare gli eventi sia Success che Failure di “Account Logon Events”

Figura 8: Abilitare gli eventi sia Success che Failure di “Logon Events”

Figura 9: Configurazioni Salvate in Modo Corretto

Per “velocizzare” il domain controllers a recepire le nuove configurazioni potete eseguire il CMD sul domain controllers come amministratori ed eseguire il comando gpudate /force

Figura 10: Comando per forzare la ricezione della modifica della GPO

Figura 11: Comando eseguito in modo corretto

Ora all’interno del vostro controller di Dominio verranno loggati tutti gli eventi di Login degli utenti, inclusi quelli RDP, sia Failed che Success.

A questo punto recatevi all’interno del vostro workspace di Microsoft Sentinel Home page – Microsoft Azure

Figura 12: Apertura Microsoft Sentinel direttamente dal portale di Microsoft Azure

Figura 13: Selezionare il Workspace di Microsoft Sentinel

Figura 14: Installazione connettore di Windows Security Events per collezionare i log del Domain Controller verso Sentinel

Figura 15: Installazione riuscita correttamente

Figura 16: Configurazione del connettore

Figura 17: Configurazione connettore AMA per collezionare eventi di Login del domain controller 

Figura 18: Creazione Data Collection Rule

Figura 19: Creazione Data Collection Rule per collezionare eventi del solo Domain Controller

Figura 20: Selezionare il Domain Controller di cui collezionare i Log

Figura 21: Collezioniamo solo gli eventi Windows 4624 e 4625 relativi a login success e login failed

Figura 22: Ultimare la creazione della Data Collection Rule

Figura 23: DCR Salvata in modo corretto

Ora, per verificare che i log siano in Microsoft Sentinel:

Figura 26: KQL che vi fornisce evidenza dei login success e dei login failed del vostro domain controller

Per ottimizzare la KQL vi consiglio di strutturarla in questo modo:

In questo modo avrete a disposizione solo le colonne utile ad una eventuale Analisi ed il risultato è fornito in questo modo:

Figura 27: Risultato KQL ottimizzata

Vi vorrei fornire anche la KQL utile ad eseguire una ricerca dei TOP Users con login fallite

In questo modo avrete un risultato “pulito” con il nome utente ed il numero di tentativi di Login falliti.

Figura 28: Risultato KQL per vedere i top users di login failed

Ora che avrete predisposto tutti i prerequisiti potete creare la Analytics Rule. Insieme ad essa vedremo anche come rispondere in modo automatizzato.

Figura 29: Creazione di una regola di Analitica Custom

Scegliete ora un nome parlante con relativa descrizione.

Figura 30: Creazione regola di Analitica Custom per il discover di RDP Brute Force

Figura 31: Inserimento KQL per la ricerca delle attività di sospetto Brute Force

Vi riporto la KQL scritta, in quanto nello screen non è possibile darvi evidenza di tutti i campi necessari

Ora dovrete eseguire il Mapping (Parsing) dei log per identificare:

• Account coinvolto nell’alert
• IP di provenienza della richiesta di connessione RDP
• Host in cui il potenziale attaccante stà tentando di collegarsi

Userò inoltre le seguenti impostazioni:

• La KQL verrà eseguita ogni 5 minuti
• La KQL ricercherà dati nei 30 minuti precedenti

Figura 32: Mapping dei parametri che vi interessano maggiormente e che saranno visibili negli alert

Figura 33: Indicazione di ogni quanto tempo deve essere eseguita la regola e indichiamo l’arco temporale in cui ricercare i dati

Figura 34: Impostazione per raggruppamento degli Alert quando la regola contiene dei risultati

Figura 35: Non creiamo al momento nessuna regola di Automazione per rispondere a questo Alert

Figura 36: Overview della regola creata con relativo salvataggio della stessa

Figura 37: Regola creata presente all’interno del riepilogo delle regole di Analitica

Ora, ho simulato diversi tentativi di Brute Force sbagliando appositamente la password per l’accesso in RDP al mio Domain Controller

Figura 38: RDP Failed verso il Domain Controller

Come investighiamo gli Alert generati?

Recatevi all’interno degli Alert di Microsoft Sentinel

Figura 39: Alert generati in Microsoft Sentinel con la regola di Analitica creata

Figura 40: Apertura dei dettagli dell’incident

Figura 41: Visibilità delle utenze coinvolte, degli alert simili e degli IP di provenienza dei tentativi di Brute Force

Come possiamo prevenire un attacco di Brute Force che vada a buon fine?

A mio avviso lo strumento migliore per prevenire un attacco Brute Force che vada a buon fine è l’uso del secondo fattore di autenticazione anche per le connessioni RDP, in questo modo è l’utente amministratore che approva in modo puntuale se quell’accesso è lecito o meno.

Come avete potuto notare sono soggetti ad attacco le utente amministrative “Standard” come ad esempio l’Administrator, utenza che a mio avviso va protetta in modo esemplare per evitare spiacevoli sorprese.

Avete visto che con pochi e semplici passaggi possiamo ottimizzare gli avvisi di sicurezza della nostra infrastruttura ed analizzare in modo semplice e rapido eventi di questo tipo per rispondere in modo rapido a questa tipologia di attacchi che potrebbero compromettere in modo irrimediabile il nostro Business.