Ao tentar abrir uma sessão de Área de Trabalho Remota (RDP) entre um PC com Windows 10 22H2 e uma workstation com Windows 11 24H2, apareceu o alerta “CredSSP encryption oracle remediation”. O erro persistiu mesmo após alinhar a diretiva System ▶ Credentials Delegation ▶ Encryption Oracle Remediation nas duas máquinas. A causa: discrepância no requisito de Autenticação em Nível de Rede (NLA). A seguir, veja o porquê, como remover o bloqueio e como restaurar a segurança total sem comprometer a produtividade.
Por dentro do CredSSP e da mensagem “encryption oracle”
O Credential Security Support Provider (CredSSP) protege o logon remoto criptografando as credenciais antes do envio. Em março de 2018, a Microsoft corrigiu a vulnerabilidade CVE‑2018‑0886, introduzindo o parâmetro Encryption Oracle Remediation com três estados:
- Vulnerable – não valida o handshake; permite conexões de clientes desatualizados.
- Mitigated – padrão recomendado; exige clientes patchados.
- Force Updated Clients – apenas hosts inteiramente atualizados.
Quando o cliente envia uma cifra incompatível, o servidor responde com o erro em questão. Contudo, mesmo com a mesma diretiva em ambos os lados, o Windows ainda checa se a NLA está habilitada. Se um lado exigir NLA e o outro não souber negociar as novas chaves, a sessão falha.
Solução rápida: desabilitar temporariamente a NLA
- Pressione Win + R, digite sysdm.cpl e pressione Enter.
- Abra a guia Remoto.
- Desmarque Permitir conexões somente de computadores que executam Área de Trabalho Remota com Autenticação de Nível de Rede (recomendado).
- Clique em Aplicar e OK.
- Repita nos dois computadores e tente novamente a conexão RDP.
Sem a exigência de NLA, o handshake CredSSP completa-se com sucesso e a sessão é estabelecida.
Por que funciona?
Ao remover a NLA, o cliente inicia a autenticação após estabelecer o canal RDP seguro (TLS). Isso contorna a parte do protocolo na qual o CredSSP valida a assinatura do pacote e onde ocorre a divergência de patches. É uma medida emergencial: conveniente para retomada imediata de acesso, mas reduz a blindagem contra ataques de força‑bruta e man‑in‑the‑middle.
Boa‑prática: restaurar a NLA com segurança
Após concluir a tarefa urgente, siga os passos para voltar a um estado seguro:
- Execute Windows Update em ambas as máquinas e instale todos os patches pendentes, sobretudo os de março de 2018 em diante (incluindo atualizações cumulativas).
- Garanta que a política Encryption Oracle Remediation esteja em Mitigated.
- Reative a NLA em sysdm.cpl.
- Reinicie os dois dispositivos para aplicar as definições.
Checklist de compatibilidade CredSSP
| Item | Verificação | Correção sugerida |
|---|---|---|
| Patches de março/2018 ou posterior | Ambos os hosts possuem? | Instalar rollups cumulativos mais recentes. |
| Estado da política “Encryption Oracle Remediation” | Igual em cliente e servidor? | Mitigated é o alvo ideal. |
| NLA habilitada | Consistente entre as máquinas? | Ativar somente após corrigir patches. |
| Firewall/IPS | Bloqueia porta 3389 ou variações de TLS? | Liberar RDP/TLS, inspecionar logs. |
Entendendo a diretiva “Encryption Oracle Remediation”
Disponível em Gpedit.msc ▶ Computer Configuration ▶ Administrative Templates ▶ System ▶ Credentials Delegation, a política escreve no registro:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters
AllowEncryptionOracle assume valores 2 (Vulnerable), 1 (Mitigated) ou 0 (Force Updated Clients). Em servidores de produção, mantenha “1”. A opção “2” deve ser usada apenas enquanto ainda houver endpoints legados, com prazo para desativação.
Automatizando a verificação via PowerShell
Verificar patches de 2018+
Get-HotFix | Where-Object {$_.HotFixID -match "KB4103727|KB4103721|KB4103731"}
Conferir valor da Oracle Remediation
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' \`
-Name AllowEncryptionOracle
Ajustar para Mitigated
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' \`
-Name AllowEncryptionOracle -Value 1
Automatizar facilita a padronização em dezenas de hosts e impede que a exceção temporária permaneça indefinidamente.
Segurança: riscos de manter a NLA desativada
Sem NLA, o servidor exibe a tela de logon antes de confirmar a identidade do cliente. Isso abre espaço para ataques de força‑bruta de senha e amplia vetores de credential harvesting. Casos práticos de exploit (como malware que abusa de RDP exposto à Internet) destacam a importância de:
- Usar senhas complexas ou, preferencialmente, autenticação multifator (MFA).
- Restringir o acesso RDP a redes VPN ou segurança de perímetro.
- Habilitar lockout de conta e monitorar tentativas de logon nas Visões de Evento 4625 e 4624.
- Ativar Network Level Authentication tão logo o ambiente esteja alinhado.
Boa‑práticas de hardening adicional
| Tema | Recomendações |
|---|---|
| Criptografia | Force TLS 1.2+ via HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. |
| Máximos de tentativas | Definir bloqueio de conta após 5 tentativas em Gpedit.msc ▶ Account Policies. |
| Porta RDP | Manter 3389, mas filtrar IPs via firewall; portas não‑padrão não substituem segurança de autenticação. |
| Autenticação | Implementar Windows Hello for Business ou smart card para contas administrativas. |
| Auditoria | Centralizar logs no Azure Monitor ou SIEM equivalente; criar alertas para eventos 4648 (logon remoto). |
FAQ Rápido
Posso definir “Vulnerable” para sempre?
Não. Esse modo desativa a verificação de assinatura e deixa a sessão sujeita a captura de tráfego. Use apenas durante migração.
O erro pode voltar após um cumulative update?
Sim. Uma máquina atualizada pode voltar a exigir NLA de forma automática se uma política local ou domínio a re‑habilitar. Mantenha scripts de verificação recorrentes.
Preciso reiniciar o servidor sempre que mudo a política?
Não. Um gpupdate /force ou reinício do serviço TermService costuma bastar, mas reiniciar garante que componentes dependentes recarreguem DLLs CredSSP.
Resumo
O alerta “CredSSP encryption oracle remediation” surge quando cliente e servidor discordam sobre patches ou políticas de CredSSP. Desativar temporariamente a NLA resolve na hora e permite retomar o acesso remoto. Contudo, para manter o ambiente protegido:
- Atualize ambos os sistemas ao nível mais recente.
- Defina Encryption Oracle Remediation = Mitigated.
- Reative a Autenticação em Nível de Rede.
- Implemente controles de senha, MFA e monitoração contínua.
Assim, você elimina o erro sem abrir mão da integridade e confidencialidade da sessão RDP.