RDP Autenticação de Nível de Rede, Modo Restricted Admin, Active Directory: As Três Configurações Que Decidem Quem Controla Sua Sessão

Toda checklist de hardening de Remote Desktop termina com os mesmos três itens: Autenticação de Nível de Rede do RDP, Modo Restricted Admin, credenciais em cache do Active Directory. Marcar os três não torna uma sessão de Remote Desktop segura. Dois deles são ganhos defensivos genuínos, e o terceiro — o modo Restricted Admin — protege as credenciais que você digita enquanto entrega a um atacante que já possui um hash uma forma de entrar.

Este artigo separa as três configurações, mostra como elas se restringem mutuamente e fornece os valores de registro, os caminhos de Group Policy e os campos de evento necessários para auditar cada uma.

O Que São RDP Autenticação de Nível de Rede, Modo Restricted Admin, Active Directory

Uma conexão de Remote Desktop a um host associado ao domínio envolve três decisões independentes, cada uma configurada em um local diferente:

1. Autenticação de Nível de Rede (NLA) — o usuário é autenticado antes de uma sessão ser estabelecida?
2. A camada de segurança — como o próprio canal é autenticado e criptografado?
3. O modo de delegação de credenciais — o cliente chega a enviar credenciais ao host remoto?

Uma quarta configuração, o número de logons em cache, decide quanto material de credencial fica retido no host depois. A maioria das ferramentas de auditoria relata isso como quatro caixas de seleção sem relação entre si. Na prática, elas interagem: escolher a camada de segurança errada desativa a NLA silenciosamente, e habilitar o modo de delegação "seguro" muda o que um atacante precisa para efetuar logon.

A Camada de Segurança Vem Primeiro

As Três Camadas de Segurança

A Microsoft documenta três camadas de segurança para uma conexão de RD Session Host. A distinção importa mais do que parece, porque uma das três é mutuamente exclusiva com a NLA:

Essa última frase é da Microsoft, em Configure Server Authentication and Encryption Levels. É o motivo pelo qual um host pode ter uma política de "NLA obrigatória" e ainda assim não ter a NLA em vigor: quando a camada negociada recai sobre a criptografia nativa do RDP, a própria exclusão da Microsoft se aplica, e a Autenticação de Nível de Rede não pode ser usada.

O fato de "Negotiate" ser o padrão é o problema silencioso, e não é um artefato legado: a atual referência de SecurityLayer da Microsoft ainda documenta 1 (negotiate) como "o valor padrão". Ela não impõe TLS — aceita o que o cliente oferecer e faz downgrade para a Camada de Segurança RDP quando o cliente afirma não suportar TLS. Um atacante que controla o lado cliente do handshake controla essa escolha.

Níveis de Criptografia

Uma configuração separada, o nível de criptografia, rege a força da chave. A Microsoft lista quatro valores, com Compatível com o Cliente como padrão:

Vale dizer claramente sobre o nível "Baixo": ele deixa o tráfego do servidor para o cliente — o conteúdo da tela de uma sessão administrativa — em texto claro.

Todas essas configurações ficam em Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security, e a Microsoft observa que essas configurações de Group Policy "têm precedência sobre as configurações definidas na Configuração do Host de Sessão de Área de Trabalho Remota, com exceção da configuração de política do Modelo de Certificado de Autenticação do Servidor."

Por Que a Autenticação de Nível de Rede Importa

A NLA move a autenticação do usuário para antes do estabelecimento da sessão. A descrição original da Microsoft continua sendo a mais clara: ela "conclui a autenticação do usuário antes que você estabeleça uma conexão de Área de Trabalho Remota e a tela de logon apareça", e as vantagens declaradas são que o computador remoto "usa um número limitado de recursos antes de autenticar o usuário" e que isso "pode ajudar a fornecer melhor segurança, reduzindo o risco de ataques de negação de serviço" (Configure Network Level Authentication).

O valor dessa barreira de pré-autenticação não é teórico. Nas soluções alternativas publicadas com o aviso para a CVE-2019-0708, a vulnerabilidade de execução remota de código pré-autenticação nos Serviços de Área de Trabalho Remota comumente chamada de BlueKeep, a Microsoft escreveu:

A NLA transformou um bug wormable de pré-autenticação em um bug pós-autenticação. Esse é todo o argumento para exigi-la — ela coloca qualquer futura vulnerabilidade de RDP de pré-autenticação atrás de uma verificação de credenciais.

A configuração do lado do host é um único valor de registro:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication

1 exige NLA, 0 a desativa. A própria orientação de solução de problemas de VM do Azure da Microsoft usa exatamente esse valor para desativar e reativar temporariamente a NLA — que também é como ela costuma ser desligada permanentemente durante um incidente e nunca mais reativada.

Modo Restricted Admin: O Controle Que Corta Nos Dois Sentidos

O modo Restricted Admin muda o que o cliente envia. A documentação da Microsoft sobre Remote Credential Guard lista seus benefícios de segurança com precisão:

• As credenciais não são enviadas ao host remoto
• A sessão de Área de Trabalho Remota se conecta a outros recursos usando a identidade do host remoto
• Um atacante não pode agir em nome do usuário, e qualquer ataque fica local ao servidor

A tabela comparativa da Microsoft marca o modo Restricted Admin como uma proteção contra Pass-the-Hash e, para cenários de helpdesk, recomenda explicitamente: "as conexões RDP só devem ser iniciadas usando o parâmetro /RestrictedAdmin." Observe também que o acesso RDP sob o Restricted Admin é concedido pela associação ao grupo Administradores no host remoto, e não ao grupo Usuários da Área de Trabalho Remota.

Tanto o modo quanto o Remote Credential Guard dependem de um único valor do lado do host:

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

A Inversão

É aqui que as duas leituras divergem, e a divergência é direcional.

A alegação da Microsoft é sobre credenciais que saem do cliente: com o Restricted Admin, nada fica registrado no host remoto, então nada pode ser coletado ali e reutilizado. Isso é verdade.

A consequência diz respeito às credenciais que entram no host. Como o cliente não envia mais uma senha, o logon é satisfeito com o material de credencial que o cliente já possui — o que significa que um hash NTLM é suficiente. Pesquisas públicas documentaram isso no mesmo ano em que o recurso foi lançado. A Portcullis Labs (autor MRL, 20 de outubro de 2013) descreveu o cliente enviando "credenciais vazias na estrutura TSPasswordCreds" no Windows 8.1 e no Windows Server 2012 R2, e demonstrou autenticação passando um hash no lugar da senha. A prova de conceito deles não era um cliente padrão: exigia o FreeRDP-pth, um FreeRDP modificado cujo argumento -p carrega um hash NT em vez de uma senha.

# FreeRDP-pth, o cliente modificado de 2013 — -p recebe o hash NT
xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

Um build padrão não aceita isso: trata o hash como uma senha em texto claro, e o logon falha. O FreeRDP atual implementa a capacidade de forma nativa, com a opção documentada como "Pass the hash (restricted admin mode)":

xfreerdp3 /u:test /pth:36374BD2767773A2DD4F6B010EC5EE0D /v:192.168.226.129

O mesmo post observa que a técnica funciona apenas para administradores — membros do grupo Usuários da Área de Trabalho Remota não conseguem se autenticar dessa forma. Com o cliente nativo do Windows, o equivalente é injetar o hash em uma sessão de logon primeiro:

sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:"mstsc.exe /restrictedadmin"

Portanto, as duas afirmações são verdadeiras. O modo Restricted Admin impede que suas credenciais sejam roubadas do host remoto, e ele reduz a barreira para efetuar logon nesse host, de uma senha em texto claro para um hash. Se o pass-the-hash já é viável no seu ambiente, habilitar o modo Restricted Admin em todo o domínio estende isso ao acesso RDP interativo em todos os hosts onde ele estiver ativado.

Há uma segunda consequência. Como a autenticação é avaliada com base em um token, e não em uma senha digitada, os controles aplicados no destino podem ser contornados. A SpiderLabs (Apurva Goenka, 15 de novembro de 2023 — publicado sob a Trustwave, desde então adquirida pela LevelBlue) documentou que a autenticação "não ocorre no servidor de Área de Trabalho Remota, mas sim no próprio cliente", de modo que "fatores de autenticação aplicados no servidor de destino, como MFA fornecido via Duo, Okta... tornam-se ineficazes" (Restricted Admin Mode – Circumventing MFA On RDP Logons).

Logons em Cache: O Que Fica Para Trás

As credenciais de domínio em cache permitem que um usuário faça logon quando nenhum controlador de domínio está acessível. A orientação da Microsoft sobre Logon interativo: número de logons anteriores a armazenar em cache (caso o controlador de domínio não esteja disponível) declara o risco diretamente: "um atacante capaz de acessar o sistema de arquivos do servidor poderia localizar essas informações em cache e usar um ataque de força bruta para tentar determinar senhas de usuários." As informações em cache "não expiram, mas podem ser substituídas."

O padrão é de 10 logons em servidores membros e computadores cliente, e o intervalo aceito vai de 0 a 50. A tabela de padrões da Microsoft lista o padrão efetivo para controladores de domínio como Sem efeito — a configuração simplesmente não se aplica ali.

Tome cuidado ao citar essa recomendação, porque a própria página da Microsoft não fala com uma única voz. A seção Contramedida diz para configurar o valor como 0, desativando o cache local. A seção Práticas recomendadas diz que as baselines de segurança do Windows "não recomendam configurar essa definição" de forma alguma. A seção Impacto potencial sugere 2 para computadores de usuário final, para que usuários móveis ainda possam fazer logon offline. A posição defensável para um servidor membro de Tier 0 é um valor baixo; em laptops, 0 quebra completamente o logon offline. Um detalhe que costuma ser mal interpretado: essa configuração não se aplica a controladores de domínio, cujo padrão efetivo a Microsoft lista como "Sem efeito" — os DCs mantêm o diretório e não armazenam logons de domínio em cache.

Detecção

O evento 4624 contém os campos necessários para distinguir esses logons. A versão 2 do evento (Windows 10 e posterior) adicionou um campo RestrictedAdminMode, que, segundo a Microsoft, "só é preenchido para sessões de logon do tipo RemoteInteractive" e é um indicador Sim/Não de se o modo Restricted Admin foi usado.

Esse detalhe importa para escrever uma regra correta: uma sessão RDP em Restricted Admin ainda é Logon Type 10 (RemoteInteractive), não Type 3. O modo fica visível no indicador, não no tipo de logon.

Vale adotar literalmente a recomendação de monitoramento da Microsoft na mesma página: se o modo Restricted Admin precisar ser usado por determinadas contas, monitore os logons dessas contas com Logon Type = 10 e Restricted Admin Mode = "Yes", e dispare um alerta quando Restricted Admin Mode = "No" para elas. Invertê-la também é útil — alerte quando RestrictedAdminMode = "Yes" para contas que nunca deveriam usá-lo, já que as ferramentas de atacantes recorrem propositalmente ao /restrictedadmin justamente porque ele aceita um hash.

Auditando a Configuração

Auditar a configuração em si é uma leitura de registro em cada host:

$ts = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
Get-ItemProperty -Path $ts -Name UserAuthentication, SecurityLayer, MinEncryptionLevel
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name DisableRestrictedAdmin -ErrorAction SilentlyContinue

A ausência do valor DisableRestrictedAdmin significa que o modo não está habilitado; um valor 0 significa que está.

Remediation

1. Exigir TLS como camada de segurança. Habilite Require use of specific security layer for remote (RDP) connections e selecione SSL, em Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security. Emita certificados de RD Session Host pela sua CA interna, em vez de aceitar o certificado autoassinado padrão.

2. Exigir NLA. No mesmo caminho de política, habilite Require user authentication for remote connections by using Network Level Authentication. A Group Policy tem precedência sobre a configuração local, o que é desejável para controle de deriva.

3. Elevar o nível de criptografia. Defina Set client connection encryption level como High, de modo que o tráfego seja criptografado em 128 bits nas duas direções, e confirme que nenhum host permaneça em Low.

4. Decida o modo Restricted Admin de forma deliberada, por camada (tier). Não o habilite em todo o domínio por reflexo. Onde administradores se conectam a hosts de menor confiança, prefira o Remote Credential Guard por meio da política Restrict delegation of credentials to remote servers, definida como Require Remote Credential Guard. Onde ele for genuinamente necessário para trabalho de helpdesk, habilite-o apenas nesses hosts e alerte sobre seu uso em qualquer outro lugar. Observe o alerta da Microsoft: quando Restrict Credential Delegation está habilitada, "o parâmetro /restrictedAdmin será ignorado" e o Remote Credential Guard será usado no lugar.

5. Habilitar a delegação de credenciais não exportáveis em hosts remotos — necessária tanto para o Restricted Admin quanto para o Remote Credential Guard — via Remote host allows delegation of nonexportable credentials.

6. Reduzir os logons em cache nos servidores. Defina Interactive logon: Number of previous logons to cache para um valor baixo em Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Valide isso em relação aos seus requisitos de logon offline antes de aplicar a laptops.

7. Implantar o LAPS. A Microsoft combina sua orientação sobre Restricted Admin com o Windows LAPS, que "mitiga o risco de escalonamento lateral" a partir de senhas de administrador local compartilhadas — exatamente a condição que torna um único hash roubado útil em todos os hosts.

Valide o Resultado

Valide o resultado em vez de confiar no relatório da GPO:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" |
    Select-Object UserAuthentication, SecurityLayer, MinEncryptionLevel

UserAuthentication deve ser 1 e SecurityLayer deve ser 2 (TLS).

Esses controles se reforçam mutuamente com o restante do seu hardening de autenticação — exigir TLS no RDP é o mesmo argumento que exigir assinatura SMB e assinatura LDAP em caminhos de NTLM relay, e restringir quem pode alcançar o Tier 0 via RDP é inseparável de restringir a delegação Kerberos e a política de senhas.

Como a EtcSec Detecta Isso

A EtcSec audita essas quatro configurações de forma independente, porque elas falham de forma independente. PA038_RDP_NLA_NOT_REQUIRED gera um achado quando nenhuma GPO no domínio define UserAuthentication como 1. PA038_RDP_SECURITY_LAYER_WEAK dispara a menos que uma política fixe a camada de segurança em TLS, de modo que o padrão Negotiate, que pode fazer downgrade silenciosamente, também é reportado. TERMINAL_SERVICES_NOT_HARDENED cobre a superfície mais ampla de configuração dos Serviços de Terminal e do RDP, e CACHED_LOGONS_EXCESSIVE dispara quando Winlogon\CachedLogonsCount está acima de 4. Essas são verificações no nível de política: um resultado limpo significa que a política existe, e confirmar que ela realmente chegou a todos os hosts ainda exige a leitura de registro mencionada acima.