Kerberoasting é o ataque do Active Directory em que um invasor com um TGT válido solicita tickets de serviço para contas com SPN e quebra a porção cifrada em RC4 fora da rede, extraindo a senha da conta de serviço sem tocar no host de destino e sem gerar uma única tentativa de login com falha. Para o SOC, o ponto de partida é direto: o sinal primário mora no evento 4769 dos controladores de domínio, no campo de tipo de criptografia do ticket. Um pedido RC4 para conta de serviço, disparado de uma estação de trabalho comum e em rajada, é o padrão que merece regra dedicada. A técnica está catalogada como T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting) na matriz MITRE ATT&CK, dentro da tática de acesso a credenciais.
Como o ataque acontece
Contas de serviço do Active Directory podem ter um Service Principal Name (SPN) associado, o que permite ao Kerberos autenticar clientes nelas. Qualquer usuário autenticado no domínio pode pedir ao controlador de domínio um ticket de serviço para qualquer SPN — o KDC não distingue pedido legítimo de enumeração. Quando a conta aceita RC4, o ticket sai cifrado com uma chave derivada da senha dessa conta, e o atacante leva o material para quebrar em dicionário offline, sem qualquer interação adicional com a rede da vítima. Ferramentas consolidadas fazem exatamente isso: o MITRE lista o módulo Invoke-Kerberoast do PowerSploit, o Rubeus e o GetUserSPNs do Impacket entre os procedimentos observados em intrusões reais, de grupos como FIN7 e Wizard Spider.
O resultado prático é uma senha de conta de serviço em texto claro. Como essas senhas costumam ser antigas, reutilizadas e, com frequência, pertencentes a grupos privilegiados, a quebra bem-sucedida abre caminho direto para escalada e movimento lateral — o mesmo padrão explorado no pass-the-hash: o invasor avança com material de autenticação válido, sem digitar senha em lugar nenhum.
Sinais no evento 4769
O Windows registra cada pedido de ticket de serviço no evento de auditoria 4769 e, segundo a documentação da Microsoft para esse evento, cada pedido de ticket de serviço recebido pelo KDC gera um registro de auditoria apenas nos controladores de domínio — o que define onde coletar o log. Os campos úteis são quatro: conta solicitante, serviço visado, endereço de origem e tipo de criptografia do ticket. A própria documentação orienta monitorar tipos fora da família AES, esperados desde o Windows Vista e o Windows Server 2008.
A estratégia de detecção publicada pelo MITRE para a T1558.003 resume o alvo: vigiar solicitações TGS anômalas no evento 4769 com criptografia RC4 (tipo 0x17), contas que pedem um número incomum de tickets em pouco tempo e contas de serviço procuradas fora do padrão de uso. A tabela orienta a leitura do campo:
| Valor no campo | Algoritmo | Leitura para o SOC |
|---|---|---|
| 0x17 | RC4-HMAC | Suspeito em pedido de conta de serviço a partir de estação de trabalho comum |
| 0x11 | AES128-CTS-HMAC-SHA1-96 | Valor esperado em domínio moderno |
| 0x12 | AES256-CTS-HMAC-SHA1-96 | Valor esperado em domínio moderno |
| 0x1 ou 0x3 | DES | Legado inseguro; investigar por que ainda aparece |
Falso positivo esperado: sistemas legados e appliances que só suportam RC4 geram 0x17 o dia inteiro. A regra ganha precisão quando cruza três condições — criptografia RC4, conta solicitante interativa (não um sistema) e destino que é conta de serviço com SPN. A rajada de pedidos em poucos minutos é o diferencial típico das ferramentas de enumeração. Um detalhe extra da documentação: pedidos com endereço de origem::1 indicam usuário conectado no próprio controlador de domínio; se a conta não pertence à lista de quem pode logar ali, o alerta é imediato.
Procedimento de resposta
- Confirme no evento 4769 o quadrado completo: quem pediu, para qual serviço, de qual endereço e com qual criptografia. Sem esses quatro pontos, a triagem não começa.
- Meça o volume: quantos tickets RC4 a mesma conta solicitou nos últimos minutos? Um pedido isolado é ruído; dezenas em sequência apontam enumeração.
- Confronte a baseline: aquele host e aquele usuário pedem ticket para esse serviço normalmente? O RC4 é legítimo ali, por aplicação antiga, ou é anomalia?
- Identifique o processo no host de origem, se houver EDR: ferramentas de linha de comando conhecidas solicitam os tickets de forma característica.
- Rotacione imediatamente a senha da conta de serviço visada diante de confirmação ou suspeita forte — o custo é baixo e corta a via de quebra offline.
- Hunte com a credencial exposta: logons da conta, tickets emitidos depois, acessos a recursos sensíveis e indícios de movimento lateral, incluindo cascatas de ransomware que começam por credenciais roubadas e bypass de MFA, como no caso Gunra.
Mitigações que encolhem o alvo
A defesa mais eficaz é substituir o RC4 por AES nas contas de serviço e impor senhas longas, complexas e com expiração. O MITRE recomenda expressamente habilitar AES no lugar de RC4 onde possível e senhas com, idealmente, 25 ou mais caracteres para contas de serviço. A Microsoft reforça o mesmo caminho e registra que, em resposta à CVE-2022-37966, as atualizações publicadas a partir de 8 de novembro de 2022 mudaram o tipo de criptografia padrão do Kerberos para AES-SHA1. Contas com gMSA tornam a quebra offline inviável na prática, porque a senha é gerenciada e rotacionada pelo próprio domínio. Por fim, audite SPNs registrados em contas de usuário comuns: cada um deles é um alvo de Kerberoasting esperando enumeração.
