Fallback Kerberos RC4 Active Directory: como detectar, porque ainda acontece e como eliminar

O fallback kerberos rc4 active directory descreve a situação em que um controlador de domínio continua a emitir material Kerberos com RC4 porque o cliente, o serviço, as chaves da conta ou a configuração efetiva dos tipos de encriptação não permitem que a troca permaneça em AES. Isso continua a importar em 2026 porque tickets de serviço apoiados em RC4 mantêm relevante o lado de cracking offline de Kerberoasting, mesmo em domínios que já parecem modernos no papel.

Este artigo não é um segundo guia de Kerberoasting. Também não cobre o ângulo de Silver Ticket. É um guia de deteção e remediação para provar onde o RC4 ainda é usado, porque o KDC continua a escolhê-lo e como remover essa dependência sem quebrar a autenticação.

Fallback Kerberos RC4 Active Directory: o que isto significa

Na prática, fallback de Kerberos RC4 não é uma única definição. É o resultado de o KDC escolher RC4 para um ticket ou para uma chave de sessão porque AES está indisponível, não é anunciado, ainda não foi gerado para a conta ou foi excluído pela configuração efetiva.

A Microsoft agora diz isso de forma direta. Na sua guidance atual de Kerberos, a Microsoft diz que o RC4 está a ser eliminado gradualmente, que as atualizações de Windows publicadas em 8 de novembro de 2022 ou depois alteraram o comportamento Kerberos por defeito para preferir AES-SHA1 em contas nas quais um tipo de encriptação não tinha sido definido explicitamente, e que o RC4 continua a aparecer em contas que não suportam AES-SHA1. É por isso que este tema pertence tanto a uma revisão de segurança AD orientada por evidência como a um plano de hardening AD orientado por prioridades.

Porque o RC4 ainda aparece em ambientes AD modernos

O erro mais comum é assumir que ver RC4 num ticket significa sempre um único GPO mal configurado. A documentação atual da Microsoft aponta para várias causas raiz diferentes, e nem todas são remediadas da mesma forma.

Dois pontos da Microsoft importam aqui.

Primeiro, as alterações de Kerberos de 8 de novembro de 2022 não removeram o RC4 em todo o lado. A Microsoft Support diz que essas atualizações definiram AES como tipo de encriptação por defeito para chaves de sessão em contas que ainda não estavam marcadas com um tipo de encriptação por defeito, enquanto a Microsoft Learn diz que o RC4 continua a aparecer em contas que não suportam AES-SHA1.

Segundo, contas de computador e contas de utilizador ou de serviço não se comportam da mesma forma. A Microsoft Support diz que computadores Windows definem automaticamente msDS-SupportedEncryptionTypes para as respetivas contas máquina com base na policy Kerberos local, mas contas de utilizador, group Managed Service Accounts e outras contas AD não recebem esse valor automaticamente. Essa diferença é uma das principais razões pelas quais contas de serviço continuam a aparecer em investigações RC4.

Como detetar fallback de Kerberos RC4

Na maioria dos ambientes, a deteção começa nos controladores de domínio, não no service host que acaba por receber o ticket. A Microsoft Learn diz que detalhes de uso de Kerberos RC4 são registados nos Security logs dos KDC em Windows Server 2019 e posteriores, e que o Windows Server 2016 também ganhou essa visibilidade depois da cumulative update de janeiro de 2025.

Comece com estas fontes de dados:

Se já centraliza a telemetria dos DC, isto deve viver ao lado dos eventos Kerberos cobertos em Monitoramento de Seguranca AD: Os Eventos que Importam, não num relatório ad hoc separado.

O que o Event ID 4769 realmente diz

Event ID 4769 é o local mais prático para provar fallback de Kerberos RC4 porque a Microsoft documenta tanto o valor de encriptação do ticket como os campos de contexto em redor.

Dois detalhes importam imediatamente:

1. A Microsoft documenta Ticket Encryption Type = 0x17 como RC4-HMAC, e 0x18 como RC4-HMAC-EXP.
2. A Microsoft também diz que, desde Windows Vista e Windows Server 2008, os valores esperados de encriptação para tickets de serviço são 0x11 e 0x12, que são algoritmos da família AES.

Isso torna 4769 uma das formas mais limpas de provar que o RC4 ainda está a ser emitido.

Nota: não confunda Ticket Encryption Type = 0x17 em Event ID 4769 com msDS-SupportedEncryptionTypes = 0x18 ou DefaultDomainSupportedEncTypes = 0x18. Em Event 4769, 0x17 e 0x18 são valores de ticket da família RC4. No contexto do bitmask AD e KDC, 0x18 significa apenas AES128 mais AES256.

Essa distinção importa porque é fácil construir a remediação errada se misturar valores de evento com bitmasks de AD.

Ao investigar 4769, use-o com o contexto da conta em redor:

• Se Ticket Encryption Type pertence à família RC4 e a conta de serviço não tem chaves AES, o histórico de palavra-passe é muitas vezes a verdadeira causa.
• Se o cliente ou o alvo não anuncia AES, a compatibilidade de policy ou de plataforma costuma estar envolvida.
• Se os campos do evento sugerem que uma conta suporta apenas comportamento padrão, reveja se essa conta tem realmente um valor msDS-SupportedEncryptionTypes bruto em AD ou se o KDC está a recorrer ao padrão do domínio.

Causas raiz comuns por trás da emissão de tickets RC4

Contas antigas sem chaves AES regeneradas

A Microsoft Learn diz que, se uma conta de utilizador foi criada antes de o suporte a AES-SHA1 ser adicionado ao Windows Kerberos e a palavra-passe nunca foi reposta depois disso, a conta pode não ter chaves AES-SHA1. A Microsoft liga isto à introdução histórica do suporte AES no Windows Server 2003 e diz explicitamente que alterar a palavra-passe da conta gera as chaves em falta.

É por isso que a limpeza de RC4 é em parte um problema de ciclo de vida de palavras-passe e não apenas um problema de policy de protocolo. Isso também explica porque este tema frequentemente se sobrepõe aos problemas de higiene de contas de serviço descritos em Active Directory Password Security: Misconfigurations That Matter.

msDS-SupportedEncryptionTypes está ausente, incompleto ou mal interpretado

A Microsoft Support diz que, se uma conta não tem msDS-SupportedEncryptionTypes definido, ou se o valor é 0, os controladores de domínio assumem um valor por defeito de 0x27 ou usam a definição de registo DefaultDomainSupportedEncTypes. A Microsoft Learn também diz que o KDC usa o padrão do domínio quando a máquina de origem ou de destino não tem um valor definido.

Isso significa que RC4 pode continuar a aparecer sem que um administrador tenha marcado explicitamente qualquer opção RC4 na própria conta.

Use os comandos da Microsoft para inspecionar o que está realmente configurado.

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"

Essa consulta vem da Microsoft Support e destina-se especificamente a encontrar contas em que DES ou RC4 estão explicitamente ativados mas AES não.

Para rever um único objeto, a Microsoft Learn mostra este padrão:

$accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"

Dispositivos e serviços legacy que ainda não suportam AES

A documentação da Microsoft sobre a policy Kerberos continua a avisar que a definição Network security: Configure encryption types allowed for Kerberos pode afetar a compatibilidade com computadores cliente, serviços e aplicações. A mesma guidance da Microsoft Learn diz que a última plataforma Windows que não suportava AES-SHA1 foi o Windows Server 2003 e recomenda migração para dispositivos que ainda dependem desse comportamento antigo.

É aqui que fallback RC4 se torna um problema de engenharia e não apenas uma caixa de seleção. Se desativar RC4 antes de perceber que clientes e serviços ainda precisam dele, troca um problema de segurança por uma falha de autenticação.

Casos limite Linux integrados

A Microsoft documenta agora um cenário específico de integração Linux em que o AD DS continua a emitir tickets cifrados com RC4. Nesse caso, Event ID 4769 mostra Ticket Encryption Type: 0x17, e a Microsoft diz que forçar msDS-SupportedEncryptionTypes para 24 (0x18) ou alterar o GPO de tipos de encriptação Kerberos não resolve o problema.

A razão documentada é mais estreita do que dizer “Linux causa RC4”. A Microsoft diz que o problema acontece porque o atributo operatingSystemVersion é interpretado de forma a fazer com que o KDC trate a conta como se os tipos de encriptação suportados não estivessem preenchidos, levando o KDC a usar em vez disso tipos de encriptação assumidos como suportados.

Este é um caso limite útil porque prova que algumas conclusões RC4 são causadas pela semântica dos metadados do diretório, e não apenas por deriva óbvia de policy.

Como remediar dependências RC4 com segurança

A ordem de remediação mais segura é progressiva.

Actionable next steps

Comece por confirmar a emissão RC4, agrupar as contas afetadas e tratar esta limpeza dentro do mesmo fluxo que um plano de hardening AD orientado por prioridades antes de qualquer endurecimento global.

1. Provar onde o RC4 está a ser emitido antes de alterar padrões

Não comece por desativar RC4 em todo o domínio. Comece por provar onde RC4 ainda é emitido em 4769 e a que conta ou serviço corresponde cada evento. Se atualizou controladores de domínio com as atualizações Windows de 13 de janeiro de 2026 ou posteriores, monitorize também os eventos de auditoria Kdcsvc introduzidos para o caminho de hardening de tickets de serviço RC4.

2. Regenerar chaves AES em falta quando essa é a causa real

Se uma conta antiga de utilizador ou de serviço não tiver chaves AES, a Microsoft diz que alterar a palavra-passe da conta as gera. Isso deve acontecer antes de aplicar alterações mais amplas do lado do KDC. Para contas de serviço com SPN, este é também o ponto em que o risco se cruza com Kerberoasting: tickets apoiados em RC4 são mais fáceis de transformar em cracking offline quando também existem palavras-passe fracas ou reutilizadas.

3. Separar configuração AD bruta do comportamento efetivo do KDC

Verifique o atributo msDS-SupportedEncryptionTypes bruto e depois compare-o com o que o evento mostra. Se o atributo estiver vazio ou for 0, o KDC pode estar a usar DefaultDomainSupportedEncTypes em vez disso. Se uma conta máquina definir o valor automaticamente a partir da policy local, corrija a policy do dispositivo. Se uma conta de utilizador ou de serviço precisar de um valor explícito, altere essa conta deliberadamente em vez de mudar primeiro o padrão de todo o domínio.

4. Remover dependências legacy antes de endurecer a policy Kerberos

Se o cliente, serviço, appliance ou stack não Windows não suportarem realmente AES, a própria guidance da Microsoft é migrar ou substituir quando possível. É também por isso que a documentação do GPO Kerberos continua a avisar sobre impacto de compatibilidade. A limpeza de RC4 deve remover primeiro dependências legacy, não fingir que elas não existem.

5. Usar Protected Users apenas onde realmente encaixa

A Microsoft documenta que Protected Users restringe os seus membros a AES para Kerberos, deixa de criar chaves DES ou RC4 e impede DES ou RC4 na preauthentication de Kerberos. Isso torna o grupo útil para contas humanas selecionadas que já conseguem operar de forma limpa com AES.

Não é uma alavanca universal de remediação RC4. A Microsoft avisa explicitamente para não adicionar contas de serviço ou contas de computador a Protected Users. Por outras palavras, Protected Users é um controlo direcionado para as contas de utilizador certas, não um substituto para corrigir contas de serviço, dispositivos ou configuração de KDC.

6. Preparar-se para as alterações padrão de RC4 em 2026 com datas explícitas

A guidance da Microsoft sobre tickets de serviço RC4 acrescenta uma segunda timeline que importa operacionalmente:

• January 13, 2026: começa a fase inicial de rollout e são adicionados eventos de auditoria para comportamento padrão RC4 de risco.
• April 14, 2026: a fase de enforcement altera o valor padrão DefaultDomainSupportedEncTypes para operações KDC para 0x18, ou seja, apenas AES-SHA1, para contas que não tenham valor explícito de msDS-SupportedEncryptionTypes.
• July 2026: a Microsoft diz que o controlo temporário de rollback para este comportamento é removido e enforcement passa a ser o modo permanente.

Esta é a timeline atual da Microsoft. Se ainda precisar de RC4 depois de 14 de abril de 2026, a Microsoft diz que ele deve ser ativado explicitamente no bitmask msDS-SupportedEncryptionTypes da conta de serviço em vez de depender do antigo comportamento padrão.

Validação após a passagem para AES

O trabalho só está concluído quando a evidência muda, não quando o GPO parece mais limpo.

Valide a alteração nesta ordem:

1. Confirmar que novas entradas de Event ID 4769 para os serviços remediados já não mostram valores de ticket da família RC4.
2. Confirmar que em vez disso aparecem os valores esperados da família AES, normalmente 0x11 ou 0x12.
3. Confirmar que a conta agora tem chaves AES se uma reposição de palavra-passe era a correção pretendida.
4. Confirmar que a autenticação do serviço continua a funcionar após reposição de palavra-passe, reinício de serviço ou alteração de definições da conta.
5. Em controladores de domínio atualizados para o caminho de hardening de 2026, confirmar que não existem avisos ou erros Kdcsvc 201-209 relevantes para os caminhos remediados.
6. Testar explicitamente a interoperabilidade não Windows. A Microsoft diz que a ausência de eventos de auditoria não garante que todos os dispositivos não Windows continuem a funcionar depois da atualização de enforcement de 14 de abril de 2026.

Se quiser acompanhar isto ao longo do tempo em vez de o tratar como uma limpeza pontual, integre-o num workflow de auditoria recorrente e mantenha-o na mesma família de controlos que as configurações incorretas de segurança do Active Directory mais comuns que alimentam a deriva de identidade.

Como a EtcSec deteta fallback de Kerberos RC4

A EtcSec deteta fallback de Kerberos RC4 correlacionando a evidência que a Microsoft agora expõe de forma operacional:

• emissão de tickets de serviço Kerberos da família RC4
• contas que ainda dependem de definições de encriptação padrão ou explícitas compatíveis com RC4
• principals que não têm chaves AES utilizáveis após deriva por antiguidade de conta ou histórico de palavra-passe
• caminhos de contas de serviço onde fallback RC4 e exposição a tickets crackable se sobrepõem

Isto permite que equipas meçam novamente depois de reposições de palavra-passe, alterações de definições de conta, limpeza de serviços legacy e hardening de KDC, em vez de tratar RC4 como um tema de revisão única.

Referências primárias

• Detect and remediate RC4 usage in Kerberos
• Event 4769: A Kerberos service ticket was requested
• KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
• How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833
• Protected Users security group
• Preventing Kerberos change password that uses RC4 secret keys
• Linux accounts can't get AES-encrypted tickets in AD DS
• Network security: Configure encryption types allowed for Kerberos