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

O fallback Kerberos RC4 no Active Directory significa 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. É um guia de deteção e remediação para provar onde o RC4 ainda está a ser usado, porque o KDC continua a escolhê-lo e como remover essa dependência sem quebrar a autenticação.

O que significa o fallback Kerberos RC4 no Active Directory

Na prática, o 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 o AES está indisponível, não é anunciado, ainda não foi gerado para a conta, ou é excluído pela configuração efetiva.

A Microsoft afirma isto agora de forma direta. Na sua orientação atual sobre Kerberos, a Microsoft diz que o RC4 está a ser eliminado progressivamente, que as atualizações do Windows lançadas em ou após 8 de novembro de 2022 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 ser usado 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 auditoria como a um plano de limpeza AD orientado por hardening.

Porque o RC4 ainda aparece em ambientes AD modernos

O erro mais comum é presumir que ver RC4 num ticket significa sempre uma GPO má. A documentação atual da Microsoft aponta para várias causas-raiz diferentes, e nem todas se remediam da mesma forma.

Há dois pontos da Microsoft que importam aqui.

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

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

Como detetar o fallback Kerberos RC4

Na maioria dos ambientes, a deteção começa nos controladores de domínio, não no anfitrião do serviço que acaba por receber o ticket. O Microsoft Learn diz que os detalhes de utilização de RC4 no Kerberos são registados nos logs de Segurança nos KDCs para Windows Server 2019 e posterior, e que o Windows Server 2016 também ganhou visibilidade da utilização de RC4 nestes eventos depois da atualização cumulativa de janeiro de 2025.

Comece por estas fontes de dados:

Se já centraliza a telemetria dos DCs, isto deve ficar junto dos eventos Kerberos abordados em Monitorização de Segurança do Active Directory: os Event IDs que Importam, e não num relatório ad hoc separado.

O que o Evento ID 4769 realmente lhe diz

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

Dois detalhes importam de imediato:

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

Isso faz do 4769 uma das formas mais claras de provar que o RC4 ainda está a ser emitido.

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

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

• Se o Ticket Encryption Type é da família RC4 e a conta de serviço não tem chaves AES, o histórico de palavras-passe é frequentemente o verdadeiro problema.
• Se o cliente ou o alvo não anunciar AES, está normalmente envolvida a compatibilidade de política ou de plataforma.
• Se os campos do evento sugerirem que uma conta suporta apenas o comportamento por defeito, verifique se a conta tem, de facto, um valor msDS-SupportedEncryptionTypes em bruto no AD ou se o KDC está a recorrer ao valor por defeito do domínio.

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

Contas antigas sem chaves AES regeneradas

O Microsoft Learn diz que, se uma conta de utilizador foi criada antes de o suporte a AES-SHA1 ter sido adicionado ao Kerberos do Windows e a palavra-passe nunca foi redefinida depois de esse suporte ter sido adicionado, a conta pode não ter chaves AES-SHA1, e que alterar a palavra-passe da conta gera essas chaves em falta.

Há uma ressalva sobre datas, porque as próprias páginas da Microsoft se contradizem entre si. A página de remediação do RC4 afirma que o suporte a AES-SHA1 no Kerberos do Windows "foi adicionado no Windows Server 2003", mas a mesma página também chama ao Windows Server 2003 a última versão do Windows que não suportava AES-SHA1. As outras referências da Microsoft são consistentes com a segunda leitura: a documentação da política Kerberos lista AES128_HMAC_SHA1 e AES256_HMAC_SHA1 como "Não suportado no Windows 2000 Server, Windows XP, ou Windows Server 2003", e a documentação do Evento ID 4769 lista 0x11 e 0x12 como "Suportado a partir do Windows Server 2008 e do Windows Vista". Trate o Windows Vista e o Windows Server 2008 como o ponto em que o AES-SHA1 passou a estar disponível, e o Windows Server 2003 como a última plataforma Windows sem ele.

É por isso que a limpeza do RC4 é, em parte, um problema de ciclo de vida das palavras-passe, e não apenas um problema de política de protocolo. Isto também explica porque é que o problema costuma sobrepor-se aos problemas de higiene de contas de serviço descritos em Segurança de Palavras-passe no Active Directory: Configurações que os Atacantes Adoram.

msDS-SupportedEncryptionTypes está ausente, incompleto, ou é mal interpretado

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

Isto significa que o RC4 pode continuar a aparecer sem que um administrador tenha alguma vez marcado explicitamente uma opção de RC4 na própria conta.

Use os próprios comandos da Microsoft para inspecionar o que está efetivamente configurado.

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

Esta query vem do Microsoft Support e destina-se especificamente a encontrar contas em que o DES ou o RC4 estão explicitamente ativados mas o AES não está.

Para a revisão de um único objeto, o 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 legados que ainda não suportam AES

A documentação da política Kerberos da Microsoft continua a avisar que a definição Network security: Configure encryption types allowed for Kerberos "pode afetar a compatibilidade com computadores cliente ou com serviços e aplicações". Separadamente — e isto vem da orientação de deteção e remediação de RC4 da Microsoft, não da página de política — a Microsoft diz que a última versão do Windows que não suportava AES-SHA1 foi o Windows Server 2003, e recomenda migrar para uma versão do Windows que suporte AES-SHA1.

É aqui que o fallback de RC4 se transforma num problema de engenharia em vez de numa simples checkbox. Se desativar o RC4 antes de perceber quais clientes e serviços ainda precisam dele, está a trocar um problema de segurança por uma interrupção de autenticação.

Casos extremos de integração com Linux

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

A razão documentada é mais restrita do que "o Linux causa RC4". A Microsoft diz que o problema ocorre porque o atributo operatingSystemVersion é interpretado de uma forma que leva o KDC a tratar a conta como se os tipos de encriptação suportados não estivessem preenchidos, fazendo com que o KDC use tipos de encriptação suportados presumidos.

As correções documentadas pela Microsoft são igualmente restritas: remover o atributo operatingSystemVersion, definir o seu valor de forma a que o primeiro carácter não seja um dígito, ou passar para uma versão de sistema que cumpra a especificação.

Este é um caso extremo que vale a pena conhecer porque prova que algumas descobertas de RC4 são causadas pela semântica dos metadados do diretório, e não apenas por um desvio óbvio de política.

Como remediar dependências RC4 com segurança

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

1. Prove onde o RC4 está a ser emitido antes de alterar valores por defeito

Não comece por desativar o RC4 em todo o domínio. Comece por provar onde o RC4 ainda está a ser emitido no 4769 e a que conta ou serviço cada evento corresponde. Em controladores de domínio atualizados com as atualizações do Windows de 13 de janeiro de 2026 ou posteriores, monitorize também os eventos de auditoria Kdcsvc introduzidos para o percurso de reforço dos tickets de serviço RC4.

2. Regenere as chaves AES em falta onde essa for realmente a causa

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 fazer alterações mais amplas do lado do KDC. Para contas de serviço com SPNs, este é também o ponto em que o risco se sobrepõe ao Kerberoasting: os tickets apoiados em RC4 são mais fáceis de transformar em trabalho de cracking offline quando também existem palavras-passe fracas ou reutilizadas.

3. Separe a configuração AD em bruto do comportamento efetivo do KDC

Verifique o atributo msDS-SupportedEncryptionTypes em 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. Se uma conta de computador estiver a definir o valor automaticamente com base na política local, corrija a política do dispositivo. Se uma conta de utilizador ou de serviço precisar de um valor explícito, altere essa conta deliberadamente em vez de alterar primeiro todo o valor por defeito do domínio.

4. Remova as dependências legadas antes de reforçar a política Kerberos

Se o cliente, serviço, appliance, ou stack não-Windows não suportar realmente o AES, a orientação da própria Microsoft é migrar ou substituí-lo sempre que possível. É também por isso que a documentação da GPO Kerberos continua a avisar sobre o impacto na compatibilidade. A limpeza do RC4 deve remover primeiro as dependências legadas, e não fingir que elas não existem.

5. Use o Protected Users apenas onde realmente se aplica

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

Não é uma alavanca universal de remediação de RC4. A Microsoft avisa explicitamente para nunca adicionar contas de serviços e computadores ao Protected Users. Por outras palavras, o Protected Users é um controlo direcionado para as contas de utilizador certas, não um substituto para corrigir a configuração de contas de serviço, dispositivos, ou do KDC — o mesmo problema de âmbito abordado em Contas Privilegiadas no Active Directory: Protected Users, Delegação e Lacunas nas Contas de Serviço.

6. Considere as alterações por defeito do RC4 de 2026, que já entraram em vigor

A orientação da Microsoft sobre tickets de serviço RC4 acrescenta uma segunda linha temporal que importa a nível operacional. As três fases já pertencem todas ao passado, por isso isto já não é trabalho de preparação — é o estado que tem de assumir em controladores de domínio atualizados:

• 13 de janeiro de 2026: a fase inicial de implementação entrou em vigor, avisando sobre o reforço que estava para vir e adicionando eventos de auditoria para o comportamento por defeito de RC4 arriscado.
• 14 de abril de 2026: a fase de aplicação alterou o valor por defeito de DefaultDomainSupportedEncTypes para as operações do KDC para 0x18, ou seja, apenas AES-SHA1, para contas que não têm um valor explícito de msDS-SupportedEncryptionTypes. Nesta fase, a aplicação ainda podia ser revertida manualmente.
• Julho de 2026: as atualizações do Windows lançadas em ou após julho de 2026 removeram o suporte para a subchave de registo RC4DefaultDisablementPhase, pelo que o controlo manual de reversão deixou de existir e a aplicação passou a ser o modo permanente.

Se ainda precisar de RC4 hoje, a Microsoft diz para o configurar explicitamente no atributo msDS-SupportedEncryptionTypes da conta de serviço, em vez de depender do antigo comportamento por defeito, porque o valor por defeito do domínio deixou de o fornecer.

Validação depois de migrar para AES

O trabalho está concluído quando as evidências mudam, não quando a GPO parece mais limpa.

Valide a alteração por esta ordem:

1. Confirme que as novas entradas do Evento ID 4769 para os serviços remediados deixaram de mostrar valores de ticket da família RC4.
2. Confirme que aparecem, em vez disso, os valores de ticket esperados da família AES, tipicamente 0x11 ou 0x12.
3. Confirme que a conta já tem chaves AES, caso a redefinição da palavra-passe fosse a correção pretendida.
4. Confirme que a autenticação do serviço continua a funcionar depois de redefinições de palavra-passe, reinícios de serviço, ou alterações nas definições da conta.
5. Em controladores de domínio atualizados para o percurso de reforço de 2026, confirme que não existem avisos ou erros Kdcsvc 201-209 relevantes para os percursos remediados.
6. Teste explicitamente a interoperabilidade com sistemas não-Windows. A Microsoft diz que a ausência de eventos de auditoria não garante que todos os dispositivos não-Windows vão aceitar com sucesso a autenticação Kerberos depois da atualização de abril de 2026.

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

Como a EtcSec deteta o fallback Kerberos RC4

A EtcSec deteta o fallback Kerberos RC4 correlacionando as evidências que a Microsoft agora expõe operacionalmente:

• emissão de tickets da família RC4 na telemetria de tickets de serviço Kerberos
• contas que ainda dependem de definições de encriptação por defeito ou explicitamente compatíveis com RC4
• principais que não têm chaves AES utilizáveis devido à idade da conta ou ao desvio do histórico de palavras-passe
• percursos de contas de serviço onde o fallback de RC4 e a exposição de tickets crackáveis se sobrepõem

Isso permite às equipas voltar a medir depois de redefinições de palavra-passe, alterações nas definições da conta, limpeza de serviços legados, e reforço do KDC, em vez de tratar o RC4 como um item de revisão único.

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
• CVE-2026-20833 in the NVD
• 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