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

Ho parlato all’interno della community diverse volte del SIEM e SOAR di casa Redmond e di come possono aiutarvi a collezionare log provenienti da diverse fonti per poi creare regole che attraverso l’automazione vi aiutano a prevenire attacchi informatici sempre più sofisticati.

Oggi con questo articolo vorrei portare alla vostra attenzione una funzionalità veramente interessante Investigation Graph e di come essa attraverso un’analisi “grafica” vi permette di identificare tutti gli attori coinvolti in un Incident di Sicurezza Informatica.

Quando Microsoft Sentinel genera in incident di sicurezza significa che quella determinata azione richiede la nostra attenzione e deve essere analizzata in modo proattivo per evitare poi spiacevoli sorprese.

La base per una buona analisi è fondata da tre pillar:

• Analisi degli Incident
• Analisi del grafico di Indagine
• Risposta proattiva alle minacce

Considerate inoltre che un Incident può includere più alert, che per comodità vengono “raggruppati” dal SIEM questo perché viene svolta “un’aggregazione” di tutte le prove rilevanti di uno specifico Incident di Sicurezza.

Prerequisiti

Esistono dei prerequisiti che dovrete rispettare per utilizzare questa funzionalità, che vi riepilogo di seguito:

• Mapping delle entità coinvolte nell’incident (Device, Utente, SourceIP)
• Accessi a Microsoft Sentinel con un’utenza che possa eseguire Query e analizzare gli Incident
• Subscription Microsoft Azure e Workspace di Microsoft Sentinel (utili alla log collection)
• Connettori di Microsoft Sentinel configurati in modo corretto per recepire i log dalle fonti interessate
• Licenza Microsoft 365 che nel mio caso preveda la possibilità di utilizzare Microsoft Defender for Identity (nel mio caso una Microsoft 365 E5) Microsoft 365 E5 | M365 Maps

Ricordo inoltre che più log vengono immagazzinati in Microsoft Sentinel e più il SIEM sarà in grado di eseguire correlazione e fornirvi di conseguenza degli alert puntuali sull’attività potenzialmente illecita svolta.

Svolgimento

Per darvi evidenza di questa funzionalità io utilizzerò una Subscription di Microsoft Azure a consumo il connettore di Microsoft Defender XDR per Microsoft Sentinel ed un Domain Controller sul quale è installato il sensore di Defender for Identity, per ultimo avrà a disposizione un client Windows 10 all’interno del quale simulerò un attacco che verrà rilevato dal sensore di Defender for Identity.

Figura 1: Workspace di Microsoft Sentinel utile per collezionare i log provenienti nel mio caso da Defender for Identity

Figura 2: Licenze Microsoft 365 E5 utilizzate per Defender for Identity all’interno del domain controller

Figura 3: SRVDOREMINIO, il domain controller che attraverso il sensore di Defender for Identity invia i log a Microsoft Sentinel

Figura 4: Client a Dominio all’interno del quale simulerò un attacco per far scaturire un alert in Microsoft Sentinel

Figura 5: Connettore Defender for Identity per Microsoft Sentinel che recepisce i log provenienti dal Domain Controller e li salva all’interno del Workspace

NB: Tutte le tecniche ti attacco descritte in questo paragrafo sono a titolo informativo e utilizzate a scopo didattico per la ricerca nel campo della sicurezza informatica. L’uso di questi tools / strumenti senza l’esplicito consenso del proprietario dei sistemi informatici è illegale e può comportare gravi conseguenze legali. L’autore e gli editori declinano qualsiasi responsabilità per l’abuso o l’uso improprio di queste informazioni da parte degli utenti. Si consiglia vivamente di ottenere il consenso scritto prima di condurre qualsiasi tipo di test o di valutazione della sicurezza su sistemi informatici.

Ora genererò un Incident “User and group membership reconnaissance (SAMR)” attraverso questi comandi eseguiti in un Computer in dominio:

• net user /domain
• net group /domain
• net group “Domain Admins” /domain
• net group “Enterprise Admins” /domain
• net group “Schema Admins” /domain

Prima di procedere però vorrei spiegarvi che tipologia di Alert è “User and group membership reconnaissance (SAMR)”.

In precedenza questo specifico alert era chiamato “Reconnaissance using directory services queries”, questo specifico attacco viene utilizzato da malintenzionati per mappare la struttura delle directory delle proprie vittime e prendere coscienza degli account privilegiati per poi sviluppare il proprio attacco. Il protocollo SAM-R (Security Account Manager Remote) è uno dei metodi utilizzati per eseguire query all’interno della Directory.

Vi riporto anche le tecniche mitre associate a questa tipologia di attacchi:

• Tecnica MITRE primaria Discovery, Tactic TA0007 – Enterprise | MITRE ATT&CK®
• MITRE attack technique Account Discovery, Technique T1087 – Enterprise | MITRE ATT&CK®, Permission Groups Discovery, Technique T1069 – Enterprise | MITRE ATT&CK®
• MITRE attack sub-technique Account Discovery: Domain Account, Sub-technique T1087.002 – Enterprise | MITRE ATT&CK®, Permission Groups Discovery: Domain Groups, Sub-technique T1069.002 – Enterprise | MITRE ATT&CK®

Eseguirò anche un altra tipologia di attacco “User and IP address reconnaissance” precedentemente conosciuta come “Reconnaissance using SMB Session Enumeration”.

Questa tipologia di attacco sfrutta il protocollo SMB (Server Message Block) e consente agli attaccanti di ottenere informazioni relative alle login degli utenti, ed una volta entrati in possesso di queste informazioni gli attaccanti possono eseguire operazioni di Lateral Movement in specifiche network.

Vi riporto anche le tecniche mitre associate a questa tipologia di attacchi:

• Primary MITRE tactic Discovery, Tactic TA0007 – Enterprise | MITRE ATT&CK®
• MITRE attack technique     Account Discovery, Technique T1087 – Enterprise | MITRE ATT&CK®, System Network Connections Discovery, Technique T1049 – Enterprise | MITRE ATT&CK®
• MITRE attack sub-technique Account Discovery: Domain Account, Sub-technique T1087.002 – Enterprise | MITRE ATT&CK®

Attacco User and group membership reconnaissance (SAMR)

Ora mi posizionerò all’interno della macchina a dominio aprendo il CMD come amministratore

Figura 6: Apertura CMD come amministratore all’interno di CLientDoreminio

Figura 7: CMD aperto in modo corretto come amministratore

Figura 8: Comandi per simulazione di Incident eseguiti correttamente

Attacco User and IP address reconnaissance

Per simulare questo attacco utilizzeremo un tool di terze parti chiamato NetSess.exe. Una volta scaricato il tool apriamo il CMD come amministratore e posizioniamoci nella cartella del tools, nel mio caso “C:\service\NetSess”

Figura 9: Posizioniamoci nella cartella in cui è presente il tools

Figura 10: Esecuzione comando per simulare l’attacco, sostituite doreminio.local con il vostro dominio locale di Active Directory

Figura 11: Simulazione di Attacco andata a buonfine

Figura 12: Alert dell’attacco presente nella console di Microsoft Defender

Figura 13: Alert generato dal portale di Microsoft Defender dopo l’attività tramite CMD

Ora verifichiamo lato Microsoft Sentinel come viene visualizzato l’incident rechiamoci all’interno del portale di Azure

Figura 14: Selezione Microsoft Sentinel per accedere al Workspace

Figura 15: Selezioniamo il Workspace di Microsoft Sentinel per accedere ai nostri Incident / Log

Figura 16: Apertura dei dettagli dell’incident in Microsoft Sentinel

Figura 17: Apertura della modalità di Investigation Graph

Figura 18: Visualizzazione di Investigation Graph degli incident raggruppati

Con questa prima schermata avrete già a disposizione un grafico che identifica tutte le entità coinvolte nell’incident con gli utenti ed i vari programmi/processi coinvolti, se vogliamo approfondire cosa una singola entità a svolto, possiamo cliccare su entity e selezionare (nel mio caso l’utente) per prendere coscienza del percorso di attacco

Figura 19: Selezioniamo una entity per visualizzare il percorso di attacco

Figura 20: Attività svolte dall’utente selezionato nel percorso di attacco

Inoltre cliccando sulla specifica Entity, che nel mio caso è sempre l’utente, possiamo avere visibilità di tutte le informazioni necessarie

Figura 21: Dettagli dell’utente coinvolto nell’attacco, sui cui eventualmente potremmo eseguire dei Playbook

Figura 22: Possibilità di vedere tutti gli eventi collegati a questo utente

Successivamente se volete approfondire ad esempio i login dell’utente selezionato basta che eseguito un click con il pulsante sinistro del mouse in “Events” di “User Account Successful”

Figura 23: Visualizzare eventi specifici per l’utente di Login

Figura 24: KQL (Kusto Query) creata direttamente da Sentinel per eseguire la ricerca delle login Success dell’utente

Come ultimo step, potreste avere la necessità di verificare il singolo Endpoint (nel mio caso ClientDoreminio) per vedere in un Investigation Graph più “ristretto” quali processi sono stati eseguiti, per fare ciò basterà cliccare sul device e successivamente “View Full Details”

Figura 25: Visualizzazione dei dettagli avanzati per il device “ClientDoreminio”

Figura 26: Entrate nella sezione di Investigate del relativo Client

Figura 27: Dettaglio dei processi all’interno dell’Endpoint ClientDoreminio

Figura 28: Alert Attivi sull’Endpoint

Conclusioni

Come avete potuto notare con questa funzionalità messa a disposizione dalla casa di Redmond, vi permette in poco tempo di eseguire un’analisi forense per tutti gli “attori” coinvolti presenti in un Incident di sicurezza, e potete analizzare nel dettaglio tutto quanto dai processi eseguiti a quali utenti hanno eseguito quella determinata azione, in modo semplice veloce ed intuitivo, senza dover aprire gli Incident dal portale di Security che vi occuperebbe diverso tempo nella gestione e nell’analisi, in questo modo avrete la possibilità anche di avere delle KQL già fatte per recuperare Log “grezzo” in modo veloce senza dover necessariamente ricostruire la struttura della Query.

Nel mondo della sicurezza informatica essere tempestivi è una buona base di partenza per evitare spiacevoli e “costose” sorprese.