RC4 no Kerberos: Preparar o Domínio para a Remoção

A Microsoft tem dois marcos: em Abril de 2026, as actualizações mudam o valor por omissão de DefaultDomainSupportedEncTypes para 0x18 (AES-SHA1) e activam o modo Enforcement; em Julho de 2026, a remoção da chave de registo RC4DefaultDisablementPhase elimina o botão de recuo e fecha o Audit Mode. O anúncio está na documentação oficial de detecção e remediação de RC4, ligado ao CVE-2026-20833. Para o sysadmin, a pergunta prática é uma: o meu domínio sobrevive ao dia em que o RC4 desliga?

Porquê o RC4 Está em Risco

O RC4 é uma stream cipher dos anos 80, considerada insegura há uma década. No Kerberos, o seu principal risco é o Kerberoasting: o atacante pede service tickets, captura-os e quebra a encriptação offline. Com RC4, quebrar é rápido. Com AES-SHA1, a quebra deixa de ser prática.

A história recente mostra a direcção:

  • Novembro de 2022 (CVE-2022-37966, KB5021131): o tipo de encriptação por omissão passou a AES-SHA1 para contas sem configuração explícita.
  • Windows Server 2025: os campos msDS-SupportedEncryptionTypes processados deixaram de anunciar DES e RC4 por compatibilidade.
  • 2026: o KDC deixa de assumir RC4 para a emissão de tickets de service accounts — a remoção efectiva.

Auditoria: Quem Ainda Usa RC4

Os eventos de uso de RC4 ficam no Security log dos KDCs (Windows Server 2019+ e o Server 2016 recebeu os campos na cumulative update de Janeiro de 2025):

  • 4768 — pedido de TGT (Kerberos Authentication Ticket).
  • 4769 — pedido de service ticket.

Nos dois eventos, os campos MSDS-SupportedEncryptionTypes (os etypes que a conta suporta), Advertized Etypes (os que o cliente anunciou) e Session Encryption Type (o usado no ticket) dizem exactamente quem depende de RC4. O valor 0x17 identifica RC4-HMAC na encriptação da sessão. O 0x4 no msds-SET indica uma conta configurada só com RC4.

Para não filtrar eventos à mão, a Microsoft publica dois scripts open source no repositório Kerberos-Crypto:

.\List-AccountKeys.ps1
.\Get-KerbEncryptionUsage.ps1

O primeiro enumera as chaves disponíveis por conta (o hash da password existe em RC4? em AES?). O segundo identifica os tipos de encriptação em uso nos tickets, com filtros por algoritmo — a lista de contas “RC4-only” sai daqui.

Remediação: A Ordem Certa

  1. Corrigir contas com msDS-SupportedEncryptionTypes = 0x4 (só RC4): adicionar AES aos etypes da conta — 0x18 (AES128 + AES256) ou 0x1C (RC4+AES128+AES256) durante a transição.
  2. Substituir o insubstituível: dispositivos que só fazem RC4 por não terem AES (Windows Server 2003 e anteriores na origem do hash) não se “configuram” — substituem-se ou isolam-se. São também o caso clássico de appliance que nunca teve actualização.
  3. Testar contas de serviço com gMSA — as gMSA rodam chaves automaticamente com AES e eliminam a classe de problema inteira.
  4. Só depois de o relatório ficar vazio, desactivar RC4 nas políticas (Network security: Configure encryption types allowed for Kerberos).

O erro clássico é o passo 4 antes do 1: desactivar RC4 em GPO com contas RC4-only pendentes quebra autenticações em produção, tipicamente em service accounts antigas de impressoras, aplicações legadas e appliances.

Distinção Importante

Este movimento é sobre a cifra do Kerberos, não sobre o protocolo. A auditoria e migração de NTLM — que já foi coberta aqui — é sobre o protocolo de autenticação em si. Os dois projectos correm em paralelo e partilham o mesmo inventário de contas de serviço: quem está a mapear NTLM usage já tem meio do trabalho do RC4 feito.

Artigos Relacionados