• Cloud, Guide, Microsoft 365, Sicurezza
• 31 Luglio 2026

Defender for Endpoint e Microsoft Sentinel, rispettivamente la componente XDR (Extended Detection & Response) e la componente SIEM e SOAR di casa Redmond.

All’interno della community abbiamo parlato a lungo di questi due workload e di come possano in modo sinergico aiutare le organizzazioni ad aumentare la postura di sicurezza e rispondere in modo rapido ed efficace ad Incident critici di sicurezza, a questo proposito vi lascio il link alle guide della community che racchiudono tutti gli articoli inerenti a queste due tecnologie:

• Microsoft Sentinel – ICT Power
• Defender – ICT Power

Ora vorrei parlavi ancora di una sinergia tra questi due strumenti e di come poter sfruttare i log applicativi di Defender for Endpoint per creare degli Use Case in Microsoft Sentinel per le Detection in caso di attacco mirato a sospendere la protezione della componente XDR.

Sappiamo tutti che se un attaccante accede ad un dispositivo di un utente, la prima operazione che cerca di fare è quella di disabilitare i motori AV per poi agire in modo indisturbato, ovviamente esistente la Tamper Protection che non permette le modifiche alle configurazione o lo stop dei servizi, ma è fondamentale monitorare anche queste situazioni e creare degli scenari in Microsoft Sentinel che permettano ai reparti di CyberSecurity di avere maggiore visibilità in caso di comportamenti anomali dei sistemi XDR.

Figura 1: Funzionalità di Microsoft Defender for Endpoint

Figura 2: Funzionalità chiave di Microsoft Sentinel

Per darvi evidenza di come poter implementare questa funzionalità utilizzerò in Client Windows 11 presente all’interno della console di Microsoft Defender e Workspace di Microsoft Sentinel, tutto è creato grazie ad una Subscription di Microsoft Azure a consumo e delle licenze Microsoft 365 E5 per l’uso della componente XDR.

Ci sono eventi specifici che permettono di identificare problematiche di sicurezza con Microsoft Defender for Endpoint?

Sebbene Defender for Endpoint (MDE) includa diverse impostazioni contro la “manomissione” e alert per rilevare questa attività, gli attaccanti cercano in modo costante di poter aggirare e terminare con successo la componente Antivirus.

Ci sono però scenari in cui le organizzazioni non possono applicare la protezione Antitamper su tutti i dispositivi e gli attaccanti possono bypassare le difese e trovare nuovi approcci per eludere meccanismi di difesa. Proprio per questo motivo a mio avviso è importante monitorare anche i log correlati a Defender e rispondere in modo preciso e puntuale in caso di comportamenti dannosi.

Vi riporto quindi gli eventi molto utili proprio a questo scopo:

• 3002 – Real-time protection encountered an error and failed.
• 5001 – Real-time protection is disabled.
• 5008 – The antimalware engine encountered an error and failed.
• 5010 – Scanning for malware and other potentially unwanted software is disabled.
• 5012 – Scanning for viruses is disabled.

Il prerequisito è avere una Data Collection Rule per collezionare gli eventi indicati, quindi agganciare le macchine in Azure Arc, oppure sfruttare AMA (Azure Monitoring Agent) per le macchine già presenti in Microsoft Azure.

Nel mio caso è una macchina Windows 11 in Hosting presso Microsoft Azure chiamata ITBGICTPOWER03 che risulta essere gestista ed onbordata in Microsoft Defender

Figura 3: Dispositivo di Demo presente in Microsoft Defender

Figura 4: Workspace di Microsoft Sentinel che utilizzerò per collezionare i log dell’Endpoint

Figura 5: Dispositivo demo è una macchina virtuale in Microsoft Azure che mi permetterà di creare la DCR e applicarla

Procediamo quindi a creare ora la Data Collection Rule (DCR) che installerà in automatico sulla VM Azure Monitoring Agent (AMA) che si occuperà di collezionare i log, ma prima si rende necessario di Installare il connettore

Figura 6: Installazione del connettore relativo a “Windows Forwarded Events”

Figura 7: Configurazione del connettore appena installato

Figura 8: Procediamo a configurare la Data Collection Rule

Figura 9: Scegliamo un nome della regola, la Subscription ed il Resource Group in cui inserire la DCR

Figura 10: Selezioniamo la macchina a cui applicare la DCR

Ora dovremo inserire la seguente stringa Custom per collezzionare solo gli eventi che vi ho indicato in precedenza “Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=3002) or (EventID=5001) or (EventID=5008) or (EventID=5010) or (EventID=5012)]]”

Figura 11: Scrittura della regola Custom per collezionare solo i log che ci servono

Figura 12: Creazione della DCR

Ora dovremmo attendere che all’interno della macchina in Hosting presso Azure venga eseguito il deploy di AMA

Figura 13: Estensione correttamente installata sulla macchina ora la DCR comincerà a collezionare i log indicati

Ora potete procedere, tramite Advanced Hunting, a verificare la ricezione degli eventi tramite la seguente KQL

Figura 14: Attività che viene correttamente vista con una Query all’interno della Tabella “WindowsEvents”

Ora si rende necessario creare una regola NRT (Near Real Time) per procedere a generare un alert di Microsoft Sentinel quando vengono trovati risultati tramite questa Query

Figura 15: Creazione regola NRT per Microsoft Sentinel

Figura 16: Scegliete un nome ed una descrizione parlante

Figura 17: Inserimento KQL e mapping delle entità dell’Incident

Figura 18: Proseguiamo nella configurazione

Figura 19: Proseguiamo con la configurazione aggiungendo delle regole di automazione se le abbiamo a nostra disposizione

Figura 20: Validazione della regola e creazione

Figura 21: Disabilitiamo per test la Tamper Protection sul nostro Endpoint

Figura 22: Tamper Protection Disabilitata

Ora rechiamoci all’interno del portale di Microsoft Defender

Figura 23: Incident presente all’interno del portale di Defender

Figura 24: Dettaglio dell’Incident con Tanto di grafico disponibili all’interno di Microsoft Defender

Conclusioni

Gli attaccanti se entrano in un dispositivo la prima attività che cercano di fare è quella di disabilitare la protezione del sistema Antivirus, questa operazione se collezionata all’interno di un sistema come Microsoft Sentinel che permettere di correlare gli eventi all’interno di un unico portale, al giorno d’oggi è un must per le organizzazioni.

Avere un Incident di priorità critica quando viene disabilitata la protezione è un vantaggio non indifferente per i Team di sicurezza che possono analizzare poi l’attività e capire se è lecita o meno, la tempistica di intervento in questi casi è fondamentale e l’utilizzo delle regole NRT in Microsoft Sentinel risponde proprio a questa esigenza.

In sicurezza il tempo è fondamentale e questi strumenti ci permettono di essere rapidi e veloci prima che un incident si trasformi in un grandissimo problema per le nostre organizzazioni.