Bloquear NTLM enviado pelos domain controllers Tier 0

O que "NTLM de saída" significa para um domain controller

Este guia mostra como bloquear NTLM enviado pelos domain controllers Tier 0 — as cadeias de coercion-relay como o PetitPotam e as técnicas que vieram depois dependem inteiramente da existência dessa autenticação de saída; negue-a e não sobra nada para retransmitir. Os domain controllers autenticam quase tudo o que fazem entre si e perante outros serviços integrados no Active Directory com Kerberos, mas o NTLM continua a existir por baixo como mecanismo de recurso — e, por predefinição, qualquer sistema Windows autentica-se de boa vontade para fora através de NTLM perante qualquer servidor que o solicite.

A ANSSI, a agência nacional de cibersegurança francesa, documenta este padrão diretamente no seu guia de administração do Active Directory. A autenticação NTLMv2 é um início de sessão de rede — distinto dos inícios de sessão interativos que deixam hashes reutilizáveis na memória — e o seu desafio-resposta pode ser interceptado em trânsito e retransmitido para um segundo alvo sem que o atacante chegue a conhecer o segredo subjacente, pedindo emprestados os direitos de acesso da vítima em vez de lhe roubar a palavra-passe (ANSSI-PA-099, §4.15.2). Quando o sistema coagido é um domain controller, os direitos de acesso retransmitidos são de Tier 0.

Como os ataques de coerção e retransmissão abusam do NTLM de saída

O membro melhor documentado desta classe é o PetitPotam. O aviso do CERT/CC sobre a técnica explica que ela abusa do Encrypting File System Remote Protocol: uma chamada a EfsRpcOpenFileRaw faz o sistema-alvo "use NTLM to authenticate with the host that is specified within the path", e um atacante pode apontar esse caminho para uma infraestrutura que controla — desencadeando uma tentativa de autenticação NTLM a partir da própria conta de computador do domain controller, sem necessidade de credenciais para iniciar a cadeia (CERT/CC VU#405600).

Essa autenticação NTLM capturada só é perigosa porque algo, noutro ponto, a aceita. O CERT/CC descreve a cadeia completa contra os Active Directory Certificate Services em três passos:

Passo 1 — Coagir

O atacante chama EfsRpcOpenFileRaw (ou um método RPC equivalente com o mesmo comportamento de desencadear autenticação) contra o domain controller, apontando-o para infraestrutura sob o seu controlo. A conta de computador do DC abre uma autenticação NTLM de saída — é um início de sessão de rede, nota o guia da ANSSI, não do tipo interativo que deixa hashes reutilizáveis na memória.

Passo 2 — Retransmitir

O atacante captura o desafio-resposta NTLMv2 — o hash "Net-NTLMv2" — e retransmite-o de imediato, sem alterações, para o ponto final HTTP do Web Enrollment do AD CS, antes de expirar.

Passo 3 — Converter

O AD CS emite um certificado para a conta de computador do domain controller. O CERT/CC nota que esse certificado "can be used to obtain a Ticket Granting Ticket", o que basta para comprometer todo o domínio — sem que qualquer palavra-passe ou hash tenha tido de ser quebrado.

Todos os passos dessa cadeia dependem do êxito do passo 1: o domain controller tem de estar disposto, antes de tudo, a enviar autenticação NTLM para fora. Retire isso e os passos 2 e 3 ficam sem matéria-prima.

A correção da Microsoft, registada como CVE-2021-36942 ("Windows LSA Spoofing Vulnerability"), fechou apenas a variante não autenticada da chamada EfsRpcOpenFileRaw. Não fechou o padrão subjacente — um sistema Tier 0 pode continuar a ser empurrado para uma autenticação NTLM de saída através de outras interfaces RPC com o mesmo comportamento, razão pela qual a própria orientação de remediação da Microsoft para esta família de ataques vai além de um único patch. O KB5005413 recomenda ativar a Extended Protection for Authentication nos pontos finais do AD CS e — como opção mais forte, ao nível do protocolo — "disable NTLM Authentication on your Windows domain controller" (Microsoft KB5005413). É precisamente essa segunda opção que a recomendação R73 da ANSSI operacionaliza numa única definição de política de grupo.

Bloquear NTLM enviado pelos domain controllers Tier 0 (ANSSI R73)

A recomendação R73 da ANSSI é direta: "outbound NTLM authentications from all Tier 0 systems must be blocked", aplicada através de uma única definição de política de grupo. O caminho da política de grupo, retirado do guia, é:

Computer Configuration\Windows Settings\Security Settings\Local Policies\
Security Options\Network Security: Restrict NTLM: Outgoing NTLM traffic
to remote servers → Deny all

A própria referência da Microsoft para esta definição confirma os mesmos três estados — Allow all (sem restrição), Audit all (registra todas as tentativas de NTLM de saída sem as bloquear) e Deny all (o dispositivo "can't authenticate any identities to a remote server by using NTLM authentication") — e nota que a definição está Not Configured por predefinição em todos os domain controllers e servidores membros (Microsoft Learn — Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers). Deixada sem configuração, a classe de coerção e retransmissão tem exatamente o caminho de saída de que necessita.

A ANSSI é explícita quanto a Audit all não ser suficiente para a R73 — a recomendação prescreve Deny, não registo. O modo de auditoria é o passo prévio à implementação: mantenha-o ativo o tempo suficiente para confirmar que não existe tráfego NTLM de saída legítimo a partir do Tier 0 (normalmente não deve existir, já que o tráfego entre DCs e entre DCs e serviços do AD suporta Kerberos nativamente) e depois passe para Deny all. O guia acrescenta uma ressalva operacional que vale a pena levar a sério: bloquear o NTLM de saída pressupõe que os sistemas Tier 0 alcançam os outros serviços do AD por FQDN e não por endereço IP direto, uma vez que o Kerberos depende da resolução de nomes para escolher o ticket de serviço correto — uma configuração incorreta que a fase de auditoria revela antes de se tornar uma indisponibilidade.

O controlo complementar: restringir o que o Tier 0 envia para baixo (ANSSI R82/R83)

Bloquear o NTLM de saída fecha o lado da autenticação de rede da exposição do Tier 0. A posição de base da ANSSI é que as estações de administração de Tier 0 não deveriam ter, desde logo, qualquer conectividade para baixo — fisicamente dedicadas, com tráfego de saída permitido apenas para recursos de Tier 0 (R80). A R82 e a R83 aplicam-se especificamente quando uma organização adota, em vez disso, a segunda arquitetura alternativa da ANSSI: a partilha do acesso remoto do Tier 0 a ambientes de menor confiança, como recurso transitório face a uma segregação completa. Dentro desse modelo, a R82 restringe quais os métodos de ligação remota autorizados a sair do Tier 0 em direção a zonas de menor confiança — RPC/MMC, PowerShell WinRM com a sua autenticação de rede Kerberos-ou-NTLM predefinida, ou RDP nativo, seja no modo RestrictedAdmin, seja com uma conta cujo âmbito se limita ao tier de destino. A R83 vai mais longe: a conta usada numa sessão interativa nesse destino de menor confiança tem de pertencer à zona de confiança desse próprio destino, nunca uma credencial de Tier 0 ou Tier 1, para que um sistema comprometido de um tier inferior nunca acabe a guardar segredos reutilizáveis de Tier 0. Para o percurso completo pelas restrições de início de sessão por tier, consulte Políticas de autenticação e silos do Active Directory para o Tier 0.

Detetar o NTLM de saída antes e depois do bloqueio

Event ID	Registo	Significado
8001	Applications and Services Logs\Microsoft\Windows\NTLM	Autenticação NTLM de saída tentada e registada — o Audit all está ativo, nada foi ainda bloqueado
4001	Applications and Services Logs\Microsoft\Windows\NTLM	Autenticação NTLM de saída tentada e bloqueada — o Deny all está ativo

Ambos os Event IDs estão confirmados diretamente no ANSSI-PA-099 §4.15.2.1, e a própria referência da Microsoft para a definição de política aponta para o mesmo caminho de registo operacional. Duas coisas que vale a pena monitorizar depois de o bloqueio estar ativo:

Qualquer pico de Event ID 4001 após a implementação merece investigação — ou passou ao lado uma dependência legítima durante a fase de auditoria, ou algo está ativamente a tentar forçar uma autenticação de saída e a ser travado.
O Event ID 8001 durante a fase de auditoria é o seu mapa de dependências. Cada par origem/destino que lista é algo a resolver — corrigir, isentar ou migrar para Kerberos — antes de passar para Deny all.

A cobertura de deteção relacionada — as defesas de retransmissão em LDAP e SMB, que importam independentemente de o NTLM de saída estar bloqueado — está tratada em Channel binding LDAP nos domain controllers e Assinatura SMB e NTLM relay.

Remediation

Confirme primeiro o âmbito do Tier 0. A R73 só funciona se a sua OU de Tier 0 contiver efetivamente todos os domain controllers e todos os servidores sensíveis de Tier 0 — confronte-a com o seu modelo de administração por tiers antes de ligar qualquer política de grupo.
Implemente o Audit all numa política de grupo ligada à OU de Tier 0. Deixe-o correr o tempo suficiente para abranger o seu ciclo de patches, as tarefas de backup e quaisquer tarefas de administração mensais ou trimestrais — janelas de auditoria curtas deixam passar dependências recorrentes.
Analise as entradas de Event ID 8001 e resolva todas as legítimas: aponte a origem para Kerberos (normalmente uma correção de DNS ou de SPN), acrescente-a à lista de exceções de servidores NTLM se realmente não conseguir abandonar o NTLM, ou desative a dependência.
Passe a mesma política de grupo para Deny all. Fique atento ao Event ID 4001 nos dias seguintes — tudo o que for inesperado é uma dependência esquecida ou uma tentativa ativa de coerção.
Estenda à R74+ quando o Tier 0 estiver limpo: ligue uma política de grupo equivalente na raiz do domínio para o resto do ambiente, com exceções filtradas por WMI onde o NTLM realmente ainda não possa ser removido.
Acrescente a R82/R83 para os administradores de Tier 0 que tenham de se ligar para baixo — restrinja o método de ligação remota e exija uma conta do tier de destino, conforme a secção anterior, para que este controlo e o bloqueio ao nível da rede cubram ambos os sentidos do risco.
Combine com o endurecimento do lado da retransmissão. Bloquear o NTLM de saída remove a origem das autenticações retransmitidas a partir do Tier 0, mas qualquer sistema do SI que continue a aceitar alvos de NTLM relay sem assinatura ou sem proteção (LDAP sem channel binding, SMB sem assinatura, Web Enrollment do AD CS sem Extended Protection) continua explorável contra vítimas fora do Tier 0. Trate esta política de grupo como uma camada, não como toda a defesa.

Como a EtcSec deteta isto

A auditoria de Active Directory da EtcSec verifica exatamente esta lacuna de configuração. O ANSSI_R73_NTLM_OUTBOUND_TIER0 sinaliza a ausência de qualquer definição de política de grupo que coloque RestrictSendingNTLMTraffic em Deny all nos sistemas de Tier 0 — o modo apenas de auditoria é corretamente tratado como não cumprindo o controlo. O ANSSI_R74_NTLM_OUTBOUND_DOMAIN acompanha separadamente se essa mesma política de negação foi estendida a uma política de grupo ligada à raiz do domínio. O ANSSI_R82_R83_ADMIN_ARCHITECTURE sinaliza os sistemas de Tier 0 a que faltam as salvaguardas de arquitetura de administração exigidas pela R82 e pela R83, e o NTLM_RELAY_OPPORTUNITY sinaliza a exposição mais ampla à retransmissão em todo o ambiente sempre que o NTLM permanece alcançável sem as proteções compensatórias descritas acima.