Shadow Credentials e abuso de msDS-KeyCredentialLink

O que são Shadow Credentials?

Shadow Credentials é o nome usado pela comunidade de Active Directory para um caminho de ataque que abusa de material de autenticação baseado em chave em uma conta, geralmente por meio do atributo msDS-KeyCredentialLink. O ponto importante não é o nome. O ponto importante é que um principal pode receber um caminho adicional de autenticação por chave pública, separado da senha.

Em uma implantação legítima, msDS-KeyCredentialLink é usado pelo Windows Hello for Business e por cenários relacionados de Key Trust. A Microsoft documenta que, em algumas implantações híbridas de Windows Hello for Business, a chave pública do usuário pode ser sincronizada do Microsoft Entra ID para o Active Directory e gravada no atributo msDS-KeyCredentialLink do objeto de usuário. A Microsoft também documenta o comportamento Key Trust para Kerberos PKINIT: um KDC que usa Active Directory como banco de contas deve confirmar que a conta tem a mesma chave pública em msDS-KeyCredentialLink.

Um caso de abuso de Shadow Credentials existe quando um atacante ou administrador não autorizado consegue adicionar ou preservar uma key credential inesperada em um objeto de usuário ou computador e depois usar a chave privada correspondente para autenticar como essa conta por meio de um fluxo baseado em chave. Isso não é password spraying, Kerberoasting, DCSync ou Golden Ticket. É mais próximo de um caminho de persistência e impersonificação baseado em ACL: o objeto de diretório da conta foi modificado para que uma chave diferente possa satisfazer as verificações de autenticação.

Este artigo usa o termo Shadow Credentials porque ele é amplamente reconhecido por defensores e auditores de Active Directory. A documentação da Microsoft normalmente descreve os mecanismos subjacentes como Windows Hello for Business, Key Trust, PKINIT e msDS-KeyCredentialLink. Essa distinção importa: o atributo em si não é malicioso. Um valor não nulo de msDS-KeyCredentialLink pode ser normal em ambientes que usam Windows Hello for Business, fluxos relacionados a FIDO ou recursos de confiança por chave. O objetivo defensivo é identificar key credentials não autorizadas, órfãs, inesperadas ou presentes em contas privilegiadas, não apagar todos os valores às cegas.

Para o contexto mais amplo de caminhos de ataque de identidade, veja Caminhos de Ataque AD: Ma Configuracoes em Cadeia e Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin. Shadow Credentials pertence à mesma família de problemas porque a causa raiz costuma ser capacidade excessiva de escrita sobre um objeto de identidade.

Como msDS-KeyCredentialLink funciona

Armazenamento legítimo de key credentials

msDS-KeyCredentialLink armazena dados de key credential em um objeto do Active Directory. As Microsoft Open Specifications descrevem KEYCREDENTIALLINK_BLOB como a estrutura armazenada na parte binária do atributo DN-Binary msDS-KeyCredentialLink. A Microsoft também documenta restrições para adicionar valores em objetos de computador, incluindo que a parte binária deve ser um KEYCREDENTIALLINK_BLOB bem formado, que o uso deve ser KEY_USAGE_NGC e que a origem deve ser KEY_SOURCE_AD para essa operação documentada em conta de computador.

Essa especificação de objeto de computador não deve ser generalizada para todos os cenários de objeto de usuário. Para objetos de usuário, a fonte operacional mais clara é a documentação do Windows Hello for Business: depois que um usuário provisiona uma credencial Windows Hello for Business em determinados ambientes híbridos, a chave pública do usuário pode ser sincronizada para o AD e gravada em msDS-KeyCredentialLink. A orientação de suporte da Microsoft também fornece um script para enumerar objetos de usuário com valores msDS-KeyCredentialLink não nulos e extrair campos como Source, Usage, DeviceID e KeyID.

Caminho de autenticação Key Trust

O lado de autenticação se baseia em criptografia de chave pública. A RFC 4556 define PKINIT como criptografia de chave pública para a troca inicial de autenticação Kerberos. A documentação PKCA da Microsoft descreve como o Windows implementa PKINIT e Key Trust. Em um caso de Key Trust, o KDC pode procurar uma conta pela chave pública, e implementações que usam Active Directory devem confirmar que a mesma chave pública está presente em msDS-KeyCredentialLink.

Em linguagem defensiva prática, o atributo dá ao AD uma forma de associar uma conta a material de chave que pode ser usado para autenticação. A chave privada deve permanecer protegida no dispositivo legítimo ou no contêiner de credenciais. A chave pública é o que o AD pode usar para validar que a tentativa de autenticação corresponde a uma chave esperada. Se uma chave não autorizada é adicionada a uma conta de alto valor, a conta passa a ter um caminho adicional de autenticação que defensores podem não perceber durante revisões normais de senha.

Redefinições de senha não bastam

É por isso que Shadow Credentials é diferente de uma compromissão baseada em senha. Uma redefinição de senha trata uma senha roubada. Ela não remove necessariamente um valor key credential não autorizado da conta. A Microsoft documenta que o sign-in e o desbloqueio do Windows Hello for Business usam uma chave ou certificado, e que alterar a senha da conta do usuário não afeta esse comportamento de sign-in ou desbloqueio. Para resposta a incidentes, isso significa que a rotação de senha pode ser necessária, mas insuficiente, se o objeto da conta ainda contém material de chave não autorizado.

Por que Key Trust muda o modelo de ataque

O endurecimento tradicional de Active Directory costuma focar em senhas, exposição NTLM, tickets de serviço Kerberos e participação em grupos privilegiados. Esses temas continuam importantes, mas Key Trust introduz outra pergunta: quem pode modificar o objeto da conta ou o material de chave associado à conta?

Se um usuário ou serviço tem permissão efetiva para gravar msDS-KeyCredentialLink, ou consegue alterar a DACL ou o proprietário do objeto para obter essa capacidade de escrita, o risco deixa de ser apenas login na conta. Ele passa a ser controle do objeto de identidade. O Windows Event 4662 destaca Write Property, WRITE_DAC e WRITE_OWNER como tipos de acesso importantes para monitorar em objetos AD. Esses direitos não são automaticamente maliciosos, mas em usuários privilegiados, contas de serviço, controladores de domínio ou OUs administrativas, merecem muito mais atenção.

Também por isso Shadow Credentials é um problema de caminho de ataque. O ponto inicial pode ser um grupo de helpdesk delegado, uma conta de serviço com direitos amplos sobre objetos, uma permissão herdada em uma OU ou uma delegação administrativa antiga. O estado final pode ser um caminho persistente de autenticação contra uma conta privilegiada. Se o defensor revisa apenas participação em grupos, pode perder a permissão em nível de objeto que tornou o caminho possível. O aninhamento de grupos também pode esconder quem efetivamente recebe controle delegado; revise Aninhamento Perigoso de Grupos AD: Caminhos para Domain Admin quando permissões herdadas estiverem envolvidas.

Compare isso com Ataques Delegacao Kerberos: Nao Restrita a RBCD. Abuso de delegação depende de configurações de delegação e relações de identidade de serviço. Shadow Credentials depende de material de chave e controle de escrita no objeto. Ambos são próximos de Kerberos, mas não são o mesmo modo de falha e não devem ser misturados em um artigo genérico de Kerberos.

Pré-requisitos para abuso

Um cenário de Shadow Credentials geralmente exige todas estas condições:

Condição	Significado defensivo
Uma conta alvo suporta um caminho relevante de autenticação baseada em chave	O ambiente usa ou aceita Key Trust, autenticação apoiada por certificado ou padrões Windows Hello for Business que dependem de validação de chave pública.
Um principal não autorizado pode adicionar ou preservar material key credential	A permissão perigosa pode ser escrita direta no atributo ou controle mais amplo do objeto que leva a essa escrita.
O atacante controla a chave privada correspondente	O AD armazena o lado público. A autenticação só funciona se o cliente puder provar posse da chave privada correspondente.
A atividade não é detectada ou remediada	O valor permanece no objeto e pode sobreviver a uma limpeza limitada à senha.

O que não é vulnerabilidade por si só

Esses pré-requisitos devem ser lidos com cuidado. A presença de Windows Hello for Business não significa que o ambiente seja vulnerável por si só. A presença de msDS-KeyCredentialLink não significa comprometimento por si só. O risco aparece quando permissões do objeto de conta, inventário de key credentials e telemetria de autenticação mostram que uma key credential inesperada foi adicionada ou está sendo usada.

Observação sobre objetos de computador

Objetos de computador merecem uma observação separada. A Microsoft documenta domain-joined device public key authentication e explica que dispositivos Windows modernos podem provisionar uma chave pública vinculada à própria conta de computador quando há suporte de um controlador de domínio Windows Server 2016 ou posterior. Isso significa que defensores devem esperar material de chave legítimo em algumas contas de computador. O controle não é zero key credentials em todos os lugares. O controle é propriedade correta, mapeamento esperado de dispositivos e capacidade de escrita restrita.

Observação sobre contas privilegiadas

Contas privilegiadas exigem um padrão mais rigoroso. A orientação da Microsoft sobre dual enrollment do Windows Hello for Business descreve permissões Key Admins em msDS-KeyCredentialLink e considerações AdminSDHolder para usuários e grupos privilegiados protegidos. Esse é um sinal forte para defensores: qualquer workflow que habilite intencionalmente sign-in baseado em chave para identidades privilegiadas deve ser documentado, limitado e monitorado, porque toca a mesma superfície de controle que atacantes tentariam abusar.

A cadeia de ataque

Um modelo defensivo seguro da cadeia de ataque é este:

Etapa	O que acontece	O que defensores devem verificar
1. Descoberta de permissões	O atacante identifica uma conta ou OU onde consegue afetar atributos ou o descritor de segurança do objeto alvo.	Revisar permissões efetivas em usuários de alto valor, contas de computador, contas de serviço e OUs administrativas.
2. Adição de key credential	Um valor key credential inesperado é adicionado a `msDS-KeyCredentialLink`.	Monitorar Event 5136 para o LDAP display name `msDS-KeyCredentialLink`, especialmente operações `Value Added`.
3. Autenticação baseada em chave	O atacante tenta autenticar com a chave privada correspondente à chave pública adicionada.	Correlacionar eventos 4768, padrões de pré-autenticação PKINIT ou semelhantes a smart card, hosts de origem e sensibilidade da conta.
4. Movimento lateral ou persistência	A conta é usada para acesso, escalonamento ou persistência enquanto rotação de senha sozinha pode não remover o caminho por chave.	Remover key credentials não autorizadas, corrigir permissões do objeto e validar que nenhuma autenticação baseada em chave inesperada continua.

O artigo não fornece intencionalmente comandos de exploração específicos de ferramentas. Defensores não precisam de um caminho de exploração copiável para entender a falha de controle. O ponto central é que uma modificação em objeto de diretório pode criar um caminho de autenticação que a higiene normal de senhas não remove.

Essa cadeia também explica por que Shadow Credentials frequentemente aparece ao lado de outros riscos AD. Uma conta privilegiada obsoleta, uma ACL herdada perigosa ou um modelo de delegação fraco pode criar as condições para a escrita de key credential. Para exposição de contas, veja Contas Obsoletas e Superprivilegiadas no AD. Para contexto de persistência Kerberos, compare com as mecânicas diferentes de Ataque Golden Ticket — Deteccao & Remediacao.

Detecção

A detecção de Shadow Credentials deve ser baseada em correlação. Nenhum evento Windows isolado prova a técnica completa. Uma detecção útil combina evidência de modificação de diretório, contexto de permissão do objeto, comportamento de autenticação e inventário legítimo de Windows Hello for Business.

Sinal	Fonte	O que pode provar	Limitação
Valor `msDS-KeyCredentialLink` adicionado ou alterado	Event 5136, Directory Service Changes	O atributo do objeto mudou, e o evento pode expor LDAP display name, tipo de operação, DN do objeto e correlation ID.	Não prova que a mudança é maliciosa. Enrollment WHfB ou fluxos de dispositivo podem ser legítimos.
Acesso de escrita em objetos sensíveis	Event 4662, SACL em objetos AD	Um principal executou ou tentou operações como `Write Property`, `WRITE_DAC` ou `WRITE_OWNER` em objetos ou propriedades monitorados.	Exige auditoria e cobertura SACL corretas. Sem SACLs, a evidência pode não existir.
Solicitação de TGT com pré-autenticação de estilo chave pública	Event 4768 em controladores de domínio	Um TGT foi solicitado; o evento expõe o tipo de pré-autenticação e campos relacionados a certificados em cenários relevantes.	É telemetria de autenticação, não prova que uma chave maliciosa foi adicionada. Correlacionar com 5136/4662 e contexto da conta.
Inventário de key credentials não nulas	Consulta AD ou parsing no estilo suporte Microsoft	Quais usuários têm valores `msDS-KeyCredentialLink` e o que campos como source, usage, DeviceID e KeyID mostram.	O inventário deve ser comparado com registros conhecidos de WHfB/FIDO/enrollment de dispositivos.
Permissões efetivas inesperadas	Revisão ACL AD	Quais usuários, grupos ou serviços podem escrever o atributo ou alterar a segurança do objeto.	Achados de permissão são exposição, não evidência de exploração.

Telemetria de modificação de diretório

Para 5136, a Microsoft recomenda monitorar o campo LDAP Display Name ao acompanhar modificações em um atributo AD específico. Para este tema, o nome relevante é msDS-KeyCredentialLink. Priorize eventos Value Added, depois correlacione por DN do objeto, conta que realizou a alteração, workstation de origem quando disponível e operações de diretório próximas com o mesmo correlation ID.

Para 4662, priorize usuários de alto valor, grupos privilegiados, OUs administrativas, contas de serviço e objetos de computador que representem infraestrutura sensível. A Microsoft destaca tipos de acesso como Write Property, WRITE_DAC e WRITE_OWNER como importantes de monitorar. Para uma hunt de Shadow Credentials, eles são especialmente relevantes quando envolvem um objeto de identidade privilegiado ou uma property GUID mapeada a msDS-KeyCredentialLink.

Correlação de autenticação

Para 4768, trate o evento como contexto de autenticação. A Microsoft documenta que 4768 é gerado quando o KDC emite um TGT e que o evento inclui um campo Pre-Authentication Type. Tipos associados a autenticação smart card ou por chave pública podem ajudar a identificar padrões de autenticação baseada em chave, mas devem ser correlacionados com mudanças de diretório e comportamento esperado de login. Se uma conta privilegiada passa de repente a mostrar autenticação baseada em chave depois de uma modificação inesperada do atributo, a história combinada é muito mais forte do que qualquer evento isolado.

Perguntas de inventário

Uma hunt prática deve responder a estas perguntas:

Quais usuários privilegiados, contas de serviço e contas de computador têm valores msDS-KeyCredentialLink não nulos?
Os valores são esperados para uma implantação documentada de Windows Hello for Business, FIDO ou autenticação de dispositivo?
Cada entrada mapeia para um dispositivo conhecido, usuário esperado, KeyID esperado e source esperada?
Quem pode escrever o atributo ou alterar a DACL ou o proprietário do objeto?
Valores key credential foram adicionados pouco antes de autenticação Kerberos incomum ou atividade administrativa?

Para cobertura mais ampla de eventos, use Monitoramento de Seguranca AD: Os Eventos que Importam como checklist complementar, mas mantenha a correlação de Shadow Credentials específica. Monitoramento Kerberos genérico não é suficiente.

Remediação

A remediação deve ser direcionada. Limpar msDS-KeyCredentialLink às cegas em todo o domínio pode quebrar cenários legítimos de Windows Hello for Business ou autenticação de dispositivos. A abordagem mais segura é validar propriedade, remover valores não autorizados e corrigir as permissões que permitiram que o valor aparecesse.

Inventário e triagem

Comece pelo inventário. Enumere usuários e computadores com valores msDS-KeyCredentialLink não nulos, depois faça parsing dos valores em campos como Source, Usage, DeviceID e KeyID quando possível. A orientação de suporte da Microsoft mostra esse tipo de análise para objetos de usuário e explica que o certificado correspondente deve estar no repositório pessoal de certificados do usuário no computador com o identificador de dispositivo correspondente. Em um ambiente gerenciado, esse inventário também deve ser comparado com registros de dispositivos Microsoft Entra, registros de enrollment Windows Hello for Business e o processo de acesso privilegiado.

Depois separe o esperado do inesperado. Valores esperados devem mapear para usuários, dispositivos e desenhos de autenticação conhecidos. Valores inesperados incluem entradas em contas que não deveriam usar autenticação baseada em chave, entradas que não mapeiam para um dispositivo aprovado, entradas adicionadas por um principal não aprovado, entradas que aparecem após atividade administrativa suspeita ou valores encontrados em contas privilegiadas sem processo documentado de dual enrollment ou workstation privilegiada.

Remover apenas valores não autorizados

Para entradas confirmadas como não autorizadas, remova do objeto o valor específico não autorizado. Não confie apenas em redefinição de senha. A redefinição pode ainda ser necessária se a conta foi comprometida de outra forma, mas sozinha não prova que o material de autenticação baseado em chave foi removido do AD.

Corrigir o caminho de permissões

Depois da limpeza de valores, corrija permissões. Revise direitos diretos e herdados que permitem gravar msDS-KeyCredentialLink, gravar propriedades amplas do objeto, alterar a DACL ou alterar o proprietário do objeto. Remova delegações amplas de contas privilegiadas, OUs administrativas, OUs de contas de serviço e contas de computador quando não forem necessárias. Se um workflow de helpdesk ou automação precisa gerenciar legitimamente enrollment Windows Hello for Business, limite-o de forma estreita e monitore explicitamente.

Para contas privilegiadas, revise Key Admins e grupos relacionados. A documentação Microsoft de dual enrollment descreve permissões Key Admins em msDS-KeyCredentialLink e considerações AdminSDHolder para contas protegidas. Se enrollment Windows Hello for Business é permitido para contas privilegiadas, documente quais dispositivos são aprovados, quais contas são permitidas e como novos valores key credential são autorizados. Se não for permitido, contas privilegiadas não devem acumular key credentials silenciosamente.

Por fim, endureça o modelo operacional. Use administração em camadas ou isolamento administrativo equivalente para que workstations de menor confiança e grupos delegados amplos não consigam modificar objetos de identidade de alto valor. Mantenha a administração de identidades privilegiadas separada de contas de produtividade diária. Revise caminhos de ataque periodicamente, porque esse problema normalmente é causado por uma cadeia de direitos, não por uma única participação óbvia em grupo.

Validação após a limpeza

A validação deve provar tanto a limpeza quanto a recuperação do controle.

Etapa de validação	Critério de sucesso
Executar novamente o inventário de key credentials	Apenas valores `msDS-KeyCredentialLink` esperados permanecem, e cada um mapeia para usuário, dispositivo, source, usage e KeyID documentados.
Reverificar permissões do objeto	Nenhum principal não autorizado pode escrever o atributo, escrever propriedades amplas, alterar DACL ou alterar proprietário em contas de alto valor.
Revisar 5136 após limpeza	Nenhuma operação `Value Added` inesperada ocorre para `msDS-KeyCredentialLink` em contas privilegiadas ou computadores sensíveis.
Revisar 4662 após limpeza	Atividade Write Property e security descriptor em objetos monitorados corresponde a workflows admin aprovados.
Revisar 4768 após limpeza	Autenticação baseada em chave para contas sensíveis ocorre apenas a partir de usuários, dispositivos e cenários esperados.
Testar fluxos legítimos WHfB/FIDO	Usuários aprovados ainda conseguem fazer sign-in onde o negócio depende intencionalmente de Key Trust.

Se um incidente envolveu uma conta privilegiada, a validação também deve incluir revisão de atividade downstream. Verifique logons administrativos, mudanças de participação em grupos, mudanças de configuração de serviços, edições de GPO, novos certificados e qualquer movimento posterior que possa ter usado a identidade recuperada. Shadow Credentials pode ser o método de acesso, mas não necessariamente o objetivo final.

Como a EtcSec detecta exposição relacionada

A EtcSec não deve rotular este artigo com um tipo de vulnerabilidade impreciso se o catálogo não contém uma entrada direta para Shadow Credentials ou msDS-KeyCredentialLink. A exposição relacionada ainda se encaixa no modelo de auditoria Active Directory da EtcSec: permissões perigosas em objetos, exposição de contas privilegiadas, caminhos ACL herdados e lacunas de monitoramento em mudanças de objetos AD.

Na prática, uma revisão EtcSec pode ajudar a identificar as condições que tornam esse caminho de ataque viável: principals com controle excessivo de escrita sobre objetos de usuário ou computador, contas privilegiadas não isoladas, caminhos ACL perigosos para identidades administrativas e lacunas de monitoramento sobre mudanças de diretório. Esse é o enquadramento correto. Shadow Credentials não é uma fraqueza Kerberos genérica; é um caminho de abuso Key Trust criado por controle de objeto.

Controles relacionados

Controles de Shadow Credentials devem estar ligados à propriedade da identidade, não apenas ao monitoramento Kerberos.

Controle	Por que importa
Inventariar `msDS-KeyCredentialLink` em usuários e computadores	Estabelece quais caminhos de autenticação baseada em chave existem antes de um incidente.
Restringir acesso de escrita a atributos key credential	Impede que principals não autorizados adicionem novo material de autenticação.
Monitorar 5136 em `msDS-KeyCredentialLink`	Captura mudanças em nível de atributo quando Directory Service Changes auditing e SACLs estão configurados.
Monitorar 4662 em objetos de identidade sensíveis	Expõe operações Write Property, DACL e ownership quando SACLs estão presentes.
Correlacionar 4768 com mudanças de diretório	Ajuda a conectar comportamento de autenticação baseada em chave a modificações recentes de objetos.
Proteger contas privilegiadas com isolamento administrativo	Reduz a chance de uma compromissão de nível inferior modificar objetos de identidade de alto valor.
Revisar Key Admins e comportamento AdminSDHolder	Evita que caminhos legítimos de administração WHfB se tornem caminhos descontrolados de escrita de chaves privilegiadas.

Esses controles também apoiam o endurecimento AD mais amplo. Se você está construindo uma revisão estruturada, combine este artigo com Auditar a segurança do Active Directory: checklist prática, depois priorize primeiro objetos de identidade privilegiados e OUs sensíveis.

Shadow Credentials: abuso de msDS-KeyCredentialLink no Active Directory