Rischio di Windows Attachment Manager: verificare i criteri utente

Che cos’è il rischio di Windows Attachment Manager?

Il rischio di Windows Attachment Manager riguarda i criteri di gestione dei file: quale allegato genera un avviso o un blocco, per quale utente e in quale applicazione? Un inventario delle GPO può individuare impostazioni da esaminare, ma per chiudere la verifica servono evidenze del flusso di lavoro dell’utente previsto.

Due situazioni richiedono decisioni diverse. Un inventario che non contiene né DefaultFileTypeRisk né LowRiskFileTypes pone una domanda sulla configurazione esplicita. Un criterio che seleziona un rischio predefinito basso o aggiunge estensioni di script a un elenco a basso rischio pone una domanda su un’eccezione esplicita. Considerare entrambi i casi una prova che tutti gli script scaricati vengano eseguiti senza avvisi andrebbe oltre le evidenze disponibili.

Questa guida usa la documentazione Microsoft Learn e il codice di etc-collector esaminato. I comandi Windows riportati sotto sono esempi di lettura basati sulla documentazione, non comandi eseguiti in un ambiente Windows per questo articolo. La procedura pilota è un metodo di verifica proposto; non si dichiarano test riusciti, un numero di postazioni interessate o un attacco.

Funzionamento: valori predefiniti, elenchi e contesto applicativo

Il riferimento ai criteri di Attachment Manager di Microsoft colloca queste impostazioni in Configurazione utente > Modelli amministrativi > Componenti di Windows > Attachment Manager, con le corrispondenze di rischio ed elenchi in Software\Microsoft\Windows\CurrentVersion\Policies\Associations.

Il comportamento documentato distingue tre classi di rischio:

Un criterio del rischio predefinito non configurato o disabilitato mantiene un rischio moderato. Un criterio di basso rischio non configurato mantiene la logica di attendibilità predefinita. L’inclusione personalizzata ad alto rischio ha precedenza sulle inclusioni a rischio medio e basso; quella a rischio medio precede quella a rischio basso. L’inclusione a basso rischio prevale sull’elenco integrato ad alto rischio, quindi le sovrapposizioni degli elenchi personalizzati contano. La logica di attendibilità predefinita privilegia il gestore; il criterio separato della logica di attendibilità può modificare questa valutazione. Definizioni dei criteri Microsoft

Anche il contesto applicativo fa parte del meccanismo. Il riferimento a IAttachmentExecute di Microsoft descrive un’interfaccia usata dalle applicazioni client, che comprende controlli dei criteri, avvisi e operazioni di salvataggio ed esecuzione. SetSource fornisce informazioni sull’origine e SetReferrer il contesto dell’area; il client ha anche proprie impostazioni degli allegati. Questo non dimostra che tutte le applicazioni usino l’interfaccia nello stesso modo.

Per una verifica, individuare l’applicazione che riceve il file, l’azione compiuta dall’utente e le informazioni sulla provenienza disponibili in quel momento. Un risultato di rilevamento non può colmare queste lacune. Non passare da una stringa di criterio a livello di dominio a un’affermazione su un browser, client di posta, associazione di file o percorso di avvio sconosciuti.

Rilevamento: inventariare i criteri utente e confrontare il pilota

Passaggio 1: conservare la configurazione delle GPO

Inventariare le GPO pertinenti prima di modificarle. Registrare l’identità di ogni GPO, i collegamenti, l’ambito utente, i filtri, l’ora della raccolta e i valori grezzi dei criteri. Esaminare Configurazione utente e il file User\Registry.pol decodificato, senza presumere che un rapporto sui criteri del computer contenga le impostazioni degli allegati. Conservare le configurazioni contraddittorie per riconciliarle.

Il foglio di verifica deve includere:

Distinguere valori assenti, vuoti, non raccolti e letture fallite. In particolare, il parser usato dai due controlli EtcSec non conserva una stringa LowRiskFileTypes vuota. Un campo assente dopo l’analisi non è quindi sufficiente a ricostruire lo stato originale del criterio.

I nostri quattro controlli di sicurezza GPO Active Directory spiegano la stessa disciplina per altre impostazioni: conservare la configurazione, individuare l’ambito destinatario e verificare le evidenze del client. I controlli LLMNR, WSUS, LSASS e UNC offrono un metodo di verifica utile, mentre questa indagine riguarda la gestione degli allegati utente.

Passaggio 2: recuperare il risultato dei criteri dell’utente di destinazione

Sul computer pilota, usare la sessione dell’utente previsto e ottenere il riepilogo dell’ambito utente:

gpresult /scope user /r

Per una registrazione più dettagliata, eseguire separatamente:

gpresult /scope user /z

Il riferimento a gpresult di Microsoft documenta l’ambito utente, l’output riepilogativo e quello dettagliato dei criteri. Risolvere le divergenze tra l’inventario delle GPO e il risultato riportato prima di interpretare i valori locali. Conservare gli errori come tali; un rapporto non disponibile non può sostituire la prova che la GPO prevista sia stata applicata.

Passaggio 3: leggere i valori del registro utente

Eseguire ogni comando separatamente nel contesto dell’utente previsto. Questi esempi combinano la sintassi di reg query documentata da Microsoft con la chiave Associations indicata sopra:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v DefaultFileTypeRisk

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v LowRiskFileTypes

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v HighRiskFileTypes

HKCU identifica l’hive dell’utente corrente. Eseguire la query come un amministratore diverso cambia il soggetto dell’osservazione. Conservare comando, account, host, ora, tipo di valore e output; distinguere un valore assente da un errore del comando. Confrontare queste letture con la GPO responsabile e il risultato dei criteri, invece di sostituire un output mancante con un valore presunto sicuro o non sicuro.

Passaggio 4: confrontare la configurazione con la gestione osservata

Definire un pilota autorizzato con file rappresentativi innocui e i responsabili delle applicazioni. Registrare estensione, provenienza, informazioni sull’area se disponibili, applicazione destinataria, azione selezionata e se l’accesso sia stato bloccato, abbia generato un avviso o sia stato consentito. Conservare i risultati inattesi per l’indagine; non inserire nel registro un avviso atteso come se fosse stato osservato.

Usare una matrice con una riga per ogni flusso testato. Includere un riferimento alla configurazione prima/dopo e il risultato effettivo. Un risultato ottenuto mediante un’azione di un client di posta sostiene quella specifica osservazione; non dimostra tutti i percorsi di avvio locali o tutte le popolazioni di utenti. Queste fonti non stabiliscono un Windows Event ID universale per questa verifica della configurazione.

Correzione: esaminare le eccezioni prima di modificare gli avvisi (Remediation)

Passaggio 1: assegnare la responsabilità della configurazione

Individuare l’amministratore responsabile del criterio utente che prevale e i responsabili delle applicazioni che richiedono eccezioni. Riunire il valore predefinito grezzo e tutti gli elenchi di inclusione pertinenti nella stessa verifica. Conservare l’esportazione iniziale affinché la decisione possa essere ricondotta a una configurazione reale anziché a una descrizione abbreviata del risultato.

Classificare il caso come assenza di configurazione esplicita, indebolimento esplicito, conflitto di criteri o evidenze incomplete. Non applicare la stessa azione correttiva a tutti e quattro. Un’impostazione assente richiede una decisione sul comportamento desiderato; un’eccezione esistente richiede giustificazione e verifica di compatibilità; un errore di raccolta richiede una misurazione riuscita.

Passaggio 2: rimuovere gli indebolimenti ingiustificati in un criterio pilota

Per un pilota gestito tramite GPO, esaminare Livello di rischio predefinito per gli allegati e le impostazioni di inclusione nel percorso di Attachment Manager indicato sopra. Esaminare DefaultFileTypeRisk = 6152, il valore verificato dal rilevatore di indebolimento, e ogni voce di script in LowRiskFileTypes. Rimuovere le eccezioni ingiustificate tramite il criterio responsabile e documentare ogni dipendenza mantenuta.

Scegliere il valore predefinito e gli elenchi desiderati dopo aver esaminato i requisiti applicativi e di provenienza. Evitare di sostituire una decisione di compatibilità specifica per un’applicazione con un valore predefinito basso generalizzato. Controllare le inclusioni personalizzate ad alto rischio e a rischio moderato insieme alle voci a basso rischio prima di prevedere il risultato. La presenza di una sottostringa di script nella stringa a basso rischio raccolta avvia una verifica; non costituisce una valutazione completa del rischio Windows.

Passaggio 3: raccogliere nuovamente le evidenze utente e provare il flusso

Ripetere le letture di gpresult per l’ambito utente e del registro dopo l’applicazione dei criteri, usando la stessa identità pilota. Ripetere i flussi innocui concordati e registrare gli esiti effettivi con i responsabili delle applicazioni. Se la configurazione è cambiata ma il comportamento osservato non corrisponde alle aspettative, indagare il percorso applicativo, la provenienza e il conflitto di criteri prima di ampliare la distribuzione.

Passaggio 4: mantenere controlli di esecuzione complementari

Il solo criterio di rischio degli allegati non può dimostrare un controllo completo degli script. La nostra guida alle regole ASR di Defender tramite GPO tratta regole di comportamento complementari, con identificatori delle regole, azioni ed esclusioni sui dispositivi verificati separatamente. Una verifica riuscita del criterio degli allegati non convalida ASR o AppLocker.

Chiudere la correzione dell’ambito definito soltanto allegando la decisione sui criteri, la configurazione utente risultante, il comportamento applicativo esaminato e la responsabilità delle eccezioni. Trattare la copertura di una distribuzione più ampia come una questione di evidenze separata. Una modifica GPO completata o un conteggio del collector cambiato non dimostra la protezione dell’intera flotta.

Come EtcSec rileva questa configurazione

Le due implementazioni di etc-collector esaminate sono controlli GPO di livello Medium. Analizzano i campi di registro raccolti, con questi rami esatti:

Per il secondo controllo, le sottostringhe verificate sono .hta, .js, .vbs, .wsf, .wsh e .ps1. Il codice aggiunge un motivo per il rischio predefinito 6152 e un solo motivo combinato quando compare una qualsiasi di queste sottostringhe. Diverse estensioni corrispondenti contribuiscono comunque a un solo motivo per l’elenco. È una corrispondenza di sottostringhe, non un’analisi rigorosa dell’elenco di estensioni; per esempio, può corrispondere un token più lungo che contiene .js.

Ogni campo viene selezionato indipendentemente. I rilevatori cercano prima nelle impostazioni di registro Machine e consultano quelle User soltanto se il risultato Machine per quel campo è nil. L’helper Machine dà priorità a Default Domain Controllers Policy, poi a Default Domain Policy e infine a un’altra GPO disponibile. L’helper User restituisce il primo valore non-nil incontrato in una mappa Go. Tale attraversamento della mappa non fornisce una precedenza stabile dei criteri Windows.

Il parser del registro associa un DWORD valido chiamato defaultfiletyperisk sotto una chiave che contiene associations; associa lowriskfiletypes soltanto quando la stringa analizzata non è vuota. I controlli esaminati non valutano gli elenchi di inclusione ad alto rischio o a rischio moderato, la logica di attendibilità del client o il comportamento applicativo. Poiché i due campi vengono selezionati separatamente, i loro valori possono anche provenire da GPO diverse.

Qualsiasi valore non-nil in uno dei campi selezionati sopprime il conteggio dell’assenza, senza convalidarne la sicurezza. Analogamente, un conteggio di indebolimento pari a zero non dimostra una raccolta completa, la corretta applicazione dei criteri o una gestione sicura degli allegati. Nessuno dei due controlli misura l’esecuzione universale senza avvisi, convalida AppLocker o ASR, né dimostra la sicurezza della flotta. Nessun risultato dimostra un attacco.

Usare il risultato per avviare la verifica dell’ambito descritta sopra. Conservare insieme l’inventario dei criteri, le evidenze del risultato utente e le osservazioni effettive del pilota, affinché l’editor o l’amministratore possa distinguere un segnale di configurazione da un comportamento dimostrato.