• Cloud, Guide, Microsoft 365, Sicurezza
• 23 Marzo 2026

Regole di Attack Surface Reduction (ASR): quanti di voi avranno sentito questa nomenclatura nel quotidiano, ma soprattutto quanti di voi hanno impiegato diverso effort nel configurare in modo opportuno le esclusioni dopo la modalità di Audit?

Ma prima di rispondere a questa domanda, vediamo insieme cosa sono queste regole e come aiutano le organizzazioni a ridurre in modo notevole la superfice di attacco degli Endpoint quando viene utilizzata la piattaforma di Endpoint Protection di Casa Redmond.

Perché le ASR sono così importanti?

La superfice di attacco dell’organizzazione include tutte le posizioni in cui un utente malintenzionato potrebbe compromettere i dispositivi o le reti dell’organizzazione. Ridurre la superfice di attacco significa proteggere dispositivi e rete dell’azienda, lasciando agli utenti malintenzionati un minor numero di modi per eseguire gli attacchi.

La configurazione delle regole di riduzione della superficie di attacco in Microsoft Defender per endpoint può essere utile proprio per questo motivo.

Le regole di ASR sono destinate quindi a difendere l’organizzazione da determinati comportamenti Software come ad esempio:

• Avvio di file eseguibili e script che tentano di scaricare o eseguire file
• Esecuzione di script offuscati o in altro modo sospetti
• Esecuzione di comportamenti che le app in genere non avviano durante il normale lavoro quotidiano

Questi comportamenti sono spesso considerati rischiosi perché vengono comunemente abusati dagli attaccanti tramite malware. Le regole ASR possono limitare i comportamenti rischiosi basati sul software e proteggere l’organizzazione.

Prerequisiti

Le regole di Attack Surface Reduction possono essere utilizzate solo ed esclusivamente su Sistemi Operativi Windows, Client e Server che per comodità vi riporto:

• Windows 10 Pro, version 1709 or later
• Windows 10 Enterprise, version 1709 or later
• Windows 11 Pro, version 21H2 or later
• Windows 11 Enterprise, version 21H2 or later
• Windows Server, version 1803 (Semi-Annual Channel) or later
• Windows Server 2025
• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Azure Stack HCI OS, version 23H2 and later

Modalità Attack Surface Reduction

Esistono 3 modalità differenti per le ASR:

• Audit: con questa modalità non viene eseguito nessun blocco, ma viene tenuta traccia degli eventuali blocchi che sarebbero occorsi qual’ora la regola fosse stata in block mode, questa modalità è comoda in fase di startup della soluzione per configurare le opportune esclusioni, è bene specificare che lato utente con questa casistica non compare nessun avviso quindi è completamente trasparente
• Block: la regola blocca il comportamento sospetto dell’applicazione con messaggio all’utente
• Warn: il contenuto viene bloccato, facendo comparire un messaggio all’utente che ha la possibilità di “sbloccare” il contenuto per 24H

Per la modalità Warn vi sono alcuni requisiti che vi riporto:

• Windows 10, versione 1809 o versioni successive
• Windows 11
• Windows Server versione 1809 o successiva
• Requisito minimo di rilascio della piattaforma: 4.18.2008.9
• Requisito minimo di rilascio del motore: 1.1.17400.5

La modalità Warn inoltre non è supportata per i seguenti eventi ASR:

• Impedire a JavaScript o VBScript di avviare il contenuto eseguibile scaricato (GUID d3e037e1-3eb8-44c8-a917-57927947596d)
• Bloccare la persistenza tramite la sottoscrizione di eventi WMI (GUID e6db77e5-3df2-4cf1-b95a-636979351e5b)
• Usare la protezione avanzata da ransomware (GUID c1db55ab-c21a-4637-bb3f-a12568109d35)

Per comodità vi riporto anche la lista completa delle regole ASR disponibili in Microsoft Defender for Endpoint

¹ Questa regola asr non rispetta Microsoft Defender esclusioni antivirus. Per informazioni sulla configurazione delle esclusioni per regola dell’ASR, vedere Configurare le esclusioni per regola per la riduzione della superficie di attacco.

² Questa regola asr non rispetta Microsoft Defender per endpoint indicatori di compromissione (IOC) per file o certificati.

³ Attualmente, questa regola asr potrebbe non essere disponibile nella configurazione dei criteri di riduzione della superficie di attacco Intune a causa di un problema back-end noto. Tuttavia, la regola esiste ancora ed è disponibile tramite altri metodi. Ad esempio, Microsoft Defender per endpoint la gestione delle impostazioni di sicurezza, il provider di servizi di configurazione (CSP), Add-MpPreference o la configurazione esistente dei criteri Intune ASR nelle regole create prima del problema.

⁴ Questa regola asr non rispetta Microsoft Defender per endpoint indicatori di compromissione (IOC) per i certificati.

Come posso verificare quali regole “scattano”?

Per verificare quali regole stanno bloccando il contenuto o che “scattano” in modalità Audit ci sono due modi:

• Report Microsoft Defender XDR
• Query di Hunting

Per visualizzare i Report ASR in Microsoft Defender XDR recatevi all’interno del portale Microsoft Defender

Figura 1: Sezione report di Microsoft Defender XDR

Figura 2: Overview delle regole ASR ed eventuale Export delle stesse

Figura 3: File di Export che contiene le detection

Invece per procedere attraverso la funzionalità di Hunting di Microsoft Defender accedete al portale di Defender XDR

Figura 4: KQL per Hunting utile alla ricerca degli eventi ASR nei device con relativo download

Figura 5: File csv risultato dell’Export prodotto

Una volta che si hanno queste informazioni è possibile modificare la policy di ASR per configurare le opportune esclusioni, prendiamo come esempio il mio dispositivo aadj-guido

Figura 6: Selezioniamo il pc al quale abbiamo visto il blocco della regola in precedenza con uno dei metodi

Figura 7: Regola ASR che è applicata al device

Prima avevamo verificato che la regola bloccava “svchost.exe” in questa regola ASR “AsrLsassCredentialTheftBlocked”

Figura 8: Entriamo in modalità “edit” nella regola per configurare l’esclusione

Figura 9: Cerchiamo la regola che bloccava il processo e configuriamo l’esclusione

NB: Il processo indicato è di sistema ed è utilizzato per test, non escludete tale processo dalle regole ASR per motivi di sicurezza

Figura 10: Inseriamo il path o il processo da escludere e proseguiamo

Figura 11: Proseguiamo con la configurazione

Figura 12: Salvataggio della modifica con relativa esclusione

Ma in fase di deploy della soluzione su un numero elevato di Endpoint c’è qualcosa che può darmi una mano?

Questa è la domanda che mi sono posto mentre stavo implementando le funzionalità avanzate di Microsoft Defender XDR, allora ho cercato di creare qualcosa in modo pratico che possa essere però anche d’aiuto a tante altre persone che si trovano nella medesima situazione.

Uno script PowerShell con interfaccia grafica, che tramite API, si colleghi al Tenant Microsoft 365 verifichi quali ASR risulta in modalità blocco e permetta di inserire direttamente le esclusioni nella rispettiva regola senza dover accedere ogni volta al tenant.

Questo permette di avere visibilità in fase di delivery per gli operatori che devono configurare esclusioni in modo quotidiano nelle prime fasi di implementazione.

Vi fornisco passo dopo passo l’implementazione ed il risultato finale.

Come prima cosa bisogna creare una App in EntraID con i permessi corretti è importante dire che è necessario utilizzare PowerShell 7.X

Accediamo quindi a Microsoft Entra Admin Center

Figura 13: Microsoft Entra Admin Center per registrazione nuova app di EntraID

Figura 14: Registrazione di una nuova app di EntraID

Figura 15: Scegliamo un nome per la APP e clicchiamo su “Register” nel mio caso ho dato il nome ASRManager

Figura 16: Copiatevi ora “Application (client) ID o Directory (tenant) ID”

Figura 17: Ora creiamo il Secret, dando un nome parlante ed una durata consona, ricordatevi che allo scadere per far funzionare l’applicazione sarà da rinnovare

Figura 18: Copiatevi il Value, attenzione che se eseguite il refresh della pagina il token non sarà più disponibile e sarà da rigenerare

Figura 19: Ora dobbiamo fornire i permessi necessari all’APP per eseguire quanto richiesto

I permessi necessari sono i seguenti:

• Device.Read.All
• DeviceManagementConfiguration.ReadWrite.All
• DeviceManagementManagedDevices.Read.All
• Group.Read.All
• ThreatHunting.Read.All

Figura 20: Scegliamo Application Permissions

Figura 21: Selezioniamo i permessi e poi “Add Permissions” operazione da ripetere per tutti i permessi sopra indicati

Figura 22: Verifica permessi a Grant degli stessi sulla APP

Figura 23: Permessi concessi nel modo corretto

Ora dovrete scaricare lo Script PowerShell che ho messo all’interno del mio Repository di GitHub a beneficio della community Gaudium1991/ASRExceptionManager: Include script to manage ASR Exclusion on Endpoint from an interface and API

Figura 24: Download dello Script

All’interno del repository di GitHub trovate anche un file README.md che vi permetterà di capire cosa fa lo script ed eventuali prerequisiti

Figura 25: Download del file ZIP contenente lo script

Figura 26: Script presente nella cartella Download, procederò a copiarlo ed estrarlo in un path locale nel mio caso “C:\service\ASRExceptionManager”

Figura 27: Tasto destro sul file zip e click su “Extract All”

Figura 28: Scegliete il path in cui estrarre i file e successivamente click su “Extract”

Figura 29: File estratti in modo corretto

Questo è il path in cui risiede lo script nel mio caso “C:\Service\ASRExceptionManager\ASRExceptionManager-main\ASRExceptionManager-main” nel mio caso lo sposto nella cartella padre “C:\Service\ASRExceptionManager”

Figura 30: Script copiato all’interno della cartella padre per comodità

Ora procediamo ad aprire PowerShell 7.X, non è necessario eseguire un RunAs Administrator

Figura 31: Apertura PowerShell 7.X

Figura 32: Comando PowerShell per “spostarmi” nella cartella in cui è presente lo script

Figura 33: Comando PowerShell per vedere il contenuto della cartella, è presente lo script

Ora Basterà inserire il nome dello script e premere invio per avviare l’interfaccia grafica

Figura 34: Avvio dello script direttamente da PowerShell

Figura 35: Interfaccio dello script una volta eseguito, in cui compare l’interfaccia grafica

Ora il primo passaggio che dovrete fare è inserire ApplicationID, TenantID e Secret

Figura 36: Inserimento dei parametri per permettere allo script di collegarsi al Tenant tramite API

Figura 37: Connessione riuscita in modo corretto

Figura 38: Selezionare il numero di giorno per la ricerca

Figura 39: Lista delle ASR con descrizione se “Block” or “Audit” gruppi a cui il device appartiene e regola ASR di appartenenza del device

Figura 40: Possibilità di inserire il patch o eventualmente il file da escludere, se nella regola che ha eseguito il math o tra le Global Exclusion e quindi escludere da tutte le ASR

Giusto per darvi evidenza vi fornisco la policy ASR a cui appartiene il client ITBGDC01 che non ha quel path specifico escluso al momento

Figura 41: Policy in Modalità blocco ma nessuna esclusione presente

Figura 42: Configuriamo sia la Global Exclusion e per Rule così da darvi evidenza di entrambe delle esclusioni

Figura 43: Lo script ci indica che è stata creata l’esclusione in modo corretto e verificata indicandoci anche la policy

Ora eseguo un refresh della pagina relativa alla policy “ASR – Demo Device” per darvi evidenza che l’esclusione è stata applicata correttamente

Figura 44: Per rule Exclusion andata a buon fine

Figura 45: Esclusioni Globale Andata a buon fine

NB: Vi invito a segnalare eventuali richieste di implementazioni feedback e/o problemi dello script su GitHub per migliorarlo e rendere il lavoro più semplice a tutta la community

Inoltre la funzionalità Download permette di eseguire il download in formato csv delle ASR che sono presenti

Figura 46: Selezioniamo il percorso in cui salvare il file

Figura 47: Risultato dell’Export del file

Conclusioni

Le regole di Attack Surface Reduction rappresentano uno strumento fondamentale per aumentare il livello di sicurezza degli endpoint, riducendo in modo significativo le superfici di attacco sfruttabili da malware e attori malevoli. Come visto, la loro efficacia dipende fortemente da una corretta fase iniziale di analisi in modalità Audit e da una configurazione attenta delle policy, in particolare per quanto riguarda la gestione delle esclusioni. L’adozione delle ASR non è un’attività “one-shot”, ma un processo continuo che richiede monitoraggio, ottimizzazione e collaborazione tra team di sicurezza e operations.

In questo contesto, l’automazione gioca un ruolo chiave: disporre di uno strumento che consenta agli IT Operations di gestire le esclusioni senza dover accedere ogni volta al tenant Microsoft 365 rappresenta un enorme vantaggio operativo, soprattutto in fase di rollout o in ambienti complessi e distribuiti.

Questo approccio permette di ridurre i tempi di intervento, migliorare l’efficienza operativa e garantire una maggiore coerenza nella gestione delle policy di sicurezza.

Questo script è stato progettato per la community, dalla community: uno strumento pratico creato per semplificare le operazioni quotidiane, favorire la condivisione delle conoscenze e supportare i professionisti IT nella gestione delle configurazioni ASR in modo più efficace.