Impostazioni di sicurezza GPO Active Directory: quattro controlli

Che cosa sono le impostazioni di sicurezza GPO Active Directory?

Le impostazioni di sicurezza GPO Active Directory determinano come i client Windows risolvono i nomi locali, considerano attendibili i metadati degli aggiornamenti, proteggono LSASS e autenticano l’accesso alle condivisioni dei criteri. Quattro impostazioni meritano una verifica mirata: disabilitare LLMNR, usare HTTPS per i metadati WSUS, abilitare la protezione LSA e richiedere autenticazione reciproca e integrità per SYSVOL e NETLOGON.

Ognuna affronta un diverso prerequisito di attacco. Una connessione sicura per gli aggiornamenti non protegge la memoria di LSASS; disabilitare LLMNR non disabilita la risoluzione dei nomi NetBIOS. Esaminate il valore del criterio, i computer che lo ricevono e la protezione effettivamente in uso prima di chiudere un rilievo.

La nostra guida alle configurazioni errate delle GPO esamina le autorizzazioni di modifica delegate, i collegamenti dei criteri, LAPS e la governance dei criteri delle password. Questo percorso tratta quattro impostazioni specifiche che possono restare insicure anche quando le autorizzazioni amministrative di una GPO sono corrette.

Come funziona: quattro criteri e i relativi valori di registro

Usate le impostazioni seguenti come obiettivi di verifica. I valori attesi descrivono una configurazione prevista, non i risultati di un audit del vostro ambiente.

1. Disabilitare LLMNR; gestire NBT-NS separatamente

Percorso del criterio: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution.

Chiave di registro: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient; valore: EnableMulticast, REG_DWORD 0. La formulazione negativa del criterio è rilevante: Abilitato disattiva LLMNR. Microsoft documenta la corrispondenza dei criteri del client DNS; il suo riferimento della baseline Windows Server specifica il valore zero.

LLMNR fornisce la risoluzione dei nomi locali quando la risoluzione DNS convenzionale non è disponibile. Un attaccante in grado di influenzare questo scambio locale può reindirizzare un client verso una destinazione sotto il proprio controllo e indurre l’autenticazione, come descritto nella voce MITRE ATT&CK sull’avvelenamento della risoluzione dei nomi. Le risposte NTLMv2 acquisite non sono password in chiaro: Microsoft documenta NTLM come protocollo challenge-response. Anche l’inoltro dell’autenticazione dipende dalle protezioni del servizio di destinazione.

NBT-NS è un’esposizione distinta. Microsoft documenta Win32_NetworkAdapterConfiguration.SetTcpipNetbios con TcpipNetbiosOptions=2 per disabilitare NetBIOS su TCP/IP per un adattatore. Trattate questo metodo a livello di adattatore come una decisione di distribuzione separata, con verifiche di compatibilità proprie. Il criterio LLMNR e il relativo controllo EtcSec non dimostrano la copertura di NetBIOS.

2. Proteggere i metadati WSUS con HTTPS

Percorso del criterio: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location. I modelli dei criteri di Windows 10/11 lo collocano sotto Manage updates offered from Windows Server Update Service.

Chiave di registro: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate; valori: WUServer e WUStatusServer, entrambi REG_SZ. Configurate l’URL HTTPS del server distribuito in entrambi i campi. Il valore associato HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer è REG_DWORD 1 per l’uso di WSUS. Queste corrispondenze sono documentate nelle impostazioni Windows Update.

La procedura di configurazione WSUS di Microsoft distingue i metadati HTTPS dalla distribuzione dei file tramite HTTP. Un attaccante sul percorso del traffico può alterare le informazioni di aggiornamento non protette. Valutate i client che usano realmente quel server e il percorso intercettabile; non deducete la compromissione di tutti i computer aggiunti al dominio da un solo URL.

3. Abilitare la protezione LSA con un valore RunAsPPL supportato

Per Windows 11 22H2 e versioni successive, il percorso del modello amministrativo documentato da Microsoft è Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process. L’alternativa documentata tramite Preferenze Criteri di gruppo è Computer Configuration > Preferences > Windows Settings > Registry.

Chiave di registro: HKLM\SYSTEM\CurrentControlSet\Control\Lsa; valore: RunAsPPL, REG_DWORD. 1 seleziona la protezione con blocco UEFI dove supportato; Microsoft limita l’applicazione di 2, senza quel blocco, a Windows 11 22H2 e versioni successive. Sui dispositivi x86/x64 senza supporto UEFI o con Secure Boot disabilitato, la configurazione si basa sul registro anziché su un blocco del firmware. Riavviate dopo la configurazione. Seguite la procedura Microsoft per la protezione LSA.

Protected Process Light limita le letture della memoria e l’iniezione di codice da parte di processi non protetti. La mancanza di protezione può facilitare il furto di credenziali dopo che un attaccante ha ottenuto l’accesso necessario. Un valore di registro, da solo, non dimostra la protezione del processo in esecuzione. Alcuni client moderni abilitano automaticamente la protezione LSA; l’assenza di un valore GPO raccolto richiede un’indagine, non l’affermazione categorica che LSASS sia privo di protezione.

4. Richiedere autenticazione reciproca e integrità per le condivisioni dei criteri

Percorso del criterio: Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths.

Chiave di registro: HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths. Impostate entrambi i nomi dei valori REG_SZ, \\*\SYSVOL e \\*\NETLOGON, su RequireMutualAuthentication=1,RequireIntegrity=1. La corrispondenza dei criteri Connectivity definisce la posizione del criterio e la chiave di registro; il riferimento della baseline specifica gli attributi richiesti.

L’autenticazione reciproca richiede la convalida dell’identità del server tramite Kerberos; l’integrità richiede la firma SMB. Microsoft descrive il rafforzamento UNC e le difese contro l’intercettazione, incluso il rafforzamento predefinito di SYSVOL e NETLOGON a partire da Windows 10 e Windows Server 2016.

La nostra guida a cPassword in SYSVOL spiega perché i vecchi segreti GPP richiedono rimozione e rotazione delle credenziali, e raccomanda già il rafforzamento UNC. Qui l’attenzione è sui modelli precisi delle condivisioni e sui requisiti di connessione. Proteggere il transito non elimina i segreti archiviati né corregge autorizzazioni di scrittura eccessive.

La catena di attacco: prerequisiti distinti, controlli distinti

Si tratta di quattro percorsi indipendenti, non di quattro fasi obbligatorie di un unico exploit. Usate questa distinzione per delimitare un’indagine:

Un rilievo di configurazione giustifica interventi di rafforzamento. Non dimostra che un attaccante abbia acquisito credenziali, alterato un aggiornamento, eseguito un dump di LSASS o modificato un criterio in transito. Collegate qualsiasi conclusione su un incidente a telemetria indipendente.

Rilevamento: misurare il computer di destinazione

Iniziate su una destinazione Windows in ogni ambito di criteri pertinente. Il riferimento gpresult di Microsoft documenta l’output RSoP nell’ambito computer:

gpresult /scope computer /r

Il riepilogo aiuta a identificare le GPO applicate. Usate un output RSoP dettagliato quando esaminate impostazioni in conflitto, quindi confrontatelo con i valori locali e le evidenze durante l’esecuzione. Ripetete i controlli per ogni destinazione di cui state esaminando l’ambito dei criteri.

I comandi seguenti applicano la sintassi reg query documentata da Microsoft alle chiavi sopra riportate, supportate da Learn. Eseguite ogni comando separatamente.

Misurare la configurazione LLMNR

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast

Il valore atteso è REG_DWORD 0. Se il valore manca o è diverso, riconciliate il risultato dei criteri della destinazione prima di concludere che la distribuzione è riuscita. Esaminate le destinazioni inattese della risoluzione dei nomi locali come segnale d’indagine. Il riferimento degli avvisi Defender for Identity di Microsoft riconosce la famiglia di tecniche di avvelenamento LLMNR/NBT-NS e inoltro SMB; non definisce un Event ID Windows universale per questo controllo.

Misurare la configurazione WSUS

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

Esaminate insieme WUServer, WUStatusServer e la voce AU\UseWUServer. Confrontate gli URL con il FQDN e la porta HTTPS previsti, convalidate l’attendibilità del certificato e confermate il buon esito delle ricerche di aggiornamenti dei client. Una stringa HTTPS, da sola, non convalida IIS, la gestione dei certificati o l’uso effettivo da parte dei client. Le fonti utilizzate qui non definiscono alcun Event ID specifico per un attacco WSUS.

Misurare la configurazione e l’avvio di LSA

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL

Per confermare lo stato durante l’esecuzione, esaminate System / WinInit / Event 12 dopo il riavvio. Registra l’avvio protetto di LSASS. Il riferimento wevtutil documenta le query degli eventi; questo esempio seleziona i record Event 12 da esaminare:

wevtutil qe System /q:"*[System[(EventID=12)]]" /rd:true /f:text /c:10

Confermate che il provider sia WinInit e che il messaggio riguardi l’avvio protetto di LSASS. Il filtro seleziona per ID, quindi possono comparire provider non pertinenti. In CodeIntegrity/Operational, l’evento di audit 3065 riguarda i requisiti delle sezioni condivise e 3066 quelli del livello di firma Microsoft; in modalità audit il caricamento dell’immagine resta consentito. Con la protezione attiva, 3033 identifica gli errori del livello di firma e 3063 quelli delle sezioni condivise. Questi eventi non dimostrano un dump di credenziali riuscito. La sola assenza di evidenze di avvio conservate non dimostra che la protezione sia disabilitata.

Misurare la configurazione UNC

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths"

Esaminate entrambi i modelli delle condivisioni e gli attributi richiesti. Quando le voci sono assenti, considerate le impostazioni predefinite del sistema operativo prima di classificare l’esposizione. Convalidate l’accesso alle destinazioni SYSVOL e NETLOGON reali e le relative garanzie di autenticazione e integrità. Qui non viene definito alcun Event ID specifico per la falsificazione UNC.

Correzione: distribuire e verificare ogni controllo (Remediation)

Passaggio 1: disabilitare LLMNR in un ambito pilota

Abilitate il criterio del client DNS descritto sopra. Eseguite nuovamente la query del registro LLMNR e riconciliate i criteri applicati al computer. Verificate che le applicazioni che usano nomi locali continuino a risolvere le destinazioni previste. Se NetBIOS resta necessario, registrate separatamente questa dipendenza; se può essere disabilitato, gestite il metodo documentato dell’adattatore separatamente dall’impostazione del client DNS.

Passaggio 2: configurare TLS su WSUS prima di modificare gli URL dei client

Configurate il certificato del server, i binding IIS e le radici virtuali che richiedono TLS secondo la procedura WSUS di Microsoft. Da un prompt dei comandi con privilegi elevati in C:\Program Files\Update Services\Tools, il comando documentato è:

wsusutil configuressl <certificate-name>

Sostituite il segnaposto con il nome DNS del server WSUS. Richiedete TLS per i servizi di metadati documentati, incluso ClientWebService; non richiedetelo per l’intero sito web WSUS. La distribuzione dei file usa ancora HTTP, con convalida di firme e hash. Aggiornate entrambi gli URL dei criteri client all’endpoint HTTPS distribuito; https://wsus.contoso.com:8531 è l’esempio di Microsoft, non un server individuato. Verificate l’attendibilità del certificato e la ricerca degli aggiornamenti prima di una distribuzione estesa.

Passaggio 3: testare la compatibilità LSA, abilitare la protezione e riavviare

Usate l’audit di compatibilità della procedura LSA prima di applicare la protezione. Risolvete le incompatibilità di plug-in e driver, selezionate l’opzione RunAsPPL supportata, riavviate e verificate l’avvio protetto. Gli eventi di audit non vengono generati quando Smart App Control è abilitato o quando un debugger del kernel è collegato e abilitato, quindi il silenzio non equivale a un’approvazione automatica della compatibilità. Esaminate le implicazioni del blocco UEFI prima di sceglierlo: modificare solo il registro non rimuove la variabile del firmware. La protezione LSA e Credential Guard sono controlli complementari.

Passaggio 4: richiedere entrambi gli attributi UNC su entrambe le condivisioni

Configurate esplicitamente SYSVOL e NETLOGON nel criterio Hardened UNC Paths. Testate il recupero dei criteri da ogni ambito di destinazione e indagate sugli errori di autenticazione o accesso prima di estendere la distribuzione. Aggiungete RequirePrivacy solo dopo aver verificato la compatibilità della cifratura; gli endpoint non supportati possono diventare inaccessibili. Esaminate le autorizzazioni di scrittura e i segreti riutilizzabili come attività separate, anche quando i requisiti di trasporto risultano soddisfatti.

Conservate un registro sintetico per ogni distribuzione: sistema operativo e ambito di destinazione, GPO applicate, output del registro prima e dopo, evidenze pertinenti di esecuzione o connessione ed eventuali dipendenze irrisolte. Ripetete le stesse misurazioni dopo le modifiche ai criteri, così un revisore successivo potrà distinguere un’impostazione modificata da una diversa interpretazione delle impostazioni predefinite.

Come EtcSec rileva questo problema

Le quattro implementazioni Detect() di etc-collector esaminate per questo articolo valutano i dati di registro GPO raccolti:

Le funzioni ausiliarie del registro cercano nel criterio predefinito dei controller di dominio, poi nel criterio predefinito del dominio, quindi in un’altra GPO disponibile. Il codice aggrega i valori GPO e non dimostra la configurazione effettiva di ogni workstation. Non calcola la precedenza dei collegamenti, il filtro e l’ereditarietà per ogni computer. Le GPO contraddittorie o fuori ambito richiedono quindi una conferma sul computer di destinazione.

La funzione ausiliaria UNC cerca le due stringhe degli attributi richiesti; non è un parser dei criteri effettivi. Un WUServer assente non attiva il controllo HTTP, ma questa assenza non convalida la strategia di aggiornamento. Analogamente, l’assenza di voci PPL o UNC può richiedere l’esame delle impostazioni predefinite moderne. Usate ogni rilievo per aprire un’attività di verifica mirata, allegate le evidenze della destinazione e chiudetela solo quando la protezione prevista è dimostrata per l’ambito interessato.