• Guide, Microsoft 365, Sicurezza
• 2 Luglio 2024

Rimediare in modo puntuale ad Incident di sicurezza all’interno della nostra infrastruttura è un’attività che ci permette di difenderci in modo proattivo da potenziali attacchi informatici sempre più sofisticati.

È del tutto semplice agire in un ambiente totalmente Cloud, ma come tutti sappiamo la stragrande maggioranza delle infrastrutture sono Ibride, e quindi come possiamo difenderci nel migliore dei modi da questi attacchi quando il nostro ambiente è Ibrido ?

Per darvi una risposta in modo puntuale vi invito a rileggere il mio articolo, scritto per la community, che per comodità vi riporto Automatizzare le Remediations degli incidents in Microsoft Sentinel con i playbook – ICT Power dove spiego come poter automatizzare il blocco di utenti Cloud Only sfruttando le potenzialità offerte dai Playbook di Microsoft Sentinel.

Quello che vedremo all’interno di questo articolo sarà come bloccare utenti, presenti all’interno di Active Directory, sfruttando sempre le potenzialità offerta dal SOAR di casa Redmond.

 

Licenze e Prerequisiti

Per ogni servizio Microsoft che implementeremo è sempre importante chiarire il discorso licensing quindi vediamo di seguito le licenze necessarie per procedere ad attivare questa funzionalità:

• Subscription Microsoft Azure a Consumo
• Tenant Microsoft 365 con licenze per gli utenti, che includano i servizi di cui abbiamo bisogno(Nel mio caso utilizzerò un tenant con licenze Microsoft365 E5 Microsoft 365 E5 | M365 Maps)

Queste due licenze ci permetteranno di sfruttare al meglio i servizi di Sicurezza offerti da Microsoft.

Per poter sfruttare le potenzialità di questa soluzione è necessario inoltre dire che il nostro domain controller dovrà essere presente in Azure ARC. Per eseguire l’onboarding di un server in Azure ARC vi rimando all’articolo scritto da Nicola Ferrini Azure Arc for Servers: la soluzione Microsoft per la gestione del cloud ibrido – ICT Power
nel mio caso attività non necessaria, in quanto SRVDC è già presente in Hosting presso Microsoft Azure.

 

Configurazione

Come descritto nel capitolo precedente, utilizzerò per darvi evidenza di questa funzionalità di un tenant Microsoft 365

Figura 1: Licenze presenti all’interno del Tenant di Demo

Figura 2: Subscription Azure che ospiterà l’istanza Microsoft Sentinel e i Playbook

Inoltre avrò a disposizione un server con sistema operativo Windows Server 2022 con ruolo di Domain Controller, utilizzato per darvi evidenza del blocco dell’utente

Figura 3: Caratteristiche Domain Controller Demo

Inoltre, all’interno di SRVDC è presente anche Entra Connect per la sincronizzazione degli utenti dall’Active Directory locale verso Microsoft Entra.

Figura 4: Entra Connect presente all’interno di SRVDC

Ora recatevi all’interno del portale di Microsoft Azure

Figura 5: Selezionare Automation Hybrid Worker

Questo servizio ci permetterà di automatizzare il blocco dell’utenza all’interno del nostro domain Contoller, per approfondimenti sulla funzionalità vi rimando al link ufficiale Panoramica dei ruoli di lavoro ibridi per runbook di Automazione di Azure | Microsoft Learn

Scegliete quindi ora:

• Sottoscrizione: Sottoscrizione Microsoft Azure in cui inserire questa risorsa
• Gruppo di Risorse: Resource Group in cui inserire questa nuova risorsa
• Log Analytics Workspace: Nome del workaspace di Microsoft Sentinel che avrete creato insieme all’istanza del Siem

Figura 6: Creazione della soluzione Hybrid Worker

Figura 7: Completamento Creazione Hybrid Worker

Figura 8: Risorsa Azure Automation creata correttamente

Ora dovrete procedere alla creazione di un Automation Account, che sarà “responsabile” di eseguire appunto le automazioni; nel nostro caso bloccare l’utenza in active directory locale.

Figura 9: Creazione Automation Account

Figura 10: Creazione Automation Account

Ora dovrete scegliere una Subscription in cui inserire l’account (nel mio caso Visual Studio Enterprise Subscription), un resource Group, un nome per l’account (io ho scelto sentinel-worker) e la region di Microsoft Azure. Per eventuali approfondimenti inerenti alla creazione di un Automation Account vi rimando al link ufficiale Microsoft Quickstart – Create an Azure Automation account using the portal | Microsoft Learn

Figura 11: Creazione Automation Account

Figura 12: Riepilogo della creazione dell’Automation Account

È bene inoltre specificare che l’account appena creato, nel mio caso sentinel-worker,dovrà essere abilitato come Hybrid Runbook Worker.

Figura 13: Permessi per Automation Account

Ora dovrete procedere alla creazione di un Worker Group, che per comodità io chiamerò Sentinel-Worker-Hybrid-Group. A questo punto dovrete inserire le credenziali dell’account on-prem con permessi per bloccare l’account (si consiglia, per questioni di sicurezza di dare i permessi minimi necessari ad eseguire questa operazione).

Figura 14: Creazione Worker Group con inserimento credenziali

Figura 15: Aggiunta del nostro Domain Controller

Figura 16: Creazione Hybrid Worker Group dopo aver inserito il nostro Domain Controller

Figura 17: Fine creazione dell’Hybird Worker Group

Vi riporto di come l’estensione per eseguire l’automazione sia correttamente installata all’interno di SRVDC.

Figura 18: Estensione correttamente installata all’interno di SRVDC

Perfetto! Ora la parte di creazione dei prerequisiti è stata completata e dovremmo procedere a lavorare all’interno di Microsoft Sentinel per la creazione degli alert e dell’automazione di blocco del nostro utente.

Per darvi evidenza di questa funzionalità, il domain controller collezionerà tutti i log tramite Data Collection Rule e quindi creeremo un blocco quando le login failed dell’utente di Test m365-demo\Utente.Malevolo saranno maggiori di 5 negli ultimi 5 minuti, la KQL quindi sarà configurata in questo modo:

Figura 19: Esempio KQL

Inoltre dovrete avere a disposizione uno script Powershell che vi permette di disabilitare l’utenza oggetto dell’Alert / Incident.

Figura 20: Script Powershell per installazione RSAT Tools (se non presenti) e blocco dell’utenza

Ora dovrete creare un Runbook all’interno dell’Automation Account.

Figura 21: Upload dello script per il blocco dell’utenza all’interno dell’automation Account

Ora dovrete procedere, come da schermata sottostante, a compilare i campi richiesti:

• Name: Nome del runbook, come sempre il consiglio è quello di utilizzare un nome parlante
• Runbook Type: Powershell, in quanto lo script è proprio il ps1 e quindi un powershell script
• Runtime Version: 5.1 la versione di powershell in cui eseguire lo script
• Description: Descrizione di cosa esegue lo script, anche qui siate molto specifici così da indentificare in modo puntuale cosa lo script esegue all’interno dei nostri sistemi

Figura 22: Compilazione campi per l’esecuzione dello script di blocco dell’utenza

Figura 23: Creazione Runbook per blocco utenza

Una volta cliccato su Create, la configurazione guidata vi porterà all’interno del Runbook in cui dovrete copiare nell’area selezionata il contenuto del vostro script.

Figura 24: Inserimento Script all’interno del runbook

Figura 25: Salvataggio Runbook

Figura 26: Salvataggio Runbook di blocco dell’utenza

Ora potrete eseguire un test di esecuzione del vostro script, prima di andare in produzione. Come potete fare questo test ? Nessun problema ora ve lo spiego nel dettaglio.

Come SAMACCOUNTNAME io ho inserito Utente.Test, che è il parametro del mio utente di AD; voi inserite pure un utente da provare a bloccare.

Figura 27: Esecuzione test Runbook

Figura 28: Runbook eseguito senza problemi ed utenza bloccata in modo corretto

Figura 29: Utente disabilitato in modo corretto dopo il test

Vorrei ricapitolare quanto eseguito prima di darvi evidenza degli step successivi:

• Creato Worker Group per l’aggiunta dell’estensione HybridWorker all’interno del nostro Domain Controller
• Creazione Automation Account, utile ad eseguire script all’interno della macchina
• Creazione Script Powershell per blocco dell’utenza
• Import dello script nell’account di Automazione
• Test dello script prima di andare in produzione

Ora non ci resta che generare un regola di automazione lato Microsoft Sentinel e richiamare il nostro Account di Automazione.

Recatevi quindi all’interno del workspace di Microsoft Sentinel.

Figura 30: Creazione Playbook

Figura 31: Creazione LogicApp per blocco utente

Ecco ora come dovrete impostare la LogicApp per permettere il blocco dell’utenza.

Figura 32: Inserimento Account con diritti corretti per permettere la lettura degli Incident di Microsoft Sentinel

Figura 33: Inserimento Entities per recuperare le entità coinvolte all’interno dell’incident

Figura 34: For Each Accounts coinvolti nell’incident genera un Job di Azure Automation

Ora dovrete “recuperare” i nomi di Automation Account, Resource Group, Automation Hybird Group e nome del Runbook creati nei passaggi precedenti.

Figura 35: Inserimento parametri per Azure Automation relativi a quanto creato in precedenza

Ora vi mancherà l’ultimo step: creare una Analytics Rule per eseguire una ricerca.

Figura 36: Creazione Analytics Rule

Figura 37: Scelta di un nome ed una descrizione della regola di Analitica

Figura 38: Inserimento KQL e parsing del nome entità da “passare” poi alla LogicApp per permettere il blocco dell’utente

Figura 39: Salvataggio della Regola di Analitica

Ora vi basterà associare la regola di Analitica al Playbook ed il gioco è fatto, in questo modo quanto verrà eseguito il match della regola verrà attivato il flusso.

Figura 40: Creazione regola di automazione per gestire Alert di Microsoft Sentinel

Figura 41: Parametri da inserire per la creazione della regola di automazione di Microsoft Sentinel

Figura 42: Regola di Automazione creata correttamente

Per darvi evidenza del funzionamento ho generato diverse login failed con l’utente m365-demo\utente.malevolo per far attivare la regola.

Figura 43: LogicApp eseguita con successo

Ora vi mostro l’utente all’interno di Active Directory che risulterà bloccato.

Figura 44: Utente che risulta disabilitato in Active Directory in modo corretto

Ricordo inoltre che, essendo le utenze sincronizzate attraverso Entra Connect, il blocco dell’utenza si replica anche verso Microsoft Entra ID.

Figura 45: Blocco dell’utenza avvenuto anche verso Office 365

Conclusioni

In un mondo dove lo scenario è Ibrido ed i nostri dispositivi ed utenti risiedono on-prem e poi vengono replicati verso il mondo Cloud, avere a disposizione diversi strumenti che vi permettono di rispondere in modo del tutto automatico ad Incident di sicurezza potrebbe aiutarvi in modo considerevole a ridurre i tempi di risposta ed ottimizzare le risorse a vostra disposizione.

Sentinel SIEM e SOAR di casa Redmond vi permette quindi di eseguire il blocco di un’utenza on-prem direttamente da un portale cloud, avendo a disposizione una sola interfaccia di gestione per i vostri ambienti Ibridi è uno scenario a mio avviso straordinario, in un modo sempre “caotico” e dove siamo sempre di corsa a “saltare” da un portale all’altro, l’unione di tutti questi servizio vi permette di ottimizzare tempo e risorse che potrete investire in altri ambiti.