Guido Grillenmeier e Rich Peckham

Ao longo da história do Active Directory, os agentes maliciosos têm identificado continuamente novas formas de expor vulnerabilidades no protocolo de autenticação Kerberos. Para ajudar a reduzir os riscos associados ao «Kerberoasting», a Microsoft vai descontinuar a encriptação RC4 a partir de abril de 2026. Se ainda não identificou as aplicações no seu ambiente que poderão ser afetadas por esta alteração, é altura de colocar essa tarefa no topo da sua lista de afazeres. Esta publicação explica o processo e indica-lhe recursos que podem ajudar.


Por que razão a Microsoft está a descontinuar a encriptação RC4?

As táticas, técnicas e procedimentos (TTPs) que exploram o Kerberos podem ser classificados em três categorias:

  • Ataques de tipo «roasting», como o AS-REQ Roasting e o Kerberoasting
  • Abuso de delegação, incluindo a delegação Kerberos sem restrições e a delegação restrita baseada em recursos
  • Abuso de bilhetes, incluindo o Bilhete Dourado, o Bilhete Prateado, o Bilhete Diamante, o Bilhete Safira, o Bilhete Bronze, o Pass-the-Ticket, etc.

O Kerberoasting tornou-se uma das técnicas de ataque mais comuns. Nos últimos anos, a Microsoft introduziu medidas de defesa contra ataques de Kerberoasting, e surgiram muitos artigos sobre o Kerberoasting e sobre como mitigá-lo. Não vamos aprofundar os mecanismos do ataque neste artigo, mas, numa visão geral, eis como funciona:

  1. Um atacante solicita um bilhete de serviço para um nome de entidade de serviço (SPN) válido.
  2. O Centro de Distribuição de Chaves Kerberos (KDC) emite o bilhete de serviço utilizando encriptação RC4 — um algoritmo menos seguro do que o AES-SHA1 (e, por isso, mais fácil de ser quebrado).
  3. O atacante retira esse bilhete da rede e utiliza um mecanismo de ataque por força bruta para descobrir a palavra-passe da conta.
  4. O atacante utiliza a conta comprometida para se deslocar lateralmente e escalar privilégios.

Devido à exploração frequente do RC4 no âmbito dos ataques de «Kerberoasting», a Microsoft anunciou a descontinuação desta encriptação, com a fase de auditoria a ter início em janeiro de 2026, a aplicação com reversão manual em abril de 2026 e a aplicação total em julho de 2026.

No entanto, muitas empresas continuam a utilizar aplicações internas ou de terceiros que não suportam tipos de encriptação mais seguros, como o AES-128 e o AES-256. Se a sua organização se enquadra neste grupo, terá de identificar essas contas de aplicações e configurar o AES para cada uma delas.


Que aplicações utilizam o RC4?

Então, como é que se sabe quais são as aplicações que utilizam o RC4 como tipo de encriptação Kerberos?

Terá de auditar o Serviço de Autenticação Kerberos e as operações de bilhetes de serviço Kerberos para registar os IDs de evento 4768 (eventos do Serviço de Autenticação) e 4769 (Operações de Bilhetes de Serviço) no registo de eventos de Segurança. (A Microsoft introduziu os IDs de evento adicionais 201–209, também conhecidos como reforço do KDC, com as atualizações de janeiro de 2026 no registo de eventos do sistema para apoiar ainda mais o esforço de descontinuação do RC4. No entanto, os eventos 4768 e 4769 podem ser considerados os eventos «principais», razão pela qual esta publicação se concentra no acompanhamento destes dois eventos.)

Vamos analisar esses acontecimentos.


ID do evento 4768

A Figura 1 mostra um exemplo de saída do ID de evento 4768.

      Foi solicitado um bilhete de autenticação Kerberos (TGT).

Informações da conta:
    Nome da conta:        jdoe
    Nome do reino fornecido:    CHILD
    ID do utilizador:            S-1-5-21-1873250772-3107742394-1596888999-1114
	Tipos de encriptação suportados pelo MSDS:    0x27 (DES, RC4, AES-Sk)
    Chaves disponíveis:    AES-SHA1, RC4

Informações do serviço:
    Nome do serviço:        krbtgt
	ID do serviço:        S-1-5-21-1873250772-3107742394-1596888999-502
    Tipos de encriptação suportados pelo MSDS:    0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
	Chaves disponíveis:    AES-SHA1, RC4

Informações do controlador de domínio:
    MSDS-SupportedEncryptionTypes:    0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
    Chaves disponíveis:    AES-SHA1, RC4

Informações de rede:
    Endereço do cliente:        ::ffff:10.1.1.250
    Porta do cliente:        53904
    Tipos anunciados:	
		AES256-CTS-HMAC-SHA1-96
        AES128-CTS-HMAC-SHA1-96
        RC4-HMAC-NT
        DES-CBC-MD5

Informações adicionais:
    Opções de bilhete:        0x40810010
	Código de resultado:        0x0
    Tipo de encriptação do bilhete:    0x12
    Tipo de encriptação da sessão:    0x12
    Tipo de pré-autenticação:    2
    Tipo de encriptação da pré-autenticação:    0x12

--Resto omitido por motivos de concisão.--

Figura 1. Exemplo de saída do ID de evento 4768


Este exemplo contém vários conjuntos de informações relevantes.

Informações da conta

  • Nome da conta. A identidade que solicita o Ticket Granting Ticket (TGT)
  • Nome do domínio fornecido. O domínio onde a identidade se encontra
  • ID do utilizador. O nome descritivo (ou SID) da identidade
  • MSDS-SupportedEncryptionTypes. Os tipos de encriptação que a conta pode utilizar

Informações sobre o serviço

  • Nome do serviço. O principal de serviço solicitado (neste caso, krbtgt)
  • ID do serviço. O nome descritivo (ou SID) da entidade de serviço solicitada
  • MSDS-SupportedEncryptionTypes. Os tipos de encriptação que a conta de serviço pode utilizar

Informações sobre o controlador de domínio (DC)

  • MSDS-SupportedEncryptionTypes. Os tipos de encriptação suportados pelo DC

Informação adicional

  • Opções de bilhete. 0x40810010 (reencaminhável, renovável, canônico, renovável-ok), conforme ilustrado na Figura 2.
Figura 2. Registo do Wireshark que mostra a opção de bilhete 0x40810010
  • Tipo de encriptação do bilhete. 0x12 (AES256), conforme ilustrado na Figura 3.
  • Tipo de encriptação da sessão. 0x12 (AES256), conforme ilustrado na Figura 3.
Figura 3. Registo do Wireshark a mostrar os tipos de encriptação de bilhete e sessão
  • Tipo de encriptação de pré-autenticação: 0x12 (AES256), conforme ilustrado na Figura 4.
Figura 4. Registo do Wireshark que mostra o tipo de encriptação pré-autenticação

ID do evento 4769

A Figura 5 mostra um exemplo de saída do ID de evento 4769.

      A Kerberos service ticket was requested.

Account Information:
	Account Name:		jdoe@CHILD.CONTOSO.COM
	Account Domain:		CHILD.CONTOSO.COM
	Logon GUID:		{5f752786-c7b3-fb33-0ce8-a54adeea22c3}
	MSDS-SupportedEncryptionTypes:	N/A
	Available Keys:	N/A

Service Information:
	Service Name:		CHILDMEMBER$
	Service ID:		S-1-5-21-1873250772-3107742394-1596888999-1105
	MSDS-SupportedEncryptionTypes:	0x1C (RC4, AES128-SHA96, AES256-SHA96)
	Available Keys:	AES-SHA1, RC4

Domain Controller Information:
	MSDS-SupportedEncryptionTypes:	0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
	Available Keys:	AES-SHA1, RC4

Network Information:
	Client Address:		::ffff:10.1.1.250
	Client Port:		53905
	Advertized Etypes:	
		AES256-CTS-HMAC-SHA1-96
		AES128-CTS-HMAC-SHA1-96
		RC4-HMAC-NT

Additional Information:
	Ticket Options:		0x40810000
	Ticket Encryption Type:	0x12
	Session Encryption Type:	0x12
	Failure Code:		0x0
	Transited Services:	-

--Remainder snipped brevity--

Figura 5. Exemplo de resultado do ID de evento 4769


Este exemplo contém vários conjuntos de informações relevantes.

Informações sobre o serviço

  • Nome do serviço. O SPN do pedido de bilhete de serviço (neste caso, para host/childmember.child.contoso.com), conforme ilustrado na Figura 6.
      sname-string: 2 itens
SNameString: host
SNameString: childmember.child.contoso.com

Figura 6. Excerto de um registo do Wireshark, mostrando o SPN do pedido de bilhete de serviço


  • ID do serviço. O nome descritivo (ou SID) do entidade de segurança que registou o SPN
  • MSDS-SupportedEncryptionTypes. Os tipos de encriptação que a conta de serviço pode utilizar

Informações sobre DC

  • MSDS-SupportedEncryptionTypes. Os tipos de encriptação suportados pelo DC

Informação adicional

  • Opções de bilhetes. 0x40810000
  • Tipo de encriptação do bilhete. 0x12 (AES256)
  • Tipo de encriptação da sessão. 0x12 (AES256)

Quando se utiliza o RC4 para encriptação, os resultados apresentam-se ligeiramente diferentes dos exemplos anteriores. A Figura 7 mostra a saída do ID de evento 4769 para um computador cliente que utiliza apenas encriptação RC4.

      A Kerberos service ticket was requested.

Account Information:
	Account Name:		jdoe@CHILD.CONTOSO.COM
	Account Domain:		CHILD.CONTOSO.COM
	Logon GUID:		{df8a66a8-8c1d-061e-b216-f935b45eb88a}
	MSDS-SupportedEncryptionTypes:	N/A
	Available Keys:	N/A

Service Information:
	Service Name:		CHILDMEMBER$
	Service ID:		CHILD\CHILDMEMBER$
	MSDS-SupportedEncryptionTypes:	0x4 (RC4)
	Available Keys:	AES-SHA1, RC4

Domain Controller Information:
	MSDS-SupportedEncryptionTypes:	0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
	Available Keys:	AES-SHA1, RC4

Network Information:
	Client Address:		::ffff:10.1.1.250
	Client Port:		51299
	Advertized Etypes:	
		AES256-CTS-HMAC-SHA1-96
		AES128-CTS-HMAC-SHA1-96
		RC4-HMAC-NT

Additional Information:
	Ticket Options:		0x40810000
	Ticket Encryption Type:	0x17
	Session Encryption Type:	0x17
	Failure Code:		0x0
	Transited Services:	-

--Remainder snipped for brevity--

Figura 7. Resultado para o ID de evento 4769 num computador cliente que utiliza apenas RC4


As partes em negrito mostram as principais diferenças entre este caso e os exemplos anteriores. Vamos analisá-las.

Informações sobre o serviço

  • Nome do serviço. CHILDMEMBER$ (igual ao exemplo anterior)
  • ID do serviço. O nome descritivo (ou SID) da entidade de serviço solicitada
  • Tipos de encriptação suportados pelo MSDS. 0x4 (RC4)

Informação adicional

  • Opções de bilhetes. 0x40810000 (igual ao exemplo anterior)
  • Tipo de encriptação do bilhete. 0x17 (RC4-HMAC)
  • Tipo de encriptação da sessão. 0x17 (RC4-HMAC)

Como verificar se existem aplicações que utilizam o RC4 no seu ambiente

Como demonstra o exemplo anterior do RC4, para identificar a encriptação RC4 no seu ambiente, é necessário pesquisar nos registos de eventos (de preferência registos SIEM) para encontrar pedidos de serviço de autenticação (AS-REQ) e respostas (AS-REP), bem como pedidos de serviço de concessão de bilhetes (TGS-REQ) e respostas (TGS-REP) com os tipos de encriptação de bilhete e de sessão 0x17.

Para o ajudar nesta tarefa, criámos exemplos de consultas tanto para o Microsoft Sentinel como para o Splunk. Pode utilizar estes exemplos como modelos para auditar o seu próprio ambiente.

Dependendo da forma como configurou o reencaminhamento de eventos para o Sentinel, terá de consultar o DeviceEvents ou o WindowsEvent. Por exemplo, se utilizar o Reencaminhamento de Eventos do Windows para recolher registos de eventos e reencaminhá-los para o Sentinel, terá de consultar o WindowsEvent e procurar apenas as ocorrências dos IDs de evento 4768 e 4769 que correspondam a 0x17 no Tipo de Criptografia do Bilhete ou no Tipo de Criptografia da Sessão.

Pode utilizar a seguinte consulta para pesquisar no Sentinel. Esta consulta foi alargada para incluir outras colunas de dados.

      WindowsEvent
| onde EventID está em ('4768', '4769')
| onde TimeGenerated está entre (ago(60d) .. now())
| definir EventDataJson = parse_json(EventData)
| definir TargetUserName = EventDataJson.TargetUserName
| definir TargetDomainName = EventDataJson.TargetDomainName
| extend IpAddress = EventDataJson.IpAddress
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
| extend ServiceName = EventDataJson.ServiceName
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
| extend TicketEncryption = EventDataJson.TicketEncryptionType
| extend TicketOptions = EventDataJson.TicketOptions
| where SessionKeyEncryption == '0x17' or
            TicketEncryption == '0x17'
| project  TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson

Aqui está uma breve descrição da consulta:


WindowsEvent

Como a consulta é armazenada nesta implementação do Sentinel (pode ser o DeviceEvents no seu ambiente, conforme descrito anteriormente)

| where EventID in ('4768', '4769')

Pesquisas pelos IDs de evento 4768 e 4769

| where TimeGenerated between (ago(60d) .. now())

Remonta a 60 dias (pode definir o valor que desejar)

| extend EventDataJson = parse_json(EventData)

Formata a coluna EventData em JSON e analisa o JSON para ser utilizado no resto da consulta

| extend TargetUserName = EventDataJson.TargetUserName

Especifica a identidade que solicita o bilhete

| extend TargetDomainName = EventDataJson.TargetDomainName

Especifica o domínio onde reside a identidade solicitante

| extend IpAddress = EventDataJson.IpAddress

Mostra o endereço IP do cliente, caso este esteja visível no evento

| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys

Indica as chaves de encriptação disponíveis para o serviço

| extend ServiceName = EventDataJson.ServiceName

Especifica o SPN ao qual se refere o pedido de bilhete

| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType

Especifica o tipo de encriptação da chave de sessão que o cliente (solicitante) utilizará para interagir com o proprietário do bilhete

| extend TicketEncryption = EventDataJson.TicketEncryptionType

Especifica o tipo de encriptação do TGT ou do bilhete de serviço

| extend TicketOptions = EventDataJson.TicketOptions

Fornece informações adicionais sobre as opções de ticket da solicitação, o que pode ser útil para identificar opções de ticket como tickets de encaminhamento, delegação, tickets reencaminhados, tickets de proxy, etc.

| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'

Procura encriptação da chave de sessão ou encriptação do bilhete que seja RC4-HMAC (0x17)

| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson

Indica os campos a apresentar na visualização dos resultados


A Figura 8 mostra um exemplo dos resultados desta consulta.

Um exemplo de resultados de uma consulta no Microsoft Sentinel
Figura 8. Um exemplo dos resultados de uma consulta no Microsoft Sentinel

No Splunk, esta mesma consulta teria o seguinte formato:

      index="wineventlog" LogName="Security" EventCode IN ("4768", "4769") earliest=-60d@d latest=now
| search Session_Encryption_Type="0x17" or Ticket_Encryption_Type="0x17"
| tabela _time EventCode Account_Name Account_Domain Client_Address service_name Ticket_Encryption_Type Session_Encryption_Type Ticket_Options, _raw

Antes de utilizar estas consultas no seu ambiente, certifique-se de que a Auditoria de Tickets de Serviço está ativada. Sem esta ativação, os DCs não irão gerar os eventos relevantes (IDs de evento 4768 e 4769 e IDs de evento 201–209, que dizem respeito ao reforço de segurança do KDC).

A melhor forma de ativar a auditoria de bilhetes de serviço é atualizar uma política de grupo existente ou adicionar uma que esteja atribuída à unidade organizacional (OU) do seu servidor de domínio (DC). É necessário fazer isto para todos os domínios da sua floresta AD. O caminho para as definições relevantes é Configuração do Computador > Definições do Windows > Definições de Segurança > Configuração Avançada da Política de Auditoria > Políticas de Auditoria > Início de Sessão da Conta. Ative as subcategorias Auditar Serviço de Autenticação Kerberos e Auditar Operações de Bilhetes de Serviço Kerberos tanto para Sucesso como para Falha ( Figura 9).

Ativar a auditoria de tickets de serviço
Figura 9. Ativação da auditoria de bilhetes de serviço

Se nunca configurou uma Política de Auditoria Avançada nos seus domínios, certifique-se de que também ativa a política «Auditoria: Forçar as definições da subcategoria da política de auditoria (Windows Vista ou posterior) para substituir as definições da categoria da política de auditoria» em «Configuração do Computador» > «Definições do Windows» > «Definições de Segurança» > «Políticas Locais» > «Opções de Segurança». Esta política é normalmente definida na mesma Política de Grupo que a «Auditoria de Bilhetes de Serviço».


Nota: Se não encontrar quaisquer eventos de bilhete de serviço 4769 nos registos de eventos de segurança dos seus DCs, também não verá avisos de reforço de segurança do KDC (201–209) no registo do sistema.

Dica de validação: Force temporariamente um dispositivo a suportar apenas RC4 e solicite um bilhete de serviço a partir de uma conta sem quaisquer valores em msDS-SupportedEncryptionTypes. Se a auditoria estiver devidamente configurada, deverá ver os avisos relacionados. Para mais detalhes, consulte o artigo do Microsoft Learn«Detectar e corrigir a utilização de RC4 no Kerberos».


Assim que tiver a certeza de que a auditoria do Kerberos está a funcionar, começa o verdadeiro trabalho: analisar os eventos recebidos e corrigir as contas ou os sistemas afetados.

A principal dificuldade na remoção do RC4 decorre das contas de serviço antigas cujas palavras-passe não são alteradas há muitos anos. Como o RC4 no Active Directory está associado ao hash NT, qualquer conta cuja palavra-passe nunca tenha sido redefinida após a introdução do AES (ou seja, após o lançamento do Windows Server 2008 e do Windows Vista) poderá ainda possuir apenas chaves compatíveis com o RC4.

Só é possível resolver este problema redefinindo a palavra-passe da conta de serviço duas vezes, o que obriga o AD a gerar as chaves AES necessárias. No entanto, também terá de saber onde essa conta de serviço está a ser utilizada no seu ambiente; por exemplo, para iniciar o serviço em questão num determinado servidor membro ou para executar uma tarefa agendada.

Se observar avisos de reforço de segurança do KDC (eventos 201–209 no registo do sistema) juntamente com os eventos 4768 ou 4769, esta publicação no LinkedIn de Jerry Devore, da Microsoft, oferece uma excelente visão geral sobre como corrigir as contas e os sistemas em questão, em que msds-SET = msDS-SupportedEncryptionTypes (Tabela 1).

Par de eventosO que isso significaCausa principalSolução rápida
201/203Cliente apenas RC4 + msds-SET vazioDispositivo antigo ou keytabAtive o AES no cliente OU defina msds-SET para 28
202/204A conta não possui chave AES + msds-SET em brancoSenha antigaReiniciar a palavra-passe da conta (duas vezes)
205Tipos de encriptação suportados pelo domínio predefinido em usoSubstituição do registo ativaRemova a substituição, se possível
206/208Cliente apenas RC4 + msds-SET apenas AESIncompatibilidade do clienteAdicionar RC4 ao msds-SET (valor 28)
207/209A conta não possui chave AES + AES msds-SETA palavra-passe não foi redefinidaReiniciar a palavra-passe da conta (duas vezes)
Tabela 1. Contas e sistemas em recuperação

O essencial para os administradores de TI

  • Verifique agora se existem contas e dispositivos ainda ligados ao RC4.
  • Atualize as contas de serviço para configurações compatíveis com AES antes da aplicação total da medida ou da descontinuação do RC4.
  • Elimine ou atualize os sistemas antigos que não suportam o AES.
  • Utilize os registos de eventos de forma proativa para detetar dispositivos problemáticos antes que estes deixem de funcionar — o que irá acontecer após a aplicação das atualizações de julho de 2026.

Precisa de mais ajuda?

A descontinuação do RC4 é um passo positivo na luta contra o Kerberoasting, mas exige uma ação rápida. Se tiver dúvidas sobre estas questões ou precisar de ajuda para fazer a transição das contas da sua aplicação, estamos à sua disposição.