• Cloud, Guide, Sicurezza
• 29 Gennaio 2026

Microsoft Sentinel, la piattaforma SIEM e SOAR di casa Redmond, consente alle organizzazioni di centralizzare la raccolta dei log, correlare eventi provenienti da sorgenti eterogenee e automatizzare i processi di risposta agli incidenti di sicurezza. Grazie a un’architettura cloud-native e all’integrazione nativa con l’ecosistema Microsoft, Sentinel permette di ottenere una visibilità completa sullo stato della sicurezza, riducendo i tempi di rilevamento e mitigazione delle minacce.
Attraverso funzionalità avanzate di analisi, orchestrazione e automazione, le aziende possono reagire in modo rapido ed efficace a incidenti di sicurezza critici, migliorando sensibilmente la postura di sicurezza complessiva e ottimizzando il lavoro dei team di CyberSecurity.

Ho parlato già all’interno della community di come Microsoft Sentinel può rispondere ad attacchi di Brute Force in RDP, a tal proposito vi rimando all’articolo della community per eventuali approfondimenti Come Microsoft Sentinel può rispondere ad attacchi di Brute Force? Scopriamolo Insieme! – ICT Power

Ma come possiamo automatizzare il Blocco dell’indirizzo IP Malevolo per non permettere più il collegamento in RDP alla nostra Virtual Machines in hosting presso Microsoft Azure?

Una domanda lecita e precisa, sappiamo che nel mondo della sicurezza informatica il tempo è fondamentale, e rispondere in modo automatico ad incident di sicurezza può veramente fare la differenza tra contenere un attacco e subirne le conseguenze.

Avete presente quando ricevete un alert per Brute Force RDP Connection e dovete, in modo manuale, bloccare l’IP sorgente di questo attacco informatico?

Ecco, la soluzione che vedremo in questo articolo servirà proprio a questo.

Avremo una Virtual Machines in Microsoft Azure che sarà sotto attacco di Brute Force, Microsoft Sentinel, tramite alert segnalerà questo attacco ed in modo automatico l’IP di provenienza di questo attacco verrà bloccato inserendo un Deny sulla scheda di rete di quella VM per le connessioni provenienti da quell’indirizzo IP Malevolo.

Che licenze sono necessarie per utilizzare questa funzionalità?

Nel caso specifico la licenza è quella relativa a Microsoft Azure, nel mio caso utilizzerò una Subscription a consumo che conterrà sia la Virtual Machine e sia il Workspace di Microsoft Sentinel

Figura 1: Server “ITBGDC01” con sistema operativo Windows Server 2022 che sarà oggetto dell’attacco di Brute Force

Figura 2: Subscription di Microsoft Azure utilizzata per ospitare il Workspace di Microsoft Sentinel

Figura 3: Workspace di Microsoft Sentinel

Oramai tutte le funzionalità relativa alla componente di Security stanno pian piano traslando sul portale di Microsoft Defender per avere un’unica piattaforma di accesso sia per gli IT Admin che per gli analisti di sicurezza.

Specifico che i “Windows Security Event” della mia Virtual Machines “ITBGDC01” sono già riportati in Microsoft Sentinel, eseguirò quindi la seguente query (KQL) per darvi evidenza che i log sono già presenti nella tabella “Security Event”

SecurityEvent
| where Computer == “ITBGDC01.doreminio.local”

Sostanzialmente ricerco nella tabella “SecurityEvent” tutti gli eventi che provengono dal mio Domain Controller

Figura 4: KQL Scritta per darvi evidenza della presenza dei log di Windows della macchina di demo

Figura 5: Risultato della KQL appena eseguita

Se volete capire come creare la Data Collection Rule (DCR) per collezionare i log da dispositivi on-prem vi rimando sempre all’articolo in cui spiego come sentinel risponde ad attacchi di Brute Force Come Microsoft Sentinel può rispondere ad attacchi di Brute Force? Scopriamolo Insieme! – ICT Power

Ora possiamo creare una Analytics Rule in Microsoft Sentinel che ci permetta di recuperare solo gli eventi di Login Failed e ci generi un alert quando c’è un tentativo di Brute Force, la KQL può essere strutturata in questo modo in cui vengono recuperate solo i login falliti:

SecurityEvent
| where EventID == 4625
| project TimeGenerated, EventID, WorkstationName, LogonTypeName, Account, Computer, IpAddress
| extend AccountEntity = Account
| extend IPEntity = IpAddress

Figura 6: Risultato della KQL vista in precedenza

Ora possiamo creare la Analytics Rule in Microsoft Sentinel, lo facciamo direttamente dal portale di Microsoft Defender

Figura 7: Scegliamo di creare una Analytics Rule con schedulazione

Figura 8: Scegliamo nome e descrizione parlante, una severity coerente e proseguiamo con la configurazione

Figura 9: Inseriamo la KQL che abbiamo visto in precedenza e procediamo al mapping delle entità

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 10: Mapping delle entità e schedulazione della Analytics Rule

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

Figura 12: Nel mio caso c’è un Playbook che mi invia una mail quando viene generato l’incident, proseguiamo con la configurazione

Figura 13: Regola “validata” procedo con il salvataggio

Ora la regola è correttamente creata, procederò a simulare un Brute Force mediante una macchina KALI LINUX utilizzata per questi scopi solo ed esclusivamente per Demo e/o scopi didattici lo scrittore non si prende responsabilità per l’uso proprio di questi tools

Figura 14: Incident presente all’interno del portale di Microsoft Defender

Figura 15: Playbook che ho creato che mi invia una mail con i dettagli dell’Incident

Ora come procediamo al blocco in modo automatico dell’indirizzo IP di provenienza dell’attacco?

Ora però dovremmo creare un blocco in modo automatico di questo IP inserendolo come Deny all’interno della scheda di rete della nostra macchina Virtuale in Microsoft Azure, per farlo utilizzeremo una Azure Logic App messa a disposizione in Github Azure-Sentinel/Playbooks/Add-IP-Entity-To-NSG/readme.md at master · Azure/Azure-Sentinel · GitHub dovremmo avere però a disposizione alcuni parametri per poi modificare il json, che per comodità vi riepilogo di seguito:

• SubscriptionID in cui è presente il Network Security Group della Virtual Machine
• Il Network Security Group Name della Virtual Machine
• Il nome del Resource Group in cui è presente NSG della Virtual Machine

Per trovare il SubrscriptionID

Figura 16: Copiarsi il SubscriptionID

Successivamente dobbiamo recuperare e copiarci, ci serviranno negli step successivi, il nome del Resource Group e del Network Security Group in cui è presente la VM, nel mio caso il domain controller ITBGDC01

Figura 17: Copiamoci il nome del “Network Security Group”

Figura 18: Copiamoci il nome del Resource Group

Ora, andando su Github possiamo procedere ad implementare la Logic App, ringraziamo Brian Eld per la logic app.

Figura 19: Deploy della logic app in Microsoft Azure

Figura 20: Scegliere la Subscription e il Resource Group in cui eseguire il deploy della logic-app

Dovrete prendere il contenute del punto “2” e sostituire /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/networkSecurityGroups/<nsgName> con i parametri copiati in precedenza

Figura 21: Copiamo la stringa con i parametri corretti e scegliamo una priorità della regola nel mio caso 150 così la metto on top

Figura 22: Creiamo la Logic App di Azure

Figura 23: Risorse create nel modo corretto

Ora dobbiamo procedere ad assegnare a questa Logic App due permessi, che saranno necessari per:

• Inserire regola in DENY sul Network Security Group à Network Contributor, nel mio caso sul resource group “RG-ICTPOWER”, deve essere quello in cui è presente la scheda di rete della macchina Virtuale
• Leggere I dati dell’Incident in Microsoft Sentinel à Microsoft Sentinel Responder, nel mio caso sul resource group “RG-SIEM”. Deve essere quello in cui è presente il Workspace di Microsoft Sentinel

Figura 24: Assegnazione permesso della Logic App sui relativi resource group

Figura 25: Selezionare la corretta Subscription e procedere all’assegnazione del ruolo

Figura 26: Assegnazione ruolo Network Contributor

Figura 27: Assegnazione ruolo Microsoft Sentinel Contributor

Figura 28: Permessi assegnati correttamente

Ora dobbiamo solo procedere ad assegnare il Playbook alla generazione di un incident di Brute Force, ritorniamo nel portale di Microsoft Defender

Figura 29: Generazione di una Automation quando viene eseguito il Trigger di un Incident

Figura 30: Diamo un nome alla regola, la faremo “scattare” quando viene creato un incident con il titolo della Regola che abbiamo creato e faremo eseguire il Playbook

NB: La macchina virtuale ha un RDP Permesso in Any come demo, se avete una VM in Cloud non pubblicate mai il protocollo RDP in Internet senza controlli

Figura 31: Regole Network attualmente presenti nella Virtual Machines prima che il Playbook eseguisse il suo “lavoro”

Ora eseguirò un tentativo di Brute Force per darvi evidenza del comportamento della regola di Automazione con il Playbook

Figura 32: Dopo Brute Force l’Incident viene correttamente creato

Figura 33: Regola di Automazione che ha fatto girare il Playbook in modo corretto

Figura 34: Regola creata nel modo corretto per bloccare il traffico dall’indirizzo IP

Conclusioni

L’episodio di brute force analizzato dimostra quanto sia fondamentale adottare un approccio proattivo alla sicurezza in ambienti cloud come Microsoft Azure. Grazie all’integrazione di Microsoft Sentinel, è stato possibile non solo individuare tempestivamente l’attività malevola proveniente da un indirizzo IP sospetto, ma anche automatizzare la risposta tramite il blocco immediato dell’IP, riducendo drasticamente la superficie di attacco e i tempi di reazione.

L’automazione delle risposte agli incidenti, supportata da playbook e regole di analisi, rappresenta un valore aggiunto significativo: consente di mitigare le minacce in tempo reale, limitando l’intervento manuale e minimizzando il rischio di compromissione dei sistemi. Questo caso evidenzia come l’adozione di soluzioni SIEM/SOAR avanzate non sia solo una scelta strategica, ma una necessità per garantire un adeguato livello di sicurezza operativa.