Operação Kerberos

SPN significa Service Principal Name — é basicamente o endereço oficial de um serviço dentro do domínio. Funciona como uma etiqueta que diz: "esse serviço existe, está rodando nessa máquina, nessa porta, e pertence a essa conta."

No laboratório, o SPN configurado na conta svc_sql é:

Kerberos é o sistema de autenticação do Active Directory. Em vez de enviar a senha pela rede, ele usa tickets temporários. Clique em cada mensagem para entender o que ela faz.

💡 Clique nas setas para ver a explicação de cada etapa

No TGS-REP (etapa ④), o ticket de serviço é cifrado com uma chave de longo prazo derivada do segredo da conta de serviço. No caso RC4-HMAC do laboratório, essa chave está ligada ao hash NT da senha. Isso permite testar palpites de senha offline sem enviar cada tentativa ao DC.

O SPN viabiliza a solicitação do ticket; a senha fraca torna a recuperação offline mais provável; o privilégio excessivo aumenta o impacto. As duas últimas condições não são necessárias para solicitar o TGS, mas tornam o cenário muito mais grave.

Importante: o atacante não precisa ser Domain Admin. Uma conta comum, após se autenticar, pode obter um TGT e solicitar tickets de serviço para SPNs registrados.

Antes de qualquer operação, confirmar que o Kali alcança o Domain Controller.

✔ Conectividade confirmada. Rota livre até o Domain Controller.

Com as credenciais de alice em mãos — obtidas via phishing ou ataque de senha fraca — o atacante lista todos os usuários do domínio a partir do Kali.

↑ svc_sql aparece no domínio. Próximo passo: verificar se tem SPN.

Este é o coração do ataque. GetUserSPNs encontra contas com SPN e requisita o ticket criptografado.

O terminal valida parâmetros, respeita a ordem das etapas e explica tentativas incorretas. A fase só termina quando o hash estiver salvo e confirmado.

Uma lista pequena de senhas candidatas. Em ambientes reais, wordlists chegam a bilhões de entradas.

O modo -m 13100 é específico para hashes Kerberos TGS-REP (Kerberoasting).

Confira a wordlist, execute o Hashcat no modo correto e valide a senha recuperada.

⚠️ No cenário simulado, a conta de Alice foi tratada como comprometida e usada como ponto de entrada. A senha fraca de svc_sql foi recuperada e, como a conta estava em Domain Admins, essa credencial poderia levar ao comprometimento do domínio. O laboratório não executou essa etapa final.

Aplique menor privilégio, valide os grupos, rotacione a senha comprometida e consulte os eventos Kerberos.

• Remover svc_sql do grupo Domain Admins

  Princípio do menor privilégio. Contas de serviço não precisam de acesso total ao domínio.
• Trocar para senha longa, aleatória e única

  Senhas longas, aleatórias e exclusivas elevam fortemente o custo da quebra offline e retiram a conta de wordlists previsíveis.
• Migrar para gMSA (Group Managed Service Account)

  O AD gerencia uma senha longa e aleatória e, por padrão, usa intervalo de 30 dias. Isso reduz muito o risco de senha humana fraca, sem eliminar a necessidade de proteger quem pode recuperar a senha gerenciada.
• Remover SPNs desnecessários

  SPN sem serviço ativo é superfície de ataque sem utilidade. Audite e remova periodicamente.
• Monitorar Event ID 4769 — TGS Request

  RC4 (0x17) em tickets de serviço merece investigação, principalmente quando combinado com volume, origem ou contas incomuns. Isoladamente, não prova Kerberoasting.
• Desabilitar criptografia RC4 onde possível

  Prefira AES após validar compatibilidade. AES aumenta o custo da quebra em relação ao RC4, mas senha forte e menor privilégio continuam indispensáveis.
• Auditar contas com senha que nunca expira

  Para contas sem gMSA, defina uma política de senha longa e exclusiva, monitore exposição e faça rotação planejada quando necessário.
• Treinar usuários contra phishing e senhas fracas

  No cenário, Alice representa uma credencial previamente comprometida. Conscientização e MFA reduzem phishing e abuso de senha, mas não substituem a proteção das contas de serviço.

Com a política Audit Kerberos Service Ticket Operations habilitada no DC, use o evento 4769 para investigar solicitações TGS. O filtro abaixo é um exemplo inicial e deve ser correlacionado com conta, serviço, origem, volume e padrão histórico:

Kerberoasting não é um exploit sofisticado. É um abuso de comportamento legítimo do protocolo Kerberos. O ponto de entrada foi a conta de uma usuária comum — alice — comprometida via phishing ou senha fraca. A partir daí, bastou solicitar legitimamente um ticket de serviço, tentar recuperar a senha offline e explorar o privilégio excessivo da conta de serviço. A defesa precisa atuar em todas as camadas: conscientização de usuários, senhas fortes, menor privilégio e monitoramento ativo.

🔬 Ambiente: lab.local · Hyper-V · Windows Server + Kali Linux
🛠️ Ferramentas: impacket, hashcat
📋 Escopo: laboratório acadêmico controlado

Conteúdo revisado com base na especificação do Kerberos e na documentação oficial da Microsoft:

• RFC 4120 — Kerberos Network Authentication Service (V5)
• Microsoft — Service Principal Names (SPNs)
• Microsoft — Audit event 4769
• Microsoft — Group Managed Service Accounts (gMSA)
• Microsoft — Advanced audit policy configuration