Active Directory Pentest: Kerberoasting Passo a Passo em Lab GOAD

Kerberoasting e o ataque que paga aluguel em quase todo engagement interno, porque nao precisa de nada alem de uma unica conta de dominio valida e transforma tickets de servico pedidos em silencio em cracking de senha offline, sem privilegios especiais e sem exploit barulhento. Neste guia voce monta um lab com o GOAD, o Game of Active Directory da Orange Cyberdefense, e roda a cadeia completa: entender como o Kerberos emite tickets, enumerar service principal names, pedir os tickets, quebra-los offline com hashcat e depois fechar o ciclo com a deteccao e o hardening que de fato o param. Tudo roda contra seus proprios domain controllers, numa rede isolada, sob autorizacao escrita; o objetivo e fluencia no mecanismo, nao um trofeu.

Como funciona a autenticacao Kerberos#

Kerberos e um protocolo de tickets com tres partes: o cliente, o Key Distribution Center que vive no domain controller, e o servico. Primeiro o cliente prova quem e com um AS-REQ e recebe um Ticket Granting Ticket, cifrado com a chave da conta krbtgt para que so o KDC leia. Quando o cliente quer alcancar um servico, apresenta o TGT num TGS-REQ e pede um ticket de servico; o KDC responde com um TGS cifrado usando a chave propria da conta de servico, derivada da senha dessa conta. O cliente entrega esse ticket ao servico, que o decifra para provar autorizacao. O detalhe critico e que o KDC da a qualquer usuario autenticado um ticket de servico para qualquer servico, e esse ticket esta cifrado com uma chave derivada de uma senha escolhida por um humano.

Por que Kerberoasting funciona#

Esse unico fato de design e toda a vulnerabilidade. Qualquer usuario de dominio pode pedir um TGS para qualquer conta com um Service Principal Name registrado, e o ticket devolvido esta cifrado com a chave derivada da senha da conta de servico. Leve o ticket offline e voce pode brute-forcar a senha sem tocar o dominio de novo, porque a verificacao acontece no seu proprio hardware. Piora quando o ticket volta como RC4 (etype 23, o hash $krb5tgs$23$), que quebra muito mais rapido que AES. Contas de servico sao as vitimas perfeitas: costumam carregar senhas fracas, antigas e postas por humanos, raramente rotacionam, e frequentemente estao superprivilegiadas porque alguem lhes deu domain admin ha anos para um installer funcionar.

Montando o lab GOAD#

O GOAD entrega uma floresta Active Directory multi-dominio deliberadamente vulneravel, construida para exatamente essa pratica. Provisione com Ludus ou pelo caminho de Vagrant e Ansible num hypervisor com RAM suficiente, porque uma floresta realista quer varias VMs de Windows Server e um host de ataque Kali ou Windows. Mantenha todo o ambiente numa rede isolada sem rota para producao ou internet, porque o GOAD e intencionalmente fraco e nunca deve tocar nada real. Uma vez que os domain controllers estao no ar e voce tem uma conta de dominio de baixo privilegio, voce tem a posicao inicial exata de um atacante que acabou de phishar um unico usuario de helpdesk, o ponto de entrada realista que o Kerberoasting foi feito para explorar.

Enumeracao: encontrar as contas de servico#

Voce nao rostisa o que nao ve, entao primeiro enumere contas com um SPN. No Windows, setspn -T domain -Q */* lista os service principal names registrados, enquanto o Get-DomainUser -SPN do PowerView filtra direto contas de usuario com um SPN definido, que sao os alvos quebraveis. No Linux, um ldapsearch autenticado por servicePrincipalName=* faz o mesmo. Jogue o dominio no BloodHound e ele nao so lista usuarios kerberoasteaveis mas mostra quais pertencem a grupos de alto valor, para voce priorizar a conta de servico que por acaso tambem esta em Domain Admins. Anote os tipos de cifra que cada conta suporta; uma conta que ainda permite RC4 e o alvo mais mole do tabuleiro.

Pedir e extrair os tickets#

Escolhidos os alvos, peca os tickets. De um foothold no Windows, Rubeus.exe kerberoast /outfile:hashes.txt pede um TGS para cada conta kerberoasteavel e escreve os hashes em formato quebravel; adicione /tgtdeleg ou filtre por usuario para ficar quieto. No Linux com Impacket, GetUserSPNs.py DOMAIN/user:password -dc-ip 10.0.0.10 -request faz o mesmo em um comando e despeja os blobs $krb5tgs$. Se puder, mire de proposito contas que respondem com hashes RC4; se o KDC devolver AES etype 18 ($krb5tgs$18$), ainda da para quebrar, so muito mais devagar. Cada hash que voce junta fica agora completamente desconectado da rede, exatamente por isso o proximo passo acontece na sua propria maquina.

Quebrar os tickets offline#

Offline e onde o Kerberoasting fica cruel. De os hashes ao hashcat com o modo -m 13100 para tickets TGS RC4 ou -m 19700 para AES, aponte para uma wordlist forte como a rockyou mais regras direcionadas, e deixe a GPU trabalhar. Uma senha de servico fraca cai em segundos; uma senha humana de doze caracteres com estrutura previsivel muitas vezes cai em horas. Como a verificacao e local, nao ha lockout, nem rate limit, nem entrada de log no dominio para te entregar. Essa assimetria e todo o ponto: a politica de senhas do defensor e a unica coisa entre uma unica conta de baixo privilegio e uma credencial de servico quebrada que pode ter muito mais acesso do que a conta com que voce comecou.

Pos-crack: transformar uma senha em poder de dominio#

Uma conta de servico quebrada raramente e o fim; e um pivot. Faca login como a conta de servico e rode o BloodHound de novo a partir do contexto dela para mapear o que ela alcanca, porque contas de servico rotineiramente tem admin local em muitos servidores ou ficam em grupos privilegiados. Se a conta e um servico de SQL ou de backup, ela pode ter caminhos ate um domain controller via delegacao ou abuso de DACL. Por isso o Kerberoasting e tao valorizado em engagements reais: converte a posicao inicial mais fraca possivel, um usuario comum, em credenciais provisionadas para maquinas e portanto confiadas muito mais do que qualquer conta humana deveria ser.

Deteccao: a visao do defensor#

Todo Kerberoast deixa rastro se voce estiver observando. O Event ID 4769 do Windows registra cada requisicao TGS, e o denunciante e o campo de tipo de cifra: uma rajada de eventos 4769 com tipo de cifra 0x17 (RC4) de um unico usuario contra muitos servicos distintos numa janela curta e a assinatura de uma rodada de rostisagem. Alerte sobre esse padrao no seu SIEM em vez de sobre eventos individuais, porque um 4769 e normal e mil num minuto nao e. A deteccao unica mais forte e um SPN honeypot: crie uma conta de servico isca com um SPN, nunca a use para nada, e dispare um alerta de severidade alta no instante em que alguem pedir o ticket dela, porque nenhum processo legitimo jamais fara isso.

Mitigacao e hardening#

O fix mira a quebrabilidade, nao a requisicao. Substitua contas de servico geridas por humanos por group Managed Service Accounts, cujas senhas de 240 caracteres geradas por maquina rotacionam automaticamente e sao praticamente impossiveis de quebrar offline. Onde um gMSA ainda nao e possivel, imponha uma senha bem longa e aleatoria em cada conta de servico e rotacione. Desative RC4 no dominio inteiro para que os tickets voltem so como AES, o que sobe o custo de cracking em ordens de magnitude, e audite cada conta de servico por privilegio desnecessario para que ate uma credencial quebrada nao leve a lugar nenhum. Ponha o SPN honeypot e a deteccao de 4769 por cima, e voce reduziu tanto a chance de um crack bem sucedido quanto o raio de dano se um acontecer.

Armadilhas e um checklist#

Os erros comuns cortam nos dois sentidos. Atacantes se entregam pedindo todos os tickets de uma vez em vez de dosar e mirar, ou perdem dias quebrando um hash AES que poderiam ter pulado por um RC4. Defensores se acham seguros porque impuseram uma politica de senhas aos usuarios enquanto suas contas de servico ainda carregam uma senha de uma decada e RC4 habilitado. Antes de chamar o dominio de endurecido, confirme que nenhuma conta de usuario permite RC4, que cada conta de servico e um gMSA ou tem uma senha longa e aleatoria, que existe um SPN honeypot que alerta, que a deteccao de anomalia 4769 esta viva, e que nenhuma conta kerberoasteavel esta num grupo privilegiado. Prove rostisando o seu proprio dominio e vendo o honeypot disparar.

Um primo proximo: AS-REP roasting#

Uma vez que o Kerberoasting encaixa, o irmao dele custa quase nada para adicionar. O AS-REP roasting mira contas com pre-autenticacao do Kerberos desabilitada, um ajuste que deixa o KDC devolver um AS-REP cifrado com a chave derivada da senha do usuario antes de o usuario ter provado qualquer coisa. Isso significa que voce pode pedir o blob dessa conta sem nenhuma credencial e quebra-lo offline exatamente como um TGS. Enumere as vitimas com Get-DomainUser -PreauthNotRequired no PowerView ou GetNPUsers.py no Impacket, depois de o hash $krb5asrep$ resultante ao modo -m 18200 do hashcat. A historia defensiva e identica em espirito: nunca desabilite a pre-autenticacao, imponha senhas fortes e alerte sobre a requisicao anomala. Rodar os dois ataques um atras do outro no GOAD ensina que toda a familia de bugs de roasting se reduz a mesma raiz, uma chave de cifra derivada de uma senha humana fraca que qualquer um pode pedir.

FAQ#

Preciso de direitos de admin para Kerberoast? Nao, e e exatamente isso que o torna perigoso. Qualquer conta de dominio autenticada pode pedir tickets de servico e leva-los offline; sem elevacao, sem exploit e sem acesso especial, por isso e um dos primeiros movimentos apos qualquer foothold.

Habilitar AES para o Kerberoasting por completo? Nao, torna muito mais dificil, nao impossivel. Tickets AES ainda podem ser pedidos e quebrados, so muito mais devagar, entao uma senha de servico fraca continua vulneravel mesmo sob AES. O fix duravel sao senhas gMSA que nenhuma wordlist vai alcancar, combinadas com least privilege para que um crack nao renda nada.

Takeaway pratico: suba o GOAD, rode a cadeia uma vez de uma unica conta de baixo privilegio ate um ticket de servico quebrado ate um pivot privilegiado, depois vire para o lado azul e construa o SPN honeypot e a deteccao de 4769 ate o seu proprio rostisamento acende-los. Kerberoasting nao e uma tecnica exotica; e uma consequencia de design do Kerberos encontrando senhas de servico fracas. Rotacione para gMSA, mate o RC4, tire privilegio e vigie a requisicao, e voce transforma um pagamento confiavel do atacante num beco sem saida.