Como consegui o Admin de Domínio via SafeNet Agent para Login do Windows através do ESC1
Feb 2, 2026
A Netwrix descobriu que as versões 4.0.0–4.1.2 do SafeNet Agent para Windows Logon criam, por padrão, um modelo de certificado AD CS inseguro, permitindo um caminho ESC1 que permite a qualquer usuário autenticado escalar para Administrador de Domínio.. A Thales corrigiu o problema na versão 4.1.3 restringindo a inscrição de certificados à conta de serviço NDES.
Descrição
Netwrix Security Research relatou recentemente um risco de segurança relacionado ao SafeNet Agent para Windows Logon versões 4.0.0, 4.1.1, e 4.1.2. Por design, o agente depende de um modelo de certificado nos Serviços de Certificado do Active Directory (AD CS), e a configuração desse modelo cria um caminho ESC1. Isso permite que Usuários Autenticados escalem para Administrador de Domínio, mesmo que o modelo tenha a intenção de suportar o recurso de login do Windows sem senha.
SafeNet Agent para Login do Windows é um componente leve instalado em máquinas Windows para fortalecer a segurança do login com autenticação multifatorial (MFA). Ele ajuda a garantir que recursos sensíveis sejam acessados apenas por usuários autorizados e protege aplicativos e processos de desktop que dependem do CredUI. Ao fazer isso, pretende fornecer uma experiência de login segura e consistente para os usuários finais. O Login do Windows sem senha, que é construído sobre o SafeNet Agent para Login do Windows, remove a necessidade de senhas ao acessar a máquina e outros recursos. O Login do Windows sem senha usa MFA baseado em certificados X.509 (PKI) e é projetado como um ponto de entrada para organizações que estão começando sua transição para autenticação sem senha. Ajuda a reduzir chamadas ao suporte técnico para redefinições de senha, proporciona aos funcionários uma experiência de login mais suave que apoia a produtividade e prepara o ambiente para uma adoção mais ampla da autenticação sem senha e moderna.
Aqui está um diagrama de arquitetura de alto nível da solução de Logon do Windows sem senha e como seus componentes interagem.
Como mencionado anteriormente, a instalação requer um AD CS e a criação de um modelo de certificado para habilitar o login sem senha. A Thales também fornece um arquivo ZIP na documentação oficial que contém dois scripts do PowerShell para automatizar essas tarefas.
Quando extraímos o arquivo ZIP que vem com a instalação, encontramos um arquivo JSON interessante chamado CertTemplate.json, que é usado para automatizar e preencher o modelo de certificado. A primeira coisa que se destacou foi o conjunto de Extended Key Usages que permitem autenticação, combinado com msPKI-Certificate-Name-Flag sendo definido como 1, que habilita o ENROLLEE_SUPPLIES_SUBJECT flag. Se você está familiarizado com o abuso do AD CS, essa configuração sugere fortemente um problema do tipo ESC1.
Este script instala as ferramentas necessárias do Active Directory e do AD CS PowerShell, e então cria um novo modelo de certificado AD CS chamado WLAPwdlessLogon usando as configurações de CertTemplate.json e o publica. Depois disso, concede à grupo Usuários Autenticados permissão de Inscrição no modelo e reinicia o serviço de Serviços de Certificado.
Executar o script do PowerShell em nosso laboratório confirma que o modelo é criado e que os Usuários Autenticados recebem permissão para Inscrever.
Após publicar o modelo de certificado, verificamos se ele era realmente vulnerável executando o Certify.exe para listar modelos inseguros. A saída mostra que todas as condições ESC1 são atendidas, o que significa que este modelo permite que qualquer usuário autenticado escale para Administrador de Domínio.
Agora podemos solicitar um certificado para qualquer conta de usuário ou computador e usar o ESC1 para impersonar essa identidade, incluindo um Administrador de Domínio. Neste exemplo, faremos isso com o MSOL_1191fa1e45e4 conta, porque possui permissões DCSync.
Neste ponto, podemos solicitar um TGT Kerberos para esta identidade e usá-lo para nos mover lateralmente como essa conta.
Cronograma de divulgação
- Relatamos este problema de segurança ao Thales PSIRT em 24 de novembro de 2025, incluindo uma prova de conceito mostrando que o produto é vulnerável por design e permite que usuários autenticados usem ESC1 para alcançar o Admin do Domínio. Thales reconheceu o relatório no mesmo dia e o escalou para a equipe responsável pela solução.
- Em 28 de novembro de 2025, entramos em contato com a Thales para solicitar uma atualização sobre este caso, pois acreditamos que representa uma falha de design significativa.
- Em 4 de dezembro de 2025, a Thales respondeu que ainda estava aguardando feedback de sua equipe de engenharia.
- Em 10 de dezembro de 2025, a Netwrix Security Research fez um acompanhamento para solicitar uma atualização.
- Em 12 de dezembro de 2025, a Thales confirmou que sua equipe de engenharia havia identificado o problema e estava trabalhando em uma remediação e em um boletim de segurança para informar os clientes.
- Em 5 de janeiro de 2026, a Netwrix Security Research fez um novo acompanhamento para solicitar uma atualização sobre o boletim de segurança da Thales que cobre as mitigação para este problema.
- Em 12 de janeiro de 2026, a Thales respondeu e confirmou que havia emitido um boletim de segurança e lançado uma versão atualizada do produto que mitiga o problema.
Mitigação
No momento da redação, a Thales havia reservado CVE-2026-0872 e publicou um boletim de segurança recomendando que os clientes atualizassem o SafeNet Agent para Windows Logon para a versão 4.1.3 para mitigar o problema.
Na versão atualizada, a orientação do modelo AD CS também foi revisada. Usuários Autenticados não têm mais direitos de Inscrição, e apenas a conta de serviço NDES tem permissão para se inscrever para este modelo.
Se reexecutarmos Certify.exe, podemos confirmar que Ler/Inscrever permissões agora estão limitadas ao conta de serviço NDES, e Usuários Autenticados não têm mais esses direitos.
Conclusão
Este caso mostra um exemplo do mundo real de que um produto MFA ainda pode introduzir riscos significativos se depender de um design ruim do AD CS. O recurso sem senha foi construído em um modelo de certificado que permite que qualquer usuário autenticado solicite um certificado com EKUs de autenticação do cliente e ENROLLEE_SUPPLIES_SUBJECT, e o script do fornecedor até concede a Inscrição a Usuários Autenticados por padrão. Juntos, isso transforma um recurso de segurança em um caminho ESC1 pronto para o Administrador de Domínio.
Referências
Perguntas Frequentes
Compartilhar em
Saiba Mais
Sobre o autor
