Custom Detection con Advanced Hunting di Microsoft Defender for Endpoint

Al giorno d’oggi, durante un attacco informatico, abbiamo bisogno, una volta capito quale processo esegue azioni malevoli, di capire su quali dispositivo esso è attivo, ma non abbiamo magari a disposizione gli strumenti necessari per eseguire questa ricerca.

La casa di Redmond con la suite di Microsoft Defender for Endpoint, mette a disposizione una funzionalità veramente interessante che vi permette di eseguire delle Detection Custom per eseguire discover di Processi, Applicazioni presenti all’interno dei vostri endpoint, per poi permettervi di eseguire le opportune remediation per la mitigazione della compromissione.

Microsoft Defender for Endpoint è un servizio che vi offre una copertura totale dei vostri dispositivi e mette anche a disposizione degli strumenti per la gestione in modo semplificato del parco installato.

Cosa è esattamente il servizio di Hunting?

Il servizio di Hunting è uno strumento di ricerca delle minacce basato su Query (KQL) che consente di ricercare fino a 30 giorni di dati che non sono stati elaborati.

È possibile quindi sfruttare questo servizio per la ricerca di minacce o potenziali, e ci sono principalmente due modalità:

  • Guidata
  • Avanzata

Utilizzando la modalità guidata, per chi non ha dimestichezza con KQL è sicuramente la scelta migliore in quanto in base alla tipologia di ricerca vengono proposte direttamente da Microsoft delle KQL già preimpostate.

La modalità Avanzata invece permette di eseguire delle ricerche più approfondite, ma dovrete conoscere il linguaggio Kusto Query (KQL) per procedere.

E’ possibile inoltre salvare le ricerche per creare delle regole di rilevamento su un determinato processo, eseguibile ecc.

La ricerca avanzata supporta i seguenti Workload Microsoft 365:

  • Microsoft Defender for Endpoint
  • Microsoft Defender for Office 365
  • Microsoft Defender for Cloud Apps
  • Microsoft Defender for Identity

All’interno di questo articolo vedrete come poter eseguire Advanced Hunting all’interno del servizio Microsoft Defender for Endpoint, per eventuali approfondimenti vi invito a fare riferimento alla documentazione ufficiale di Microsoft Panoramica – Ricerca avanzata – Microsoft Defender XDR | Microsoft Learn

Prerequisiti

Vediamo insieme ora i prerequisiti per poter sfruttare la funzionalità di Hunting:

  • Device agganciato a Microsoft Defender for Endpoint / Server
  • Licenze di Microsoft Defender for Server P2 (per la parte server) o Microsoft Defender for Endpoint P2 (per la parte client) Microsoft Defender for Endpoint | M365 Maps
  • Credenziali utente con Accesso amministrativo al portale Microsoft Defender

Scenario

Presupponiamo di dover ricercare all’interno dei nostri Endpoint un processo che abbiamo capito essere malevolo, nel mio caso ricercherò il processo di TeamViewer, in quanto all’interno del mio ambiente di demo non ho installato questo programma e secondo me potrebbe essere stato l’attaccante ad installarlo per scopi illeciti.

L’ambiente per darvi dimostrazione di quanto indicato è composto da un server Windows Server 2022 in hosting presso Microsoft Azure chiamato SRVDC01

Figura 1: Caratteristiche Server per ambiente di Demo

Il dispositivo inoltre è protetto da Microsoft Defender for Server

Figura 2: Server (SRVDC01) gestito e protetto da Microsoft Defender for Server

Figura 3: Servizio TeamViewer attivo ed in running all’interno del server di Demo

Svolgimento

Recatevi all’interno del portale di Microsoft Defender Security & Compliance (microsoft.com)

Figura 4: Sezione di Advanced Hunting all’interno del portale di Microsoft Defender

Ora dovrete procedere a creare la KQL (Kusto Query) necessaria ad eseguire il discover del processo che vorrete ricercare, nel mio caso quello di TeamViewer, per capire il funzionamento delle KQL vi riporto l’articolo che ho scritto inerente a Microsoft Sentinel Configurare Microsoft Sentinel per ricevere Log da dispositivi On-Premises – ICT Power nel quale descrivo la struttura di “costruzione” di questa tipologia di Query.

Dovrete avere a disposizione il nome del processo da ricercare per farlo potete recarvi all’interno del Server, nel mio caso SRVDC01 ad aprire i servizi del dispositivo

Figura 5: Apertura Services all’interno del Server di Demo

Figura 6: Apertura proprietà del processo da ricercare,nel mio caso TeamViewer

Figura 7: Ricerca nome del processo da ricercare

Una volta che avrete il nome dell’eseguibile del processo da ricercare, nel mio caso “TeamViewer_Service.exe”, riposizionatevi all’interno del portale di Microsoft Defender nella sezione di Advanced Hunting

Figura 8: Esecuzione KQL per la ricerca del processo

Vorrei però ora spiegarvi brevemente la Kusto Query

DeviceProcessEvents
| where FileName == “TeamViewer_Service.exe”
| distinct DeviceName
| project  DeviceName

  • DeviceProcessEvents: Tabella di riferimento in cui ricercare, dovendo eseguire la ricerca di un processo la tabella di riferimento è quella relativa ai processi attivi sui device
  • FileName: il nome del processo da ricercare
  • Distinct: parametro che permette di rimuovere eventuali duplicati dai risultati
  • Project : parametro che permette di avere nei risultati solo la colonna della tabella interessata (nel mio caso il nome del device)

Una volta eseguita la KQL vedrete il risultato ottenuto

Figura 9: Risultato della KQL eseguita, che riporta il nome del device su cui il processo è presente

Creazione Regola Custom di Detection

Le regole custom di detection a mio avviso sono un forte strumento di analisi messo a disposizione da Microsoft nel workload di Defender for Endpoint / Server, infatti è possibile creare questa regola partendo dalla Query eseguita in precedenza, ora insieme vedremo come.

E’ bene specificare che per la creazione di questa regola sono obbligatorie determinati colonne della tabella, come riportato nello screen sottostante

Figura 10: Colonne obbligatorie per la creazione di una Custom Detection

Inserendo le colonne richieste l’opzione di creazione sarà accessibile

Figura 11: Con colonne obbligatorie la creazione è possibile

Figura 12: Creazione regola Custom di Detection

Vi spiego anche il significato dei diversi campi:

  • Detection Name: Nome della regola, il mio consiglio è quella di fornire un nome “parlante”, questo vi permetterà in future di capire a colpo d’occhio a cosa serve la regola
  • Frequency: Frequenza con cui la regola viene eseguita, in caso di compromissione confermata, consiglio di settare il parametro in Continuous così capirete se l’attaccante è ancora all’interno della vostra infrastruttura
  • Severity: Gravità della ricerca, qui potete selezionare la severity in base alla situazione di ricerca, in caso di compromissione è suggerita High
  • Category: Tipologia dell’attacco, nel mio caso la regola è una ricerca quindi ho inserito Discovery
  • Description: Descrizione di quello che la regola ricerca, anche qui vale quando indicato per il nome della Detection, più scrivete e più sarà semplice capire cosa la ricerca fa.
  • Recommended Actions: Azione raccomandata quando viene eseguito il match della regola, nel mio caso indico di procedere alla disinstallazione di TeamViewer

Figura 13: Selezione Entity della ricerca, nel mio caso “Device” e selezione di quela attributo usare per eventuali automazioni

Figura 14: Indico cosa fare quando la regola ha un match, isolo il device per sicurezza

Nel mio coso, quando viene eseguito il match della regola, ho scelto di isolare il device.

Figura 15: Riepilogo di quanto configurato e salvataggio della regola

Figura 16: Visualizzazione delle Detection Rule Create all’interno del portale di Microsoft Defender

Figura 17: Device su cui la detection ha rilevato TeamViewer è stata isolato

Figura 18: Creato Alert con priorità media come indicato nella detection

Ora per rimuovere il device dall’isolamento settate la Detection in stato di Off

Figura 19: Disabilito Detection per rimuovere il device dall’isolamento

Figura 20: Detection Disabilitata in modo corretto

Figura 21: Rimozione del device dall’isolamento

Figura 22: Rimozione device dall’isolamento

Figura 23: Rimozione dall’isolamento eseguita in modo corretto

Conclusioni

Avere a disposizione uno strumento, che con una Kusto Query, ci permette di ricercare processi, programmi, vulnerabilità all’interno del nostro parco macchine installato e automatizzare le operazioni di remediation è un vantaggio non di poco conto.

Pensate ad esempio in un caso di compromissione dichiarata, dover ricercare l’azione dell’attaccante all’interno di un numero elevato di dispositivi, questo strumento ci permette appunto di ricercare questa azione in modo rapido su tutto il parco installato e scegliere se eseguire scansioni o come nel mio caso isolare in modo del tutto automatizzato il device, per evitare che il potenziale attaccante estenda la compromissione a tutta la nostra rete aziendale e fare non pochi danni.

Per chi possiede le licenze necessarie è uno strumento sicuramente da utilizzare per estendere la protezione dei device ed evitare spiacevoli sorprese.