Um minuto de tickets fracos: como pegar Kerberoasting nos logs do DC

No Active Directory, um serviço como o SQL Server roda sob uma conta que tem um service principal name (SPN). Para acessá-lo, o usuário pede ao controlador de domínio um ticket de serviço Kerberos, e parte desse ticket é criptografada com uma chave derivada da senha da conta de serviço. Qualquer usuário autenticado pode pedir um ticket para qualquer SPN, então a requisição é normal e é atendida.

O Kerberoasting (MITRE ATT&CK T1558.003, apresentado por Tim Medin em 2014) pede esses tickets em massa e os quebra offline, onde nenhum log enxerga. Os tickets RC4 (0x17) são o prêmio: a chave deles é o hash NT da conta, que as GPUs testam em ordens de grandeza mais rápido que as chaves AES (0x12), com salt e iterações, então a senha de uma conta de serviço escolhida por um humano cai rápido. O MITRE lista o uso da técnica por grupos de ransomware como o Wizard Spider e pelo APT29 no comprometimento da SolarWinds.

O controlador de domínio registra cada ticket como evento 4769, e a criptografia do ticket é decidida pela conta de serviço. A Microsoft anunciou que, a partir de meados de 2026, os controladores de domínio aceitam apenas AES por padrão, com RC4 somente onde um administrador o habilitar; a Ashgrove manteve o RC4 ligado por causa de um cliente ERP antigo, então suas oito contas de serviço mais velhas, que nunca receberam uma configuração AES, ainda entregam tickets RC4 a qualquer um, enquanto as contas de computador e a gMSA recebem AES. A orientação da Microsoft para esse evento é vigiar criptografia de ticket diferente de 0x11 e 0x12; o MITRE acrescenta o formato: uma conta pedindo um número incomum de tickets de serviço em pouco tempo.

• Responder svc_erpbatch. Ela tem exatamente tantos tickets RC4 quanto o atacante, mas sempre para um único serviço, svc_sqlerp, a cada dois minutos, a partir do servidor ERP: uma tarefa agendada numa conta antiga, uma exceção a ser aposentada, não um ataque. Conte serviços distintos por conta, não linhas.
• Responder svc_tenable. Cinco serviços em catorze segundos é a varredura autenticada do scanner de vulnerabilidades: tickets AES, para contas de computador (nomes terminados em $) cujas senhas são longas, aleatórias e rotacionadas, então não vale a pena fazer roasting nelas.
• Responder a.quintero. Um ticket RC4 para svc_crm é um usuário abrindo o CRM, que ainda roda sob uma conta antiga. RC4 sozinho não é o sinal.
• Responder uma conta de serviço atacada. svc_sql, svc_backup e as outras são as vítimas: os tickets delas é que foram pedidos. A pergunta é quem os pediu.
• Responder a estação de trabalho. WKS-0417 (10.20.14.37) é de onde vieram as requisições e a máquina a isolar, mas os tickets foram emitidos para a conta c.ferrante.
• Procurar falhas. Todas as linhas têm código de falha 0x0: um Kerberoast é feito de requisições bem-sucedidas e perfeitamente válidas.

Faça os tickets não valerem o esforço de quebrar e depois faça o padrão de requisição ficar barulhento.

• Dê AES a toda conta de serviço: defina msDS-SupportedEncryptionTypes como 0x18 (AES128 + AES256) e redefina a senha uma vez para que as chaves AES existam. Depois aposente a exceção do RC4: atualize o cliente ERP e deixe o RC4 ir embora, como os novos padrões da Microsoft pretendem.
• Migre os serviços para contas de serviço gerenciadas de grupo (gMSA): o domínio dá a elas senhas longas e aleatórias e as rotaciona, então um ticket roubado não pode ser quebrado. Onde isso for impossível, use uma senha aleatória de 25+ caracteres, como o MITRE recomenda, e rotacione-a.
• Remova SPNs que ninguém usa e mantenha as contas de serviço fora de grupos privilegiados como Domain Admins.
• Habilite Audit Kerberos Service Ticket Operations em todos os controladores de domínio e alerte quando uma conta obtiver tickets RC4 (0x17) para vários serviços distintos em um minuto; ignore serviços terminados em $ e coloque em allowlist pares legados conhecidos, como svc_erpbatch para svc_sqlerp. Uma conta honeypot com um SPN que nada usa transforma qualquer pedido de ticket para ela em um alerta de alta confiança.
• Responda: redefina agora as senhas das oito contas de serviço atacadas (os tickets já estão offline), isole a WKS-0417 e investigue a sessão de c.ferrante.