Configurações de segurança GPO: Quatro verificações no AD

O que são as configurações de segurança GPO do Active Directory?

As configurações de segurança GPO do Active Directory determinam como os clientes Windows resolvem nomes locais, confiam nos metadados de atualização, protegem o LSASS e autenticam o acesso às partilhas de políticas. Quatro configurações merecem uma análise específica: desativar o LLMNR, utilizar HTTPS para os metadados do WSUS, ativar a proteção LSA e exigir autenticação mútua e integridade para SYSVOL e NETLOGON.

Cada uma aborda um pré-requisito de ataque diferente. Uma ligação de atualização segura não protege a memória do LSASS; desativar o LLMNR não desativa a resolução de nomes NetBIOS. Analise o valor da política, os computadores que o recebem e a proteção efetivamente utilizada antes de encerrar uma constatação.

O nosso guia de configurações incorretas de GPO aborda permissões de edição delegadas, ligações de políticas, LAPS e a governação de políticas de palavras-passe. Este guia trata de quatro configurações específicas que podem continuar inseguras mesmo quando as permissões administrativas de uma GPO estão corretas.

Como funciona: Quatro políticas e os seus valores de registo

Utilize as configurações seguintes como alvos de análise. Os valores esperados descrevem uma configuração pretendida, não resultados de uma auditoria do seu ambiente.

1. Desativar o LLMNR; tratar o NBT-NS separadamente

Caminho da política: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution.

Chave de registo: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient; valor: EnableMulticast, REG_DWORD 0. A formulação negativa da política é importante: Ativada desliga o LLMNR. A Microsoft documenta o mapeamento da política DNS Client; a referência da baseline do Windows Server especifica o valor zero.

O LLMNR permite a resolução de nomes locais quando a resolução DNS convencional não está disponível. Um atacante capaz de influenciar essa troca local pode redirecionar um cliente para um destino sob o seu controlo e induzir a autenticação, tal como descrito na entrada do MITRE ATT&CK sobre envenenamento da resolução de nomes. As respostas NTLMv2 capturadas não são palavras-passe em texto simples: a Microsoft documenta o NTLM como um protocolo de desafio-resposta. A retransmissão da autenticação também depende das proteções do serviço de destino.

O NBT-NS constitui uma exposição separada. A Microsoft documenta Win32_NetworkAdapterConfiguration.SetTcpipNetbios com TcpipNetbiosOptions=2 para desativar o NetBIOS sobre TCP/IP num adaptador. Trate esse método ao nível do adaptador como uma decisão de implementação separada, com as suas próprias verificações de compatibilidade. A política LLMNR e a verificação correspondente do EtcSec não comprovam a cobertura do NetBIOS.

2. Proteger os metadados do WSUS com HTTPS

Caminho da política: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location. Os modelos de políticas do Windows 10/11 colocam esta opção em Manage updates offered from Windows Server Update Service.

Chave de registo: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate; valores: WUServer e WUStatusServer, ambos REG_SZ. Configure o URL HTTPS do servidor implementado em ambos os campos. O valor associado HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer é REG_DWORD 1 para utilização do WSUS. Estes mapeamentos estão documentados nas configurações do Windows Update.

O procedimento de configuração do WSUS da Microsoft distingue os metadados por HTTPS da entrega de conteúdos por HTTP. Um atacante no percurso do tráfego pode manipular informações de atualização desprotegidas. Avalie os clientes que efetivamente utilizam esse servidor e o percurso suscetível de interceção; não deduza a compromissão de todos os computadores associados ao domínio a partir de um único URL.

3. Ativar a proteção LSA com um valor RunAsPPL suportado

Para o Windows 11 22H2 e versões posteriores, o caminho dos modelos administrativos documentado pela Microsoft é Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process. A alternativa documentada através das Preferências de Política de Grupo é Computer Configuration > Preferences > Windows Settings > Registry.

Chave de registo: HKLM\SYSTEM\CurrentControlSet\Control\Lsa; valor: RunAsPPL, REG_DWORD. 1 seleciona a proteção com bloqueio UEFI quando suportado; a Microsoft limita a aplicação de 2, sem esse bloqueio, ao Windows 11 22H2 e versões posteriores. Nos dispositivos x86/x64 sem suporte UEFI ou com Secure Boot desativado, a configuração depende do registo em vez de um bloqueio de firmware. Reinicie após a configuração. Siga o procedimento de proteção LSA da Microsoft.

O Protected Process Light limita leituras de memória e injeções de código por processos desprotegidos. A ausência de proteção pode facilitar o roubo de credenciais depois de um atacante obter o acesso necessário. Um valor de registo, por si só, não comprova a proteção do processo em execução. Alguns clientes modernos ativam automaticamente a proteção LSA; a ausência de um valor GPO recolhido exige investigação, não uma afirmação categórica de que o LSASS está desprotegido.

4. Exigir autenticação mútua e integridade para as partilhas de políticas

Caminho da política: Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths.

Chave de registo: HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths. Defina ambos os nomes de valores REG_SZ, \\*\SYSVOL e \\*\NETLOGON, como RequireMutualAuthentication=1,RequireIntegrity=1. O mapeamento da política Connectivity estabelece a localização da política e a chave de registo; a referência da baseline especifica os atributos obrigatórios.

A autenticação mútua exige a validação da identidade do servidor por Kerberos; a integridade exige assinatura SMB. A Microsoft descreve o reforço UNC e as defesas contra interceção, incluindo o reforço predefinido de SYSVOL e NETLOGON a partir do Windows 10 e do Windows Server 2016.

O nosso guia de cPassword no SYSVOL explica por que motivo os segredos históricos de GPP exigem limpeza e rotação de credenciais, e já recomenda o reforço UNC. Aqui, o foco são os padrões precisos das partilhas e os requisitos de ligação. Proteger a transmissão não remove segredos armazenados nem corrige permissões de escrita excessivas.

A cadeia de ataque: Pré-requisitos separados, controlos separados

Estes são quatro percursos independentes, não quatro fases obrigatórias de uma única exploração. Utilize esta distinção ao definir o âmbito de uma investigação:

Uma constatação de configuração fundamenta o trabalho de reforço. Não comprova que um atacante tenha capturado credenciais, alterado uma atualização, extraído a memória do LSASS ou modificado uma política em trânsito. Associe qualquer conclusão sobre um incidente a telemetria independente.

Deteção: Medir o computador de destino

Comece num computador Windows de destino em cada âmbito de política relevante. A referência de gpresult da Microsoft documenta a saída RSoP ao nível do computador:

gpresult /scope computer /r

O resumo ajuda a identificar as GPO aplicadas. Utilize uma saída RSoP detalhada ao investigar configurações contraditórias e compare-a depois com os valores locais e as evidências de execução. Repita as verificações para cada computador de destino cujo âmbito de política esteja a analisar.

Os comandos seguintes aplicam a sintaxe de reg query documentada pela Microsoft às chaves acima, fundamentadas no Learn. Execute cada comando separadamente.

Medir a configuração LLMNR

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

Espere REG_DWORD 0. Se o valor estiver ausente ou for diferente, reconcilie o resultado das políticas do computador de destino antes de decidir que a implementação foi bem-sucedida. Analise destinos inesperados de resolução de nomes locais como sinais para investigação. A referência de alertas do Defender for Identity da Microsoft reconhece a família de técnicas de envenenamento LLMNR/NBT-NS e retransmissão SMB; não estabelece um ID de evento Windows universal para esta verificação.

Medir a configuração WSUS

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

Analise em conjunto WUServer, WUStatusServer e a entrada AU\UseWUServer. Compare os URLs com o FQDN e a porta HTTPS pretendidos, valide a confiança no certificado e confirme que as pesquisas de atualizações dos clientes são bem-sucedidas. Uma cadeia HTTPS, por si só, não valida o IIS, o tratamento dos certificados ou a utilização efetiva pelos clientes. As fontes aqui utilizadas não estabelecem um ID de evento específico de ataque ao WSUS.

Medir a configuração LSA e o arranque

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

Para confirmação em execução, examine System / WinInit / Event 12 após reiniciar. Este evento regista o arranque protegido do LSASS. A referência de wevtutil documenta a consulta de eventos; este exemplo seleciona registos do Event 12 para análise:

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

Confirme que o fornecedor é WinInit e que a mensagem diz respeito ao arranque protegido do LSASS. O filtro seleciona por ID, pelo que podem aparecer fornecedores sem relação com esta verificação. Em CodeIntegrity/Operational, o evento de auditoria 3065 diz respeito aos requisitos de secções partilhadas e o 3066 aos requisitos de nível de assinatura Microsoft; em modo de auditoria, a imagem continua autorizada a carregar. Com a proteção ativa, o 3033 identifica falhas de nível de assinatura e o 3063 identifica falhas de secções partilhadas. Estes eventos não comprovam uma extração bem-sucedida de credenciais. A ausência de evidências de arranque conservadas, por si só, não comprova que a proteção esteja desativada.

Medir a configuração UNC

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

Examine ambos os padrões de partilha e os atributos obrigatórios. Quando os registos estiverem ausentes, considere as predefinições do sistema operativo antes de classificar a exposição. Valide o acesso aos destinos reais SYSVOL e NETLOGON e as suas garantias de autenticação e integridade. Não é estabelecido aqui um ID de evento específico de falsificação UNC.

Correção (Remediation): Implementar e verificar cada controlo

Passo 1: Desativar o LLMNR num âmbito piloto

Ative a política DNS Client descrita acima. Volte a executar a consulta de registo LLMNR e reconcilie as políticas aplicadas ao computador. Verifique se as aplicações que utilizam nomes locais continuam a resolver os destinos pretendidos. Se o NetBIOS continuar necessário, registe essa dependência separadamente; se puder ser desativado, faça a gestão do método documentado do adaptador separadamente da configuração DNS Client.

Passo 2: Configurar o TLS do WSUS antes de alterar os URLs dos clientes

Configure o certificado do servidor, as associações IIS e os diretórios virtuais que exigem TLS de acordo com o procedimento WSUS da Microsoft. Numa Linha de Comandos com privilégios elevados, em C:\Program Files\Update Services\Tools, o comando documentado é:

wsusutil configuressl <certificate-name>

Substitua o marcador pelo nome DNS do servidor WSUS. Exija TLS para os serviços de metadados documentados, incluindo ClientWebService; não exija TLS para todo o site WSUS. A entrega de conteúdos continua a utilizar HTTP, com validação de assinatura e hash. Atualize ambos os URLs das políticas dos clientes para o ponto de acesso HTTPS implementado; https://wsus.contoso.com:8531 é o exemplo da Microsoft, não um servidor descoberto. Verifique a confiança no certificado e a pesquisa de atualizações antes de uma implementação abrangente.

Passo 3: Testar a compatibilidade LSA, ativar a proteção e reiniciar

Utilize a auditoria de compatibilidade do procedimento LSA antes de aplicar a proteção. Resolva incompatibilidades de plug-ins e controladores, selecione a opção RunAsPPL suportada, reinicie e verifique o arranque protegido. Os eventos de auditoria não são gerados quando o Smart App Control está ativado ou um depurador de kernel está ligado e ativado; por isso, o silêncio não constitui aprovação automática de compatibilidade. Analise as implicações do bloqueio UEFI antes da seleção: alterar apenas o registo não remove a variável de firmware. A proteção LSA e o Credential Guard são controlos complementares.

Passo 4: Exigir ambos os atributos UNC em ambas as partilhas

Configure explicitamente SYSVOL e NETLOGON na política Hardened UNC Paths. Teste a obtenção de políticas a partir de cada âmbito de destino e investigue falhas de autenticação ou de acesso antes de expandir a implementação. Adicione RequirePrivacy apenas depois de verificar a compatibilidade de encriptação; os pontos de acesso não suportados podem ficar inacessíveis. Analise as permissões de escrita e os segredos reutilizáveis como tarefas separadas, mesmo quando os requisitos de transporte são cumpridos.

Mantenha um registo compacto de cada implementação: sistema operativo e âmbito de destino, GPO aplicadas, saída do registo antes/depois, evidências relevantes de execução ou de ligação e quaisquer dependências não resolvidas. Repita as mesmas medições após alterações de políticas, para que um revisor posterior consiga distinguir uma configuração alterada de uma interpretação alterada das predefinições.

Como o EtcSec deteta este problema

As quatro implementações de Detect() do etc-collector analisadas para este artigo avaliam dados de registo GPO recolhidos:

As funções auxiliares de registo pesquisam primeiro a política predefinida dos controladores de domínio, depois a política predefinida do domínio e, em seguida, outra GPO disponível. O código agrega valores GPO e não comprova a configuração efetiva de cada estação de trabalho. Não calcula a precedência das ligações, a filtragem e a herança para cada computador. Por isso, GPO contraditórias ou fora do âmbito exigem confirmação no computador de destino.

A função auxiliar UNC pesquisa as duas cadeias de atributos obrigatórios; não é um analisador de políticas efetivas. A ausência de WUServer não desencadeia a verificação HTTP, mas essa ausência não valida a estratégia de atualização. Da mesma forma, entradas PPL ou UNC ausentes podem exigir investigação das predefinições modernas. Utilize cada constatação para abrir uma tarefa de verificação específica, anexar as evidências do computador de destino e encerrá-la apenas quando a proteção pretendida estiver demonstrada para o âmbito afetado.