O que é Kerberoasting e como proteger seu Active Directory

Imagine que um funcionário novo, com acesso básico ao domínio da empresa, consegue extrair a senha do servidor de banco de dados sem disparar nenhum alarme — tudo usando ferramentas nativas do Windows. É exatamente isso que o Kerberoasting permite. Não é um zero-day sofisticado: é uma característica do próprio protocolo Kerberos, e qualquer conta de domínio pode iniciar o ataque.

Como o Kerberos funciona (em 60 segundos)

O Kerberos é o protocolo de autenticação padrão em ambientes Windows com Active Directory. O fluxo básico tem três etapas:

1. O usuário se autentica no Key Distribution Center (KDC) e recebe um Ticket Granting Ticket (TGT).
2. Quando quer acessar um serviço, o usuário apresenta o TGT ao KDC e solicita um Ticket Granting Service (TGS).
3. O TGS é entregue criptografado com o hash da senha da conta de serviço responsável por aquele serviço.

O passo 3 é onde o Kerberoasting entra. O KDC não valida se o usuário que pediu o ticket tem permissão de usar o serviço — ele simplesmente entrega o ticket. Crackear o ticket offline depois é problema do atacante, não do AD.

O que são SPNs e por que isso importa

Um Service Principal Name (SPN) é o identificador único de uma instância de serviço no Active Directory. Quando você configura SQL Server, IIS, SharePoint ou qualquer serviço Windows, um SPN é registrado no AD vinculando aquele serviço a uma conta.

Qualquer usuário autenticado no domínio pode listar todos os SPNs registrados — sem privilégio especial. E para cada SPN listado, pode solicitar um TGS. O resultado: um arquivo de hash pronto para ser quebrado offline com hashcat ou John the Ripper.

O ataque passo a passo

1. Enumeração: o atacante lista SPNs com Get-ADUser -Filter {ServicePrincipalName -ne "$null"} ou com ferramentas como Impacket.
2. Requisição de tickets: para cada SPN, solicita um TGS ao KDC. Operação completamente legítima, sem alerta.
3. Extração: extrai os tickets da memória (Mimikatz, Rubeus) ou captura direto pelo tráfego de rede.
4. Cracking offline: roda hashcat no modo -m 13100 (RC4) ou -m 19600 (AES) contra wordlists e regras.
5. Lateral movement: com a senha da conta de serviço, acessa o servidor alvo — muitas vezes com privilégios elevados ou acesso a dados sensíveis.

O que é Kerberoasting?

Kerberoasting é um ataque que explora o protocolo Kerberos para extrair tickets de serviço do Active Directory e quebrá-los offline, recuperando a senha em texto claro da conta de serviço — sem necessidade de privilégios administrativos.

O nome vem de "Kerberos" + "roasting" (assar), numa referência ao processo de "torrar" o hash até revelar a senha. O ataque foi documentado formalmente por Tim Medin em 2014, mas continua relevante porque ataca o design do protocolo, não uma vulnerabilidade específica.

RC4 vs AES: por que o algoritmo muda tudo

Tickets Kerberos podem ser criptografados com RC4 (NTLM) ou AES-128/256. A diferença prática para quem está crackeando:

• RC4: derivado direto do hash NTLM da senha, sem salt, sem iteração. GPUs modernas conseguem testar bilhões de candidatos por segundo. Uma senha de 8 caracteres cai em horas.
• AES: usa PBKDF2 com salt e 4.096 iterações. Muito mais lento de crackear — mas não impossível se a senha for fraca.

A Microsoft está expandindo o padrão de AES-only no Kerberos ao longo de 2026, o que torna o Kerberoasting mais difícil. Senhas fracas ainda caem mesmo com AES, então a mudança de algoritmo não substitui uma política de senha robusta.

Contas mais visadas: quais têm SPN no seu domínio?

Qualquer conta de serviço com SPN é alvo em potencial. As mais comuns:

• Contas de serviço do SQL Server (MSSQL/servidor.dominio.local)
• Contas de serviço do SharePoint, Exchange e IIS
• Contas de serviço de aplicações legadas que nunca tiveram a senha trocada

O problema clássico: essas contas costumam ter senhas antigas, criadas antes das políticas modernas, e nunca rotacionadas porque "o serviço para se trocar a senha".

Como se defender do Kerberoasting

1. Use Group Managed Service Accounts (gMSA)

gMSAs são contas de serviço gerenciadas pelo próprio AD, com senhas de 120 caracteres aleatórios rotacionadas automaticamente. Não há senha conhecida por humano — impossível de crackear na prática. Se o serviço suporta gMSA, migre agora.

2. Senhas longas em contas de serviço com SPN

Se não puder usar gMSA, use passphrases de pelo menos 25 caracteres. Com AES e uma senha longa, o cracking se torna computacionalmente inviável.

3. Habilite AES-only para contas de serviço

Nas propriedades da conta no AD: marque "This account supports Kerberos AES 128/256 bit encryption" e desmarque RC4. Remove o vetor mais rápido de cracking.

4. Monitore requisições de TGS em volume

Um usuário solicitando TGS para dezenas de SPNs em segundos é anomalia clara. No Windows Event Log, o evento 4769 (Kerberos Service Ticket Operation) com código de resultado 0x0 para múltiplos serviços é sinal de enumeração ativa. Configure alertas no seu SIEM para esse padrão.

5. Princípio do menor privilégio para contas de serviço

Contas de serviço não devem ter privilégios de Domain Admin nem acesso irrestrito. Limite ao mínimo necessário — se a conta for comprometida, o raio de explosão precisa ser controlado.

Kerberoasting no contexto de um ataque real

Kerberoasting raramente é o primeiro passo. Normalmente aparece depois de uma entrada inicial — um phishing bem-sucedido, um LLMNR poisoning que entregou credenciais de domínio, ou um Pass-the-Hash que escalou o acesso lateral. Com uma conta de domínio em mãos, o atacante usa Kerberoasting para chegar a uma conta de serviço com acesso a dados sensíveis ou ao próprio Domain Controller.

Para reforçar a camada de acesso remoto enquanto revisa as contas internas, veja também como proteger o RDP contra força bruta e ataques de senha — outro vetor clássico de entrada em ambientes Windows.

O ataque é classificado no MITRE ATT&CK como T1558.003 e aparece regularmente em relatórios de incidentes de ransomware como técnica de escalada de privilégios antes do payload final. A combinação de gMSA, AES-only, senhas longas e monitoramento do evento 4769 torna o Kerberoasting inviável na prática — mesmo que o atacante já tenha um pé no domínio.