O que é o mapeamento fraco de certificados?
O mapeamento fraco de certificados é um risco de autenticação baseada em certificado no Active Directory, em que um certificado pode ser associado a uma conta por meio de dados de nome reutilizáveis em vez de uma vinculação de conta forte e não reutilizável. Em termos concretos de AD CS, o problema aparece quando o logon Kerberos por certificado ou a autenticação por certificado de cliente Schannel aceita mapeamentos baseados em nomes como UPN, nome DNS, endereço de e-mail, nome do assunto, ou emissor e nome do assunto combinados.
O risco não é que os certificados sejam inseguros por padrão. A autenticação baseada em certificado é um recurso de identidade legítimo do Windows. O risco é que os mapeamentos baseados em nome podem ser ambíguos ou reutilizáveis, especialmente quando certificados, nomes de conta, UPNs, nomes alternativos do assunto ou mapeamentos legados não vinculam de forma única o certificado à conta pretendida. A Microsoft tratou essa classe de problemas por meio de alterações na autenticação baseada em certificado em controladores de domínio Windows, incluindo a aplicação do mapeamento forte de certificados e eventos de auditoria para certificados incompatíveis com o modo Full Enforcement.
Este artigo se concentra no comportamento de mapeamento de certificados documentado pela Microsoft: a força do mapeamento do KDC Kerberos, altSecurityIdentities, StrongCertificateBindingEnforcement, os CertificateMappingMethods do Schannel, e os eventos operacionais que revelam mapeamentos fracos ou falhos. Não trata todos os problemas de AD CS como o mesmo problema. Configurações incorretas de template, como registro SAN arbitrário, estão relacionadas, mas o mapeamento fraco de certificados diz respeito especificamente a como o certificado é vinculado a uma conta durante a autenticação.
Para a superfície de ataque AD CS mais ampla, veja Ataques de certificados ADCS: como ESC1 a ESC8 levam a Domain Admin. Para um caminho de autenticação baseado em chave relacionado, mas distinto, veja Shadow Credentials: abuso de msDS-KeyCredentialLink no Active Directory.
Como funciona o mapeamento de certificados
Logon Kerberos por certificado
Na autenticação Kerberos baseada em certificado, o Key Distribution Center (KDC) recebe uma solicitação de autenticação baseada em certificado e precisa determinar qual conta o certificado representa. A documentação Microsoft PKCA define a força do mapeamento de certificados e classifica os métodos de mapeamento como fracos ou fortes. Mapeamentos fracos dependem de dados de nome. Mapeamentos fortes dependem de identificadores mais difíceis de reutilizar ou diretamente vinculados à conta.
A Microsoft lista mapeamentos fracos do KDC como SAN UPNName, SAN DNSName, altSecurityIdentities emissor e assunto, altSecurityIdentities apenas assunto, e o campo 822 de altSecurityIdentities. A Microsoft lista mapeamentos fortes como o SID, Key Trust, altSecurityIdentities emissor e número de série, identificador de chave do assunto, hash SHA1 da chave pública, e emissor e SID. A diferença operacional é direta: se o KDC mapear um certificado por meio de um método fraco, ele deve continuar procurando um mapeamento mais forte e pode rejeitar a solicitação de autenticação se não encontrar nenhum.
Essa distinção explica por que a vinculação forte importa. Um certificado que contém um nome reutilizável não é tão forte quanto um certificado que carrega uma extensão SID ou que é explicitamente mapeado por emissor e número de série, SKI, ou hash SHA1 da chave pública. O trabalho do defensor é remover mapeamentos fracos evitáveis e garantir que a autenticação por certificado só tenha sucesso por meio de mapeamentos fortes.
Mapeamento de certificado de cliente Schannel
O Kerberos não é o único componente do Windows que mapeia certificados para contas. A Microsoft documenta que o Schannel pode mapear um certificado de cliente fornecido a uma aplicação de servidor para uma conta de usuário do Windows. O valor de registro CertificateMappingMethods controla quais métodos de mapeamento o Schannel pode usar. A Microsoft afirma que os mapeamentos de certificado Subject/Issuer, Issuer, e UPN são fracos e desabilitados por padrão no comportamento atualizado, enquanto S4U2Self e S4U2Self explícito são fortes.
Isso importa porque a autenticação por certificado pode aparecer em mais de um lugar: logon com cartão inteligente, PKINIT, autenticação TLS de cliente, aplicações web legadas, portais VPN, fluxos NPS/RADIUS, e serviços administrativos internos. Um domínio pode ter o KDC reforçado enquanto um caminho de aplicação ainda depende de um mapeamento Schannel fraco. Trate Kerberos e Schannel como superfícies de controle relacionadas, mas distintas.
O papel dos templates AD CS
Os templates de certificado AD CS influenciam quais certificados podem ser emitidos e quais dados de identidade eles contêm. A documentação do Microsoft Defender for Identity descreve templates de certificado arriscados em que os usuários podem solicitar certificados válidos para usuários arbitrários com base nas configurações do template. Ela aponta especificamente a opção Supply in the request, EKUs de autenticação como Client Authentication ou Smartcard Logon, permissões de inscrição excessivamente permissivas, falta de aprovação do gestor, e templates publicados por uma CA.
O abuso de templates e o mapeamento fraco não são idênticos. Um problema de template controla se um usuário pode obter um certificado com afirmações de identidade perigosas. Um problema de mapeamento controla se o domínio ou a aplicação aceita esse certificado como uma conta específica. Em ambientes reais, os dois problemas geralmente se combinam: um template permite que um usuário sem privilégios solicite um certificado com dados de identidade controlados pelo atacante, e um mapeamento fraco faz com que esses dados sejam resolvidos para uma conta privilegiada.
Por que o mapeamento fraco ainda importa após as mudanças de aplicação da Microsoft
O KB5014754 da Microsoft documenta as alterações de autenticação baseada em certificado para controladores de domínio Windows. As alterações abordam vulnerabilidades de elevação de privilégio que podem ocorrer quando o KDC Kerberos atende solicitações de autenticação baseadas em certificado. A Microsoft explica que, antes da atualização de segurança de 10 de maio de 2022, a autenticação baseada em certificado não considerava um cifrão no final de um nome de máquina, e que conflitos entre UPNs e sAMAccountName introduziam vulnerabilidades de falsificação.
As datas operacionais importantes já passaram. A Microsoft documentou que os controladores de domínio passaram para o modo Full Enforcement com a atualização de segurança do Windows de fevereiro de 2025, a menos que os administradores já tivessem configurado a chave de registro StrongCertificateBindingEnforcement. A Microsoft também documentou que, após a atualização de segurança do Windows de 9 de setembro de 2025, essa chave de registro deixaria de ser suportada. No modo Full Enforcement, se um certificado não puder ser mapeado fortemente, a autenticação é negada.
Isso não torna o tema obsoleto. Isso muda o que os defensores devem auditar. Em um ambiente atualizado, as dependências de mapeamento fraco tornam-se falhas operacionais, dívida de segurança, ou um sinal de que alguém manteve configurações de compatibilidade que deveriam ser removidas. Em ambientes menos consistentes, níveis de patch mistos de controladores de domínio, uso legado de certificados de cliente, aplicações baseadas em Schannel, implantações de CA não Microsoft, e mapeamentos manuais de altSecurityIdentities ainda podem criar uma exposição real.
Uma auditoria madura deve responder a três perguntas:
- Todos os controladores de domínio e servidores AD CS estão atualizados com as atualizações de segurança relevantes da Microsoft?
- Os logons por certificado têm sucesso por meio de mapeamentos fortes em vez de mapeamentos fracos baseados em nome?
- Alguma aplicação ou controlador de domínio ainda depende de comportamento de compatibilidade, métodos Schannel fracos, ou mapeamentos manuais legados?
A cadeia de ataque
Um modelo defensivo seguro de cadeia de ataque é assim:
| Etapa | O que acontece | O que os defensores devem verificar |
|---|---|---|
| 1. Oportunidade de emissão de certificado | Um template, configuração de CA, ou caminho de inscrição permite que um usuário obtenha um certificado com dados de identidade que podem influenciar a autenticação. | Revisar os EKUs de autenticação, Supply in the request, permissões de inscrição, aprovação do gestor, assinaturas autorizadas, e se o template está publicado. |
| 2. Mapeamento fraco de conta | O certificado é mapeado para uma conta por meio de dados de nome reutilizáveis ou um mapeamento legado de altSecurityIdentities em vez de uma vinculação de conta forte. | Inventariar métodos de mapeamento fraco, mapeamentos manuais, configurações do Schannel, e eventos de auditoria do KDC. |
| 3. Autenticação baseada em certificado | O certificado é apresentado para PKINIT Kerberos, logon com cartão inteligente, ou um caminho de autenticação de cliente Schannel. | Correlacionar eventos do KDC, comportamento do Schannel, emissão da CA, e sensibilidade da conta alvo. |
| 4. Impacto nos privilégios | A conta mapeada é privilegiada, tem direitos de movimento lateral, ou pode alcançar serviços sensíveis. | Revisar contas privilegiadas, acesso a serviços, e uso posterior após a autenticação por certificado. |
| 5. Risco de persistência ou repetição | O certificado permanece válido até a expiração ou revogação, mesmo em caso de redefinição de senha. | Revogar certificados quando apropriado, remover mapeamentos fracos, e verificar a vinculação forte após a limpeza. |
O artigo evita intencionalmente a sintaxe de ferramentas ofensivas. A falha técnica é clara sem um caminho de exploração pronto para copiar e colar: um certificado é emitido ou aceito com dados de identidade que não deveriam ser suficientes para representar a conta alvo.
Esse caminho está ao lado de outros caminhos de escalonamento do Active Directory. Para caminhos de permissões de objeto, veja Abuso de ACL e DCSync: os caminhos silenciosos para Domain Admin. Para persistência Kerberos que não depende de certificados, compare Ataque Golden Ticket: as chaves do seu reino e Ataque Silver Ticket: tickets de serviço Kerberos forjados no Active Directory.
Detecção
A detecção do mapeamento fraco de certificados é um problema de correlação. Um único evento pode mostrar um mapeamento de certificado fraco ou falho, mas por si só não explica como o certificado foi emitido, se a conta é privilegiada, ou se um caminho de aplicação legado ainda depende de um comportamento fraco.
| Sinal | Fonte | O que procurar | Limitação |
|---|---|---|---|
| Eventos de mapeamento fraco ou falho do KDC | Log do Sistema do controlador de domínio após atualizações relevantes | Eventos documentados pelo KB5014754 para certificados sem mapeamento forte ou que falham nos critérios de Full Enforcement. | Requer controladores de domínio atualizados e tentativas de autenticação por certificado relevantes. |
| Emissão de certificados para identidades sensíveis | Logs de segurança da CA do AD CS | Certificados emitidos com EKUs de autenticação, identidade do solicitante, nome do template, dados SAN ou de assunto, se registrados. | O registro da CA deve estar habilitado e mantido; a emissão por si só não prova uma autenticação bem-sucedida. |
Valores fracos de altSecurityIdentities | Inventário do Active Directory | Mapeamentos manuais baseados em nome, como emissor/assunto, apenas assunto, ou mapeamentos do tipo RFC822/e-mail. | O mapeamento manual pode ser lógica de negócio legada; validar antes de remover. |
| Configuração de mapeamento fraco do Schannel | Registro do controlador de domínio e comportamento da aplicação | Valores de CertificateMappingMethods que reativam métodos de mapeamento fracos. | Falhas do Schannel podem afetar aplicações; testar antes de alterar configurações de produção. |
| Risco do template | Revisão de template AD CS ou avaliação do Defender for Identity | Supply in the request, EKUs de autenticação, permissões de inscrição amplas, falta de aprovação, templates publicados. | O risco do template e o risco de mapeamento estão relacionados, mas não são idênticos. |
Eventos do KDC e sinais de Full Enforcement
O KB5014754 da Microsoft adicionou eventos de auditoria para identificar certificados incompatíveis com o modo Full Enforcement. Também documenta que, no modo Full Enforcement, a autenticação é negada se um certificado não puder ser mapeado fortemente. Controladores de domínio que registram esses eventos estão indicando que uma tentativa de autenticação por certificado é incompatível com a vinculação forte, ou que ainda existe um mapeamento de certificado legado em um caminho que você precisa entender.
Não trate esses eventos como ruído. Um aviso de mapeamento fraco pode ser um problema de compatibilidade de negócio, uma tarefa de migração, ou uma investigação de segurança. Priorize eventos envolvendo usuários privilegiados, contas de serviço, controladores de domínio, estações de trabalho administrativas, serviços VPN/NPS, e certificados emitidos por templates que permitem autenticação.
Telemetria de emissão e template do AD CS
A telemetria de emissão do AD CS responde a uma pergunta diferente: de onde veio o certificado? Revise os logs da CA em busca de certificados emitidos, solicitações negadas, nomes de template, contas solicitantes, e propriedades do certificado. Quando a auditoria de serviços de certificação está habilitada, eventos como 4886, 4887, 4888, 4870, 4871, 4872, 4891, 4892, e 4898 fornecem telemetria concreta de solicitação, emissão, negação, revogação, publicação de CRL, alteração de configuração, e carregamento de template. Combine isso com a configuração do template: EKUs de autenticação, assunto ou SAN fornecido pelo solicitante, permissões de inscrição, requisitos de aprovação, assinaturas autorizadas, e se o template está publicado em alguma CA.
As avaliações de postura de segurança do Microsoft Defender for Identity podem ajudar a identificar templates que permitem que usuários solicitem certificados válidos para usuários arbitrários, e templates expostos pelas condições do CVE-2024-49019. O Defender for Identity recomenda especificamente remover permissões de inscrição não privilegiadas, desabilitar Supply in the request, aplicar patches relevantes para servidores AD CS vulneráveis, e usar mitigações como aprovação do gestor ou requisitos de assinatura quando apropriado.
Inventário de mapeamentos manuais
Inventarie altSecurityIdentities em usuários, contas privilegiadas, e contas de serviço. A Microsoft documenta vários valores suportados e classifica os mapeamentos de acordo com sua força. Os fracos são baseados em nome. Os fortes usam emissor e número de série, SKI, hash SHA1 da chave pública, mapeamento relacionado ao SID, ou Key Trust.
Tenha cuidado durante a limpeza. Um mapeamento fraco em um usuário legado de baixo risco pode ser uma dependência operacional, enquanto um mapeamento fraco em uma conta privilegiada é um achado de risco muito maior. O plano de remediação deve substituir mapeamentos fracos por mapeamentos fortes, não simplesmente excluir caminhos de autenticação de produção sem migração.
Para uma cobertura de logs mais ampla em torno da atividade do controlador de domínio e objetos do AD, combine este artigo com Monitoramento do Active Directory: os IDs de evento de segurança que importam.
Remediação
A remediação deve abordar tanto a emissão de certificados quanto o mapeamento de certificados. Corrigir apenas um lado deixa lacunas. Um plano seguro remove mapeamentos fracos desnecessários, atualiza as práticas de emissão de certificados, valida a aplicação no nível do controlador de domínio, e testa caminhos de aplicação que dependem de certificados de cliente.
Aplicar vinculação forte de certificados
Comece pelos controladores de domínio. Certifique-se de que todos os controladores de domínio que atendem à autenticação por certificado estejam atualizados com as atualizações relevantes da Microsoft. Em ambientes modernos atualizados, o Full Enforcement é o estado esperado. Se algum controlador de domínio ainda tiver uma configuração de compatibilidade ou um caminho de exceção, documente por que ele existe, quais certificados dependem dele, e o plano exato de retirada.
⚠️ Atenção: as diretrizes da Microsoft são claras — o modo Full Enforcement nega a autenticação quando um certificado não atende aos critérios de mapeamento forte. A Microsoft também afirma que os métodos Schannel fracos são desabilitados por padrão no comportamento atualizado, e que reverter CertificateMappingMethods para o valor amplo anterior reativa métodos de mapeamento de certificados fracos. Trate essa alteração de registro como uma exceção de compatibilidade, não como um estado de reforço normal.
Substituir mapeamentos fracos
Para mapeamentos manuais em altSecurityIdentities, substitua mapeamentos fracos por mapeamentos fortes quando o negócio ainda precisar de um mapeamento explícito. A Microsoft recomenda mapeamentos fortes como emissor e número de série quando os certificados não puderem ser reemitidos com a nova extensão SID. Outras opções de mapeamento forte incluem SKI e o hash SHA1 da chave pública, de acordo com a documentação da Microsoft sobre força de mapeamento.
Não deixe contas privilegiadas mapeadas por meio de nomes reutilizáveis. Administradores de domínio, administradores de certificados, agentes de inscrição, contas de serviço, identidades de emergência (break-glass), e usuários de estações de trabalho administrativas não devem depender de uma vinculação de identidade fraca. Se existir um fluxo de certificado privilegiado, ele deve usar mapeamento forte, emissão documentada, tempos de vida de certificado curtos quando apropriado, e monitoramento explícito.
Corrigir templates de certificado e configurações de CA
Revise os templates que podem emitir certificados capazes de autenticação. As recomendações do Microsoft Defender for Identity destacam várias mitigações concretas para templates que permitem solicitações de certificado para usuários arbitrários: desabilitar Supply in the request, remover EKUs que permitem autenticação de usuário quando não necessário, remover permissões de inscrição excessivamente permissivas, exigir aprovação do gestor, exigir assinaturas autorizadas, ou despublicar templates das CAs se não forem necessários.
Revise também configurações no nível da CA, como EDITF_ATTRIBUTESUBJECTALTNAME2. O Microsoft Defender for Identity indica que, se esse sinalizador estiver habilitado e um template for válido para autenticação, um atacante pode registrar um certificado capaz de se passar por contas arbitrárias. Isso não é o mesmo que mapeamento fraco, mas afeta diretamente se afirmações de identidade perigosas podem aparecer em certificados emitidos.
Testar dependências do Schannel e de aplicações
Antes de alterar as configurações de mapeamento do Schannel, identifique as aplicações que usam autenticação por certificado de cliente: aplicações IIS, VPN, NPS/RADIUS, portais de administração internos, fluxos de autenticação de dispositivos, e middleware legado. Teste-as com caminhos de mapeamento forte. Se um serviço falhar apenas quando o mapeamento fraco for desabilitado, a correção não é preservar o mapeamento fraco indefinidamente. A correção é atualizar a emissão de certificados e o mapeamento de contas para que o serviço se autentique por meio de uma vinculação forte.
Revogar e reemitir quando necessário
Se certificados suspeitos foram emitidos ou mapeados fracamente, revogue os certificados afetados, publique CRLs atualizadas quando apropriado, e valide se os sistemas dependentes verificam a revogação. Reemita certificados com suporte a mapeamento forte ou com mapeamento manual forte explícito. Se a conta foi usada após a autenticação por certificado, trate a investigação como um comprometimento de identidade: revise mudanças de grupo, acesso a serviços, movimento lateral, e ações administrativas posteriores.
Validação após o reforço
A validação deve provar que a autenticação continua funcionando para usuários legítimos e falha para certificados fracamente vinculados.
| Etapa de validação | Critério de sucesso |
|---|---|
| Revisão de patches dos controladores de domínio | Todos os controladores de domínio que atendem à autenticação por certificado estão atualizados e operando no estado de aplicação esperado. |
| Revisão de eventos do KDC | Nenhum aviso recorrente de mapeamento fraco permanece para fluxos de autenticação legítimos após a migração. |
| Teste de mapeamento forte | Logons de certificado de usuário e máquina têm sucesso por meio de extensão SID, Key Trust, ou mapeamentos fortes explícitos. |
| Teste de mapeamento fraco | Certificados que só se mapeiam por métodos fracos baseados em nome falham em condições de aplicação. |
| Revisão de templates | Templates capazes de autenticação não permitem afirmações de identidade arbitrárias sem controles compensatórios. |
| Revisão do Schannel | Aplicações que usam certificados de cliente não dependem de métodos de mapeamento fracos Subject/Issuer, Issuer, ou UPN. |
| Validação de incidentes | Certificados revogados ou substituídos não se autenticam mais, e a atividade posterior da conta foi revisada. |
Execute a validação em fases. Comece com uma UO de teste ou um grupo de serviço representativo, e depois expanda para usuários privilegiados, estações de trabalho administrativas, VPN/NPS, usuários de cartão inteligente, contas de serviço, e cenários de certificado de máquina. Não presuma que passar em um teste de cartão inteligente valida todos os caminhos de autenticação por certificado no domínio.
Como o EtcSec detecta essa exposição
O EtcSec deve tratar o mapeamento fraco de certificados como uma exposição de vinculação de identidade de certificado, não apenas como um problema de template AD CS. Os sinais relacionados incluem mapeamentos altSecurityIdentities fracos ou legados, templates de certificado que emitem certificados capazes de autenticação com controle perigoso do assunto, permissões de inscrição excessivamente amplas, configurações de CA que permitem SANs fornecidos pela solicitação, e configurações de compatibilidade do controlador de domínio que preservam um comportamento de mapeamento fraco.
A plataforma também pode conectar essa exposição a caminhos de ataque adjacentes: templates AD CS que permitem identidades arbitrárias, principais que podem modificar as ACLs de template de certificado, usuários privilegiados que dependem de mapeamentos de certificado fracos, e monitoramento ausente do controlador de domínio para eventos de autenticação por certificado. Essa é a visão operacional útil. Um mapeamento fraco é perigoso porque fica entre a emissão do certificado e a autenticação da conta.
Controles relacionados
| Controle | Por que importa |
|---|---|
| Full Enforcement para autenticação por certificado | Nega a autenticação quando o certificado não pode ser mapeado fortemente. |
| Caminhos de vinculação forte de certificados | Substitui mapeamentos baseados em nomes reutilizáveis por mapeamentos manuais fortes altSecurityIdentities, como emissor/número de série, SKI, ou hash SHA1 da chave pública, ou por outros caminhos fortes como extensão SID, Key Trust, ou emissor/SID. |
| Reforço dos templates AD CS | Impede que usuários não confiáveis obtenham certificados capazes de autenticação para identidades arbitrárias. |
| Revisão do mapeamento Schannel | Encontra caminhos de aplicação que ainda dependem de mapeamento de certificado fraco. |
| Monitoramento de emissão da CA | Mostra quais certificados foram emitidos, para quem, a partir de qual template, e com quais dados de identidade. |
| Revisão de certificados de contas privilegiadas | Garante que administradores e contas de serviço sensíveis não dependam de vinculação de identidade fraca. |
| Validação de revogação | Confirma que certificados suspeitos ou substituídos não se autenticam mais. |
O mapeamento fraco de certificados não é uma caixa de seleção isolada. Faz parte da segurança do AD CS, da autenticação Kerberos, do ciclo de vida das contas, e da autenticação de aplicações. Se você está construindo uma revisão completa, combine este artigo com Como auditar a segurança do Active Directory: checklist prática para equipes internas e Ataques de delegação Kerberos: da delegação irrestrita ao abuso de RBCD para entender caminhos de identidade adjacentes.
Referências principais
- Microsoft Support: KB5014754 alterações de autenticação por certificado em controladores de domínio Windows
- Microsoft Open Specifications: MS-PKCA Mapping Strength
- Microsoft Defender for Identity: avaliações de postura de segurança de certificados
- Microsoft Learn: documentação do Active Directory Certificate Services
- Microsoft Learn: Audit Certification Services
- Microsoft Learn: visão geral da autenticação Kerberos