Agora o primeiro ataque específico do AD, e um dos mais elegantes e usados: o Kerberoasting. Ele explora uma característica de design do protocolo Kerberos — não um bug — para obter material que permite crackear senhas de contas de serviço offline. É poderoso porque um usuário de domínio comum, sem privilégios especiais, consegue executá-lo, e porque contas de serviço frequentemente têm privilégios elevados. Entender o Kerberoasting exige uma noção de como o Kerberos funciona, então vamos construí-la. Laboratório AD, sempre.
Uma noção de Kerberos e seus tíquetes
Primeiro, uma noção acessível do Kerberos, o protocolo de autenticação do AD. A ideia central é evitar enviar senhas pela rede repetidamente, usando um sistema de "tíquetes". Simplificadamente: quando você loga, o DC (atuando como centro de distribuição de chaves) te dá um "tíquete inicial" (TGT) que prova quem você é. Depois, quando você quer acessar um serviço específico, você usa o TGT para pedir ao DC um "tíquete de serviço" (TGS) para aquele serviço. O detalhe crucial para o ataque: esse tíquete de serviço é cifrado com o hash da senha da conta que roda o serviço. Guarde isso — é a semente do Kerberoasting.
SPN: o tíquete cifrado com o hash do serviço
Os serviços no AD são identificados por SPNs (Service Principal Names), e associados a contas de serviço. Aqui está a característica explorável: qualquer usuário autenticado do domínio pode solicitar um tíquete de serviço (TGS) para qualquer SPN — é assim que o Kerberos funciona, por design. E como esse tíquete vem cifrado com o hash da senha da conta de serviço, o atacante que o solicita recebe, na prática, algo derivado da senha da conta de serviço — que ele pode levar para casa e atacar offline. O Kerberoasting é exatamente isto: solicitar tíquetes de serviço para os SPNs do domínio, extrair a parte cifrada, e crackeá-la offline (com Hashcat, aula Cracking offline com John e Hashcat: quebrando hashes em escala) para recuperar a senha em texto claro da conta de serviço.
O fluxo, conceitualmente:
# 1. enumerar contas de serviço (SPNs) no domínio — qualquer usuário pode
# 2. solicitar tíquetes de serviço (TGS) para esses SPNs
# (ferramentas: GetUserSPNs do Impacket, Rubeus)
GetUserSPNs.py dominio/usuario:senha -request
# 3. extrair os tíquetes (hashes) e crackear offline
hashcat -m 13100 hashes_tgs.txt rockyou.txt
Três razões para ser tão eficaz
Por que isso é tão eficaz? Três razões que se somam. Primeiro, qualquer usuário comum pode fazê-lo — não requer privilégio, apenas uma credencial de domínio válida. Segundo, é um ataque offline — depois de obter os tíquetes, você craqueia sem tocar no domínio, sem gerar tentativas de login, sem risco de bloqueio, silenciosamente (contrastando com a força bruta online da aula Brute force online com Hydra: atacando serviços vivos). Terceiro, e crucial: contas de serviço frequentemente têm senhas fracas e privilégios altos. Elas costumam ser configuradas por administradores com senhas que raramente mudam (às vezes definidas há anos) e frequentemente pertencem a grupos privilegiados. Craquear uma conta de serviço pode entregar credenciais poderosas — às vezes um caminho direto para privilégios administrativos.
AS-REP Roasting, o ataque irmão
Um ataque irmão e complementar é o AS-REP Roasting, que explora uma condição relacionada. No Kerberos, há uma opção chamada "pré-autenticação" que normalmente protege a etapa inicial. Contas configuradas sem a pré-autenticação Kerberos exigida (uma configuração que existe por compatibilidade) permitem que um atacante solicite material de autenticação para elas e o receba cifrado com o hash da senha — de novo, algo craqueável offline —, e desta vez sem sequer precisar de credenciais válidas no caso de contas conhecidas. O AS-REP Roasting mira contas com essa configuração fraca; o Kerberoasting mira contas de serviço com SPN. Ambos compartilham a essência: obter, legitimamente, material cifrado com o hash de uma senha e levá-lo para cracking offline. São o mesmo raciocínio aplicado a duas facetas do Kerberos.
Explora o design, não uma falha
O ponto conceitual: esses ataques exploram o funcionamento normal do Kerberos, não falhas. O protocolo precisa entregar tíquetes cifrados com hashes de senhas de serviço — é assim que ele autentica. A vulnerabilidade emerge da combinação desse design com senhas fracas de contas de serviço. Isso ilustra um tema recorrente do AD: muitos ataques não são "bugs" a corrigir com um patch, mas consequências da arquitetura que só se mitigam com configuração e higiene corretas. É por isso que a defesa do AD é tão sobre disciplina operacional contínua, não apenas atualização.
Senha forte de serviço e gMSA
Do lado defensivo, as contramedidas contra Kerberoasting e AS-REP Roasting são específicas e claras: senhas fortes e longas para contas de serviço (a defesa central — se a senha não craqueia offline, obter o tíquete é inútil; senhas de 25+ caracteres tornam o cracking inviável); usar Managed Service Accounts (gMSA) — contas de serviço gerenciadas cujas senhas são longas, complexas e rotacionadas automaticamente pelo sistema, eliminando o problema na raiz; exigir pré-autenticação Kerberos em todas as contas (fechando o AS-REP Roasting); menor privilégio para contas de serviço (para que, mesmo craqueada, uma conta não dê muito poder); e monitorar solicitações anômalas de tíquetes (um usuário solicitando TGS para muitos SPNs de uma vez é a assinatura do Kerberoasting). A lição: contas de serviço são um ponto cego clássico de segurança, e tratá-las com o rigor de senha que se aplicaria a administradores é essencial.
Fontes e leituras recomendadas
- HackTricks — seções de "Kerberoasting" e "AS-REP Roasting"
- Impacket (GetUserSPNs) e Rubeus — ferramentas dos ataques
- Documentação da Microsoft sobre Kerberos, SPNs e gMSA (contexto defensivo)
- Laboratório GOAD — cenários de Kerberoasting para praticar
Exercícios
-
No Kerberos, o que é um tíquete de serviço (TGS) e por que o fato de ele ser cifrado com o hash da conta de serviço é a base do Kerberoasting?
✓ Resposta:O TGS é o tíquete que autoriza o acesso a um serviço específico, entregue pelo DC mediante o TGT do usuário. Ele é cifrado com o hash da senha da conta que roda o serviço; assim, obter o TGS dá ao atacante material derivado dessa senha, que pode ser atacado offline — a base do Kerberoasting.
-
Que característica de design do Kerberos permite a qualquer usuário comum executar o Kerberoasting?
✓ Resposta:Por design, qualquer usuário autenticado do domínio pode solicitar um tíquete de serviço (TGS) para qualquer SPN. Como o TGS vem cifrado com o hash da conta de serviço, essa solicitação legítima já entrega o material craqueável.
-
Por que o Kerberoasting é tão eficaz? Cite as três razões que se somam.
✓ Resposta:(1) Qualquer usuário comum pode fazê-lo, sem privilégio especial; (2) é um ataque offline, silencioso, sem gerar tentativas de login nem risco de bloqueio; (3) contas de serviço frequentemente têm senhas fracas e raramente alteradas, além de privilégios altos, então craqueá-las pode entregar acesso poderoso.
-
Qual a essência comum entre Kerberoasting e AS-REP Roasting, e qual configuração o AS-REP Roasting explora?
✓ Resposta:A essência comum é obter, de forma legítima, material cifrado com o hash de uma senha e levá-lo para cracking offline. O AS-REP Roasting explora contas configuradas sem a pré-autenticação Kerberos exigida, permitindo solicitar e receber esse material craqueável (às vezes sem credenciais válidas).
-
Cite a contramedida central contra o Kerberoasting e explique como as gMSA resolvem o problema na raiz.
✓ Resposta:A contramedida central são senhas fortes e longas para contas de serviço, que tornam o cracking offline inviável. As gMSA (Managed Service Accounts) resolvem na raiz porque usam senhas longas, complexas e rotacionadas automaticamente pelo sistema, eliminando as senhas fracas e estáticas que o ataque explora.
