Problema de configuração do SafeNet Agent para Windows Logon AD CS (ESC1)

Como consegui o Admin de Domínio via SafeNet Agent para Logon 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

Pesquisa de Segurança Netwrix relatou recentemente um risco de segurança relacionado ao SafeNet Agent for 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 Certificação do Active Directory (AD CS), e a configuração desse modelo cria um caminho ESC1. Isso permite que Usuários Autenticados se elevem a Administrador de Domínio, mesmo que o modelo seja destinado a 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 Login do Windows sem senha e como seus componentes interagem.

Figure 1. High-level diagram of Passwordless Windows Logon between the user device, STA, the SCEP server, and ADCS.

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 PowerShell para automatizar essas tarefas.

Figure 2. Official setup steps for Passwordless Windows Logon.

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 Usos de Chave Estendida que permitem a autenticação, combinado com msPKI-Certificate-Name-Flag definido como 1, que ativa o ENROLLEE_SUPPLIES_SUBJECT sinalizador. Se você está familiarizado com abusos de AD CS, essa configuração sugere fortemente um problema do tipo ESC1.

Figure 3. CertTemplate.json showing the WLAPwdlessLogon certificate template, including its display name, authentication EKU OIDs, and msPKI-Certificate-Name-Flag set to 1 (ENROLLEE_SUPPLIES_SUBJECT).

Este script instala as ferramentas do PowerShell necessárias para Active Directory e AD CS, 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, ele concede ao grupo Authenticated Users permissão de inscrição no modelo e reinicia o serviço de Serviços de Certificados.

Figure 4. The CreateCertTemplate.ps1 script uses grant_enroll_permission to assign Enroll rights on the WLAPwdlessLogon certificate template to Authenticated Users. Figure 4. The CreateCertTemplate.ps1 script uses grant_enroll_permission to assign Enroll rights on the WLAPwdlessLogon certificate template to Authenticated Users.

Executar o script PowerShell em nosso laboratório confirma que o modelo é criado e que os Usuários Autenticados recebem a permissão de Inscrição.

Figure 5. Output from CreateCertTemplate.ps1 showing the WLAPwdlessLogon template created and Enroll permission granted to Authenticated Users. Figure 5. Output from CreateCertTemplate.ps1 showing the WLAPwdlessLogon template created and Enroll permission granted to Authenticated Users.

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.

Figure 6. Certify output showing the WLAPwdlessLogon template with ENROLLEE_SUPPLIES_SUBJECT set, client/smart card logon EKUs, and Enroll rights granted to Authenticated Users. Figure 6. Certify output showing the WLAPwdlessLogon template with ENROLLEE_SUPPLIES_SUBJECT set, client/smart card logon EKUs, and Enroll rights granted to Authenticated Users.

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 tem permissões DCSync.

Figure 7. Using Certipy to request a certificate for the MSOL_1191fa1e45e4 account via the vulnerable WLAPwdlessLogon template.

Neste ponto, podemos solicitar um TGT Kerberos para esta identidade e usá-lo para nos mover lateralmente como essa conta.

Figure 8. Rubeus using the MSOL certificate to request a Kerberos TGT via PKINIT, successfully returning a ticket for the MSOL_1191fa1e45e4 account.

Linha do tempo 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 Administrador de 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 perguntar sobre uma atualização do boletim de segurança da Thales cobrindo as mitigações 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, as diretrizes do modelo AD CS também foram revisadas.Usuários autenticados não têm mais direitos de Inscrição, e apenas a conta de serviço NDES está autorizada a se inscrever para este modelo.

Figure 10. Official documentation updated the certificate template configuration to modify security permissions required for Passwordless Windows Logon enrollment. https://thalesdocs.com/sta/agents/wla-windows_logon/wla-preinstallation_passwordless/index.html

Figure 11. Shows CreateCertTemplate.ps1 updated the certificate template to remove Enroll permissions from Authenticated Users and grant Enroll only to the NDES service account.

Se reexecutarmos Certify.exe, podemos confirmar que Read/Enroll as permissões agora estão limitadas ao conta de serviço NDES, e Usuários Autenticados não têm mais esses direitos.

Figure 12. Certify.exe shows Enroll is now limited to the NDES service account.

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 de 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 uso para o Administrador de Domínio.

Referências

Perguntas Frequentes

O que é ESC1 nos Serviços de Certificado do Active Directory (AD CS)?

Como um modelo de certificado mal configurado pode levar à escalada de privilégios?

Qual é o papel do AD CS em um ambiente Windows?

Como o SafeNet Agent para Logon do Windows se relaciona com a segurança do AD CS?

O que as organizações devem fazer para mitigar as vulnerabilidades dos modelos AD CS?

Compartilhar em

Saiba Mais

Sobre o autor

Como consegui o Admin de Domínio via SafeNet Agent para Logon do Windows através do ESC1

Descrição

Linha do tempo de divulgação

Mitigação

Conclusão

Referências

Perguntas Frequentes

Sobre o autor

Huy Kha

Diretor de Pesquisa de Segurança

Últimos blogs

Nossos principais artigos